T1557.002: ARP Cache Poisoning

ARP Cache Poisoning matters because it can let an adversary on the same local network segment place themselves between devices and observe or relay traffic. For leaders, the risk is not the ARP message itself; it is the follow-on exposure of credentials, sensitive data, or manipulated communications when local traffic is not encrypted or when monitoring does not see east-west network behavior.

Executive priority

Prioritize this as a local-network resilience and evidence question: do critical Windows, Linux, and macOS segments have controls and telemetry that can prove ARP abuse would be noticed, and is sensitive traffic encrypted even inside the network? This technique is most material where legacy or insecure protocols still carry credentials or operational data, and where SOC visibility is concentrated only at network boundaries.

Technical view

ATT&CK lists this as a sub-technique of Adversary-in-the-Middle under credential-access and collection for Linux, Windows, and macOS. Detection text is not provided for the technique, but ATT&CK relates DET0387, Detect ARP Cache Poisoning Across Linux, Windows, and macOS. SOC and detection teams should validate coverage for abnormal ARP replies, gratuitous ARP activity, duplicate IP-to-MAC mappings, rapid ARP cache changes, and endpoint ARP table inconsistencies. IR teams should treat suspected events as potential precursors to Network Sniffing or Transmitted Data Manipulation, especially when unencrypted protocols are present.

Likely telemetry

Endpoint ARP cache/table snapshots or change events from Linux, Windows, and macOS systems
Network packet captures or sensor data showing ARP requests, ARP replies, and gratuitous ARP replies on local segments
Network intrusion detection or prevention alerts for ARP spoofing/poisoning behavior
Logs or observations that show duplicate IP-to-MAC mappings or unexpected MAC address changes for key hosts
Evidence of insecure or unencrypted local traffic that could expose credentials or sensitive data if intercepted

Detection direction

Validate whether DET0387-aligned logic or equivalent analytics exist for Linux, Windows, and macOS environments.
Tune for local baseline behavior: legitimate network changes can create ARP churn, so compare alerts against known maintenance, address changes, and device moves.
Do not rely only on perimeter monitoring; ARP poisoning occurs on a local network segment and may be invisible to boundary-focused sensors.
Correlate ARP anomalies with credential-access and collection indicators, including unexpected authentication prompts, cleartext protocol use, or suspicious traffic relay patterns where telemetry exists.
Use the ATT&CK relationship to the parent Adversary-in-the-Middle technique to scope follow-on investigation, but avoid assuming data theft or manipulation without corroborating evidence.

Mitigation priorities

Encrypt sensitive information in transit so intercepted local traffic does not expose credentials or content.
Limit access to network resources so only systems and accounts with a business requirement can reach sensitive services.
Filter lateral, ingress, and egress traffic where feasible to reduce unnecessary communication paths.
Use network intrusion prevention or detection signatures where supported to identify or block ARP poisoning behavior.
Disable or remove unnecessary services, features, or programs that expose avoidable network attack surface.

Analyst notes and limits

ATT&CK associates this technique with Cleaver and LuminousMoth and cites RFC826, SANS ARP spoofing material, and the Cylance Operation Cleaver report. Those relationships support threat-informed prioritization, but they do not establish current activity or exposure in any specific environment. The most useful local analysis is a gap assessment: which local segments carry sensitive traffic, which are monitored for ARP anomalies, and which still use unencrypted protocols.

The official ATT&CK detection field for this technique is not provided. The take is therefore based on the official description, platforms, tactics, external references, and supplied relationships, including DET0387 and listed mitigations. Local architecture, encryption usage, segmentation, and telemetry availability are required to determine actual risk and coverage.

Official MITRE ATT&CK definition

ARP Cache Poisoning

Adversaries may poison Address Resolution Protocol (ARP) caches to position themselves between the communication of two or more networked devices. This activity may be used to enable follow-on behaviors such as Network Sniffing or Transmitted Data Manipulation.

