It Passed Every Check. It Was Still the Attack.

Executive Summary

• Over ten months with a large US insurance and employee benefits provider, adversary-in-the-middle (AiTM) phishing made up 34% of every takedown we performed, across close to 100 distinct phishing sites.
• None of the pages victims clicked asked for credentials. Harvesting happened one hop later, so the source page had no login form to flag and no malicious content to render.
• Those pages were reused. The same impersonating blog post kept reappearing behind new phishing sites, which makes the endpoint disposable and the redirector the durable asset.
• Victims arrived through poisoned search results and paid ads impersonating the customer as often as through phishing messages, putting the entry point outside the inbox entirely.
• Finding them meant capturing source and destination together and rendering as a real user, since delay timers and CAPTCHA gates show crawlers a blank page. Median detection ran 24 to 48 hours.

Key Findings

1. The page that catches victims never asks for a password. This holds across every variant. Harvesting happens one hop later, on infrastructure the victim never chose to visit. Scan the page they clicked and there’s no login form, no impersonation, nothing to score as malicious.
2. The redirector outlives the phishing site. Close to 100 phishing sites, fed by a smaller set of source pages. The same impersonating blog post kept reappearing behind new endpoints, which means takedowns have been removing the disposable half.
3. The delivery layer evolved over the ten months. It started with legitimate blogs, where a path like /login-secure returned a redirect where a 404 belonged. It moved toward disposable pages: a paragraph of filler, one button, barely enough script to fire a meta refresh.
4. The entry point often isn’t an inbox. Victims arrived through poisoned search results and paid ads impersonating the customer as often as through phishing messages. Both work on someone already looking for the brand, which is why the redirector content is brand-targeted.
5. Much of this was built specifically to beat scanners. Redirects fired after ten to fifteen second delays or chained through hops, and CAPTCHA gates served crawlers an empty page while passing real users through. Not a false negative so much as a different page.
6. Detection failed correctly, which is the uncomfortable part. Reputation scoring, crawling, and link analysis all did what they were designed to do. The evidence of safety was genuine, just incomplete in exactly the way the attacker engineered.

The Investigation

Our team recently wrapped a stretch of work for a customer, a large US insurance and employee benefits provider, and one number from it has stayed with me since. Between August 2025 and May 2026, adversary-in-the-middle phishing made up 34% of every takedown we ran for them. A third of the enforcement volume for a major insurer, aimed at stealing sessions rather than passwords.

We went in expecting a lookalike domain. That’s the usual shape of these things: a near-miss spelling of the brand, registered last week, sitting on hosting nobody reputable uses. What we found instead was a blog. A real one, with real articles, an about page, and a clean history. Request any normal URL on that site and you get exactly what you’d expect to get, which is why every automated check that looked at it returned the same verdict. Safe.

Then request a path that doesn’t exist on the site, something along the lines of /login-secure, and the server doesn’t return a 404. It returns a redirect. The visitor lands on an adversary-in-the-middle proxy that mirrors a login page closely enough to take credentials, relay the MFA challenge in real time, and capture the authenticated session that comes out the other side. Same domain, same certificate, and the same reputation score, but two completely different behaviors, only one of which anybody was ever looking at.

I want to be careful not to oversell this, because there’s nothing exotic in the technique itself. Conditional server responses are older than most of the security industry. What’s interesting is where the attacker chose to hide, and what that choice says about how well they understand the way we check things.

How the Delivery Layer Changed

What held my attention longer, though, was watching the approach change over the ten months. The blogs didn’t go away, and neither did the poisoned search results feeding traffic into them. But alongside them a second pattern emerged, and it was stripped down almost to nothing: a page with one paragraph of unremarkable copy, a single prominent button, a short-link or blob URL sitting underneath it, and just enough JavaScript to fire a meta refresh. No articles, no history, nothing borrowed. Where the blog approach rents credibility that somebody else spent years accumulating, these pages manufacture the appearance of harmlessness from scratch, and they do it cheaply enough to be treated as disposable.

The interesting part is that both work for the same reason, and it isn’t the one I’d have guessed. It’s not the domain’s age or reputation. It’s that neither page ever asks for a password. Every scanner that examined them was looking for a credential form, brand impersonation, or malicious content, and none of those things were present, because the harvesting happens one hop later on infrastructure the victim never chose to visit. The page you can inspect is genuinely clean. The page that takes your credentials is the one you were sent to.

Something else showed up once we had enough volume to see it. Close to 100 distinct phishing sites came out of this work, but the pages funneling traffic into them were fewer, because the same impersonating blog post kept reappearing behind new endpoints. That reordered how I think about what we’re actually removing. A phishing site is the disposable part. The redirector, sitting on a host with real standing and ranking for the terms people search when they’re looking for their benefits provider, is the asset. Take down the endpoint and the funnel is still there, pointed at whatever gets stood up next.

Why It Kept Working

Which brings up how victims found any of this. Some arrived from a phishing email, but plenty didn’t. A poisoned search result waits to be found, and the person who finds it went looking for their benefits provider on purpose, which means they arrive with a reason to trust whatever they clicked. That’s also why the redirector content is brand-targeted rather than generic: it has to rank for the terms people actually search, or it has to be worth bidding on. The paid version runs the same play with money instead of patience, buying placement against the brand’s own terms with an ad that impersonates the customer outright. Someone searches for their insurer, sees what looks like their insurer, clicks through a page that asks nothing of them, and lands on a form that takes everything.

