How One SOC Team's ARP Audit Stopped a Lateral Movement Attack That Had Been Hiding for Weeks

For nineteen days, the threat actor moved. Quietly, methodically, and largely undetected, they traversed internal network segments of a mid-sized financial services organization headquartered in the Midwest. The intrusion was not discovered through an endpoint detection alert, a firewall anomaly, or a threat intelligence feed. It was discovered because a senior analyst, preparing for a routine quarterly audit, pulled ARP table data and noticed something that should not have been there.

What followed became one of the more instructive incident response engagements the organization's security team had ever conducted — not because the attack was unprecedented, but because the detection method was. This case study examines exactly what the team found, why conventional monitoring had missed it, and what other SOC teams can implement today to close the same gap.

The Environment and the Threat Actor's Approach

The organization operated a flat-ish internal network with nominal VLAN segmentation across approximately 400 endpoints. Dynamic ARP Inspection (DAI) had been partially deployed but was not enforced on all switch ports. The SOC team relied primarily on a SIEM fed by endpoint telemetry, firewall logs, and DNS query data. ARP traffic, by contrast, was not systematically ingested or analyzed.

The threat actor had gained an initial foothold through a phishing-delivered credential harvester targeting a finance department workstation. From that single compromised host, they began a deliberate lateral movement campaign using ARP spoofing to intercept and redirect traffic between target hosts and the default gateway. The goal, reconstructed during post-incident forensics, was to reach a segment housing the organization's internal treasury management application.

Because the attacker kept ARP reply rates low — never flooding, never triggering volume-based thresholds — the activity sailed beneath every automated detection rule the team had in place.

What the ARP Audit Actually Revealed

The analyst conducting the pre-audit review was not looking for an intrusion. She was validating whether ARP table entries across core distribution switches were consistent with the organization's documented IP-to-MAC address assignments. The process was methodical: export current ARP tables, cross-reference against the DHCP lease database, flag discrepancies.

Three anomalies emerged immediately.

Duplicate MAC-to-IP bindings. A single MAC address appeared associated with two different IP addresses in different ARP table snapshots taken forty minutes apart. This indicated the attacker's machine was cycling through addresses, likely to avoid persistent detection.

Unexpected gateway MAC entries. On two access-layer switches, the MAC address associated with the default gateway IP had changed from the legitimate router interface to an unknown address — one that did not appear anywhere in the DHCP lease database or the organization's asset inventory.

Asymmetric ARP reply patterns. When the analyst pulled raw ARP packet captures from a span port that had been configured for an unrelated troubleshooting task months earlier (and never disabled), she identified a host generating unsolicited ARP replies at irregular intervals. The replies claimed gateway ownership for multiple IP addresses simultaneously — a textbook indicator of ARP spoofing in progress.

Within four hours of that discovery, the incident response process was fully activated.

The Procedural Gaps That Allowed Nineteen Days of Persistence

Post-incident review identified several compounding failures that had permitted the attack to persist.

First, DAI had been configured on uplink ports but not on access ports serving workstation segments — a common misconfiguration that effectively inverts the protection the feature is designed to provide. Second, the SIEM had no ARP-specific correlation rules. The platform was capable of ingesting syslog data from switches that could have surfaced ARP binding changes, but no one had written the rules to make use of it. Third, the organization's incident response runbooks contained no ARP-specific investigation procedures. When analysts received alerts for lateral movement indicators from the endpoint agent, their investigation path did not include Layer 2 verification.

Collectively, these gaps created a detection-free corridor at precisely the layer the attacker had chosen to exploit.

Detection Rules SOC Teams Can Implement Immediately

The following monitoring rules are derived directly from the indicators identified during this engagement. They are written in plain logic and can be adapted to most SIEM platforms.

Rule 1 — Gateway MAC Binding Change Alert. Baseline the MAC address associated with each default gateway IP in every VLAN. Alert on any ARP reply that maps a gateway IP to a MAC address not present in the approved binding table. Threshold: any single occurrence.

Rule 2 — Duplicate IP Binding Detection. Alert when a single IP address is associated with more than one MAC address within a configurable rolling window (recommended: 10 minutes). Exclude known failover pairs documented in the asset inventory.

Rule 3 — Unsolicited ARP Reply Rate Anomaly. Establish a baseline for gratuitous or unsolicited ARP reply volume per host over a 24-hour rolling window. Alert when any host exceeds two standard deviations above its individual baseline. This approach avoids the false positives that fixed-threshold rules generate during legitimate network changes.

Rule 4 — ARP-DHCP Consistency Check. On a scheduled basis (recommended: every 6 hours), compare active ARP table entries against current DHCP lease records. Flag any MAC-to-IP binding that exists in the ARP table but has no corresponding DHCP lease, or that conflicts with an existing lease assignment.

What Structured ARP Training Would Have Changed

It is worth noting that the analyst who discovered the attack had recently completed structured training in Layer 2 protocol analysis as part of a professional development initiative. Her familiarity with ARP table structure, normal binding behavior, and the specific signatures of spoofing activity was not incidental — it was the direct product of deliberate credentialing.

The broader lesson for security operations leadership is straightforward: ARP-level threats are not exotic. They are a well-documented class of attack that has been used in financial fraud, corporate espionage, and ransomware staging operations for over two decades. The reason they persist is not that defenders lack the tools to detect them. It is that most SOC teams have never been trained to look.

For organizations reviewing their current detection coverage, this case study offers a concrete starting point. Pull your ARP tables. Cross-reference your DHCP leases. Check your DAI configuration on access ports. And if your analysts cannot immediately interpret what they find, that is the gap that requires the most urgent attention.