AI-Generated Phishing Pages and MFA Session Theft: A Defender's Guide to Detecting and Stopping AiTM Account Takeovers

Fake login pages are the oldest trick in the credential-theft playbook. What's changed in 2026 is not the trick — it's the factory. Generative AI has collapsed the skill, time, and cost required to produce pixel-perfect replicas of trusted login portals, and attackers are using it to clone Microsoft 365, Google Workspace, Okta, banking, and SaaS login screens at scale, tailored to specific organizations and even specific employees.

More importantly, these kits are no longer just password skimmers. Modern adversary-in-the-middle (AiTM) phishing infrastructure proxies the real authentication flow — capturing MFA codes and, critically, the authenticated session cookie issued after successful login. Once an attacker holds that session token, your MFA did exactly nothing. They replay the cookie from their own infrastructure and inherit a fully authenticated session.

If your organization's identity defense strategy is still "we have MFA enabled," this threat class renders that control insufficient. Here's what we're seeing, how to hunt it, and what to do about it.

Why Generative AI Changes the Math for Defenders

From the IR side of the table, the practical impact of AI-generated phishing infrastructure shows up in four ways:

1. Visual fidelity is no longer a detection signal. Tell your users to "look for typos and bad design" and you've just told them nothing. LLM-assisted kits produce flawless markup, correct brand assets scraped dynamically, and even region-appropriate language and localization. The classic "spot the phish" training material from three years ago is actively counterproductive now.

2. Personalization at scale. Attackers feed scraped LinkedIn profiles, breached credential dumps, and corporate email formats into generation pipelines. The result is pre-texting that references real projects, real managers, and real SaaS tenants — including your actual Okta or Microsoft login domain branding.

3. Volume and churn. Phishing kits that used to take a skilled operator days to stand up are now generated in minutes, on freshly registered domains, behind CDN proxies and CAPTCHA gates that block automated sandbox detonation. Domain-reputation-based blocking has a shrinking window of usefulness.

4. MFA capture and session relay. The most dangerous evolution: the phishing page sits between the victim and the real identity provider as a reverse proxy (Evilginx-class tooling). The victim genuinely authenticates — real password, real MFA — but the session token lands in the attacker's hands. This defeats push-based MFA, SMS, and TOTP. Only phishing-resistant authentication (FIDO2/passkeys bound to the origin) structurally breaks this attack.

Attack Chain: How AiTM Account Takeover Works

Understanding the chain is essential because every link is a detection opportunity:

1. Lure delivery — Email, SMS, malvertising, QR code, or direct message links the target to a convincing login page on a lookalike domain (punycode, homoglyph, or long subdomain chains like login-portal.microsoft-auth-verify.example-secure.io).
2. Credential capture — The page proxies the real IdP. The victim's username and password pass through and are logged.
3. MFA relay — The victim approves a push or enters a TOTP code. The attacker's proxy completes the authentication with the real IdP.
4. Session token theft — The IdP issues session cookies (e.g., ESTSAUTH / ESTSAUTHPERSISTENT for Entra ID). The proxy stores them and may serve the victim a real page so nothing seems wrong.
5. Session replay — The attacker imports the stolen cookie into their own browser (often via anti-detect browsers), inheriting the authenticated session from a new IP, device, and geography — with no further authentication required.
6. Persistence and pivoting — Mailbox rules, OAuth consent grants, new MFA method registration, inbox reconnaissance, and lateral phishing from the compromised internal account.

Exploitation status: This is not theoretical. AiTM phishing kits are mature, commercialized, sold as phishing-as-a-service, and confirmed in active campaigns throughout 2025–2026. CISA and Microsoft have both documented large-scale session-cookie theft campaigns targeting enterprises. This is a present-tense problem.

Detection & Response

The bad news first: the phishing page itself lives on attacker infrastructure, so you will rarely see the theft happen on your endpoints. The good news: the consequences are highly observable — anomalous sign-ins, impossible travel, session reuse from new devices, and post-compromise mailbox behavior. That's where your detections should concentrate.

Sigma Rules

The first rule targets proxy/DNS telemetry for lookalike login domains — tune the brand list to what your organization actually uses. The second targets Entra ID sign-in logs for the classic post-AiTM pattern: an authenticated session from a new device/location without a fresh interactive MFA challenge. The third catches a common post-compromise persistence action — suspicious inbox rule creation.

---
title: Lookalike Authentication Portal Domain Access
id: 3f8c1a92-7b44-4e5a-9c1d-2a6b8d0e4f71
status: experimental
description: Detects proxy or DNS access to domains that combine authentication keywords with lookalike or high-risk TLD patterns commonly used by AI-generated phishing kits impersonating enterprise login portals.
references:
  - https://attack.mitre.org/techniques/T1566/002/
  - https://thehackernews.com/2026/10/ai-generated-fake-login-pages-are.html
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1566.002
logsource:
  category: proxy
