How an AiTM Phishing Attack Cleared SPF, DKIM, and MFA

At a glance

• A phishing domain was registered at 18:23 UTC and used twelve minutes later – inside the window before any reputation feed can issue a verdict
• The email cleared SPF and DKIM legitimately, because the attacker sent it through a real compromised account on a paid marketing platform
• A live reverse proxy relayed the genuine Google login in real time, capturing the session cookie after the user completed MFA – the authentication control performed correctly and the attack operated around it

At 18:23 UTC, the attacker registered the domain. Twelve minutes later, a phishing email arrived in an executive mailbox at a security company. In that twelve-minute window, no blocklist had a verdict, no reputation feed had a score, and no threat intelligence platform had seen the domain before.

That timing is the design. Modern AiTM phishing operations provision infrastructure on demand, use it once, and discard it. A domain with no history has no score. A message sent from a legitimately compromised account clears every email authentication check. The economic model behind reputation-based security assumes attackers need infrastructure that accumulates history before it reaches a target. This attack was built on the premise that they do not.

This article documents how that attack unfolded, what the UnderDefense SOC team found during the investigation, and what the containment scope actually looks like for a session-level compromise.

Why standard email security controls fail to catch AiTM phishing

Email authentication – SPF, DKIM, and DMARC – was designed to answer one question: did the claimed sender actually send this message? It was not built to verify whether the brand visible to the reader has any relationship to the sending infrastructure.

The email in this case passed SPF. It passed DKIM. Both checks were legitimate. The attacker had taken over a paid account on a commercial email marketing platform operated by a small European software vendor. That account genuinely sent the message, so both cryptographic checks resolved correctly: SPF confirmed the sending address was authorised, DKIM confirmed the content had not been modified in transit.

The impersonation lived outside the scope of all three protocols. The DocuSign notification format, and the named analyst at a real US healthcare company whose signature block appeared in the footer, existed only in the message body and display name. DMARC is scoped to the authenticated envelope sender. Neither impersonated brand appeared in the headers. Three controls ran correctly. None of the three things they checked was the brand the recipient saw.

URL reputation analysis hit the same structural limit. The call-to-action button linked to a commercial email service provider’s click-tracking URL – a domain with a clean, established history. Inside that URL, base64-encoded in the path, was a second commercial tracker from a different provider. Inside that, also base64-encoded, was the actual destination. At delivery time, a scanner reading the message body sees two well-known commercial services. The malicious host exists only as encoded text inside path parameters that scanners do not decode.

How the attack unfolded: five stages

AiTM phishing defined. Adversary-in-the-middle (AiTM) phishing uses a reverse proxy positioned between the victim and a legitimate identity provider. The victim authenticates against the real service through the attacker’s relay. The attacker captures the session cookie issued at the end of a successful, MFA-verified login – a credential that grants access independently of any password and persists until each session is individually revoked.

Stage 1 – Infrastructure provisioned on demand. The attacker registered the final-destination domain at 18:23 UTC. Eleven minutes and thirty-six seconds later, the phishing email arrived. That gap is the entire window available for reputation-based blocking. No feed closed it.

Stage 2 – Delivery through a compromised platform account. The email was sent via a compromised account on a legitimate marketing platform. SPF and DKIM passed because a real, authorised account sent a real message. The DocuSign impersonation and the forged healthcare company signature lived only in the body, outside the authentication scope.

Stage 3 – Three-layer URL encoding. The button linked to a commercial ESP click tracker containing a second commercial tracker (base64-encoded), which contained the actual destination (also base64-encoded). The recipient’s own email address travelled encoded in the URL fragment – the portion after the # character that no server ever receives. It survived every redirect intact, and JavaScript at the destination decoded it to pre-fill the sign-in form. The recipient entered only a password.

Stage 4 – Live reverse proxy in front of the real identity provider. The final destination was a live reverse proxy relaying traffic to the genuine Google authentication service in real time. The UnderDefense investigation team confirmed this from captured network traffic: genuine Google session cookies arrived in server responses rewritten to the attacker’s domain, Google’s actual CAPTCHA was proxied through including the audio alternative, and Google’s own front-end assets were served from attacker-controlled subdomains.

