Which SIEM platforms have a T1498.002 detection rule?

df00tech provides T1498.002 (Reflection Amplification) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the T1498.002 detection?

The T1498.002 detection is rated high severity with medium confidence.

What are common false positives for T1498.002?

Common false positives for T1498.002 include: Legitimate high-traffic DNS or NTP servers receiving large volumes of resolution requests from many clients — an authoritative DNS server may see hundreds of unique source IPs per minute normally; CDN or load balancer nodes that legitimately receive high UDP traffic volumes from distributed clients; Network scanning tools (nmap, masscan) running authorized reconnaissance that contact many amplification-port hosts in bulk.

T1498.002 Microsoft Sentinel · KQL

Detect Reflection Amplification in Microsoft Sentinel

Q: What data sources are required to detect Reflection Amplification (T1498.002)?

Detecting Reflection Amplification requires the following data sources: Network Traffic: Network Traffic Flow, Network Traffic: Network Traffic Content, Microsoft Defender for Endpoint, Azure NSG Flow Logs / CommonSecurityLog.

Adversaries may attempt to cause a denial of service (DoS) by reflecting a high-volume of network traffic to a target using third-party server intermediaries (reflectors). The attacker sends UDP packets to publicly accessible servers with the victim's spoofed source IP address, causing those servers to direct large responses at the victim. This technique exploits protocols whose responses are significantly larger than requests — known as amplification. Prominent amplification vectors include DNS (ANY queries, amplification factor ~28–54x), NTP (monlist command, up to 700x), memcached UDP (up to 51,200x), SSDP (up to 30x), CLDAP/LDAP (up to 70x), and CharGen (up to 358x). Because UDP allows source IP spoofing without a three-way handshake, attackers can direct enormous response volumes at a victim with minimal bandwidth cost. Multiple compromised systems (botnets) are commonly used to multiply the effect. Impacts include network link saturation, upstream provider congestion, and complete unavailability of internet-facing services.

MITRE ATT&CK

Tactic: Impact
Technique: T1498 Network Denial of Service
Sub-technique: T1498.002 Reflection Amplification
Canonical reference: https://attack.mitre.org/techniques/T1498/002/

KQL Detection Query

Microsoft Sentinel (KQL)

kusto

let AmplificationPorts = dynamic([53, 123, 11211, 1900, 389, 5353, 161, 19, 5683, 1434, 17, 520, 1194]);
let SamplingWindow = 5m;
let InboundFloodThreshold = 500;
let UniqueSourceThreshold = 25;
// Part 1: Victim-side detection — inbound flood from reflectors (CommonSecurityLog / firewall)
// Reflectors respond FROM amplification service ports TO the spoofed victim IP
let InboundFlood =
    CommonSecurityLog
    | where TimeGenerated > ago(1h)
    | where Protocol =~ "UDP"
    | where SourcePort in (AmplificationPorts)
    | summarize
        ConnectionCount = count(),
        UniqueSourceIPs = dcount(SourceIP),
        TotalBytesReceived = sum(ReceivedBytes),
        AmplificationPortsSeen = make_set(SourcePort, 10),
        SampleSourceIPs = make_set(SourceIP, 5)
      by DestinationIP, bin(TimeGenerated, SamplingWindow)
    | where ConnectionCount > InboundFloodThreshold or UniqueSourceIPs > UniqueSourceThreshold
    | extend
        DetectionType = "Inbound Reflection Flood (Victim)",
        AttackType = case(
            AmplificationPortsSeen has "53",    "DNS Amplification",
            AmplificationPortsSeen has "123",   "NTP Amplification",
            AmplificationPortsSeen has "11211", "Memcached Amplification",
            AmplificationPortsSeen has "1900",  "SSDP Amplification",
            AmplificationPortsSeen has "389",   "CLDAP Amplification",
            AmplificationPortsSeen has "1434",  "MSSQL/SSDP Amplification",
            AmplificationPortsSeen has "161",   "SNMP Amplification",
            AmplificationPortsSeen has "5683",  "CoAP Amplification",
            AmplificationPortsSeen has "17",    "CharGen Amplification",
            "Generic Reflection Amplification"
        ),
        GbReceived = round(toreal(TotalBytesReceived) / 1073741824.0, 3)
    | project TimeGenerated, AffectedIP = DestinationIP, AttackType, DetectionType, ConnectionCount, UniqueSourceIPs, GbReceived, AmplificationPortsSeen, SampleSourceIPs;
// Part 2: Attacker/Bot-side detection — endpoint making high-volume outbound UDP to many amplification-port IPs
// This catches compromised hosts participating in a DDoS botnet
let OutboundAttack =
    DeviceNetworkEvents
    | where Timestamp > ago(1h)
    | where Protocol =~ "Udp"
    | where RemotePort in (AmplificationPorts)
    | where RemoteIPType == "Public"
    | summarize
        ConnectionCount = count(),
        UniqueDestinations = dcount(RemoteIP),
        PortsTargeted = make_set(RemotePort, 10),
        SampleDestIPs = make_set(RemoteIP, 5)
      by DeviceName, LocalIP, InitiatingProcessFileName, bin(Timestamp, SamplingWindow)
    | where UniqueDestinations > 50 or ConnectionCount > 1000
    | extend
        DetectionType = "Outbound to Amplifiers (Bot/Attacker)",
        AttackType = case(
            PortsTargeted has "53",    "DNS Amplification Sender",
            PortsTargeted has "123",   "NTP Amplification Sender",
            PortsTargeted has "11211", "Memcached Amplification Sender",
            PortsTargeted has "1900",  "SSDP Amplification Sender",
            PortsTargeted has "389",   "CLDAP Amplification Sender",
            "Generic Amplification Sender"
        ),
        GbReceived = 0.0
    | project
        TimeGenerated = Timestamp,
        AffectedIP = LocalIP,
        AttackType,
        DetectionType,
        ConnectionCount,
        UniqueSourceIPs = UniqueDestinations,
        GbReceived,
        AmplificationPortsSeen = PortsTargeted,
        SampleSourceIPs = SampleDestIPs;
