The Illusion of Two-Factor Authentication
Forensic analysis of an AiTM attack – and why standard MFA is no longer enough.
Most companies lull themselves into a false sense of security. The belief: "We have Microsoft 365 and the Authenticator app enabled; nothing can happen to us." The reality we see during incident response operations tells a different story.
The following anonymized deployment log documents a successful, multi-stage cyberattack that our team recently analyzed and mitigated. It demonstrates how attackers exploit trust relationships and bypass Two-Factor Authentication (MFA) in real time.
1. Reconstructing the Kill Chain
The attack didn’t start with a poorly written email from a “Nigerian prince.” It originated in the Microsoft 365 tenant of a trusted external business partner (Patient Zero). An attacker had authenticated access (MAPI) there and sent malicious messages directly from the genuine mailbox to our client.
The methodology for bypassing security filters:
- Cloud Storage Abuse: To bypass signature-based email filters (Defender, Barracuda, etc.), the email did not contain a direct malicious link, but a legitimate Microsoft OneDrive link (
1drv.ms). Only the document hosted there contained the actual redirect to the attacker’s infrastructure. - Cloaking (Bot Detection): Calling the attacker’s infrastructure first led to a server-side validation script. This evaluated the client environment to actively reject automated analysis tools from security vendors, allowing only regular, human users to pass.
- Adversary-in-the-Middle (AiTM): After client verification, the user was redirected to a fake Microsoft authentication page. The attackers acted as an invisible proxy between the user and the real Microsoft servers. When the user entered their credentials and approved the MFA prompt, the valid session token was intercepted by the attackers in real time. The Two-Factor Authentication was rendered useless.
2. Forensic Evidence
We don’t rely on assumptions. The technical analysis of the headers and network telemetry provided clear proof.
Verification of the Origin (Original Headers)
Examining the original message confirmed the authenticity of the sender. It was not spoofing:
Authentication-Results: dkim=pass […] spf=pass […] dmarc=pass
X-MS-Exchange-CrossTenant-AuthAs: Internal
Finding: The email was sent via a regular, authenticated user session utilizing the MAPI protocol of the compromised business partner.
Analysis of the Attacker Infrastructure
The network-level verification of the extracted target URLs (using cURL) documented the obfuscation methods deployed:
HTTP/2 301 Moved Permanently
server: cloudflare
set-cookie: PHPSESSID=[Session-ID]; path=/
Finding: Use of Cloudflare for IP masking; protocol switching to hinder analysis; session tracking (PHPSESSID) for real-time, server-side control of the AiTM phishing.
Decrypting the Polymorphic Payload
Fetching the source code revealed JavaScript explicitly checking for security tools:
if(/bot|crawl|spider|headless|phantom|puppet|selenium|lighthouse|wget|curl|scan/i.test(navigator.userAgent))return!1;
To bypass this bot filtering and secure forensic evidence, we simulated a regular Windows client including HTTP redirect following. In the secured source code, we found the attacker’s client-side decryption routine:
const tvOoEK… = (rplQ…, EdrX… = 15) => rplQ….map(n => String.fromCharCode(n - EdrX…)).join(’’);
const VVjnkPP… = tvOoEK…([116, 133, 112, 123]);
Finding: The ASCII shift by a value of 15 generates the string eval. This initiated the execution of the dynamically decrypted payload to finalize the compromise of the victim. The raw data was secured and handed over to the cybercrime authorities (ZAC).
3. The Hard Consequences for Enterprises
A stolen session token grants full access to the Microsoft 365 account – completely independent of whether you use an Authenticator app or receive SMS codes. The attacker is inside the system.
The primary risks at this moment:
- Data Exfiltration: Silent, unauthorized extraction of corporate and client data.
- Lateral Movement: Using the legitimate account to infect other business partners or prepare ransomware deployment within the local network.
- Persistence: Creating stealthy inbox rules to continue monitoring communications even after a password reset.
What Actually Protects?
When standard MFA is no longer sufficient, security must happen at the architectural level. Pure user training (“Don’t click on bad links”) inevitably fails when the link comes from a known business partner and points to a genuine Microsoft OneDrive location.
Effective protection requires Zero-Trust Architectures and Conditional Access Policies: Access to corporate data must not solely depend on a password and a 2FA code. It must strictly be tied to the hardware compliance status of the endpoint and cryptography-based FIDO2 hardware tokens. A machine we do not manage is not allowed to access data – even with the correct password.
Only those who design and secure their IT infrastructure as a holistic system will survive initial contact with professionally orchestrated attacks.
About the author
This post is part of our series on Infrastructure Design. At rusch.be, we build and maintain critical, zero-bullshit IT infrastructure for SMEs in Germany. We rely heavily on Linux standards, Systemd, and Podman Quadlets to keep complexity low and security high.