Stage 5 – Session harvest. Two endpoints not belonging to Google captured submitted credentials the instant they were entered and returned a harvest status confirming what had been extracted. The proxy relayed MFA challenges in both directions. When the user successfully completed multi-factor authentication, the proxy relayed that exchange too. The session cookie Google issued at the end of a verified login was the attacker’s asset.

The investigation team confirmed no credentials were submitted during the period the targeted mailbox was under observation.

What a stolen session cookie actually costs to contain

The distinction between a stolen credential and a stolen session cookie is where the business impact of AiTM diverges from standard phishing.

In a credential-only attack, resetting the password is effective containment. The attacker’s access depends on it. After an AiTM capture, access depends on the session cookie. That cookie grants application-level access across every connected service independently of the current password. Resetting the password does not terminate it. The attacker retains access until each individual session is explicitly revoked.

For organisations in regulated sectors – financial services, healthcare, insurance – the scope of what must be checked and documented under NIS2, DORA, and SEC cyber disclosure rules is materially different for a session compromise than for a credential event. Treating the two categories as equivalent leaves persistence vectors unaddressed and notification obligations misaligned with what actually occurred.

Full containment for an account that may have reached the proxy page requires five distinct actions:

1. Active session and refresh token revocation across all connected applications, not only the primary identity provider
2. MFA registration audit to identify any additional authenticators registered during the active session window
3. Mailbox rule and forwarding review to identify persistence mechanisms added during access
4. OAuth grant audit to identify third-party application permissions granted while the session was active
5. Identity provider activity log review covering the full session timeline from first authentication to revocation

Each of those is a potential persistence vector that a credential-only IR playbook does not surface. For executive accounts specifically, each is also an entry point for lateral movement, mailbox exfiltration, and supply chain impersonation via outbound communications from a trusted sender.

Why MFA does not stop AiTM, and what does

MFA performed correctly in this case. The proxy relayed the challenge to the user and relayed the correct response back to Google. From Google’s perspective, a legitimate user on a legitimate device completed authentication. From the attacker’s perspective, the same was true.

TOTP codes, push notifications, and SMS-based MFA verify that the person entering a password also controls a second factor at that moment. They do not verify that the session being established is passing through a third-party relay. AiTM operates at the session layer, above the point where those controls apply.

One authentication control category is architecturally not relayable: phishing-resistant MFA.

FIDO2 security keys and passkeys bind the cryptographic authentication assertion to the origin the user’s browser confirmed during the session. When a reverse proxy intercepts a FIDO2 challenge and attempts to relay it, the proof includes the attacker’s domain as the relying party origin. That assertion does not validate against the legitimate service’s expected origin. Authentication fails at the proxy, before the user completes any interaction.

For detection teams, three signals from this investigation indicate where reputation-based controls have structural gaps:

• Domain age under 24 hours at delivery time – the attacker-controlled domain junkpermario[.]icu was registered twelve minutes before first use, with no history for any feed to evaluate 
• URL chain depth exceeding two commercial trackers – each additional encoding layer increases the distance between what the scanner reads and where the user lands
• URL fragment carrying a base64-encoded target address – this pattern signals infrastructure designed to pre-populate a specific account’s credentials without the user typing a username

What to check in your environment

1. Which executive and admin accounts use TOTP or push MFA? These are the accounts where AiTM generates the highest attacker value. Identify them, map them to a FIDO2 migration timeline, and treat that timeline as a risk item in your next board security review.
2. Does your email gateway decode nested redirects before scoring URLs? Most delivery-time scanners evaluate the first URL in a message. If the architecture does not follow and decode multi-layer encoded redirect chains, attacker-controlled destinations behind commercial trackers go unscored. 
3. Do you have a session revocation playbook separate from your password reset playbook? These are different containment actions with different scopes. If your IR runbook treats phishing as a credential event and ends at password reset, it does not cover AiTM session compromise.
4. Are new MFA method registrations alerted on for privileged accounts? If an attacker registers an additional authenticator during an active session, that method survives a password reset. Alerting on MFA registration changes for C-suite and admin accounts is a low-effort detection with direct containment value.

For CISOs managing executive and privileged account security: what is your current roadmap for migrating high-value accounts from TOTP or push MFA to phishing-resistant authentication? Contact the UnderDefense team to assess how this attack chain performs against your current email security and identity stack.