InboundFlood
| union OutboundAttack
| sort by ConnectionCount desc

high severity medium confidence

Detects Reflection Amplification attacks using a dual-path approach. Path 1 uses CommonSecurityLog (firewall/NSG flow logs) to identify the victim: high-volume inbound UDP traffic originating FROM amplification service ports (DNS/53, NTP/123, Memcached/11211, SSDP/1900, CLDAP/389, etc.) from a large number of unique source IPs. Path 2 uses DeviceNetworkEvents to identify compromised hosts acting as bots: endpoints making high-volume outbound UDP connections to many unique public IPs on amplification ports. The attack type is classified by the observed amplification port. Thresholds of 500 connections or 25 unique source IPs per 5-minute window are starting points and should be tuned to the environment.

Data Sources

Network Traffic: Network Traffic FlowNetwork Traffic: Network Traffic ContentMicrosoft Defender for EndpointAzure NSG Flow Logs / CommonSecurityLog

Required Tables

CommonSecurityLogDeviceNetworkEvents

False Positives & Tuning

Legitimate high-traffic DNS or NTP servers receiving large volumes of resolution requests from many clients — an authoritative DNS server may see hundreds of unique source IPs per minute normally
CDN or load balancer nodes that legitimately receive high UDP traffic volumes from distributed clients
Network scanning tools (nmap, masscan) running authorized reconnaissance that contact many amplification-port hosts in bulk
Misconfigured or chatty IoT devices sending repeated SSDP or mDNS discovery packets that aggregate to threshold levels
Cloud environments during peak load where auto-scaling triggers many simultaneous DNS lookups from newly spawned instances

Download portable Sigma rule (.yml)

Other platforms for T1498.002

Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

Testing Methodology

Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

Test 1DNS ANY Query Amplification Probe
Expected signal: Sysmon Event ID 22 (DNS Query) if Sysmon is configured. Zeek/Bro dns.log entry showing qtype=ANY. Network flow logs showing UDP packet to dst_port=53. The response packet will be significantly larger than the query packet.
Test 2NTP Monlist Request — Amplification Vector Validation
Expected signal: Network flow log showing outbound UDP to dst_port=123. If ntpdc is used, expect a UDP packet of ~48 bytes sent and potentially a large multi-packet response if the server is vulnerable. Zeek/Bro will log this as a bro:ntp or zeek:ntp event.
Test 3Memcached UDP Statistics Request
Expected signal: Network flow log showing UDP connection to dst_port=11211. If memcached responds, the response bytes will be significantly larger than the 16-byte request. Sysmon Event ID 3 (Network Connection) if running on Windows with a memcached instance. Zeek/Bro conn.log entry with orig_bytes vs resp_bytes showing amplification ratio.
Test 4SSDP M-SEARCH Amplification Discovery
Expected signal: Network flow log showing outbound UDP to dst_ip=239.255.255.250 (multicast) dst_port=1900. Inbound UDP responses from local SSDP-capable devices to src_port=1900. Sysmon Event ID 3 (Network Connection) on Windows. Zeek/Bro conn.log showing the multicast connection.
Test 5High-Volume UDP Flood Simulation to Amplification Ports (hping3)
Expected signal: NetFlow/IPFIX records showing 1000+ UDP packets to dst_port=53 and 123 from src_ip=127.0.0.1. Sysmon Event ID 3 (Network Connection) may not capture loopback traffic — use external lab IP for Sysmon telemetry. Firewall logs or Zeek/Bro conn.log showing packet counts exceeding 1000 per minute on amplification ports.

Last updated: 2026-04-19 Research depth: deep

References (13)

Response Playbook

1. Examine the full command line and decode any Base64 content...
2. Identify the parent process chain and user context...
3. Check for concurrent network connections from the process...

Investigation Guide

Related techniques: T1027, T1105, T1562.001...
Forensic artifacts: PSReadLine history, Prefetch, ScriptBlock logs...

Atomic Red Team Tests

Test 1: Encoded command execution...
Test 2: Download cradle via Net.WebClient...

Unlock Pro Content

Get the full detection package for T1498.002 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Detect Reflection Amplification in Microsoft Sentinel

MITRE ATT&CK

KQL Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1498.002

Testing Methodology

Response Playbook

Investigation Guide

Atomic Red Team Tests

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

MITRE ATT&CK

KQL Detection Query

Data Sources

Required Tables

False Positives & Tuning

Other platforms for T1498.002

Testing Methodology

Unlock Pro Content

Related Detections

Parent Technique

Related Sub-techniques

Related Techniques

Same Tactic: Impact

Popular Detections

Get new detections in your inbox