The ARP protocol is used to resolve IPv4 addresses to link layer addresses, such as a media access control (MAC) address.[1] Devices in a local network segment communicate with each other by using link layer addresses. If a networked device does not have the link layer address of a particular networked device, it may send out a broadcast ARP request to the local network to translate the IP address to a MAC address. The device with the associated IP address directly replies with its MAC address. The networked device that made the ARP request will then use as well as store that information in its ARP cache.

An adversary may passively wait for an ARP request to poison the ARP cache of the requesting device. The adversary may reply with their MAC address, thus deceiving the victim by making them believe that they are communicating with the intended networked device. For the adversary to poison the ARP cache, their reply must be faster than the one made by the legitimate IP address owner. Adversaries may also send a gratuitous ARP reply that maliciously announces the ownership of a particular IP address to all the devices in the local network segment.

The ARP protocol is stateless and does not require authentication. Therefore, devices may wrongly add or update the MAC address of the IP address in their ARP cache.[2][3]

Adversaries may use ARP cache poisoning as a means to intercept network traffic. This activity may be used to collect and/or relay data such as credentials, especially those sent over an insecure, unencrypted protocol.[2]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

Filter related techniques 1 rows

Domain	ID	Name	Relationship / procedure
Enterprise	T1557	Adversary-in-the-Middle	This object subtechnique of Adversary-in-the-Middle.

Associated objects

Groups, software, and campaigns

G0003: Cleaver

Cleaver is a threat group that has been attributed to Iranian actors and is responsible for activity tracked as Operation Cleaver. [1] Strong circumstantial evidence suggests Cleaver is linked to Threat Group 2889 (TG-2889). [2]

G1014: LuminousMoth

LuminousMoth is a Chinese-speaking cyber espionage group that has been active since at least October 2020. LuminousMoth has targeted high-profile organizations, including government entities, in Myanmar, the Philippines, Thailand, and other parts of Southeast Asia. Some security researchers have concluded there is a connection between LuminousMoth and Mustang Panda based on similar targeting and TTPs, as well as network infrastructure overlaps.[1][2]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1041: Encrypt Sensitive Information Enterprise uses · Group G0003: Cleaver Enterprise subtechnique of · Technique T1557: Adversary-in-the-Middle Enterprise mitigates · Mitigation M1031: Network Intrusion Prevention Enterprise mitigates · Mitigation M1017: User Training Enterprise uses · Group G1014: LuminousMoth Enterprise mitigates · Mitigation M1042: Disable or Remove Feature or Program Enterprise detects · Detection Strategy DET0387: Detect ARP Cache Poisoning Across Linux, Windows, and macOS Enterprise mitigates · Mitigation M1035: Limit Access to Resource Over Network Enterprise mitigates · Mitigation M1037: Filter Network Traffic Enterprise

Mitigations

Mitigation direction

M1041: Encrypt Sensitive Information

Protect sensitive information at rest, in transit, and during processing by using strong encryption algorithms. Encryption ensures the confidentiality and integrity of data, preventing unauthorized access or tampering. This mitigation can be implemented through the following measures:

Encrypt Data at Rest:

- Use Case: Use full-disk encryption or file-level encryption to secure sensitive data stored on devices. - Implementation: Implement BitLocker for Windows systems or FileVault for macOS devices to encrypt hard drives.

Encrypt Data in Transit:

- Use Case: Use secure communication protocols (e.g., TLS, HTTPS) to encrypt sensitive data as it travels over networks. - Implementation: Enable HTTPS for all web applications and configure mail servers to enforce STARTTLS for email encryption.

Encrypt Backups:

- Use Case: Ensure that backup data is encrypted both during storage and transfer to prevent unauthorized access. - Implementation: Encrypt cloud backups using AES-256 before uploading them to Amazon S3 or Google Cloud.

Encrypt Application Secrets:

