A Day Old Domain That Passed Every Auth Check

The domain that sent this message was twenty seven hours old.

WHOIS put its creation stamp a little over a day before the send: a budget registrar, the minimum one year term, every registrant contact field empty, parking nameservers still authoritative when the mail went out.

In that single day the attacker completed full domain authentication with a major commercial email service provider. The signing key was published, an authenticated sending subdomain resolved, and the message reached the chief executive and co-founder of a healthcare technology company with SPF, DKIM and DMARC all passing.

One Day Was Enough to Satisfy Every Identity Check

The receiving service recorded a clean sweep. DKIM passed with selector s1, signing for the sender's own domain. SPF passed, with the provider's outbound address authorized for the envelope domain. DMARC passed on alignment, because the header From and the signing domain were identical. Only one receiving path exists in the record, and relay analysis confirms no security gateway sat anywhere in it, so nothing external explains those results.

The passes are true statements, and nearly empty ones. DKIM proved the attacker held a key they had published themselves that morning. SPF proved a shared provider's outbound estate was authorized by a domain that had authorized it minutes earlier. DMARC proved the two aligned. Each describes control of a domain and nothing else. The published DMARC policy made the point plainly: none, with a subdomain policy of none, permissive enough to satisfy alignment while enforcing nothing.

The Body Was Copied Out of a Webmail Window

The email was not built from scratch. It was lifted whole out of a real Google notification message as that message appeared inside a webmail client, and the delivered source still carries the fingerprints.

Every style class wears the client's message scoped prefix, the m_ plus message identifier pattern it writes when rendering received mail. Its injected wrapper element survives, and the document title still reads review.html. The hero graphic loads a genuine Google hosted marketing asset through the client's own image proxy. The button carries Google's notification styling: the same blue background value, the Google Sans typeface stack, the same three pixel corner radius.

One attribute is the attacker's own work. The button carries a safe redirect attribute, normally written by the webmail client, hand set to an unrelated video sharing site while the real link target points elsewhere. The purpose is not established by the record, but the mismatch is verifiable. A hidden preheader sits at the top of the body too, zero height, zero font size, white and display suppressed, containing the words Check out.

Three Names for a File That Was Never There

The message could not decide what it was delivering. The From display name is eForm. The subject calls the item a Spreadsheet, then a PDF. The body headline reads (3) New ShareFiles _2mb PDF. Three document types, in fields a recipient reads in one glance.

There was no attachment: the array on the incident is empty and attachment analysis returned nothing to inspect. Beyond the headline and the button the body is close to empty, blank table cells with no sender context, no file owner and no message.

The only personalization is a subject token the kit builds in a fixed construction and fills with the recipient's own first name, which is why the subject is quoted here in masked form. The return path repeats the problem, encoding the recipient's mailbox and domain into the bounce address, where identity reads as routing data to tooling and as a targeting artifact to anyone who decodes it. One mailbox was affected, and it was the chief executive's.

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

The Gate Reworded Itself Between Visits

The button did not point at the landing domain directly. It pointed at a third party click tracking and redirect host, shared infrastructure rather than anything attacker owned, which answered with a 302 to a landing domain fronted by a content delivery network. That domain was roughly a month old, not a day, and carried the hostname accounts. to borrow the shape of a sign in host.

What waits there is not a sign in page. Two independent screenshots of the landing URL were pulled from the platform, and both show one card: white, rounded, on a pale gradient, with a grey outline shield icon, a heading, a line of subtext and a pill shaped control. No branding, no known verification widget, no input field.

The two renders differ in one respect. One reads Verify you're not a robot, with subtext A quick check to make sure you're not a bot. and a control labeled I'm not a robot. The other reads Confirm you're not a bot, with subtext Confirm you're not an automated visitor. and a control labeled Confirm you're human. Same card, same shield, same geometry, different words. The rotation mechanism and variant count are not established, but two fetches of one URL produced two different strings, so a signature built on the first would miss the second.

The scanner results follow from that design. The tracking redirector came back a mixed result, and the landing page itself came back clean, a 200 response with no login form visible. That is not a scanner failure, it is a page with nothing to grade until a person clicks. Gates like this commonly precede further redirection, but nothing past this one was observed. URL and payload analysis scoring only what a fetch returns will keep calling such pages harmless.

What Was Left to Detect On

Nothing technical failed, so nothing technical fired. Adaptive AI scored the message at 89 percent confidence and labeled it credential theft with a VIP recipient, and the platform automatically resolved the case as phishing without an analyst. Both labels classify the message as a whole rather than record a credential form. No mitigation was logged against the mailbox: action, status and timestamp are all empty.

The decisive sender signal was registration age. The platform's insight named the sending domain a newly registered return path domain typically associated with suspicious activity, and an independent WHOIS pull confirmed it. Content wording and community reputation on similar incidents contributed as well. That is the class of signal still available once authentication has been satisfied, because it does not ask who sent the message, it asks what this sender has done before.

Three Practices This Case Argues For

The 2024 Verizon Data Breach Investigations Report puts phishing in 15% of breaches and the human element in 68%, with a median of 21 seconds from delivery to click. A message that satisfies every identity check and asks for a single click is built for that window, and the NIST definition of phishing turns on deception and objective, both of which this one supplied while answering every question about its own identity truthfully.

Three practices follow. Score domain age and registration posture as first class inputs: a fully authenticated domain on parking nameservers with an empty registrant record is a contradiction available at delivery time. Treat an interaction gate as a detection event rather than a dead end, and match on its layout, hosting and redirect shape instead of on its copy. And read a message's document type claims against its actual parts, because three file types named for an attachment that does not exist is a contradiction no real notification produces. As CISA's phishing guidance notes, controls that stop at the authentication result will keep delivering mail that is technically authentic and substantively false.

Indicators of Compromise

MITRE ATT&CK Mapping