There’s an economics story underneath all of this. Building convincing brand impersonation takes real effort, and even when AI makes the final page nearly indistinguishable from the real thing, the surrounding infrastructure leaves artifacts behind: registration records, hosting patterns, visual similarity. What these operators worked out is that the expensive, detectable part only has to exist at the last hop. Everything before it can be cheap, clean, and reusable.

Several of these were also built to make that inspection harder. Redirects fired after a ten or fifteen second delay, or chained through multiple hops before landing anywhere interesting. Bot-detection services sat in front, rendering a CAPTCHA or a blank page to anything that looked automated while passing real visitors through untouched. Our scanners weren’t getting a wrong answer about these pages. They were being shown a different page.

What Happens After the Click

What happens after that last hop is worth walking through slowly, because the theft lands later than most people assume. The victim reaches a page identical to the real login and enters their credentials, which the proxy forwards to the legitimate service in real time. The service responds with an MFA challenge, the proxy passes it back, and the victim approves it. Everything they experience is authentic, because everything is actually happening. The legitimate service then does exactly what it’s designed to do and issues a valid session, and that session cookie is the thing the attacker was after all along. Replayed later, it grants access without any second factor at all.

This is the part I’d encourage security leaders to sit with if MFA rollout is checked off somewhere on a slide. Frameworks like Evilginx have turned this into a commodity capability, and the distinction that matters is architectural rather than procedural. FIDO2 keys and passkeys bind authentication to the legitimate origin, so a proxy can’t satisfy the challenge no matter how convincing the page looks. SMS codes, authenticator apps, and push approvals offer no such guarantee, and they still cover most of the installed base.

Why This Slipped Through

What I keep returning to, though, is not the attack. It’s the check.

Detection in this space has largely been built to answer one question: is this domain bad? It’s a reasonable question, and for a long time it was close enough to the right one. This work is a clean demonstration of where it breaks down, because the honest answer about most of these source pages was no. The blogs were legitimate and trusted, so reputation scoring relaxed. Their valid paths served genuine content, so anything crawling them the way a search engine would found articles rather than phishing. The minimal redirector pages had no reputation either way and nothing objectionable on them to find. And in both cases the thing that mattered, a path or a button that sent you somewhere else, appeared in no sitemap and no internal link, which meant it lived only inside the attacker’s own distribution and was never in the set of URLs anyone thought to test.

Every one of those defenses worked correctly. The evidence of safety was real. It was just incomplete, and it was incomplete in precisely the way the attacker intended.

What Has to Change

So the adjustment I’d argue for is less about adding tools and more about changing the unit of analysis. A verdict attached to a domain has a short shelf life and, in this case, was wrong the moment it was issued. Treat the source page and wherever it sends people as a single artifact, captured together, because separately each half looks defensible and only the pair tells you anything. Go looking for the paths nobody links to, since the malicious URL exists only in the lure. Follow every redirect to wherever it actually terminates and render what’s there, waiting out the delay timers, because in this work the redirect wasn’t a detail in a log, it was the whole attack. Scan the way a real visitor arrives, from residential vantage points, or the bot gates will keep handing you a clean page that no victim ever sees. Run on a clock that matches how quickly this infrastructure moves, and keep watching sites after they go quiet, because removing a site doesn’t remove the actor and the same operator often rebuilds within days on the same templates. Registration and WHOIS patterns help too, frequently exposing a campaign before the first victim ever clicks.

None of that is theoretical for us. This work pushed us to build URL path testing to surface phishing hidden behind specific malicious URLs, tighten our rescan cadence on active pages, extend monitoring to sites that have gone dormant, and pull registration signals in earlier so domains get flagged before they’re armed. Because so many of these campaigns begin in search rather than in an inbox, that monitoring now covers the discovery layer as well, watching search results and paid placements for the poisoned entries that feed traffic into this infrastructure. We route scans through residential paths so the bot gates behave as they would for a real visitor, and we capture source and destination together rather than scoring either one alone. Much of this was developed alongside the customer whose environment surfaced the problem, and it’s since been rolled out well beyond them. The payoff shows up in the timing: across this customer’s environment, median time from a page going live to detection ran 24 to 48 hours, and a meaningful share were caught the same day they appeared. Our analysts were in the loop the entire way, which mattered here, because this kind of campaign only reveals itself under conditions a generic crawler wouldn’t reproduce on its own.

I’ve said before that the phishing page isn’t the beginning of an attack anymore. It’s usually the end. This work is another version of that same lesson, just further upstream than most teams are currently looking. The redirector, whether it’s a blog with an unlisted path or a page with one button on it, is part of the campaign, and it exists well before anyone types a password. If you ask whether a page is safe, and you answer by examining a page built to survive exactly that question, you’ll get a true answer that doesn’t matter very much.

Your customers aren’t visiting a domain. They’re following a path from wherever they started, and the only part of it that ever looked dangerous was the part they never got to inspect.

These are the conversations we’re having with customers right now. If you’d like to see how this plays out across full campaigns rather than single pages, we recently hosted a webinar on how modern fraud campaigns are built, and the on-demand recording is available here.