MFA is not the finish line
AitM attacks can target session access, which means defenders need visibility beyond password-based compromise.
Lab Safety Boundary
This lab does not deploy a phishing proxy, collect real credentials, capture live tokens, or target any real user. The AitM portion is modeled as a scenario condition so the lab can focus on defensive understanding of post-compromise mailbox behavior.
The goal is to understand the risk: after a successful phishing event, mailbox access can become automated, quiet, and difficult to recognize without the right logging and detection strategy.
What You’ll Build
Visual Attack Flow
The lab models a common business email compromise path: the user is lured into an AitM authentication flow, access is established, and mailbox data is queried through an API-style workflow.
Phishing Email
AitM Relay
MFA Completed
Session Access
Mailbox Access
EWS Interaction
Step-by-Step Lab Walkthrough
1Create a controlled Microsoft 365 lab mailbox
Use a dedicated lab tenant and synthetic users only. Populate the victim mailbox with harmless sample messages such as fake invoices, project updates, and test MFA notifications.
2Define the simulated AitM compromise condition
The lab begins after the user has interacted with a phishing lure and a valid access context exists. This keeps the scenario realistic without building credential-theft infrastructure.
3Model mailbox access through EWS-style interaction
Exchange Web Services historically allowed applications to interact with mailbox data programmatically. In Exchange Online, Basic authentication is no longer supported for EWS, and OAuth-based access is required for supported EWS application workflows.
// Safe lab pseudocode
connect_to_lab_mailbox(access_context)
select_folder("Inbox")
retrieve_message_subjects(limit=10)
review_results_for_sensitive_themes()
4Review what an attacker would look for
Focus on attacker objectives rather than credential theft mechanics. Common mailbox targets include financial language, vendor threads, password resets, MFA notifications, invoices, attachments, and executive communication patterns.
5Document defender observations for Phase 2
Capture what should become detection logic later: unusual mailbox access patterns, API-driven activity, impossible travel, unusual user agents, new inbox rules, and mailbox access following suspicious authentication.
Lab Screenshots
The following sanitized visuals show the safe lab flow without exposing personal, production, or tenant-specific information.
Step 1: Controlled lab mailbox
The mailbox contains synthetic messages only, giving the lab realistic content without using real user data.
Step 2: AitM scenario boundary
The AitM portion is represented as a simulated compromise condition so the lab stays defensive and controlled.
Step 3: Programmatic mailbox access
The simulated API workflow retrieves message subjects from the lab mailbox without using Outlook or a browser session.
Step 4: Mailbox data review
Retrieved mailbox data is reviewed from the attacker’s perspective to understand what defenders should detect.
Why This Matters
Mailboxes are high-value targets
Email contains business context, financial conversations, reset links, attachments, and trust relationships.
API access changes the signal
Mailbox access may not look like a normal user browsing Outlook, making audit and behavioral analysis critical.
Defender Takeaways
- Model the post-compromise behavior, not just the phishing email.
- Track mailbox access patterns after suspicious authentication activity.
- Pay attention to inbox rule changes, message reads, keyword searches, and attachment access.
- Use this Phase 1 lab as the foundation for Phase 2 detection engineering.
Exchange Online EWS is on a retirement path, but the defender lesson remains important: attackers abuse authorized access paths, APIs, sessions, and mailbox permissions to quietly extract value after phishing.
Next Phase
Phase 2 will focus on detection: audit logs, mailbox access telemetry, suspicious sign-ins, inbox rule creation, and KQL logic that helps identify post-phishing mailbox abuse.
Build. Break. Defend. Repeat.