AN1140: 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
Analyst context for executives and security teams
This analytic describes a network pattern consistent with reflection/amplification abuse: spoofed outbound traffic toward protocols such as DNS, NTP, or Memcached, followed by disproportionate traffic being reflected at a victim. For leaders, the value is in validating whether the organization can see and control spoofed egress and abnormal traffic volumes before they become an availability, abuse, or incident-response problem.
Executive priority
Prioritize this as an operational resilience and network governance question: can the business prove that Windows-associated network activity and boundary controls prevent or reveal spoofed outbound traffic to amplification services? The audit and risk value comes from evidence of egress filtering, volume monitoring, and incident procedures for abnormal reflector-related traffic. Because no ATT&CK relationships or active exploitation context are supplied, this should be treated as a detection-control validation item rather than a claim of current threat activity.
Technical view
For SOC, detection engineering, and IR teams, validate visibility for Windows-platform network activity and perimeter traffic involving DNS, NTP, and Memcached-like amplification protocols. The analytic hinges on correlating outbound spoofed traffic with abnormal traffic volume toward remote reflectors and disproportionate traffic returned to a victim. Since ATT&CK provides no official detection logic, teams should define local baselines, confirm whether spoofed source detection is possible at network boundaries, and document where host telemetry alone is insufficient.
Likely telemetry
- Network flow records such as NetFlow or equivalent egress/ingress metadata
- Firewall, router, proxy, or gateway logs showing outbound traffic to DNS, NTP, Memcached, or similar services
- Packet metadata or sampled packet capture where available to assess source address validity
- Windows host network connection telemetry where Windows systems are potential sources or observation points
- Traffic-volume baselines for outbound reflector-bound traffic and inbound disproportionate return traffic
Detection direction
- Validate whether monitoring can distinguish legitimate DNS, NTP, or Memcached use from abnormal high-volume reflector-directed traffic.
- Confirm that egress points can identify or block spoofed source addresses; many host-only data sources will not prove spoofing by themselves.
- Tune against local service baselines to reduce false positives from legitimate infrastructure, time synchronization, caching, or DNS resolver activity.
- Correlate outbound protocol spikes with remote reflector patterns and any disproportionate return traffic to a victim, as described by the analytic.
- Document visibility gaps caused by unmanaged network segments, encrypted/aggregated flow collection, missing perimeter logs, or lack of packet-level evidence.
Mitigation priorities
- Start with anti-spoofing and egress filtering at network boundaries so internal systems cannot emit traffic with invalid source addresses.
- Restrict and monitor use of amplification-prone protocols to approved servers and business purposes.
- Apply rate limits or segmentation where high-volume DNS, NTP, or Memcached traffic is not expected.
- Maintain incident-response runbooks for abnormal reflector-related traffic, including escalation paths for network operations and service owners.
- Retain compliance-ready evidence showing that boundary controls, logging, and alert review are operating as intended.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and has no tactic or relationship context. The practical emphasis is therefore on validating telemetry and control coverage for the described network pattern rather than mapping it to a broader intrusion chain.
Official detection logic is not provided. Relationship context is absent. The only supplied platform is Windows, but the described behavior is primarily network-observable, so local architecture and telemetry determine how much can actually be detected or proven.
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
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | f21ef61852e6… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN1140Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.