DET0387: Detect ARP Cache Poisoning Across Linux, Windows, and macOS
DET0387 is a detection strategy for finding ARP cache poisoning activity associated with ATT&CK technique T1557.002. For leaders, the significance is that...
Analyst context for executives and security teams
DET0387 is a detection strategy for finding ARP cache poisoning activity associated with ATT&CK technique T1557.002. For leaders, the significance is that this behavior can put an adversary between devices on a local IPv4 network, creating conditions for credential access, collection, network sniffing, or transmitted data manipulation. It matters most in environments where local network trust, endpoint visibility, and incident response evidence are important to business continuity.
Executive priority
Prioritize this as a validation question for network and endpoint visibility rather than as a standalone control. Executives and security leaders should ask whether SOC and IR teams can prove they would see suspicious ARP cache changes or ARP traffic patterns across Linux, Windows, and macOS systems where those platforms are in use. The business value is stronger assurance around local-network compromise scenarios, credential exposure risk, and evidence readiness during an incident involving traffic interception or manipulation.
Technical view
The supplied ATT&CK relationship states that DET0387 detects T1557.002, ARP Cache Poisoning, which is tied to credential-access and collection tactics and applies to Linux, Windows, and macOS. Detection engineering should validate visibility into ARP behavior and endpoint ARP cache state on relevant platforms, then correlate unusual ARP-to-MAC mapping changes with affected hosts, network segments, and any follow-on signs of network sniffing or transmitted data manipulation. Because no official ATT&CK detection text is provided for this strategy, local baselining and environment-specific tuning are required.
Likely telemetry
- ARP traffic on local network segments, especially IP-to-MAC mapping changes
- Endpoint ARP cache state or change evidence from Linux, Windows, and macOS where available
- Network security monitoring data from segments where device-to-device communication is business-critical
- Host and network context linking affected IP addresses, MAC addresses, and systems
- Incident response evidence showing whether traffic interception, sniffing, or manipulation may have followed
Detection direction
- Validate that the SOC can observe ARP cache or ARP traffic anomalies on the relevant local network segments, not only north-south perimeter traffic.
- Tune detections around unexpected or conflicting IPv4-to-MAC address mappings while accounting for legitimate network changes that may create false positives.
- Correlate suspected ARP cache poisoning with the related ATT&CK context: credential access, collection, Network Sniffing, and Transmitted Data Manipulation indicators where telemetry exists.
- Check platform coverage explicitly for Linux, Windows, and macOS endpoints, because the related technique lists those platforms but the detection strategy itself provides no platform field.
- Document blind spots where unmanaged endpoints, isolated subnets, or lack of local network monitoring would prevent confident detection.
Mitigation priorities
- Start by inventorying where local IPv4 network trust is business-critical and where ARP visibility is currently absent.
- Ensure endpoint and network monitoring can preserve evidence needed by SOC and incident response teams during suspected traffic interception events.
- Use network segmentation and access control priorities to reduce the blast radius of local-network positioning scenarios where appropriate.
- Establish response playbooks for validating conflicting ARP mappings, identifying affected devices, and assessing possible credential or data exposure.
- Maintain compliance and audit evidence showing which segments and platforms have monitoring coverage and which require compensating controls.
Analyst notes and limits
This take is based on the detection strategy metadata and its ATT&CK relationship to T1557.002 ARP Cache Poisoning. The object name references Linux, Windows, and macOS, and the related technique lists those platforms. No official description or detection logic was supplied, so recommendations focus on validation questions, telemetry classes, and coverage gaps rather than specific signatures.
ATT&CK provided no official detection text, no tactics, and no platforms directly on the DET0387 object. The technical scope is derived from the relationship to T1557.002 and its supplied description. Local network architecture, endpoint management coverage, and sensor placement are required to determine actual detection capability.
Detect ARP Cache Poisoning Across Linux, Windows, and macOS
No official description is available in the imported ATT&CK source object.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1557.002 | ARP Cache Poisoning Sub-technique | This object detects ARP Cache Poisoning. |
All related ATT&CK context
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 | 3ab419e43b03… |
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 DET0387Open 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.