detection:
  selection_auth_kw:
    cs-uri|contains:
      - 'login'
      - 'signin'
      - 'auth'
      - 'verify'
      - 'account'
  selection_brand:
    cs-host|contains:
      - 'microsoft'
      - 'office365'
      - 'okta'
      - 'google'
      - 'm365'
  filter_legit:
    cs-host|endswith:
      - '.microsoft.com'
      - '.microsoftonline.com'
      - '.office.com'
      - '.office365.com'
      - '.okta.com'
      - '.google.com'
  condition: selection_auth_kw and selection_brand and not filter_legit
falsepositives:
  - Legitimate third-party services using brand names in vanity subdomains; maintain an allowlist after triage
level: high
---
title: Entra ID Session Reuse From New Device Without Interactive Authentication
id: 9d2e7b41-5c38-4f62-a7e3-1b4c6d8f0a25
status: experimental
description: Detects successful Entra ID sign-ins using an existing session token (no fresh interactive auth) from a previously unseen device or location, consistent with stolen session cookie replay following AiTM phishing.
references:
  - https://attack.mitre.org/techniques/T1550/004/
  - https://attack.mitre.org/techniques/T1539/
  - https://thehackernews.com/2026/10/ai-generated-fake-login-pages-are.html
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.credential_access
  - attack.t1539
  - attack.t1550.004
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    status.errorCode: 0
    authenticationRequirement: 'singleFactorAuthentication'
  filter_known:
    deviceDetail.trustType:
      - 'Azure AD joined'
      - 'Hybrid AD joined'
      - 'Compliant'
  condition: selection and not filter_known
falsepositives:
  - Token refresh from unmanaged personal devices in BYOD environments; baseline per user and alert on new country or ASN
level: high
---
title: Suspicious Inbox Rule Created After Login
id: 6a1f4d83-2e97-4c58-b3d6-7c9e1f2a5b84
status: experimental
description: Detects creation of mailbox rules that delete, move, or forward mail - a common persistence and evidence-suppression action immediately following AiTM account takeover.
references:
  - https://attack.mitre.org/techniques/T1098/002/
  - https://attack.mitre.org/techniques/T1114/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1098.002
  - attack.collection
  - attack.t1114.003
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName: 'New-InboxRule'
    parameters|contains:
      - 'DeleteMessage'
      - 'ForwardTo'
      - 'ForwardAsAttachmentTo'
      - 'RedirectTo'
      - 'MoveToFolder'
  condition: selection
falsepositives:
  - Legitimate user-created forwarding or filing rules; investigate when correlated with new sign-in locations
level: medium

KQL — Microsoft Sentinel / Defender

This hunt looks at network telemetry for connections to suspected lookalike login domains, and pairs endpoint context for users who may have just entered credentials into a phishing page. Run it against proxy logs ingested via CEF and Defender network events:

let LookalikePattern = @"(?i)(login|signin|auth|verify|account|sso|portal).*(microsoft|office365|okta|google|m365)";
let LegitSuffixes = dynamic([".microsoft.com",".microsoftonline.com",".office.com",".office365.com",".okta.com",".google.com",".live.com"]);
let SuspectDomains =
    CommonSecurityLog
    | where TimeGenerated > ago(7d)
    | where RequestURL matches regex LookalikePattern or DestinationHostName matches regex LookalikePattern
    | extend Host = coalesce(DestinationHostName, tostring(split(RequestURL, "/")[2]))
    | where not(Host has_any (LegitSuffixes))
    | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Hits=count(), Users=make_set(SourceUserID), SampleURL=any(RequestURL) by Host;
SuspectDomains
| join kind=leftouter (
    DeviceNetworkEvents
    | where TimeGenerated > ago(7d)
    | where RemoteUrl matches regex LookalikePattern
    | summarize EndpointHits=count(), Devices=make_set(DeviceName), Processes=make_set(InitiatingProcessFileName) by RemoteUrl
) on $left.Host == $right.RemoteUrl
| project Host, FirstSeen, LastSeen, ProxyHits=Hits, Users, EndpointHits, Devices, Processes, SampleURL
| order by EndpointHits desc;

If you ingest Entra sign-in logs, correlate any user who appears in Users against SigninLogs for new-IP or new-device authentications within 24 hours of the visit — that join is your confirmed AiTM compromise indicator, and it should page someone.

Velociraptor VQL

This artifact hunts endpoints for evidence of phishing lure artifacts — .url shortcut files and HTML files dropped in user download directories that redirect to lookalike authentication domains. These survive even when the user never admits to clicking:

-- Hunt for phishing lure artifacts (.url shortcuts and HTML redirects) referencing lookalike auth domains
LET lure_files = SELECT FullPath, Size, Mtime
FROM glob(globs='C:/Users/*/Downloads/*.url', accessor='ntfs')
WHERE Mtime > now() - 604800

