Valid-Account VPN Takeover After MFA Fatigue
At 03:07, Cisco ISE logs a VPN authentication for account 'jdoe' from 198.51.100.23 in Country A after 11 denied MFA pushes in 4 minutes; the user's normal login is 203.0.113.45 in Country B. The identity provider shows the MFA acceptance came from a new device, and the user's laptop has been offline for 6 hours. Umbrella then records DNS queries from VPN pool 10.8.20.0/24 to 'cdn-sync-update[.]top' and 'api-telemetry[.]cloud' with low prevalence. At 03:19, Secure Firewall sees RDP from the VPN pool to 10.10.5.12, a finance app server with no EDR agent. The user is traveling and unreachable by phone; their manager confirms they reported a lost phone yesterday but did not report it to IT. No endpoint malware alerts appear. The SOC has 20 minutes before shift change.
1. Is this a true positive or benign travel? Explain the evidence you would weigh.
Read the worked answer
This is a valid-account takeover via MFA fatigue. The 11 denied pushes followed by acceptance, impossible travel, a new MFA device, and a user-reported lost phone all point to credential and token compromise, not benign travel. The lack of endpoint malware alerts is expected because the attacker is using native VPN and RDP access. Check whether 'jdoe' is a shared or service account; if so, scope every user of that account. Correlate ISE, Umbrella DNS, and firewall connection logs to see what the session touched. Do not close this as a false positive because the user is traveling; the lost-phone report strengthens the compromise hypothesis. Preserve logs before remediation because sessions and tokens are volatile.
2. What containment sequence minimizes disruption while stopping the attacker?
Read the worked answer
Revoke all VPN and SSO sessions and refresh tokens for jdoe; disable the account; reset the password; remove the lost phone's MFA method and require in-person re-enrollment. Block the source IP/ASN and both domains at Secure Firewall and Umbrella. Isolate finance app server 10.10.5.12 with a network ACL or switch-port shutdown because it has no EDR, and capture its logs before any reboot. Search ISE for other accounts authenticating from 198.51.100.23 and for RDP from the VPN pool. A password reset alone is insufficient because active sessions persist. Notify the user through an alternate channel and the manager/HR; involve legal if finance data was accessed.
3. What evidence and scoping steps support notification decisions?
Read the worked answer
Export ISE authentication and authorization logs, Umbrella DNS, firewall connection events, VPN concentrator logs, and Windows Security logs from 10.10.5.12. Build a timeline from 03:07 onward and identify accessed files or shares. Preserve MFA push logs from the identity provider. Scope by searching all VPN accounts for the source IP/ASN and the two domains over 30 days, and check for new MFA devices. Notification: follow the breach policy if finance data was accessed; do not confront the user by email. Document the lost-phone reporting gap as a control failure. Recommend number matching or phishing-resistant MFA to prevent repeated push fatigue.