In short:
- What happened: A social engineering assessment used adversary-in-the-middle (AiTM) phishing to capture a live, authenticated Google session from a single developer, MFA included.
- What the assessment found: The stolen session led to email-approved MFA re-enrollment, plaintext credentials, and a compromised AI coding assistant configuration that quietly logged every prompt.
- Outcome: Department-wide account access, roughly twenty re-enrolled MFA factors, tens of terabytes of exposed storage, and a working VPN path into the internal network, from one clicked link that phishing-resistant MFA would have stopped at the door.
This is based on a real, authorized engagement. Client details, employee names, credentials, IP addresses, domains, and internal project specifics have been removed or generalized. Operational specifics (proxy configuration, landing-page code, exact lure content) are deliberately left out. It’s written for security leads, SOC teams, and anyone deciding whether their organization’s phishing resilience is being measured or assumed.
See how the UnderDefense Agentic AI SOC investigates, triages, and resolves real alerts.
Why does phishing still work, and why didn’t MFA save this organization?
Phishing awareness has improved across most companies. People are taught to check senders, hover over links, and question urgency. This campaign was built to defeat exactly that mindset, because it didn’t rely on a careless click. It relied on a login that was genuinely indistinguishable from the real one.
Adversary-in-the-middle (AiTM) phishing routes a victim’s login through an attacker-controlled proxy positioned between the victim and the real identity provider. Instead of a static fake page that only collects a username and password, the proxy sits in the middle of the real flow. The victim sees the genuine login page, enters real credentials, and completes the real MFA prompt. The proxy passes everything through to the legitimate service and, in return, captures the session token the service hands back. With that token, the attacker is already logged in. The second factor was satisfied once, by the victim, and the attacker rides the resulting session.
This assessment ran three pretexts, each chosen to produce a routine, low-suspicion click:
- An AI tool team-plan invitation, aimed at technical staff.
- A ticketing-system task assignment, aimed at engineering and operations.
- A document-share notification with a salary-statement theme, aimed broadly.
All three funneled into the same place: a cloned Google single sign-on page, since nearly everything in the organization authenticated through Google. Across the campaigns, a few hundred emails were sent, dozens of employees reached the credential step, and a large share completed it. MFA wasn’t uniformly enforced, which widened the impact further. For a board or an auditor, “we have MFA” is a checkbox; for an attacker running AiTM phishing, that checkbox holds up right until the token is copied.
The lure that landed: how one invitation reached the developers with the most access
The pretext worth dwelling on is the AI team-plan invitation, because it targeted engineers and developers, the people with the most access.
The email looked like an automated invitation to join the company’s workspace on an AI tool, sent in the name of a real colleague. For a developer, accepting a tooling invite is a routine, expected action, which made it effective. The call to action opened a cloned sign-in page offering the normal “continue with Google” path, which routed the victim into the AiTM proxy on a look-alike domain. The victim authenticated as usual, and the proxy captured a live Google session.
That session was the whole prize. Because the organization used Google as its identity backbone, one captured session wasn’t access to a single app. It was access to everything that trusted that Google account: mail, files, calendar, and any third-party service behind the same sign-in. From the outside, nothing looked wrong.
How did one phished login become full account takeover?
A stolen session is temporary by itself. It became standing access because of what the assessor found next.
The captured Google session reached a developer’s connected collaboration workspace. That workspace was protected by email-based MFA, which sounds like a second barrier until the reset email lands in an inbox the attacker already controls. Approving it took no effort at all.
Inside the workspace sat credentials in plaintext next to MFA enrollment QR codes for several other accounts. A QR code is the seed used to generate authenticator codes, so anyone who can read it can enroll the same factor on a new device. The assessor did exactly that, re-enrolling MFA on attacker-controlled devices for multiple accounts. At that point, the accounts had MFA in name, but the second factor no longer belonged to the account owner.
How the compromise reached the AI coding pipeline
One of the newly compromised accounts held the configuration for the team’s AI coding assistant. Configuration files like this are trusted by default and rarely reviewed, which made them a convenient target.
Three changes followed, each ordinary in isolation: the assistant’s API traffic was repointed through an attacker-controlled proxy, prompt and response logging was switched on, and an auto-loading extension was added that called out to an attacker endpoint at the start of every session.
None of it changed what the developers saw day to day. But every prompt became readable, and developers routinely paste credentials, tokens, and internal code into prompts without treating them as secrets. The startup callback meant the access no longer depended on any single stolen session staying alive.
The broader point holds beyond this one tool: AI developer tooling now sits close enough to production credentials and code that its configuration deserves the same scrutiny as a CI/CD pipeline, not the trust of a personal utility.
The blast radius: what one phished click reached
Tracing the chain from the first click to its end shows how far it travelled: full access to a department, roughly twenty accounts with their MFA factors and recovery codes re-enrolled, a live read on the team’s AI coding prompts, and a cloud storage account holding tens of terabytes of company data.
A few findings extended it further. Valid third-party credentials turned up in notes and storage. A VPN configuration file, left in an inbox, still worked and reached the internal network without touching perimeter controls. A telephony platform allowed the assessor to authenticate and send a message, which is action, not just visibility.
None of it required a novel exploit. It came from ordinary weaknesses stacked together: identity consolidated behind one sign-on with inconsistent MFA, second factors approvable from already-compromised inboxes, secrets stored in plaintext, reusable VPN material with no expiry, and AI tooling nobody was watching.
Why wasn’t awareness training the fix, and what is?
User training alone couldn’t have stopped this chain. The login was real. The MFA prompt was real. The lure was an action the target performs every week. Telling people to be more careful doesn’t close a gap that only opens after a normal login.
What closes it is architecture and monitoring, roughly in order of how much each would have blunted this specific chain:
- Move to phishing-resistant MFA. AiTM defeats codes and push approvals because the victim completes them for real. Hardware security keys and passkeys (FIDO2/WebAuthn) bind to the real site’s origin and don’t produce a token an attacker can replay, which is why CISA’s guidance on implementing phishing-resistant MFA treats it as the current standard. This is the single change that breaks the entry step.
- Stop storing secrets in plaintext. Credentials, API keys, and MFA recovery codes turning up in collaboration pages, spreadsheets, and inboxes is what turned one account into many. Mandate a password manager as the only approved store, move application secrets into a dedicated secrets manager with rotation, and periodically scan collaboration and storage platforms for exposed secrets.
- Lock down MFA enrollment and alert on it. Treat enrolling a new factor as a privileged action, restrict where enrollment QR codes and recovery codes can live, and alert when a new factor is added to an account.
- Treat AI tooling as sensitive infrastructure. Protect and monitor AI assistant configuration the way you protect production config. Pin traffic to sanctioned provider endpoints, alert on configuration changes and auto-loaded extensions, and remind developers that prompts aren’t a safe place for secrets.
- Expire and bind remote-access material. VPN and similar configurations shouldn’t be reusable forever from an inbox. Apply expiry, device binding, and revocation so a leaked file can’t quietly reach the internal network later.
- Watch for session and token theft. VPN and SSO logs are where impossible-travel and MFA-bypass patterns actually show up, along with anomalous OAuth grants. AiTM leaves these traces even when the password and MFA looked legitimate.
- Measure it with a real assessment. A social engineering assessment shows which pretexts land, which controls hold, and how far an attacker actually gets, including whether newer tooling has become a blind spot.
Where UnderDefense fits
Most of what let this chain spread wasn’t the initial phish, it was the silence afterward: a session reused from a new device, a new MFA factor enrolled from a stolen seed, an OAuth grant to a coding assistant nobody was watching. Those are exactly the identity-layer signals most EDR and SOC stacks aren’t built to see. UnderDefense Agentic AI SOC correlates identity, cloud, and SaaS telemetry, including AI developer tooling, so a reused session or a rogue MFA enrollment surfaces as one flagged incident instead of four unrelated log lines. It’s the same pattern our team keeps finding in red-team engagements that start with one phishing email: tools alone don’t close the gap, someone has to be watching what they produce.
See how UnderDefense Agentic AI SOC resolves a real incident on your stack.
A second piece in this series looks at the detection side: the telemetry that catches AiTM session theft, the signals a rogue MFA enrollment leaves behind, and what to watch for in AI developer tooling specifically.
1. What is AiTM (adversary-in-the-middle) phishing?
AiTM phishing uses a reverse proxy positioned between a victim and the real login page. The victim authenticates normally, including MFA, while the proxy captures the resulting session token. Because the token, not the password, is what grants access, the attacker can log in without ever knowing the password or defeating MFA directly.
2. Why does MFA fail against AiTM phishing attacks?
Most MFA methods, one-time codes and push approvals, prove that a second factor was completed, not which site it was completed on. An AiTM proxy lets the victim complete that step for real, then reuses the session it produces. The second factor gets satisfied on the attacker’s behalf, not defeated technically.
3. What makes MFA "phishing-resistant"?
Phishing-resistant MFA, primarily FIDO2/WebAuthn security keys and passkeys, cryptographically binds each login to the real site’s origin at the protocol level. A look-alike domain fails the exchange outright, so there’s no session token left for a proxy to capture or replay.
4. Can email-based or SMS MFA stop AiTM phishing?
No. Both rely on a channel the attacker may already control once a first session is compromised. In this case, an MFA reset email landed directly in an inbox the attacker had access to, and plaintext QR-code enrollment secrets let the assessor re-enroll the same factor on a new device.
5. Should AI coding assistants be treated as sensitive infrastructure?
Yes. An AI assistant’s configuration controls where its traffic goes and what runs alongside it, similar to CI/CD tooling. In this case, redirected traffic and a malicious extension turned a routine developer tool into a way to read prompts and maintain access, without the developers noticing anything had changed.
6. What's the fastest way to reduce AiTM phishing risk?
Moving privileged accounts to FIDO2/WebAuthn hardware keys or passkeys closes the entry point AiTM relies on. It won’t fix plaintext secrets or unmonitored AI tooling by itself, so pair it with the checks in this article rather than treating it as a complete answer.