- Use Case: Store sensitive credentials, API keys, and configuration files in encrypted vaults. - Implementation: Use HashiCorp Vault or AWS Secrets Manager to manage and encrypt secrets.

Database Encryption:

- Use Case: Enable Transparent Data Encryption (TDE) or column-level encryption in database management systems. - Implementation: Use MySQL’s built-in encryption features to encrypt sensitive database fields such as social security numbers.

M1031: Network Intrusion Prevention

Use intrusion detection signatures to block traffic at network boundaries.

M1017: User Training

User Training involves educating employees and contractors on recognizing, reporting, and preventing cyber threats that rely on human interaction, such as phishing, social engineering, and other manipulative techniques. Comprehensive training programs create a human firewall by empowering users to be an active component of the organization's cybersecurity defenses. This mitigation can be implemented through the following measures:

Create Comprehensive Training Programs:

- Design training modules tailored to the organization's risk profile, covering topics such as phishing, password management, and incident reporting. - Provide role-specific training for high-risk employees, such as helpdesk staff or executives.

Use Simulated Exercises:

- Conduct phishing simulations to measure user susceptibility and provide targeted follow-up training. - Run social engineering drills to evaluate employee responses and reinforce protocols.

Leverage Gamification and Engagement:

- Introduce interactive learning methods such as quizzes, gamified challenges, and rewards for successful detection and reporting of threats.

Incorporate Security Policies into Onboarding:

- Include cybersecurity training as part of the onboarding process for new employees. - Provide easy-to-understand materials outlining acceptable use policies and reporting procedures.

Regular Refresher Courses:

- Update training materials to include emerging threats and techniques used by adversaries. - Ensure all employees complete periodic refresher courses to stay informed.

Emphasize Real-World Scenarios:

- Use case studies of recent attacks to demonstrate the consequences of successful phishing or social engineering. - Discuss how specific employee actions can prevent or mitigate such attacks.

M1042: Disable or Remove Feature or Program

Disable or remove unnecessary and potentially vulnerable software, features, or services to reduce the attack surface and prevent abuse by adversaries. This involves identifying software or features that are no longer needed or that could be exploited and ensuring they are either removed or properly disabled. This mitigation can be implemented through the following measures:

Remove Legacy Software:

- Use Case: Disable or remove older versions of software that no longer receive updates or security patches (e.g., legacy Java, Adobe Flash). - Implementation: A company removes Flash Player from all employee systems after it has reached its end-of-life date.

Disable Unused Features:

- Use Case: Turn off unnecessary operating system features like SMBv1, Telnet, or RDP if they are not required. - Implementation: Disable SMBv1 in a Windows environment to mitigate vulnerabilities like EternalBlue.

Control Applications Installed by Users:

- Use Case: Prevent users from installing unauthorized software via group policies or other management tools. - Implementation: Block user installations of unauthorized file-sharing applications (e.g., BitTorrent clients) in an enterprise environment.

Remove Unnecessary Services:

- Use Case: Identify and disable unnecessary default services running on endpoints, servers, or network devices. - Implementation: Disable unused administrative shares (e.g., C$, ADMIN$) on workstations.

Restrict Add-ons and Plugins:

- Use Case: Remove or disable browser plugins and add-ons that are not needed for business purposes. - Implementation: Disable Java and ActiveX plugins in web browsers to prevent drive-by attacks.

M1035: Limit Access to Resource Over Network

Restrict access to network resources, such as file shares, remote systems, and services, to only those users, accounts, or systems with a legitimate business requirement. This can include employing technologies like network concentrators, RDP gateways, and zero-trust network access (ZTNA) models, alongside hardening services and protocols. This mitigation can be implemented through the following measures:

Audit and Restrict Access:

- Regularly audit permissions for file shares, network services, and remote access tools. - Remove unnecessary access and enforce least privilege principles for users and services. - Use Active Directory and IAM tools to restrict access based on roles and attributes.

Deploy Secure Remote Access Solutions:

