This network-traffic detection rule flags a rogue DHCP race: two or more distinct DHCP servers respond with an OFFER or ACK for the same DHCP transaction ID (xid) within a short window (30 seconds). It operates purely on observed wire behavior (server IPs and optional server_identifier), making it OS-agnostic since it does not rely on host telemetry. When two or more legitimate-looking servers answer the same DHCP transaction, the rule raises a detection for potential adversary-in-the-middle activity that could enable traffic interception via a hostile gateway or DNS (TunnelVision-like behavior) or deliver malformed responses that compromise client DHCP parsing. The rule is implemented against Packetbeat network traffic data (DHCPv4 on UDP 67/68) and requires being on the same broadcast segment to observe competing OFFER/ACKs. It’s not compatible with Zeek’s DHCP stream, which aggregates the DORA exchange and cannot support per-transaction server-count checks. Typical detection outcome includes multiple DHCP servers observed for the same xid within 30 seconds, with the rule reporting the distinct server IPs and server identifiers involved, plus a count of replies. The rule can be correlated with endpoint telemetry and network topology data to identify the rogue server, the affected client segments, and any escalation via misconfigurations or CVEs on clients or servers. Remediation focuses on removing the rogue server, updating DHCP stacks, and enforcing network controls like DHCP snooping to restrict legitimate DHCP responses to authorized ports/MACs, thereby mitigating broader exploitation such as TunnelVision-style route injections. This rule aligns with MITRE ATT&CK techniques for Adversary-in-the-Middle (T1557.003) and related client-execution/exploitation vectors, and is tagged for network monitoring and vulnerability-focused use cases.