Threat Hunting Exercise: Analyzing VPN Impossible Travel Concurrent Session Dataset
This hunt uses simulated corporate VPN concentrator logs (vpn_impossible_travel_2022-05-02T080000.csv, Cisco AnyConnect/Palo Alto GlobalProtect style) to catch T1078: Valid Accounts abuse - a stolen credential being used to establish a VPN session from a geographically implausible second location while the legitimate user's session is still active, a classic sign of credential compromise that geo-velocity analytics are purpose-built to catch.
Step 1: Hypothesis Formation
Hypothesis: A legitimate remote-access account authenticates successfully from its normal location, and shortly afterward (or concurrently) authenticates again from a location that would require physically impossible travel speed between the two points within the elapsed time, indicating the credential (and possibly a valid MFA token/session) is in the hands of two different actors. Indicators:
- Two VPN logon events for the same username within a short window, with source IP geolocations implying a travel speed exceeding ~800 km/h (commercial flight speed) between them.
- Concurrent/overlapping session duration (both sessions active simultaneously) - an even stronger signal than sequential impossible travel.
- The anomalous session using a different client OS/device fingerprint than the account's established baseline.
- Immediate anomalous internal activity (unusual file share access, mail rule changes) following the suspicious session.
Null Hypothesis: Legitimate use of a corporate VPN exit-node/proxy service that changes the apparent source geolocation, or a false GeoIP resolution. Invalidate via device fingerprint mismatch, concurrent (not just sequential) session overlap, and absence of a known corporate proxy/CDN IP range in the anomalous connection.
Rationale: VPN geo-velocity is a cheap, high-signal detection layer that complements the earlier Azure AD password-spray hunt - it catches compromised credentials being used, not just successfully guessed, and works even when MFA was bypassed via phishing/token theft rather than brute force.
Step 2: Data Sources and Scope
- Sources: VPN concentrator authentication/session logs (username, source IP, geolocation, client OS, session start/end, MFA method); identity provider MFA logs for corroboration.
- Scope: ~2022-05-02T08:00:00-08:45:00 UTC; Account: rharris (Sales, based in Chicago, IL, USA); Anomalous source: Bucharest, Romania.
- SIEM Queries (Splunk/ELK):
- Impossible travel:
sourcetype=vpn_logs | streamstats current=f last(geo_lat) as prev_lat, last(geo_lon) as prev_lon, last(_time) as prev_time by username | eval km=haversine(geo_lat,geo_lon,prev_lat,prev_lon), hrs=(_time-prev_time)/3600, speed=km/hrs | where speed > 900 - Concurrent sessions:
sourcetype=vpn_logs action="session_start" | join username [search sourcetype=vpn_logs action="session_end"]→ flag overlapping start/end windows for the same user. - Device mismatch:
sourcetype=vpn_logs username="rharris" | stats values(client_os) as os_seen
Step 3: Key Findings
Parsed VPN session log (8 rows shown) confirms a genuine concurrent-session impossible-travel event, with the anomalous session pivoting into internal mailbox rule tampering.
| Timestamp (UTC) | Username | Source IP | Geolocation | Client OS | Session Action | IOC/Why Suspicious? |
|---|---|---|---|---|---|---|
| 2022-05-02 08:00:12 | rharris | 24.14.88.201 | Chicago, IL, USA | Windows 11 (corporate laptop fingerprint) | session_start | Baseline session - matches rharris's established location and device history. |
| 2022-05-02 08:22:44 | rharris | 185.81.157.9 | Bucharest, Romania | Linux (unrecognized client string: "OpenConnect/9.01") | session_start | Core IOC: Second concurrent session for the same account, ~8,000km away, 22 minutes after the first - implies a sustained flight speed of ~22,000 km/h, physically impossible. Different, unrecognized client entirely. |
| 2022-05-02 08:22:44 | rharris | 24.14.88.201 | Chicago, IL, USA | Windows 11 | (session still active) | Concurrency IOC: Original Chicago session has no session_end event - both sessions genuinely overlap, ruling out simple sequential travel or a stale cached session. |
| 2022-05-02 08:23:10 | rharris | 185.81.157.9 | Bucharest, Romania | Linux | MFA method: push-approved (Duo) | MFA was approved - either the legitimate user was tricked into approving a push (MFA fatigue) or the token/session itself was stolen/replayed. |
| 2022-05-02 08:25:01 | rharris | 185.81.157.9 | Bucharest, Romania | Linux | Internal activity: Outlook Web Access rule created | Pivot IOC: Immediately after establishing the anomalous session, a mail forwarding rule is created (see companion mailbox-exfil hunt) - a common next step after VPN-level compromise. |
| 2022-05-02 08:30:00 | rharris | 185.81.157.9 | Bucharest, Romania | Linux | Internal activity: SharePoint access to "Finance/Payroll" | Access to a resource well outside rharris's normal Sales-role usage pattern. |
| 2022-05-02 08:40:00 | rharris | 24.14.88.201 | Chicago, IL, USA | Windows 11 | session_end | Legitimate user's session ends normally - consistent with them being unaware of the concurrent compromise. |
| 2022-05-02 08:45:00 | rharris | 185.81.157.9 | Bucharest, Romania | Linux | session_end | Anomalous session ends 20 minutes after the legitimate one - actor operated in parallel with, not instead of, the real user. |
Validation:
- Timeline: Two genuinely overlapping sessions (08:00-08:40 Chicago vs. 08:22-08:45 Bucharest) for one account - this is concurrency, the strongest possible impossible-travel signal, not just fast sequential geolocation change.
- False Positives: No corporate proxy/CDN egress range matches 185.81.157.9; the client string "OpenConnect/9.01" has never appeared in rharris's prior 180 days of VPN history, which is exclusively the corporate-managed Windows client.
- Correlation: The MFA-push-approved event alongside an unfamiliar client suggests either MFA fatigue (user approved unknowingly) or an adversary-in-the-middle session/token theft - worth confirming directly with the user.
Step 4: Recommendations & Next Steps
- Response: Terminate the Bucharest session immediately; force a password reset and full MFA re-enrollment for rharris; review and remove the newly created mail forwarding rule; interview the user about any recent unexpected MFA push prompts (to distinguish fatigue-approval from token theft).
- Detection: Standing geo-velocity rule:
title: VPN Impossible Travel→selection: same username, two session_start events, computed travel speed between source geolocations > 900 km/h, OR overlapping session windows. - Pro Tip: Concurrent-session detection is strictly better than simple sequential-geo-velocity - it also catches cases where an attacker uses a residential proxy near the victim's actual location (defeating naive distance checks) but can't fake the legitimate user's session still being open.
Hypothesis confirmed - concurrent VPN session compromise with a real-time pivot into mailbox and SharePoint access! The overlapping-session detail was what elevated this from "curious" to "confirmed active compromise."