Traditional phishing was simple: send a fake login page, steal a password, log in. Multi-factor authentication (MFA) made that much harder… so attackers evolved. Modern attackers are increasingly using Adversary-in-the-Middle (AiTM) and Browser-in-the-Middle (BitM) techniques:
- They sit between the user and the real service with a reverse proxy, relaying traffic.
- They steal session cookies or tokens as the user logs in, then replay those tokens to bypass MFA entirely.
Two tools that keep showing up in real-world attack reporting are Evilginx (AiTM) and EvilnoVNC (BitM). Let's unpack how they're abused at a high level and then how to defend.
Evilginx: The Cookie Thief Sitting Between You and the Cloud
Evilginx is a framework that acts as a reverse proxy between the victim and a legitimate site (Microsoft 365, Google, Okta, etc.). It was originally created as a penetration-testing tool, but is now widely abused by threat actors. Here's the gist of what attacks do with it:
- The victim clicks a link to what looks like a company login page.
- That page actually points to an Evilginx server, which fetches the real login page from the legitimate service and relays it.
- The victim enters username, password, and MFA code on the real page, but the attacker's proxy is in the middle.
- Evilginx captures credentials plus session cookies / tokens as they flow through, then passes them on so the login appears successful.
- The attacker replays the stolen tokens to hijack the session without ever needing MFA again.
From the user's point of view:
- The page is the real Microsoft/Google/Okta page.
- TLS looks valid.
- They get prompted for their MFA code as usual.
- There's almost nothing visually "phishy" until their account is quietly taken over.
EvilnoVNC & Browser-in-the-Middle: When You're Using Their Browser, Not Yours
If Evilginx is about intercepting sessions, EvilnoVNC goes one step further and gives the attacker a live window into your session. EvilnoVNC is built around noVNC, a browser-based VNC client. In a typical attack chain, it's used like this:
- The victim is lured to a site that actually shows them a remote browser session running in the attacker's environment (through noVNC).
- The victim sees what looks like a normal login page and interacts with it, but every click and keystroke is happening inside the attacker's browser.
- Because it's a real browser hitting the real site, there's no fake HTML to easily fingerprint, no obviously suspicious domain in the victim's own address bar (they're interacting with a "screen" instead), and full visibility for the attacker into downloads, cookies, and even saved passwords, depending on configuration.
This is a flavor of Browser-in-the-Middle (BitM). BitM attacks let criminals trick victims into using the attacker's browser to access real sites; there's no obvious fake page, and MFA works normally for the attacker.
"Realistic phishing" is exactly the point: the login flow is almost indistinguishable from the real thing, while allowing attackers to bypass MFA and observe the session in real time.
Why These Attacks Are So Dangerous
Across incident reports and research, a few themes keep coming up:
- MFA is targeted, not ignored. Attackers don't "crack" MFA; they wait for you to use it, then steal the resulting session token.
- Tooling is commoditized. Adversary-in-the-Middle kits, often on GitHub or sold as "Phishing-as-a-Service," make it trivial to stand up Evilginx-style campaigns without deep expertise.
- Victims have very little visual signal. Browser-in-the-Middle flows remove most of the old-school red flags: odd URLs, bad TLS, obviously fake forms.
- Cloud accounts become the blast radius. Once a session is hijacked for Microsoft 365 or a similar platform, attackers can pivot into mailboxes, Teams/Slack, OneDrive/SharePoint, and other SaaS apps tied to that identity.
In other words: you can't just rely on passwords + OTPs anymore. You need to assume some sessions will be compromised and build detection and response around that.
Defending Against Evilginx & EvilnoVNC
There's no silver bullet, but multiple defensive layers seriously raise the bar:
Phishing-resistant authentication where possible
FIDO2 / passkeys bind authentication to the device and origin, making reverse-proxy kits like Evilginx far less effective.
Strong identity protections & conditional access
Conditional access rules that factor in device, location, risk score, and sign-in behavior can block or challenge suspicious logins even if the attacker has the right token.
AiTM & BitM detection on the wire and in the browser
Modern defenders look at TLS fingerprints, headers, and DOM characteristics to flag known phishing frameworks and warn or block users.
Session-centric monitoring
Monitoring for unusual token reuse (e.g., the same session hopping between countries, IPs, or devices) is key, because AiTM attacks often hijack sessions from very different infrastructure.
Targeted awareness training
Users need to understand that even legitimate-looking pages can be part of AiTM/BitM attacks, and that unusual login prompts, repeated MFA requests, or odd browser behavior are warning signs.
All of that is table stakes. But most organizations don't have the time or people to wire these signals together coherently. That's where Secto AI comes in.
How Secto Helps Stop Evilginx & EvilnoVNC-Style Attacks
Secto is designed to "stop phishing where gateways fail" by analyzing page content at the moment of click and blocking credential theft before users can enter their details. That architecture is exactly what you need when facing Evilginx, EvilnoVNC, and other Adversary-in-the-Middle / Browser-in-the-Middle kits that slip past traditional email filters.
Browser-Native, Moment-of-Click Phishing Detection
Instead of looking only at the email message or URL reputation, Secto operates at the browser layer, inspecting what the user actually sees and interacts with when they click:
- It analyzes rendered page content and behavior at click time to spot credential-harvesting flows, deceptive login prompts, and AiTM patterns that are invisible to static URL checks.
- Because it sits in the browser session, Secto can recognize when a page is acting as a reverse proxy (Evilginx-style) or presenting a remote embedded browser surface (EvilnoVNC-style), even if the TLS certificate looks valid and the HTML closely mirrors the legitimate site.
- When Secto detects that a page is trying to steal credentials or hijack a session, it can block the interaction before the user ever types their password or MFA code, cutting off the attack chain at the exact point where Evilginx and EvilnoVNC normally win.
Conclusion
Evilginx and EvilnoVNC are symptoms of a bigger shift: attackers are treating MFA like just another hurdle to be routed around, not a wall they must break through. Defending against that shift means:
- Moving from "passwords + OTPs" to phishing-resistant authentication where possible.
- Treating sessions as potentially hostile and monitoring them accordingly.
- Using Secto AI to bring together identity, configuration, and behavioral signals, so AiTM and BitM campaigns are detected and contained quickly.
If you're relying solely on traditional gateways and basic policies, these next-generation phishing kits are already aiming at your users. Secto is purpose-built for advanced phishing attacks and adds the layer that actually sees what matters most: the page your users are about to trust with their credentials.