- Use RDP gateways, VPN concentrators, and ZTNA solutions to aggregate and secure remote access connections. - Configure access controls to restrict connections based on time, device, and user identity. - Enforce MFA for all remote access mechanisms.

Disable Unnecessary Services:

- Identify running services using tools like netstat (Windows/Linux) or Nmap. - Disable unused services, such as Telnet, FTP, and legacy SMB, to reduce the attack surface. - Use firewall rules to block traffic on unused ports and protocols.

Network Segmentation and Isolation:

- Use VLANs, firewalls, or micro-segmentation to isolate critical network resources from general access. - Restrict communication between subnets to prevent lateral movement.

Monitor and Log Access:

- Monitor access attempts to file shares, RDP, and remote network resources using SIEM tools. - Enable auditing and logging for successful and failed attempts to access restricted resources.

*Tools for Implementation*

File Share Management:

- Microsoft Active Directory Group Policies - Samba (Linux/Unix file share management) - AccessEnum (Windows access auditing tool)

Secure Remote Access:

- Microsoft Remote Desktop Gateway - Apache Guacamole (open-source RDP/VNC gateway) - Zero Trust solutions: Tailscale, Cloudflare Zero Trust

Service and Protocol Hardening:

- Nmap or Nessus for network service discovery - Windows Group Policy Editor for disabling SMBv1, Telnet, and legacy protocols - iptables or firewalld (Linux) for blocking unnecessary traffic

Network Segmentation:

- pfSense for open-source network isolation

M1037: Filter Network Traffic

Employ network appliances and endpoint software to filter ingress, egress, and lateral network traffic. This includes protocol-based filtering, enforcing firewall rules, and blocking or restricting traffic based on predefined conditions to limit adversary movement and data exfiltration. This mitigation can be implemented through the following measures:

Ingress Traffic Filtering:

- Use Case: Configure network firewalls to allow traffic only from authorized IP addresses to public-facing servers. - Implementation: Limit SSH (port 22) and RDP (port 3389) traffic to specific IP ranges.

Egress Traffic Filtering:

- Use Case: Use firewalls or endpoint security software to block unauthorized outbound traffic to prevent data exfiltration and command-and-control (C2) communications. - Implementation: Block outbound traffic to known malicious IPs or regions where communication is unexpected.

Protocol-Based Filtering:

- Use Case: Restrict the use of specific protocols that are commonly abused by adversaries, such as SMB, RPC, or Telnet, based on business needs. - Implementation: Disable SMBv1 on endpoints to prevent exploits like EternalBlue.

Network Segmentation:

- Use Case: Create network segments for critical systems and restrict communication between segments unless explicitly authorized. - Implementation: Implement VLANs to isolate IoT devices or guest networks from core business systems.

Application Layer Filtering:

- Use Case: Use proxy servers or Web Application Firewalls (WAFs) to inspect and block malicious HTTP/S traffic. - Implementation: Configure a WAF to block SQL injection attempts or other web application exploitation techniques.

Change history

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 .

ATT&CK release: 19.1
Object version: 1.1
Created: Oct 15, 2020, 12:05 UTC (UTC+00:00)
Modified: Oct 24, 2025, 17:49 UTC (UTC+00:00)
Raw hash: 96c2a0d373d46463...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.1	Oct 24, 2025, 17:49 UTC (UTC+00:00)	Current bundle	`96c2a0d373d4…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
RFC826 ARP

Plummer, D. (1982, November). An Ethernet Address Resolution Protocol. Retrieved October 15, 2020.
Open source URL
[2]
Sans ARP Spoofing Aug 2003

Siles, R. (2003, August). Real World ARP Spoofing. Retrieved October 15, 2020.
Open source URL
[3]
Cylance Cleaver

Cylance. (2014, December). Operation Cleaver. Retrieved September 14, 2017.
Open source URL
[4]
mitre-attack T1557.002
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams