Your Multi-Factor Authentication just failed. Not because your user clicked through a push notification or because the attacker brute-forced a code, but because they proxied the entire authentication flow and now hold a valid session token that looks exactly like legitimate user activity.
This checklist addresses adversary-in-the-middle (AitM) phishing campaigns that bypass Multi-Factor Authentication by proxying the entire authentication flow. Arctic Wolf Labs recently documented a campaign targeting Microsoft 365 accounts across healthcare, education, manufacturing, government, and professional services in the U.S., Canada, and Europe. The attackers used residential proxies to maintain compromised sessions at eight-hour intervals, collected payroll and finance emails, and avoided typical business email compromise behaviors that trigger alerts.
Checklist Overview
You'll verify whether your authentication, monitoring, and response controls can detect and contain session hijacking when attackers hold valid credentials and session tokens. This isn't about preventing the initial phish, it's about detecting what happens after authentication succeeds.
Prerequisites
Before you start:
- Access to authentication logs showing sign-in events, session IDs, user agents, IP addresses, and geographic locations
- Mailbox audit logs with read, search, and rule-creation events
- API access logs for Microsoft Graph or equivalent directory queries
- Authority to define conditional access policies and session timeout rules
- Incident response runbook that includes session revocation procedures
Detection and Response Checklist
1. Session Fingerprint Monitoring
Done when: Your SIEM flags sessions where the SessionID remains constant while source IP, ASN, or geographic location changes.
The campaign documented by Arctic Wolf maintained the same SessionID across rotating residential proxy addresses. Your authentication logs should correlate SessionID with source metadata. Configure alerts when a single session reports sign-ins from multiple autonomous systems within a 24-hour window.
Good looks like: An alert fires within 15 minutes when SessionID abc123 reports access from AS15169 (Google) in Virginia, then AS7922 (Comcast) in California, then AS3320 (Deutsche Telekom) in Germany, all within eight hours.
2. User Agent Consistency Validation
Done when: You detect implausible browser and operating system combinations in authentication events.
The attackers reported mobile versions of Safari or Chrome on Windows 10 and used Firefox or Python Requests user agents while claiming Microsoft Outlook as the client application. Build validation rules that flag mismatches between reported client application and user agent string.
Good looks like: Your monitoring system rejects or quarantines sessions reporting "Microsoft Outlook" with user agent "Python Requests 2.31.0" and generates a high-priority ticket for investigation.
3. Geographic Proxy Detection
Done when: You identify authentication attempts originating from residential proxy infrastructure, particularly when they occur within minutes of the initial sign-in and match the victim's country code.
Residential proxies appear as consumer ISP traffic, not datacenter ranges. The documented campaign queried geolocation APIs and selected exit nodes in the victim's country. Maintain threat intelligence feeds that identify residential proxy ASNs and compare authentication source IPs against these ranges.
Good looks like: Sign-in from AS7922 (Comcast residential) triggers enhanced scrutiny when the user's typical pattern shows corporate network (AS15133) or home broadband from a consistent address block.
4. Session Refresh Pattern Analysis
Done when: Your system flags recurring authentication events at regular intervals (such as eight-hour cycles) from different source addresses.
Automated session maintenance creates predictable patterns. The campaign refreshed sessions every eight hours to prevent timeout. Monitor for sign-in events that occur at consistent intervals across multiple accounts, especially when each event originates from a different IP but maintains the same session.
Good looks like: Three accounts show sign-in events at 08:00, 16:00, and 00:00 UTC over five consecutive days, each from different residential proxy addresses, your automation correlates these as a campaign pattern and escalates.
5. Mailbox Query Scope Review
Done when: You audit Microsoft Graph API calls (or equivalent directory API queries) that enumerate users by role or function, particularly targeting payroll, HR, finance, or administrative personnel.
The attackers used Graph API to identify financial workflow personnel. Log all API queries that filter users by job title, department, or group membership. Flag bulk enumeration queries that don't match the authenticated user's typical access patterns.
Good looks like: User [email protected] suddenly queries Graph API for all users with "payroll" or "finance" in their title, your system blocks the query, revokes the session, and alerts your security team within two minutes.
6. Mailbox Access Anomaly Detection
Done when: You identify unusual message read patterns, particularly bulk access to emails containing keywords like payroll, invoice, payment, banking, or benefits.
Arctic Wolf observed attackers restricting activity to reconnaissance and mailbox collection. Enable mailbox auditing that logs message access events and correlate these with search terms. Alert when a user accesses significantly more messages than their baseline, especially messages outside their typical workflow.
Good looks like: CFO account accesses 200 messages in two hours (baseline: 30/day) with subject lines containing "wire transfer" and "payroll", your system flags this, suspends the session, and requires reauthentication with phishing-resistant MFA.
7. Inbox Rule Manipulation Guard
Done when: Your monitoring detects creation of inbox rules that automatically move, delete, or mark messages as read, particularly rules targeting financial or administrative content.
Some intrusions involved hands-on keyboard activity to create rules moving messages from Inbox to Deleted Items. Configure alerts for any inbox rule creation or modification. Block rule creation entirely for high-risk accounts (finance, payroll, executives) unless explicitly authorized through a separate approval workflow.
Good looks like: Attempt to create inbox rule "Move messages containing 'invoice' to Deleted Items and mark read" triggers immediate session termination, MFA reset requirement, and security team notification before the rule activates.
8. Phishing-Resistant MFA Enforcement
Done when: High-risk accounts (payroll, finance, HR, executives) require FIDO2 hardware tokens or certificate-based authentication that cannot be proxied through an AitM page.
Traditional MFA (SMS codes, authenticator apps, push notifications) fails against AitM attacks because the proxy captures and replays the authentication factors. Implement FIDO2 or smartcard-based authentication for accounts that access financial systems or sensitive personnel data. These methods bind authentication to the specific origin, preventing proxy-based replay.
Good looks like: Finance team members authenticate with YubiKey 5 series tokens configured to validate the authentication origin. An AitM proxy cannot complete the challenge-response because the token validates it's communicating with the legitimate Microsoft authentication endpoint, not a proxy.
Common Mistakes
Trusting geographic proximity: Attackers deliberately select residential proxies in the victim's country. A sign-in from "Chicago residential broadband" doesn't mean it's legitimate just because your user lives in Chicago.
Ignoring session persistence anomalies: A session that survives for 48 hours across 15 different IP addresses isn't a traveling user, it's automated session maintenance.
Alerting without action: Detection is worthless if your playbook doesn't include immediate session revocation. Build automatic termination into your high-confidence alerts.
Overlooking API abuse: The Graph API queries are often the clearest signal. If a marketing coordinator suddenly enumerates all finance personnel, you have seconds to act, not hours.
Next Steps
Run a tabletop exercise where you simulate an AitM compromise: valid session, rotating IPs, mailbox enumeration. Walk through your detection timeline. If you can't identify the compromise within your session timeout window, your controls need tightening.
Review your conditional access policies. Can you enforce phishing-resistant MFA for financial workflow accounts by end of quarter? Can you reduce session lifetime for these accounts from 90 days to 8 hours?
Test your session revocation procedure. When you identify a compromised session, can you terminate it globally within five minutes and force reauthentication?
The sophistication here isn't the phishing page, it's what happens after authentication succeeds. Your defenses need to assume the attacker will occasionally get valid credentials and focus on limiting what they can do with them.
