One Header Named the Attacker's Own Login

The mail platform that relayed this phishing message wrote the attacker's own login into it.

The header is called X-Authinfo, and a Korean shared business-mail provider adds it on the way out. With identifiers removed, this message carried:

X-Authinfo: SMTP authenticated <[auth-account]@[company-a][.]co[.]kr | [Azure IP] | [from-address]@[company-b][.]co[.]kr | 251118215849_741791035>

Read the fields left to right. The first is the mailbox that authenticated the outbound SMTP session. The third is the address the message was sent as. They belong to two unrelated Korean companies. The second is an IP in Microsoft Azure space, not an office network.

That one line, added by the sending platform and not by the attacker, evidences a stolen credential at company A being used to send as company B. It is the cleanest artifact in the message, and almost nobody reads it.

Why SPF Passed and the Gateway Delivered It

The same header explains the authentication results. A shared business-mail host is an authorized sender for every customer domain on it, so at the Microsoft edge this message scored spf=pass with the envelope sender on the impersonated company's domain, plus dkim=none (never signed), dmarc=bestguesspass and compauth=pass reason=109.

Microsoft rated it SCL:1, SFV:NSPM, CAT:NONE and delivered it to the Inbox. The gateway saw an authenticated message from an authorized IP and made the only call it could.

SPF validates the path, not the person holding the password. A compromised credential on a shared host inherits that host's authorization for thousands of unrelated domains at once, so blocking the From domain does nothing about the other customers the same login can send as. The account takeover sits at the sending company, not at the target, and only the target sees the evidence.

The 2026 Verizon Data Breach Investigations Report puts credentials in 39% of breaches across the full kill chain, and phishing as initial access in 16%. Its Figure 54 breakdown of gateway-blocked mail (80% plain phishing, 10% malware-laden, 5% callback, 3% business email compromise) portrays what a Secure Email Gateway, or SEG, does catch. Messages that authenticate correctly are not in that picture.

See Your Risk: Calculate how many threats your SEG is missing

The Lure Impersonated the Victim's Own Company

Most document-share phishing borrows an external brand. This one borrowed the recipient's employer.

The body announced that the victim's own company had shared a document, named the recipient's own address beside a contract filename and the phrase "Signature Required", and claimed the secure folder only worked for recipients inside the victim's own domain. The footer closed with a copyright line for the victim's domain and a note that the recipient got the mail because they have an account with their own employer.

There is a detection consequence. The Microsoft four-square logo in the message is not an image. It is four HTML table cells with the background colours #f35325, #81bc06, #05a6f0 and #ffba08. No logo file exists anywhere in the message, so image-based brand-impersonation checks have nothing to hash, and brand-reputation logic tuned for external senders is not watching a message that claims to be internal.

MITRE tracks the link delivery as T1566.002, Spearphishing Link. The half this post leads on, a borrowed mailbox credential on a shared host, is T1078, Valid Accounts, and it is the half that survives a URL block.

What the Authorize Link Actually Asked For

The call to action chained through a legitimate marketing-automation sending domain (an abused account on a commercial platform, not attacker-owned infrastructure) to a real Microsoft authorize endpoint carrying client_id=f55d5df6-3354-429b-bc87-3f01f11c7d78, prompt=none, response_type=code, response_mode=query, scope=openid profile email, state=12345, and a redirect_uri on a domain outside the victim's control.

Scope it honestly. There is no offline_access, no mail scope and no Graph scope, so an authorization code here returns basic identity and nothing more. state=12345 is a hardcoded placeholder, and there is no PKCE challenge. This is a silent check of who the victim is and whether they already hold a live session, not mailbox token theft, and calling it theft would send responders hunting a consent grant that does not exist.

It did execute. The captured landing is Azure's own response returned back through that redirect destination: error=login_required with AADSTS50058, "A silent sign-in request was sent but no user is signed in", Trace ID 5a9132b1-066d-4249-b7fc-9de1a96c1f00, timestamp 2025-11-18 12:59:06Z. That error proves the probe ran, and that the redirect destination is registered on that application. It does not prove who owns the domain. No credential-harvest page was ever captured behind the chain.

Silent probing is the cheap reconnaissance the Microsoft Digital Defense Report 2024 describes at the front end of identity attacks: learn which mailboxes are real and signed in before building the expensive part, usually a credential harvesting page.

A Recycled Footer Carried an Earlier Victim

The "Privacy Policy", "Terms of Service" and "Contact Support" links at the bottom are not attacker infrastructure at all. They are genuine marketing-tracker URLs belonging to two unrelated legitimate companies, and they still carry a previous victim's mailbox at a US school district, plus that organization's tenant identifier, inside nested link-protection parameters.

Someone lifted this template from an earlier campaign's captured message and shipped it uncleaned. The mailbox sits there URL-encoded, which is why a body-text scan walks past it.

Who Got Hit, and What Stopped It

Four mailboxes at a multinational coffee and consumer goods group were targeted between 2025-11-18 and 2025-12-02. They belonged to senior legal and commercial staff, not a shared support queue, and each message carried a per-recipient subject token (a 64-character hex string plus a UUID). All four were quarantined with recorded mitigation dates, and a human analyst marked the sender malicious, with no release requests and no prior safe verdict for that domain.

Themis, the Adaptive AI analyst, scored the message at 62 confidence with the labels "Credential Theft" and "VIP Recipient", and flagged one link as malicious. This was a first-time sender with no prior relationship in either direction, which is why relationship signals were worth more here than the authentication results. IRONSCALES platform data across 36,000+ security professionals in 18,000+ organizations averages 67.5 phishing emails per 100 mailboxes each month, and the ones that pass every check are the ones needing behavioural context.

Indicators

Hunting for the Next One

Search your mail store for X-Authinfo and compare the authenticating account against the From address on every hit. A mismatch across organizations means a compromised credential somewhere, and the owner of that mailbox usually has no idea. Report it through the hosting provider and, in the US, to the FBI Internet Crime Complaint Center.

Alert on prompt=none in any login.microsoftonline.com URL arriving by mail, then read the scopes before you escalate. Identity scopes are reconnaissance. Scopes with offline_access or mail access are a different incident, and conflating the two wastes a response.

Treat "your own company shared a document" as its own detection class. Internal-brand lures sit in the blind spot between external brand impersonation and internal-sender rules, which is why user reporting carries as much weight as filtering here, an argument CISA phishing guidance makes as well. The 2026 DBIR still puts the human element in 62% of breaches, and this message is aimed squarely at that number.

Credential compromise on somebody else's shared platform is not something your gateway can see. But the platform told us who was logged in. That is worth reading.