Reflection Amplification T1498.002
- Tactic
- Impact
- Platforms
- Windows, IaaS, Linux, macOS
- Version
- 1.4
- Created
- 02 March 2020
- Last modified
- 24 October 2025
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.[1] This Network DoS attack may also reduce the availability and functionality of the targeted system(s) and network.
Offense vs defense T1498.002
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Reflection Amplification detection strategy DET0408
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Reflection Amplification DoS (T1498.002)
AN1140 · Windows
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
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Host StatusDC0018 | Windows:perfmon | Sudden spike in outbound throughput without corresponding inbound traffic |
| Network Connection CreationDC0082 | WinEventLog:Sysmon | EventCode=3, 22 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Interval for measuring sudden outbound spike or volume pattern |
| AmplificationProtocolPorts | List of known ports used for reflection amplification (e.g., 53/DNS, 123/NTP, 11211/Memcached) |
| PacketToByteRatio | Heuristic threshold where the response volume far outweighs the request volume |
AN1141 · Linux
Spoofed outbound packets sent to amplification services from command-line tools or scripts, combined with abnormal outbound packet volume on known reflector ports
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Host StatusDC0018 | sar:network | Outbound network saturation with minimal process activity |
| Command ExecutionDC0064 | auditd:SYSCALL | Execution of spoofing tools (e.g., hping3, nping, scapy) sending UDP packets to known amplifier ports |
| Network Traffic FlowDC0078 | NSM:Flow | Outbound UDP floods targeting common reflection services with spoofed IP headers |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Sliding interval for detecting volumetric anomalies |
| AmplificationProtocolList | Which protocols to watch (e.g., DNS, NTP, SSDP, Memcached) |
| ExecutionToolList | Set of binaries and scripts commonly abused for spoofing/reflection |
AN1142 · macOS
Command-line initiated UDP traffic bursts to external reflection amplification ports using built-in scripting or binaries with network anomalies
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | macos:unifiedlog | Execution of ping, nping, or crafted network packets via bash or python to reflection services |
| Network Traffic FlowDC0078 | macos:unifiedlog | Outbound UDP spikes to external reflector IPs |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ReflectionPorts | Ports known for reflection abuse — DNS, NTP, SSDP, Memcached |
| TrafficSpikeThreshold | How much deviation in outbound traffic constitutes a suspicious spike |
AN1143 · IaaS
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
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Host StatusDC0018 | AWS:CloudWatch | Sudden spike in network output without a corresponding inbound request ratio |
| Firewall Rule ModificationDC0051 | AWS:CloudTrail | Create egress rule allowing UDP to port 53, 123, 11211 |
| Network Traffic FlowDC0078 | AWS:VPCFlowLogs | Large outbound UDP traffic to multiple public reflector IPs |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| EgressRulePorts | Cloud security group rules permitting UDP to reflector protocols |
| OutboundToInboundRatio | Ratio threshold to flag traffic as potential reflection behavior |
| VMInstanceTagContext | Cloud metadata that can help scope anomalous behavior to development, testing, or external-facing services |
When flood volumes exceed the capacity of the network connection being targeted, it is typically necessary to intercept the incoming traffic upstream to filter out the attack traffic from the legitimate traffic. Such defenses can be provided by the hosting Internet Service Provider (ISP) or by a 3rd party such as a Content Delivery Network (CDN) or providers specializing in DoS mitigations. Depending on flood volume, on-premises filtering may be possible by blocking source addresses sourcing the attack, blocking ports that are being targeted, or blocking protocols being used for transport. As immediate response may require rapid engagement of 3rd parties, analyze the risk associated to critical resources being affected by Network DoS attacks and create a disaster recovery plan/business continuity plan to respond to incidents.