Threat Hunting Exercise: Analyzing Network Rogue DHCP Server MITM Dataset

This hunt uses a simulated network/switch-log dataset (network_rogue_dhcp_mitm_2022-08-06T140000.json) capturing T1557: Adversary-in-the-Middle via a rogue DHCP server, where an adversary who gained physical or wireless access to an internal segment stands up an unauthorized DHCP server that races the legitimate one, handing out a malicious default gateway/DNS server to intercept and manipulate victim traffic.

Step 1: Hypothesis Formation

Hypothesis: DHCP OFFER messages are observed on the network segment originating from a MAC address/IP not on the authorized DHCP server allow-list, and at least one client subsequently receives a lease with a gateway or DNS server IP that does not match the environment's documented network configuration. Indicators:

• DHCP snooping logs (switch-level) or packet capture: DHCPOFFER from an untrusted port/MAC.
• Client DHCPACK binding shows Option 3 (Router) or Option 6 (DNS Server) pointing to an IP outside the documented infrastructure range.
• Affected client's subsequent DNS resolutions for known-good domains (e.g., internal portal, major cloud services) return unexpected/inconsistent IPs - corroborating traffic interception.
• Switch port security/DHCP snooping violation log entries on the port where the rogue server is physically connected.

Null Hypothesis: A legitimate but unauthorized/misconfigured device (e.g., a consumer router accidentally plugged into the network, a test lab DHCP server not properly isolated) is the source, rather than a malicious actor. Invalidate via physical/asset tracing of the switch port and MAC address, and by assessing whether the handed-out configuration facilitates interception (an accidental router misconfig usually doesn't redirect DNS to attacker infrastructure).

Rationale: Rogue DHCP is a classic and highly effective internal MITM technique because it requires no credential compromise - only physical or wireless network access - and can silently redirect all of a victim's traffic; this hunt validates DHCP-snooping-based detection as the primary control.

Step 2: Data Sources and Scope

• Sources: Switch DHCP snooping logs / DHCP-snooping violation events; Network packet capture (broadcast domain) for DHCP transaction reconstruction; Asset/port-mapping inventory (authorized DHCP server list).
• Scope: ~2022-08-06T14:00:00-14:20:00 UTC; Segment: VLAN 40 (Office-Floor3); Legitimate DHCP server: 10.150.0.10; Rogue source: switch port Gi1/0/24, MAC 00:0c:29:ab:cd:ef.
• SIEM Queries (Splunk/ELK):
• Untrusted DHCPOFFER: index=switch event_type="dhcp_snooping_violation"
• Client lease with unexpected gateway: index=dhcp message_type="DHCPACK" option3_router!="10.150.0.1"
• Port-to-MAC trace: index=switch mac="00:0c:29:ab:cd:ef" | stats values(port)

Step 3: Key Findings

Parsed events (6 shown) confirm a rogue DHCP server on an untrusted switch port successfully leased a malicious gateway/DNS configuration to at least one client before DHCP snooping blocked further offers.

Validation:

• Timeline: Rogue offer → client acceptance (race win) → DNS hijack → automated port shutdown, all within about a minute - DHCP snooping successfully contained the incident quickly, but not before one client was affected.
• False Positives: Physical port trace to a publicly-accessible conference room jack, combined with the malicious DNS-redirect configuration (not just an accidental misconfiguration), rules out benign explanations.
• Correlation: Single rogue device, single affected client (further clients protected by the automatic err-disable) - contained but confirmed impact.

Step 4: Recommendations & Next Steps

• Immediate Response: Physically locate and remove the rogue device from the conference room jack; force WKS-F3-118 to renew its DHCP lease from the legitimate server and flush its DNS cache; reset the affected user's portal credentials; review physical security/badge logs for the conference room around the incident time to identify who connected the device.
• Detection: This should already be a standing switch-level control (DHCP snooping with port err-disable on violation) rather than solely a hunt finding - supplement with a Sigma-style SIEM rule: title: DHCP Snooping Violation on Untrusted Port → selection: event_type="dhcp_snooping_violation" alerting the SOC in real time for physical-response dispatch.
• Pro Tip: Enable DHCP snooping (and ideally 802.1X port authentication) on every access-layer switch port, especially in publicly-accessible areas like conference rooms and lobbies - this is a low-cost, high-value control against an attack technique that requires no credentials at all, only physical or wireless proximity.

Hypothesis confirmed - a rogue DHCP server on an untrusted conference-room switch port successfully performed a MITM DNS hijack against at least one client before automated containment!