What the attack looks like from the victim's seat
You get an email that looks like it’s from your HR or benefits portal. The link goes to a convincing-looking domain. It will include the word “benefits” in the name, a real .com TLD, and professional branding. You click through a captcha, confirm you’re human, and land on what appears to be a Microsoft 365 sign-in page. You log in and complete the MFA process.
Between you and Microsoft sat a relay, an adversary-in-the-middle (AiTM) proxy. That proxy captured not just your password, but the live session token minted after you completed MFA. The attacker wasn’t after your benefits portal credentials. They wanted access to your mailbox, your files, your Teams chats, and any app that trusts your Microsoft identity.
How we tied the cluster together and why traditional signals weren't enough
When you’re looking at a handful of phishing sites across different IPs, different registrars, and different SSL certificates, the obvious pivots don’t get you far. The attacker just spins up new infrastructure. What they can’t easily randomize is the logic baked into their phish kit.
Every URL in this particular cluster we identified carried the same path and the same three query parameters:
/compensation/auth/<id>?s=3&ht=<token>&sso_reload=true
The s parameter is a stage counter. It mirrors a hop_count value encoded inside the token, tracking where in the multi-step redirect chain the victim currently sits. The sso_reload=true flag appears on every single URL in the cluster. And ht carries a signed, encoded token, split by a period like a JSON web token (JWT), that controls what template the kit renders at each hop.
Inside the token is a hop_count variable that tells the kit what stage to render. That logic is shared across every site running this kit, no matter the infrastructure it’s deployed on. It stays static because the kit can’t function without it. That makes it a fingerprint.
It’s also a piece of counterintelligence. The same structural signals that tied these four sites together can (and did – see the threat brief) surface related domains held by the same operator and threats not yet serving malicious content. That translates into three key advantages: a single takedown request can cover multiple assets at once; registrars and abuse teams have something actionable before malicious content goes live on a domain; and if the kit resurfaces on new infrastructure, the fingerprint gives you an early warning before the attack reaches your users.
What this means for detection going forward
Traditional phishing detection leans heavily on infrastructure signals: who registered the domain, what cert they’re using, which hosting provider they chose. These matter, but they’re all things an attacker can rotate between campaigns with minimal effort, especially when leveraging phishing-as-a-service (PhaaS) that often automates this process entirely.
Behavioral and structural signals (URL path conventions, parameter naming, token formats, template logic) are harder to change without breaking the kit. They’re baked into the code, so they persist across deployments even when the domain and IP change. That persistence is what makes them a reliable clustering signal and a campaign identifier.
All four sites in this specific cluster were taken down. But the kit is still out there, and the next wave will likely share similar structural tells.
How our platform made this findable
Manually hunting for structural consistency across phishing sites isn’t realistic at scale. An analyst staring at hundreds of alerts across different domains and IPs has no obvious reason to connect them.
Allure Intelligence automatically groups alerts by shared behavioral signals, not just infrastructure. In this case, it flagged the URL path pattern and token structure as a shared fingerprint across detections. This surfaced these threats as a single campaign cluster before any human had connected the dots.
The platform didn’t just find four phishing sites. It handed me a campaign with a common kit, a common lure strategy, and a common weakness: a token structure that couldn’t be randomized without breaking the attack. From there, I could decode the token, map the redirect logic, and produce the IOCs and detection guidance in the full threat brief.
The insight isn’t that these sites shared an IP or a registrar. It’s that they shared signals of the same engineering decisions, made by the same kit author. That’s the signal that survives infrastructure rotation.
What to do with this
There are two takeaways here, one strategic and one immediate.
Strategically: if your organization still relies on push, SMS, or TOTP for MFA, this campaign is a reminder that those methods don’t protect against AiTM. Session token theft after a completed MFA challenge is a solved problem for attackers running these kits. FIDO2/WebAuthn-based authentication (e.g., hardware keys or platform passkeys) remains the strongest defense.
Immediately: the full threat brief below contains the specific IOCs, the decoded token structure, and detection logic tied to this kit’s URL fingerprint. If you’re running a SOC or threat intel program, watch for those signals. The domains are already down, but I suspect the pattern will show up in the next wave.
SECURITY RESEARCH
One Token to Rule Them All:
Clustering a Payroll/Benefits AiTM Campaign
Detailed IOCs, token decoding walkthrough, cluster analysis, and detection guidance.
