Guest VLAN: rogue DHCP redirecting users to a fake SSO portal

From: Incident Response Lead (SOC on-call)
To: IT Leadership · Network Operations · Identity/M365 Admin · Facilities · On-call SOC
Subject: [SEV-2][INC-NET-E99A] Guest VLAN rogue DHCP redirecting users to fake SSO portal — containment in progress

Incident: INC-NET-E99A · SEV-2 / P2
Status: Active containment and investigation in progress
Classification: Cyber × Network Fusion · Rogue DHCP MITM · Credential Harvesting
Affected asset: Guest VLAN 99 + two contractor accounts · High criticality
Detected: 2026-04-22 14:18 UTC

SITUATION & SUMMARY

Multiple contractors on Guest VLAN 99 were redirected to a fake Microsoft 365 SSO portal after opening a browser. Two contractors entered credentials before being redirected to office.com.

Network evidence shows a rogue DHCP server active on Guest VLAN 99. The rogue DHCP offer came from MAC `aabb.cc11.2233`, mapped to `ACCESS-SW-21` port `Gi1/0/14`, which is a public-area conference room jack. The rogue DHCP offer assigned clients a default gateway of `10.30.99.250`, indicating traffic was being redirected through an attacker-controlled host.

Web proxy evidence confirms credential submission to `acme-sso-login[.]net`. Entra ID evidence shows a successful sign-in for `jdoe-c@acme-corp.com` from `185.244.25.17` using `python-requests/2.31`, which strongly indicates automated attacker use of captured credentials.

SEVERITY & PRIORITY

This is rated SEV-2 / P2 because the incident affects multiple users on a live network segment, includes an active rogue DHCP/MITM condition, and at least one contractor account has a confirmed successful suspicious sign-in.

The credential compromise component should be handled with urgent containment priority. Even if the affected users are contractors, the accounts may still have access to M365, SharePoint, Teams, email, or internal resources.

IMMEDIATE CONTAINMENT

* Disable or administratively shut down `ACCESS-SW-21 Gi1/0/14` to remove the rogue DHCP source from the network.
* Preserve switch evidence before clearing it, including MAC address table output, interface status, port description, CDP/LLDP neighbor data if available, and recent port-security or DHCP-related logs.
* Block `acme-sso-login[.]net` at DNS, proxy, and secure web gateway controls.
* Block or monitor attacker IP `185.244.25.17`.
* Reset passwords for the two contractors who entered credentials.
* Revoke active sessions and refresh tokens for the affected contractor accounts.
* Temporarily disable or restrict the affected contractor accounts until Identity confirms no unauthorized persistence was added.
* Require fresh MFA on next sign-in for the affected accounts.

NETWORK INVESTIGATION

* Pull DHCP logs and packet captures for Guest VLAN 99 to determine when the rogue DHCP server became active.
* Search for all DHCP offers from MAC `aabb.cc11.2233` and IP `10.30.99.250`.
* Identify all clients that accepted DHCP leases from the rogue server.
* Review `ACCESS-SW-21 Gi1/0/14` physical location and determine what device was connected.
* Have Facilities or Network Operations inspect the conference room jack and preserve any connected device, adapter, mini-router, laptop, or rogue access point as evidence.
* Check nearby public-area ports for similar rogue devices or unauthorized network equipment.
* Verify whether DHCP snooping, Dynamic ARP Inspection, IP Source Guard, and port security are enabled on Guest VLAN 99 access switches.

IDENTITY / M365 INVESTIGATION

* Review Entra ID sign-ins for the two affected contractor accounts before and after 14:11 UTC.
* Investigate the successful sign-in for `jdoe-c@acme-corp.com` from `185.244.25.17` with user agent `python-requests/2.31`.
* Check for suspicious mailbox rules, forwarding rules, OAuth grants, MFA changes, device registrations, app consents, sent mail, deleted mail, and SharePoint/OneDrive/Teams access.
* Search tenant-wide for sign-ins from `185.244.25.17`, the same user agent, and other hosting-provider IPs around the incident window.
* Identify whether any additional guest users or contractors reached `acme-sso-login[.]net`.

EVIDENCE PRESERVATION

* Preserve tcpdump/packet capture showing competing DHCP offers.
* Preserve switch output mapping `aabb.cc11.2233` to `ACCESS-SW-21 Gi1/0/14`.
* Export web proxy logs showing the GET and POST to `acme-sso-login[.]net`.
* Export Entra ID logs for the successful sign-in from `185.244.25.17`.
* Photograph and preserve any physical device connected to the conference room jack.
* Preserve relevant switch logs, DHCP logs, and NAC logs before clearing or resetting the port.

RECOVERY & NEXT STEPS

* Keep `Gi1/0/14` disabled until the physical port and connected device are inspected.
* Remove the rogue device from the environment and preserve it as evidence.
* Reissue clean network configuration to affected Guest VLAN clients by forcing DHCP renewal or disconnect/reconnect after containment.
* Confirm affected accounts have clean sign-in history after password reset and token revocation.
* Validate that Guest VLAN users are receiving DHCP only from the legitimate infrastructure.
* Enable or enforce DHCP snooping on Guest VLAN 99, marking only legitimate uplinks or DHCP server-facing ports as trusted.
* Consider enabling Dynamic ARP Inspection, IP Source Guard, and stricter port security on public-area access ports.
* Send a targeted advisory to contractors and front-desk staff warning about fake SSO pages and unexpected browser redirects.

STAKEHOLDER COMMUNICATION

* Notify Network Operations that this is an active rogue DHCP/MITM event on Guest VLAN 99.
* Notify Identity/M365 admins that at least two contractor credentials were likely captured and one suspicious login succeeded.
* Notify Facilities that the source port is a public-area conference room jack and may involve an unauthorized physical device.
* Notify contractor account owners and managers that affected accounts are under containment and review.

DO NOT

* Do not simply release/renew DHCP on clients without first disabling the rogue source.
* Do not clear switch MAC tables or reboot the switch before preserving evidence.
* Do not leave `Gi1/0/14` active while investigation continues.
* Do not assume this is only a guest-network issue; captured M365 credentials can affect cloud resources.
* Do not wipe contractor devices unless there is evidence of endpoint compromise.
* Do not share reset passwords over chat or email.
* Do not close the incident just because the rogue DHCP source is removed; identity compromise investigation must also be completed.