LET url_content = SELECT FullPath, Mtime,
       read_file(filename=FullPath, accessor='ntfs', length=4096) AS Content
FROM lure_files

SELECT FullPath, Mtime, Content
FROM url_content
WHERE Content =~ '(?i)(login|signin|auth|verify).*(microsoft|office365|okta|google)'
   AND Content =~ 'http'

Extend the glob to *.html and *.htm in Downloads and Temp for HTML-attachment lures, and to the Desktop for users who save lures before opening them.

Hardening and Verification Script

The single most effective control against AiTM session theft is phishing-resistant MFA. This PowerShell audits a Microsoft 365 tenant (via Microsoft Graph) for users whose registered authentication methods are phishable (password + SMS/voice/TOTP/push) versus phishing-resistant (FIDO2, Windows Hello for Business, certificate-based auth), giving you a prioritized remediation list:

# Requires: Microsoft.Graph PowerShell SDK, scopes: UserAuthenticationMethod.Read.All
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All" -NoWelcome

$phishable   = @('microsoft.graph.passwordAuthenticationMethod',
                 'microsoft.graph.phoneAuthenticationMethod',
                 'microsoft.graph.softwareOathAuthenticationMethod',
                 'microsoft.graph.microsoftAuthenticatorAuthenticationMethod')
$resistant   = @('microsoft.graph.fido2AuthenticationMethod',
                 'microsoft.graph.windowsHelloForBusinessAuthenticationMethod',
                 'microsoft.graph.certificateBasedAuthenticationMethod')

$users = Get-MgUser -All -Property "id,userPrincipalName,displayName"
$report = foreach ($u in $users) {
    $methods = (Get-MgUserAuthenticationMethod -UserId $u.Id).AdditionalProperties.'@odata.type'
    $hasResistant = ($methods | Where-Object { $resistant -contains $_ }).Count -gt 0
    [PSCustomObject]@{
        UserPrincipalName   = $u.UserPrincipalName
        DisplayName         = $u.DisplayName
        Methods             = ($methods -replace 'microsoft.graph.','') -join '; '
        PhishingResistant   = $hasResistant
    }
}

$report | Where-Object { -not $_.PhishingResistant } |
    Export-Csv -Path ".\Users_Without_PhishingResistantMFA.csv" -NoTypeInformation
Write-Host "$($report.Count) users audited. $(($report | Where-Object {-not $_.PhishingResistant}).Count) lack phishing-resistant MFA. Export written."

Remediation: What Actually Stops This

Ranked by impact against AiTM session theft specifically:

1. Deploy phishing-resistant MFA for everyone who touches anything sensitive. FIDO2 security keys and passkeys are cryptographically bound to the legitimate origin — a reverse proxy on a lookalike domain cannot relay them, full stop. Prioritize admins, finance, executives, and helpdesk staff. This is the only control that structurally defeats the attack rather than detecting it after the fact.

2. Enforce Conditional Access token protection and device compliance. In Entra ID, require token protection (binding sign-in session tokens to the device) and require compliant/hybrid-joined devices for access to cloud apps. A stolen session cookie replayed from attacker infrastructure fails both checks. Microsoft documents these under Conditional Access session controls — implement per Microsoft's guidance on token protection.

3. Shorten session lifetimes and enable Continuous Access Evaluation. Reduce persistent session cookie validity, require re-authentication for sensitive actions, and enable CAE so revoked sessions die in near-real-time rather than persisting for hours.

4. Lock down email authentication to reduce lure delivery. Enforce DMARC at p=reject, monitor lookalike domain registrations via a brand-monitoring service, and configure Defender for Office 365 (or your SEG) to flag first-time-seen domains and domains impersonating your login portals.

5. Kill the post-compromise playbooks. Alert on and restrict inbox forwarding rules to external addresses, OAuth consent grants (require admin consent workflows), and new MFA method registration (require it to occur from a compliant device or network location).

6. Retrain against the new reality. Update phishing awareness content: the lesson is no longer "spot the bad design" — it's "verify the URL, never authenticate from a link, report immediately even if you completed login." Speed of reporting is what lets you revoke sessions before the pivot.

7. Rehearse the IR playbook. Your runbook for suspected session theft should be muscle memory: revoke all refresh tokens (Revoke-MgUserSignInSession or portal equivalent), force password reset, review and remove rogue inbox rules and OAuth grants, audit sign-in logs for the replay window, and check for downstream phishing sent from the compromised account.

Bottom Line

Generative AI hasn't invented a new attack — it has removed every friction that used to limit an old one. Credential phishing is now high-fidelity, personalized, and MFA-aware. Defenders who keep treating MFA as the finish line will keep reading about their own incidents. The finish line moved: phishing-resistant authentication, token protection, and aggressive session anomaly detection are the controls that matter in 2026. Deploy them before the next perfectly rendered login page lands in your users' inboxes.

Related Resources

Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub