Perfect Auth Pass on the Attacker's Own Domain

One Wednesday morning, a single message arrived at one mailbox inside a large municipal government carrying an authentication record most legitimate marketing mail cannot match. SPF passed, DKIM passed, DMARC passed, and Microsoft's composite authentication returned compauth=pass reason=100, the cleanest verdict that field produces. Every check aligned on the same domain.

That domain belonged to the attacker.

Authentication Only Ever Proved Domain Control

The Authentication-Results header, recorded at the recipient's Microsoft 365 edge, reads:

spf=pass (sender IP is 89[.]34[.]14[.]138) smtp.mailfrom=techspire[.]life; dkim=pass (signature was verified) header.d=techspire[.]life; dmarc=pass action=none header.from=techspire[.]life; compauth=pass reason=100

Four green results, and none of them is a lie. The Return-Path, the header From and the DKIM signing domain are all techspire[.]life, which is exactly the alignment DMARC exists to verify (see RFC 7489). The DKIM signature uses selector mail under that same domain, so there is no third-party signer and no ARC chain patching over a forwarding hop. The operator signed his own mail with his own key. The one qualifier worth reading closely is action=none: the domain's DMARC policy is non-enforcing, which the attacker chose, because he wrote the record.

This is the part that gets misread in triage. Authentication answers one question: is this sender authorized to use the domain in the From header? When the sender owns the domain outright, the honest answer is yes, and there is no spoofing to detect because nothing is being spoofed. A perfect result on attacker-owned infrastructure is not a detection failure. It is authentication working correctly and saying something other than what the reader assumes.

One External Hop, and a Mail Host Built for This Domain Alone

The obvious counter is that a pass can be an artifact of the path, since mail relayed through a shared platform or rewritten by a gateway routinely produces confusing per-hop verdicts. That escape hatch is closed here. There is exactly one external hop between the sender and the recipient's tenant, from mail[.]techspire[.]life at 89[.]34[.]14[.]138 into Microsoft's protection edge, and every verdict above was recorded at that boundary, before anything on the recipient's side touched the message.

The shared-hosting explanation fails on three independent records that agree. The HELO name is mail[.]techspire[.]life, the reverse DNS pointer for the sending IP is mail[.]techspire[.]life, and the A record for that host resolves to the same address. A tenant riding a shared platform's SPF authorization inherits a pointer belonging to the provider and shared with its other customers; a dedicated pointer matching both HELO and the A record describes a mail host serving this one domain. Our SOC review agreed, noting that the sending host is not a recognized security gateway or legitimate third-party sending service, and that the passes come from the domain owner's own configuration.

The Impersonation Sits One Layer Above the Protocol

If the domain impersonates nobody, where is the attack? In the identity string. The mailbox is samscIub_user@techspire[.]life. The third character of the brand token is a capital letter I standing in for a lowercase L, so samsclub becomes samscIub and reads correctly at a glance in most sans-serif fonts. The display name carries the identical substitution.

That single glyph is the entire brand impersonation (T1656). Nothing else touches the real brand's infrastructure: no Sam's Club domain, mailbox, sending IP or signing key appears anywhere. The brand is invoked by a character swap and by HTML reproducing its colors.

What the Recipient Was Meant to See

The rendered body is a warehouse-club reward page offering a $100 gift card plus four bonus gifts for a thirty-second survey, closing on a single "CONFIRM & CLAIM REWARDS" button. The subject line cannot be quoted here because it carries the recipient's own details; it follows the pattern "[First Name], Your $100 Gift Card Expires TONIGHT at 11:59 PM | [Street Address], [State]".

The personalization is the pressure. Above the button sits a read-only table headed "Please verify your information below", pre-filled with the recipient's first name, last name, work email address, street address, city and state. There are no input fields and no form in the email itself; the table only displays. Framing the click as confirming details the sender already appears to hold turns a cold solicitation into an administrative chore, with a same-night expiry attached. No harvesting page was captured, so data collection is the lure's evident intent, not an observed outcome.

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

Padding Written for the Filter, Not the Reader

Wrapped around that payload are two blocks of text a human never sees. Their inline styles set a one-pixel font size, zero opacity, a maximum height of zero to two pixels, hidden overflow, white text, DISPLAY: none and mso-hide: all for Outlook specifically. Between them they carry roughly a thousand words of mundane workplace small talk styled as a two-way thread about lunch breaks, pallet counts and a deli line.

One detail gives away the purpose. Inside that invisible filler the warehouse-club name is deliberately misspelled "Same Club", four times, while the visible body spells it correctly, so the padding adds bulk without contributing brand tokens a content filter could match. The same block also repeated the recipient's work email address in plaintext. It is competent obfuscation (T1027), and also the least interesting thing here, because the authentication story required no evasion at all.

Three Callbacks, One Endpoint

Both clickable links and a one-pixel-by-one-pixel tracking image resolve to the same place: hxxp://techspire[.]life/amsweb.php, differentiated only by a long opaque token per element, all three over plain HTTP. The beacon sits in an unstyled block outside both hidden sections, so it fires on preview and confirms the mailbox is live before the recipient decides anything. Both clickable links returned a scanner verdict of Clean.

Detection Came From Behavior, Not From Auth

Microsoft's content filtering disagreed with its own authentication result, scoring the message SCL 5 with SFV:SPM and CAT:SPM and routing it to the Junk folder rather than blocking it. Defender Safe Links rewrote both call-to-action links through the government-cloud rewriting host without stopping them, and the organization's external-sender caution banner was already on the message. Every one of those controls fired, and the message was still in the mailbox.

What closed it was relationship data. Our Adaptive AI, Themis, flagged the message at a confidence of 80, drawing on content signals, community resolutions of similar incidents and sender analysis. The behavioral record backs it: a first-time sender, with no prior correspondence in either direction and none between that sender and the organization at all, on a domain that had produced exactly one incident ever at this tenant. One mailbox was affected, and the message was quarantined six seconds after delivery.

The Signal Auth Cannot Give You

The 2024 Verizon Data Breach Investigations Report puts phishing in 15% of breaches and the human element in 68% of them, with a median of 21 seconds from opening a phishing email to clicking the link inside it. Against that clock, a pass verdict a triage queue reads as reassurance is worse than no verdict at all.

Treat SPF, DKIM and DMARC as what NIST and CISA describe: controls on domain misuse, not verdicts on sender intent. Then layer the questions authentication cannot ask. Has this domain ever spoken to us before? Does the display name resemble a brand more closely than the address it belongs to? That is the work Microsoft 365 augmentation does, reading relationship history rather than headers alone (T1566.002).

Indicators of Compromise

MITRE ATT&CK Mapping

Every authentication control the industry spent two decades deploying worked exactly as specified here, and the result was a green light on a lure. Those controls answer a narrower question than a pass verdict appears to promise, and an attacker willing to configure DNS properly gets to answer it himself.