Secure Scroll

Ten years ago, phishing was a fake login page and a gamble that someone would fall for it. Today, attackers do not need you to fall for anything — they sit silently between you and the real login page, wait for you to complete MFA yourself, and steal your session the moment you are done. This article breaks down how phishing got here and what defenders can do about it.

Where It All Started — The HTML Clone Era

The original phishing kit was exactly what it sounds like. An attacker would:

1. Download the HTML of a real login page — Gmail, PayPal, a bank
2. Modify the form to send credentials to their own server
3. Host it on a cheap or compromised domain
4. Send mass emails pointing victims to it

That was it. The whole thing could be set up in an afternoon. Kits were sold on forums for a few dollars — a zip file with HTML, CSS, and a PHP script to capture passwords.

The problem for attackers: These kits only stole passwords. Once organizations started rolling out MFA, a stolen password alone stopped being enough. They had to adapt.

The First Upgrade — Fake MFA Pages

The first response to MFA was simple — just add another fake page. After the victim entered their password, they were shown a fake MFA prompt asking for their one-time code. The attacker would grab that code, log into the real service with the stolen password and code — all within the 30-second window before it expired.

It worked, but it was clunky. Someone had to be watching, manually copying codes, racing the clock. It did not scale.

The next problem: Attackers needed something that could do this automatically, for thousands of victims at the same time, without anyone sitting at a keyboard watching.

 The Game Changer — Reverse Proxy Phishing (AiTM)

This is where things got genuinely dangerous. Instead of showing a fake page, the attacker’s server became a silent relay — sitting between the victim and the real website, passing everything through.

Here is how it works:

Normal login:
  You → Microsoft login page → Authenticated ✓
AiTM phishing:
  You → Attacker's proxy → Microsoft login page → Authenticated ✓
                ↓
         Attacker silently copies your session token

The Phishing Kit Ecosystem Today

What started as a clever technical trick became an entire criminal industry. Here is where things stand:

This is not a shadowy underground anymore. Tycoon 2FA charged $120 for 10 days and $350 for a month — with a web dashboard, pre-built Microsoft 365 and Gmail templates, campaign tracking, and support. It ran like a SaaS business. A criminal one, but a business.

The OAuth Device-Code Attack — The Newest Trick

Just as defenders started catching up to AiTM proxies, a new approach emerged that does not even need a fake login page.

How it works:

OAuth device-code flow was designed for devices without keyboards — smart TVs, printers — where typing a password is not practical. The device shows you a short code, you go to a real URL on your phone or laptop, enter the code, and the TV gets signed in.

Attackers turned this against users:

1. Attacker generates a real device-code request to Microsoft
2. Sends the victim an email: “Please verify your device at microsoft.com/devicelogin — code: ABC123”
3. Victim goes to the real Microsoft page, enters the real code
4. Microsoft authenticates the attacker’s device

The victim did everything correctly. They went to a real Microsoft URL. They entered a real code. And they just handed the attacker persistent access to their account — no session token to expire, no time pressure.

Detection — The Signals AiTM Leaves Behind

AiTM is difficult to catch at the email layer. The real detection opportunity is in what happens right after authentication.

.

Rule 1 — Impossible Travel Detection

Real users do not log in from two countries within minutes. If a session shows up in two places that fast, the token has been stolen. Fires when the same account authenticates from one country and then the active session appears from a different country within 10 minutes.

title: AiTM - Impossible Travel Session Reuse
logsource:
  product: azure
  service: signin_logs
detection:
  selection:
    ResultType: 0
    TokenIssuerType: AzureAD
  condition: same UserPrincipalName with different CountryOrRegion within 10m
level: critical
tags:
  - attack.credential_access
  - attack.t1539

Rule 2 — New MFA Method Registered After Login

After stealing a session, attackers register their own MFA device immediately — so they keep access even if the victim resets their password. Fires when a new authentication method is added to an account within 1 hour of a fresh sign-in. Users almost never register new MFA devices the moment they log in.

title: AiTM - MFA Method Added After Login
logsource:
  product: azure
  service: audit_logs
detection:
  selection:
    OperationName: "Update user"
    TargetResources|contains: "StrongAuthenticationMethod"
  condition: selection within 1h of successful sign-in by same user
level: high
tags:
  - attack.persistence
  - attack.t1098.005

Rule 3 — Suspicious Inbox Rule After Authentication

Creating inbox rules right after logging in is one of the most consistent attacker behaviors — hiding replies, forwarding emails out, deleting security alerts before the victim sees them. Fires when an inbox rule that forwards, deletes, or moves emails is created shortly after a login event.

title: AiTM - Suspicious Inbox Rule Post Authentication
logsource:
  product: microsoft365
  service: exchange
detection:
  selection:
    Operation: "New-InboxRule"
    Parameters|contains:
      - 'ForwardTo'
      - 'DeleteMessage'
      - 'MoveToFolder'
  condition: selection within 30m of successful sign-in by same user
level: high
tags:
  - attack.collection
  - attack.t1114.003

Rule 4 — OAuth Consent from Unverified Publisher

Device-code phishing ends with the victim granting consent to an attacker-controlled OAuth app. Legitimate enterprise apps are almost always verified — an unverified one is a red flag. Fires when a user consents to an OAuth application from an unverified publisher.

title: AiTM - OAuth Consent by Unverified Publisher
logsource:
  product: azure
  service: audit_logs
detection:
  selection:
    OperationName: "Consent to application"
    TargetResources|contains: "IsVerified: false"
  condition: selection
level: high
tags:
  - attack.initial_access
  - attack.t1566

MITRE ATT&CK Mapping

What Actually Stops AiTM

Most MFA does not stop AiTM. Here is what does:

The uncomfortable truth: SMS codes, push notifications, and TOTP apps like Google Authenticator do nothing against AiTM. They protect the login moment. AiTM skips past the login moment entirely. FIDO2 is currently the only widely available MFA method that holds up — because the authentication is bound to the real domain and cannot be relayed through a proxy.

Final Thought

Phishing used to be about tricking people into handing over passwords. Now it is about letting people log in normally — and stealing the proof of that login.

Defenders who are still focused entirely on stopping credential theft are a step behind. The real question in 2026 is not whether your users have MFA. It is whether your MFA can survive a proxy sitting between your users and your identity provider — and whether anyone is watching what happens in the first few minutes after a successful login.

That is where attacks are landing now.