A new phishing kit tracked as N0va is actively targeting organizations across North America and Europe, and it represents the latest evolution in a threat class that should concern every identity security team: adversary-in-the-middle (AiTM) phishing that defeats multi-factor authentication. Rather than dropping obvious malware, N0va campaigns impersonate trusted services and abuse legitimate authentication flows — proxying the victim's real login session, capturing the resulting session token, and replaying it from attacker infrastructure. The outcome is a fully authenticated session on a valid account with no malicious binary on the endpoint, no brute-force noise in your logs, and MFA technically 'satisfied.'
From that single compromised identity, attackers can pivot into email, SharePoint/OneDrive data, SaaS business applications, and additional cloud tenants. We've seen this playbook in IR engagements repeatedly over the past two years — kits like Evilginx, Tycoon 2FA, and Rockstar 2FA normalized token theft; N0va continues the trend with more convincing social engineering and tighter abuse of legitimate SSO flows. If your detections still assume MFA equals trust, you have a gap. This post breaks down how these campaigns work, what to hunt for, and how to harden your identity stack against token replay.
Technical Analysis
How N0va-Style AiTM Phishing Works
N0va operates as a reverse-proxy phishing framework. The attack chain, from a defender's perspective, looks like this:
- Lure delivery: Victims receive emails impersonating trusted services — Microsoft 365 document shares, voicemail notifications, HR portals, DocuSign-style signature requests, or IT password-expiry notices. Sender infrastructure frequently abuses legitimate marketing/ESP platforms to pass SPF/DKIM and evade secure email gateways.
- Redirect chain: Links route through multiple benign-looking redirects (compromised WordPress sites, URL shorteners, or open redirects on trusted domains) before landing on the phishing proxy.
- Reverse-proxy interception: The N0va server sits transparently between the victim and the genuine identity provider (Microsoft Entra ID / login.microsoftonline.com, Okta, or Google). The victim sees the real login page — because it is the real page, proxied in real time. Credentials and the MFA response pass through the attacker.
- Session token capture: Upon successful authentication, the IdP issues session cookies and OAuth tokens (e.g., the
ESTSAUTH/ESTSAUTHPERSISTENTcookies for Entra ID, or refresh/access tokens). N0va captures these server-side. - Token replay: The attacker imports the stolen session cookie into their own browser or tooling and accesses the victim's cloud resources directly. Critically, sign-in logs show the original authentication as legitimate — MFA was completed. Subsequent access from attacker infrastructure may appear as non-interactive token usage with the MFA claim already satisfied.
- Persistence and expansion: Attackers commonly register their own MFA methods, add inbox rules to hide conversations, grant OAuth consent to malicious applications, and launch internal BEC or lateral phishing from the now-trusted account.
Why This Defeats Conventional MFA
SMS, TOTP apps, and even push-based MFA are all vulnerable to real-time proxying because the response is relayed, not just the password. Only phishing-resistant authentication — FIDO2 security keys, Windows Hello for Business, certificate-based authentication, and passkeys bound to the legitimate origin — cryptographically prevents the credential from being replayed on a lookalike domain. Additionally, token protection (token binding) in Conditional Access ties session tokens to the device, breaking replay from attacker infrastructure even after theft.
Exploitation Status
- Status: Confirmed active exploitation in the wild, targeting business users across North America and Europe.
- No CVE: This is a technique-level threat (MITRE ATT&CK T1557 – Adversary-in-the-Middle, T1539 – Steal Web Session Cookies, T1550.004 – Use Alternate Authentication Material: Web Session Cookie), not a software vulnerability. There is no patch — the fix is architectural.
- Delivery vectors: Email lures, QR codes (quishing), and malicious ads/SEO poisoning impersonating trusted SaaS brands.
Detection & Response
The harsh reality of AiTM phishing: your best telemetry is in the identity layer (sign-in logs, token claims, conditional access evaluation) and the email/proxy layer (lure delivery, redirect chains), not the endpoint. The rules below target the observable behaviors these campaigns produce.
Sigma Rules
---
title: AiTM Phishing Proxy Domain Patterns Targeting Microsoft 365 Login
description: Detects HTTP requests to lookalike authentication domains consistent with AiTM reverse-proxy phishing kits (e.g., N0va) impersonating Microsoft Entra ID login infrastructure. Typosquat and concatenated patterns such as 'login-microsoftonline', 'microsoftonline-login', or IdP branding embedded in non-Microsoft domains are high-fidelity indicators.
logsource:
category: proxy
product: webserver
detection:
selection_brand:
c-uri|contains:
- '/common/oauth2/'
- '/oauth2/authorize'
- 'login.microsoftonline'
- 'login.live.com'
selection_lookalike:
cs-host|contains:
- 'login-microsoftonline'
- 'microsoftonline-'
- 'office365-'
- '-office365'
- 'microsoft-login'
- 'login-office'
- 'okta-verify-'
- '-okta.login'
filter_microsoft_ip:
cs-host|endswith:
- '.microsoftonline.com'
- '.microsoft.com'
- '.live.com'
- '.okta.com'
condition: (selection_brand and not filter_microsoft_ip) or (selection_lookalike and not filter_microsoft_ip)
fields:
- c-ip
- cs-host
- c-uri
- cs-referrer
- sc-status
falsepositives:
- Legitimate third-party integrations redirecting to Microsoft login (rare when hostname is a lookalike)
level: high
tags:
- attack.initial_access
- attack.t1566.002
- attack.t1557
- attack.collection
status: experimental
author: Security Arsenal
date: 2026/09/15
---
title: Suspicious Process Access to Browser Session Cookie Stores
description: Detects non-browser processes accessing Chrome/Edge/Brave cookie databases or the Local State file, consistent with post-compromise session cookie theft tooling. Relevant to AiTM intrusions where attackers additionally loot local session material, and to infostealer follow-on activity after successful phishing.
logsource:
category: file_event
product: windows
detection:
selection:
TargetFilename|contains:
- '\AppData\Local\Google\Chrome\User Data\Default\Cookies'
- '\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies'
- '\AppData\Local\Microsoft\Edge\User Data\Default\Cookies'
- '\AppData\Local\Microsoft\Edge\User Data\Default\Network\Cookies'
- '\AppData\Local\Google\Chrome\User Data\Local State'
- '\AppData\Local\Microsoft\Edge\User Data\Local State'
filter_browsers:
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\brave.exe'
- '\firefox.exe'
condition: selection and not filter_browsers
fields:
- Image
- TargetFilename
- User
- ProcessId
falsepositives:
- Endpoint backup or EDR tooling legitimately scanning user profiles
- Browser extension sync utilities
level: high
tags:
- attack.credential_access
- attack.t1539
status: experimental
author: Security Arsenal
date: 2026/09/15
---
title: OAuth Application Consent Grant with High-Risk Mail and Graph Scopes
description: Detects 'Consent to application' events in Azure audit logs where delegated permissions such as Mail.Read, Mail.Send, Files.ReadWrite.All, or offline_access are granted — a common persistence and data-access step after AiTM account compromise.
logsource:
product: azure
service: auditlogs
detection:
selection_operation:
operationName: 'Consent to application'
selection_scopes:
properties.targetResources|contains:
- 'Mail.Read'
- 'Mail.Send'
- 'Mail.ReadWrite'
- 'Files.ReadWrite.All'
- 'offline_access'
- 'User.Read.All'
- 'Directory.Read.All'
condition: all of selection_*
fields:
- initiatedBy.user.userPrincipalName
- properties.targetResources
- additionalDetails
- result
falsepositives:
- Legitimate enterprise app onboarding — baseline approved publishers and correlate with change records
level: medium
tags:
- attack.persistence
- attack.t1528
- attack.collection
status: experimental
author: Security Arsenal
date: 2026/09/15
Analyst note on Rule 1: The lookalike-host condition is the high-fidelity path. Legitimate Microsoft auth traffic always terminates on Microsoft-owned hostnames; a request carrying /common/oauth2/ path structure to any other host is either phishing or a broken integration — both warrant investigation.
KQL — Microsoft Sentinel / Defender Hunting
The following query hunts for the signature pattern of AiTM token replay: a successful authentication where MFA was satisfied via a previously completed claim (token reuse), from an IP/ASN the user has never authenticated from, within a short window of an interactive sign-in from a different network. Tune the lookback window and known-IP baseline for your environment.
// Hunt for AiTM session token replay: MFA-claim reuse from novel infrastructure
let lookback = 14d;
let huntwindow = 24h;
let KnownIPs =
SigninLogs
| where TimeGenerated between (ago(lookback) .. ago(huntwindow))
| where ResultType == 0
| summarize by UserPrincipalName, IPAddress, tostring(NetworkLocationDetails);
SigninLogs
| where TimeGenerated > ago(huntwindow)
| where ResultType == 0
| where AuthenticationRequirement == "multiFactorAuthentication"
// MFA satisfied by claim in token rather than fresh factor — classic token replay indicator
| extend AuthDetails = tostring(Status)
| extend MfaDetail = todynamic(MfaDetail)
| where MfaDetail.authMethod =~ "Previously satisfied" or tostring(MfaDetail) contains "Previously satisfied"
| extend ASN = tostring(NetworkLocationDetails)
| join kind=leftanti (KnownIPs) on UserPrincipalName, IPAddress
| extend RiskState = tostring(RiskState), RiskDetail = tostring(RiskDetail)
| project TimeGenerated, UserPrincipalName, IPAddress, ASN, Location, AppDisplayName,
DeviceDetail, Browser, OS, AuthenticationRequirement, RiskState, RiskDetail, CorrelationId
| sort by TimeGenerated desc
Companion hunt — inbox rules created shortly after anomalous sign-ins (BEC staging behavior we consistently observe post-AiTM compromise):
// Inbox rule creation following suspicious sign-in — BEC / mail hiding behavior
let SuspiciousSignins =
SigninLogs
| where TimeGenerated > ago(24h)
| where RiskState in ("atRisk", "confirmedCompromised")
or RiskDetail has_any ("anonymizedIPAddress", "unfamiliarFeatures", "unlikelyTravel")
| summarize SigninTime=min(TimeGenerated), SigninIP=make_set(IPAddress) by UserPrincipalName, CorrelationId;
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("New-InboxRule", "Set-InboxRule", "UpdateInboxRules")
| extend UserId = tostring(UserId)
| extend Params = todynamic(Parameters)
| mv-expand Params
| extend RuleName = tostring(Params.Value)
| join kind=inner (SuspiciousSignins) on $left.UserId == $right.UserPrincipalName
| where TimeGenerated between (SigninTime .. SigninTime + 6h)
| project TimeGenerated, UserId, Operation, RuleName, ClientIP, SigninIP, ResultStatus
Velociraptor VQL
For endpoint-side triage after a suspected compromise — hunting for processes (other than the browser itself) reading browser session cookie stores, which catches both cookie-theft tooling and post-phishing infostealer follow-on:
-- Hunt: Non-browser processes accessing browser session cookie stores
-- Deploy as a notebook query or artifact (Generic.Forensics.LocalHunt style)
LET browser_paths = {
SELECT * FROM split(string='''
C:/Users/*/AppData/Local/Google/Chrome/User Data/Default/Network/Cookies
C:/Users/*/AppData/Local/Microsoft/Edge/User Data/Default/Network/Cookies
C:/Users/*/AppData/Local/Google/Chrome/User Data/Local State
C:/Users/*/AppData/Local/Microsoft/Edge/User Data/Local State''', sep='\n')
}
LET cookie_files = SELECT FullPath, Size, Mtime, Btime
FROM glob(globs='C:/Users/*/AppData/{Local/ Google,Local/Microsoft}*/**/Cookies')
WHERE Size > 0
-- Enumerate processes with handles/command lines referencing cookie paths
LET proc_hits = SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(Cookies|Local State|Network\\\\Cookies)'
AND NOT Exe =~ '(?i)(chrome|msedge|brave|firefox)\.exe$'
SELECT 'ProcessAccess' AS FindingType,
Pid, Name, Exe, CommandLine, Username, CreateTime,
'' AS FilePath, '' AS Mtime
FROM proc_hits
UNION ALL
SELECT 'RecentCookieStoreModification' AS FindingType,
0 AS Pid, '' AS Name, '' AS Exe, '' AS CommandLine, '' AS Username,
'' AS CreateTime,
FullPath AS FilePath, Mtime
FROM cookie_files
WHERE Mtime > Now() - 86400 -- modified in last 24h; correlate with incident window
Remediation and Hardening Script
The following PowerShell (requires Microsoft.Graph modules, run with an appropriately scoped admin account) audits Conditional Access posture for token protection, revokes sessions for flagged users, and surfaces risky OAuth consent grants — the three fastest wins after a suspected AiTM compromise:
#Requires -Modules Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Users
# N0va / AiTM Phishing Response & Hardening Script — Security Arsenal
# Run with: Connect-MgGraph -Scopes "Policy.Read.All","User.Read.All","Directory.Read.All","UserRevokeSessions.All"
Connect-MgGraph -Scopes "Policy.Read.All","User.Read.All","Directory.Read.All","UserRevokeSessions.All" -NoWelcome
# 1) Audit Conditional Access policies for token protection / phishing-resistant MFA coverage
Write-Host "`n=== Conditional Access Policy Audit ===" -ForegroundColor Cyan
$caPolicies = Get-MgIdentityConditionalAccessPolicy -All
$tokenProtection = $caPolicies | Where-Object {
$_.State -eq 'enabled' -and
($_.SessionControls.SecureSignInSession -ne $null -or $_.GrantControls.AuthenticationStrength -ne $null)
}
if (-not $tokenProtection) {
Write-Warning "No enabled CA policy enforces token protection or an authentication strength (phishing-resistant MFA). This is the primary gap N0va exploits."
} else {
$tokenProtection | Select-Object DisplayName, State | Format-Table
}
# 2) Revoke sessions for users flagged as risky or confirmed compromised
Write-Host "`n=== Revoking Sessions for At-Risk Users ===" -ForegroundColor Cyan
$riskyUsers = Get-MgIdentityProtectionRiskyUser -Filter "riskState eq 'atRisk' or riskState eq 'confirmedCompromised'" -All
foreach ($u in $riskyUsers) {
Invoke-MgInvalidateUserRefreshToken -UserId $u.Id
Write-Host "Revoked refresh tokens: $($u.UserPrincipalName) [$($u.RiskLevel)]" -ForegroundColor Yellow
}
# 3) Hunt for risky OAuth consent grants (persistence after AiTM compromise)
Write-Host "`n=== OAuth Consent Grant Audit (high-risk scopes) ===" -ForegroundColor Cyan
$highRiskScopes = 'Mail.Read','Mail.Send','Mail.ReadWrite','Files.ReadWrite.All','offline_access','Directory.Read.All'
$grants = Get-MgOauth2PermissionGrant -All
foreach ($g in $grants) {
foreach ($scope in $highRiskScopes) {
if ($g.Scope -match [regex]::Escape($scope)) {
$sp = Get-MgServicePrincipal -ServicePrincipalId $g.ClientId -ErrorAction SilentlyContinue
[PSCustomObject]@{
AppDisplayName = $sp.DisplayName
Publisher = $sp.PublisherName
Scope = $g.Scope
ConsentType = $g.ConsentType
CreatedTime = $sp.CreatedDateTime
}
}
}
}
# 4) Verify legacy auth is blocked (AiTM kits also abuse IMAP/POP fallback)
Write-Host "`n=== Legacy Auth Check ===" -ForegroundColor Cyan
$legacyBlocked = $caPolicies | Where-Object {
$_.State -eq 'enabled' -and
$_.Conditions.ClientAppTypes -contains 'exchangeActiveSync' -and
$_.GrantControls.BuiltInControls -contains 'block'
}
if (-not $legacyBlocked) { Write-Warning "Legacy authentication is not blocked tenant-wide. Block it now." }
else { Write-Host "Legacy auth block policy present." }
Disconnect-MgGraph
Remediation
There is no patch for N0va — it abuses authentication as designed. Remediation is architectural, and these steps are ordered by impact:
- Deploy phishing-resistant MFA now. Enforce FIDO2 security keys, Windows Hello for Business, or passkeys for all users — prioritize admins and finance/executive staff. Configure an Authentication Strength in Entra ID Conditional Access that permits only phishing-resistant methods for sensitive applications. Reference: Microsoft — Phishing-resistant MFA and CISA — Phishing-Resistant MFA guidance.
- Enable token protection (token binding). Conditional Access session controls for token protection cryptographically bind sign-in session tokens to the device, rendering stolen cookies useless on attacker infrastructure. Currently supported for Exchange Online and SharePoint Online on Windows devices — enable it for your highest-value workloads first. Reference: Microsoft — Conditional Access token protection.
- Block legacy authentication tenant-wide and audit for IMAP/POP/SMTP AUTH usage — AiTM actors routinely test legacy protocol fallback after stealing credentials.
- Tighten Conditional Access sign-in risk policies: require compliant device + phishing-resistant auth when Entra ID Protection flags risk; block access from anonymizing proxies/Tor; enable continuous access evaluation (CAE) so revoked tokens die in near-real-time rather than at the 1-hour refresh boundary.
- Restrict OAuth consent. Disable user consent entirely or move to admin-consent workflow; enable app consent policies so only verified publishers with low-risk scopes can be granted. Audit existing grants with the script above — Mail.Read on an unknown app is persistence, not productivity.
- Contain compromised identities immediately (per our IR playbook): revoke all refresh tokens and sessions (
Invoke-MgInvalidateUserRefreshToken/ "Revoke sessions" in the portal), reset credentials, remove attacker-added MFA methods (checkauthenticationMethodson the user object — this step is frequently missed and leaves a backdoor), delete malicious inbox rules, and review 7 days ofOfficeActivityfor data access and outbound mail. - Email and web controls: deploy DMARC enforcement (p=reject), enable Safe Links/URL rewrite with click-time detonation, block newly-registered domains at the web proxy (the vast majority of AiTM kit infrastructure is under 30 days old), and alert on — don't just block — clicks to uncategorized login-themed pages.
- Tabletop the scenario. AiTM compromise compresses the timeline: token replay can occur within seconds of the victim completing MFA. Your IR runbook must treat "successful MFA + unfamiliar IP + risk signal" as a confirmed compromise trigger, not an anomaly queue item.
The bottom line: N0va and kits like it exploit a trust model, not a bug. Every control above closes a specific link in the replay chain — and until phishing-resistant authentication and token binding are enforced, your MFA numbers on a dashboard are measuring the wrong thing.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.