Cross-source coverage

T1498.002 / ATT&CK

Network Denial of Service: Reflection Amplification

1 rule across 1 source.

From MITRE ATT&CK 19.2

Adversaries may attempt to cause a denial of service (DoS) by reflecting a high-volume of network traffic to a target. This type of Network DoS takes advantage of a third-party server intermediary that hosts and will respond to a given spoofed source IP address. This third-party server is commonly termed a reflector. An adversary accomplishes a reflection attack by sending packets to reflectors with the spoofed address of the victim. Similar to Direct Network Floods, more than one system may be used to conduct the attack, or a botnet may be used. Likewise, one or more reflectors may be used to focus traffic on the target. This Network DoS attack may also reduce the availability and functionality of the targeted system(s) and network.

Reflection attacks often take advantage of protocols with larger responses than requests in order to amplify their traffic, commonly known as a Reflection Amplification attack. Adversaries may be able to generate an increase in volume of attack traffic that is several orders of magnitude greater than the requests sent to the amplifiers. The extent of this increase will depending upon many variables, such as the protocol in question, the technique used, and the amplifying servers that actually produce the amplification in attack volume. Two prominent protocols that have enabled Reflection Amplification Floods are DNS and NTP, though the use of several others in the wild have been documented. In particular, the memcache protocol showed itself to be a powerful protocol, with amplification sizes up to 51,200 times the requesting packet.

Tactics
Impact
Platforms
Windows · IaaS · Linux · macOS
Telemetry
WinEventLog:SysmonWindows:perfmonauditd:SYSCALLNSM:Flowsar:networkmacos:unifiedlogAWS:CloudTrailAWS:VPCFlowLogsAWS:CloudWatch

How MITRE says to detect it DET0408

Detection Strategy for Reflection Amplification DoS (T1498.002)

Windows Analytic 1140

Outbound spoofed traffic to known amplification protocols (e.g., DNS, NTP, Memcached) combined with abnormal network traffic volume targeting remote reflectors, resulting in disproportionate traffic returned to a victim

  • WinEventLog:Sysmon EventCode=3, 22
  • Windows:perfmon Sudden spike in outbound throughput without corresponding inbound traffic

Linux Analytic 1141

Spoofed outbound packets sent to amplification services from command-line tools or scripts, combined with abnormal outbound packet volume on known reflector ports

  • auditd:SYSCALL Execution of spoofing tools (e.g., hping3, nping, scapy) sending UDP packets to known amplifier ports
  • NSM:Flow Outbound UDP floods targeting common reflection services with spoofed IP headers
  • sar:network Outbound network saturation with minimal process activity

macOS Analytic 1142

Command-line initiated UDP traffic bursts to external reflection amplification ports using built-in scripting or binaries with network anomalies

  • macos:unifiedlog Execution of ping, nping, or crafted network packets via bash or python to reflection services
  • macos:unifiedlog Outbound UDP spikes to external reflector IPs

IaaS Analytic 1143

Cloud-hosted VM or container generates spoofed UDP requests to third-party services on known amplifier ports, with high outbound-to-inbound traffic ratios in VPC Flow Logs

  • AWS:CloudTrail Create egress rule allowing UDP to port 53, 123, 11211
  • AWS:VPCFlowLogs Large outbound UDP traffic to multiple public reflector IPs
  • AWS:CloudWatch Sudden spike in network output without a corresponding inbound request ratio

View on attack.mitre.org ↗

splunk/security_content

1 rule
Detection Severity Format
Large Volume of DNS ANY Queries Undefined SPL

Detection rules belong to the projects that publish them and remain under their own licenses. This site indexes and links to them; it claims no rights in them.