N0va Phishkit: Defending Against AiTM Phishing

What the N0va Phishkit Is and Why It Matters

Security researchers have documented a new phishing kit called N0va that is actively targeting organizations across North America and Europe. What sets N0va apart from garden-variety credential harvesting is not its lures — it impersonates trusted services, which nearly every phishkit does — but its mechanics: it abuses legitimate authentication flows so that the victim completes a real sign-in while the attacker sits in the middle of the session.

This class of attack, commonly called adversary-in-the-middle (AiTM) phishing, matters because it breaks an assumption many organizations still depend on: that multifactor authentication stops phishing. It does not. When an attacker proxies a live session between the victim and a legitimate identity provider, the session cookie issued to the victim is just as useful to the attacker who steals it. This article explains how kits like N0va work and what practitioners should actually do about them.

How AiTM Phishing Kits Work

Traditional phishing kits serve a cloned login page, collect credentials, and ship them to the attacker for later use. AiTM kits add a real-time relay. The typical sequence:

1. Delivery: The victim receives a message that mimics a trusted service, with a link to a domain the attacker controls.
2. Proxy: The kit acts as a reverse proxy, fetching the real login page and rendering it to the victim in near real time.
3. Capture: Everything the victim submits — password, one-time code, push approval — passes through the proxy.
4. Token theft: When authentication completes, the proxy captures the session cookie or token issued by the legitimate identity provider.
5. Replay: The attacker replays that token from their own infrastructure to access the account, often within minutes.

Two consequences follow. First, credentials are no longer the main prize; session tokens are, because a replayed token skips the MFA step entirely. Second, the login page the victim sees is not a clumsy clone — it is the real service fetched live — which is why user awareness alone has limited value against these kits.

Detecting AiTM Activity in Your Environment

AiTM sessions are hard to spot with endpoint controls alone, but they leave traces in your identity logs. Focus detection on anomalies around authentication events and token usage:

• Impossible travel: a legitimate sign-in from the user’s location, followed within minutes by token replay from attacker infrastructure elsewhere.
• Token reuse from anomalous locations: tokens consumed from IPs or ASNs that do not match your user base, or from hosting providers and VPN exit nodes.
• User-agent mismatches: one browser for the login, a different client or scripted agent for the replay.
• Out-of-pattern sign-in frequency: AiTM kits typically replay immediately, so watch for rapid, unusual authentication bursts.
• New MFA enrollments: attackers who hold a session sometimes register their own authentication method to persist access.

In Microsoft Entra environments, a KQL query like the one below surfaces sign-ins where a single correlation ID shows up from multiple locations or IPs:

SigninLogs
| where ResultType == 0
| summarize Locations = make_set(Location), IPs = make_set(IPAddress)
    by UserPrincipalName, CorrelationId
| where array_length(Locations) > 1 or array_length(IPs) > 1

Treat every valid session token as a credential. If a token appears where it should not, assume it was stolen.

Defense in Depth: A Practical Checklist

No single control stops AiTM phishing. Work through this checklist from the highest-impact items down to the hygiene that makes the rest stick.

1. Deploy phishing-resistant MFA. Passkeys and FIDO2 security keys bind authentication to the domain the user is really talking to. A proxied login cannot satisfy the cryptographic challenge, so the token the attacker wants is never issued.
2. Restrict weaker methods where FIDO2 is not yet possible. Disable SMS and voice one-time codes, limit push approvals, and require number matching so users approve the specific sign-in they see on screen.
3. Require compliant, managed devices for sensitive apps. Conditional access policies that demand a healthy, enrolled device narrow the replay window, because a stolen token is useless without the device posture.
4. Bind and shorten sessions. Enforce location-based or device-based session binding and reduce token lifetimes for high-value applications.
5. Block short-lived phishing infrastructure. Feed DNS and proxy filters with newly observed and lookalike domains; AiTM kits depend on fresh infrastructure.
6. Harden mail flow. Enforce SPF, DKIM, and DMARC, and flag external mail that impersonates internal brands or services.
7. Simulate the attack yourself. Use red team exercises or open-source frameworks such as Evilginx to reproduce the AiTM path and validate your detections and playbooks before an adversary does.
8. Keep one awareness rule front and center: the URL. Teach staff to check the domain before entering anything and to report any sign-in that lands on an unfamiliar domain, even if the page looks perfect.

Responding When a Session Is Stolen

When you confirm or suspect token theft, speed matters, because AiTM attackers often act within minutes of a successful login.

1. Revoke the session, not just the password. Password resets do not kill stolen cookies. Revoke all sessions for the user and force re-authentication.
2. Force MFA re-registration. If the attacker enrolled their own method, simple re-authentication is not enough.
3. Hunt what the token touched. Review sign-in and audit logs for the compromised session, and treat every application it accessed as potentially affected.
4. Inspect mailbox rules and forwarding. Post-compromise persistence often includes inbox rules that hide or redirect attacker mail.
5. Review OAuth consent grants. Attackers sometimes register or consent to malicious apps that survive session revocation.
6. Run your IR playbook. Preserve logs and treat a confirmed AiTM compromise as a credential and data exposure event until evidence says otherwise.

N0va is not an exotic zero-day. It is a polished example of a trend that has been building for years: kits that proxy live authentication sessions and neutralize the MFA defenses most organizations worked hard to deploy. The answer is not to abandon MFA but to make it phishing-resistant, bind access to devices and networks, shrink what a stolen token can reach, and rehearse revocation and hunting steps so that when the alert fires, your team executes in minutes instead of days.