T1498.002 Google Chronicle · YARA-L

Detect Reflection Amplification in Google Chronicle

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/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule t1498_002_reflection_amplification_inbound {
  meta:
    author           = "df00tech Detection Engineering"
    description      = "Detects UDP reflection amplification DDoS attacks — high-volume inbound UDP flood from known amplification service ports targeting a single victim IP within a 5-minute window"
    mitre_attack_tactic   = "Impact"
    mitre_attack_technique = "T1498.002"
    mitre_attack_technique_name = "Network Denial of Service: Reflection Amplification"
    severity         = "HIGH"
    confidence       = "HIGH"
    rule_version     = "1.0"

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.network.ip_protocol = "UDP"
    $e.principal.port in (
      53, 123, 11211, 1900, 389, 5353, 161, 17, 19, 5683, 1434, 520
    )
    // Reflectors are public internet IPs — exclude RFC1918 sources
    not net.ip_in_range_cidr($e.principal.ip, "10.0.0.0/8")
    not net.ip_in_range_cidr($e.principal.ip, "172.16.0.0/12")
    not net.ip_in_range_cidr($e.principal.ip, "192.168.0.0/16")
    not net.ip_in_range_cidr($e.principal.ip, "127.0.0.0/8")
    $victim_ip = $e.target.ip

  match:
    $victim_ip over 5m

  outcome:
    $connection_count     = count($e.metadata.id)
    $unique_source_ips    = count_distinct($e.principal.ip)
    $total_bytes_received = sum($e.network.received_bytes)
    $gb_received          = math.round(sum($e.network.received_bytes) / 1073741824.0, 3)
    $amplification_ports  = array_distinct($e.principal.port)

  condition:
    #e > 500
}
critical severity high confidence

Chronicle YARA-L 2.0 rule detecting inbound UDP reflection amplification DDoS attacks (T1498.002). Monitors UDM NETWORK_CONNECTION events for high-volume UDP traffic sourced from known amplification service ports (DNS/53, NTP/123, Memcached/11211, SSDP/1900, CLDAP/389, mDNS/5353, SNMP/161, QOTD/17, CharGen/19, CoAP/5683, MSSQL/1434, RIP/520) targeting a single victim IP. Source RFC1918 addresses are excluded to reduce false positives from internal infrastructure. Triggers when more than 500 UDP connections from amplification ports reach a single destination IP within 5 minutes. Outcome fields expose connection count, unique source IP count, total bytes received, and observed amplification ports for alert enrichment.

Data Sources

Chronicle UDM NETWORK_CONNECTION events from any network log sourceFirewall/NGFW log feeds ingested into Chronicle (Palo Alto, Fortinet, Check Point)Network Detection and Response (NDR) platforms forwarding to Chronicle (Darktrace, ExtraHop, Vectra)Zeek/Suricata network sensor logs via Chronicle forwarder agentCloud VPC flow logs normalized to UDM (Google Cloud, AWS, Azure via Chronicle ingestion)

Required Tables

UDM NETWORK_CONNECTION event type

False Positives & Tuning

  • Organizations operating public-facing DNS infrastructure — authoritative nameservers or high-throughput resolvers with public IPs will receive many UDP/53 responses from external clients that match the flood pattern; allowlist known DNS server target IPs in the rule or add a reference list exclusion
  • NTP stratum servers responding to large client populations — time servers experiencing synchronization bursts from many clients simultaneously can generate high volumes of UDP/123 connections from diverse source IPs that trigger the 500-connection threshold
  • Authorized security testing and DDoS simulation exercises — Chronicle detection exclusions or reference list-based suppression should be applied for known red team source and target IP ranges during scheduled test windows
  • Multi-tenant cloud platforms with shared egress or anycast addressing — traffic from CDN PoPs or cloud NAT gateways may appear as high-volume UDP flows from many sources to a single aggregation point, inflating connection counts beyond the threshold
  • VOIP and real-time media platforms — SIP/RTP infrastructure receiving high volumes of UDP media streams may incidentally expose source ports matching amplification port ranges, particularly UDP/5353 in mDNS-aware environments
Download portable Sigma rule (.yml)

Other platforms for T1498.002


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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

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

Related Detections