A Carrier-Registry Phish With a Browser's CSS Pasted In

Earlier this year, one mailbox at a commercial facilities and property-services company received a message headed Official: Please Confirm Your Carrier Details, signed by the Federal Motor Carrier Safety Administration's carrier records office. It claimed the agency was reviewing information held in the SAFER System and offered a single button to put things right.

Every check a gateway is built to run came back positive or unremarkable. SPF passed. Two DKIM signatures passed. DMARC passed in alignment. Composite authentication returned a full-confidence pass. Both URLs in the message were scanned and returned clean verdicts. The sending domain had no prior bad history at this tenant.

The one thing in the message that carried real information was its HTML, and specifically a seam in it that nobody had cleaned up.

Thirteen Paragraphs That Came Out of a Browser Window

The delivered body ran a little over 28,000 characters. Thirteen of its paragraphs carried a style declaration no email designer writes by hand: orphans:2, widows:2, font-variant-caps:normal, text-decoration-thickness:initial, and a hard-coded color:rgb(15, 17, 21). Those same paragraphs sat under a class name with nothing to do with email at all, ds-markdown-paragraph, present seventeen times. Thirteen of them declared a first-position font family called quote-cjk-patch, a quotation-mark rendering fix for a web application, not a typeface any mail client would resolve.

That combination has one ordinary cause. It is what a browser writes to the clipboard when a person selects rendered text on a page and pastes it into a rich-text composer. The browser does not hand over the author's intent; it hands over the computed style of what was on screen, class names included. Properties like orphans and widows govern page-break behaviour in print layout and are inert in every mail client in use. An email builder emits none of them.

Wrapped around that pasted block, and clearly distinguishable from it, was the attacker's actual send template: component classes named node-footer, node-divider and node-paragraph, presentation-role layout tables, and a React Suspense comment marker left in the output. That is a modern component-based email framework, sending through a developer mail API on top of a large shared cloud relay. The styling residue is not part of it and does not belong to it.

So the body preserved a boundary. Copy was drafted in one application, selected in a browser, dropped into a second application, and shipped without a pass to strip the inherited markup. The renderer class prefix matches the markdown view of a chat-style AI assistant's web client, which is suggestive rather than conclusive, and the vendor identity is not the point. The point is that the residue came from the window the copy was written in rather than from the sending kit, and the recipient's own mail platform rendered it faithfully.

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

Not a Kit Leaving Traces of Itself

It is worth separating this from a family it superficially resembles. Leftover artifacts in phishing HTML usually point backwards at the same kit's previous run: a duplicate title element, unused stylesheet rules for a component the current lure does not use, a tracking parameter still carrying last month's campaign identifier. Those findings are about kit reuse, and they help you cluster campaigns that share a builder.

This residue points in the other direction. Nothing here identifies a kit, a previous victim or an earlier campaign. It identifies the composing environment upstream of the send infrastructure, which the send infrastructure never touched. The two layers can be told apart in a single body precisely because the template's own components enclose the pasted block rather than interleaving with it.

What the Attacker Actually Wanted

The payload sought was not a password. The bulleted ask was a motor-carrier and DOT number, legal business name and address, and fuel-tax and payment-system information, to be entered at a lookalike registry portal hosted on a subdomain of the attacker's own apex domain. The message pressed with a warning that unverified information could see the reader's carrier status moved to a not-authorised state, with knock-on operational delays. That is coercion aimed at carrier identity and payment-account data, which feeds freight fraud and payment redirection rather than mailbox access. The record contains no attachment, no image text, no QR code and no screenshot of the portal, so what the page served is not known.

There was also a merge failure. The greeting named a company with no connection to the recipient at all, and the recipient organisation is a facilities and building-services business that holds no carrier authority of any kind. The list was bulk-merged and badly aimed, and the message carried a working one-click unsubscribe conforming to RFC 8058 supplied by the sending platform as a default, which is exactly the surface that makes bulk fraud read as marketing.

The Signals That Said Nothing

Both DKIM signatures on the message shared an identical body hash, meaning nothing rewrote the content between the sending platform's signature and the relay's. Under RFC 6376 that is a correct, healthy result, and here it certified attacker copy end to end. The DMARC pass reflects the attacker's own published policy on its own registered domain. Nothing was spoofed, because nothing needed to be.

The recipient's platform did stop it, and the reason matters. It scored the message as bulk spam, routed it to junk, and the mailbox was quarantined under three minutes after receipt, with a human analyst later resolving the incident malicious. The impersonation flag was set but carried no supporting detail, consistent with the impersonated party being a government agency rather than a known internal identity. A targeted data-harvesting lure caught by volume heuristics is a save, but a fragile one: it depends on sending characteristics the attacker chooses, not on anything about the deception.

Hunting for Foreign Renderer Residue

The useful control here is cheap and content-side. Retain inbound HTML long enough to search it, then hunt for print-layout properties such as orphans and widows on body paragraphs, absolute rgb() colour values applied inline at scale, and class-name prefixes that belong to no mail platform you receive from. None of these are malicious by themselves. Legitimate senders paste from documents too. Treated as one weighted feature alongside first-contact status and the nature of the ask, though, a foreign renderer fingerprint is a strong indication that the copy was assembled outside the system that sent it.

That kind of layered content reasoning is what our Adaptive AI is built for, and it pairs with the human element the 2026 Verizon Data Breach Investigations Report still puts at 62% of breaches, with phishing the initial access vector in 16%. Agency-impersonation lures are a long-standing staple, described in CISA's phishing guidance and in the NIST definition of phishing; what changes is the toolchain producing them, and sometimes the toolchain writes itself into the file.

Indicators of Compromise

MITRE ATT&CK Mapping