One File, Two Lures: A Phishing Kit Caught Mid-Swap

A national staffing and recruiting firm received a message that rendered as a Microsoft OneDrive document-share notice. The word OneDrive sat at the top in large grey text, a single Open button occupied the middle, and Microsoft's corporate mailing address closed it out. There was no attachment, but the body named a document, a policy and benefit report titled with the firm's own legal entity name.

The message was not the interesting artifact. The file was. Whoever assembled the HTML left the previous pretext inside it, still declared, alongside styling for a QR code that was not in the message and a stylesheet written for debugging. It was a reusable multi-pretext template caught mid-swap, and nobody cleaned it before pressing send.

Two Title Declarations, Two Unrelated Pretexts

The document head declared a title of sup, a throwaway placeholder. Then, mid-body, after the OneDrive block had already rendered, a second title element appeared and declared something else entirely: that the recipient had been promoted and assigned a new role within the firm. A promotion notice and a document share are separate campaigns that happen to share a chassis.

Two more leftovers sat in the same file. The head carried a debug stylesheet, h1 {color:red;} p {color:blue;}, matching no element the message used. And the body defined .qr-section and .qr-code rules, the latter a 200 by 200 pixel grey placeholder block, even though the record confirms no QR code and no image-text objects were present. That CSS is residue from a QR-code variant of the template, not evidence of one here.

The markup itself was built in a marketing campaign designer: an ESP campaign class on the container, an editor-version attribute, per-module identifiers on every block, and two images loading over plain HTTP from that ESP content delivery network. Yet no ESP hop appears anywhere in the delivery chain. The template was designed in one tool and delivered by a completely different path. A signature written against the promotion pretext would have missed this send, and one written against this document share will miss the next, because the operator is rotating stories inside a fixed shell.

The Safe-List Banner Was Part of the Payload

Above the lure sat a green-tinted table with a thick left border, styled to read as system chrome. It asserted that the sender was approved for the recipient's organization, and beneath that: "This message was delivered from a verified sender on your safe list."

No gateway said that. No mail client said that. The attacker wrote it, in HTML, inside the body. Nothing in a rendered message distinguishes a trust indicator written by an attacker from one added by the platform.

The personalization was equally cheap. The subject line began with the recipient's own mailbox local-part, then a generic reminder about one pending document and a random five-character reference token. No prior knowledge was required, only the address the mail was already going to.

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

The Only Real Link Went to a Design Platform

The single Open button resolved, through the recipient gateway's URL-protection wrapper, to a subdomain of Adobe's Portfolio hosting service. Portfolio is a legitimate publishing product, which is exactly why it is useful here: the destination inherits a well-known apex domain and a reputable certificate, and there is no attacker-registered domain for a blocklist to score. Whether that subdomain was stood up by the operator or taken over is not established, and neither is what it served. Both links scanned clean and neither was screenshotted.

Three Hops, Three Different Verdicts

At the injection hop, the message was as unauthenticated as mail gets. SPF failed for the connecting address, DKIM was recorded as none because the message was not signed, DMARC failed under the sending domain's p=none policy, and there was no ARC chain. One hop later, at the recipient organization's inbound gateway, the same message evaluated as DKIM pass on a selector1 signature, SPF pass, ARC pass, and DMARC pass. In between, cloud mail infrastructure had signed the body as it stood at that first hop. An unauthenticated injection had been laundered into a full pass without the attacker ever holding a key.

The final hop reported the opposite again: SPF fail, DKIM fail with a body hash that did not verify, DMARC fail, and composite authentication of none. Both failures are mundane. The failing SPF address is the recipient gateway's own relay, and that same gateway rewrote every URL into its protection wrappers after the signature was applied, which alone invalidates a body hash. The record cannot separate that rewriting from attacker modification, so the body-hash failure is not evidence of tampering here. It is evidence that authentication results are per-hop facts about a path, not verdicts about a message. Under RFC 7489, a p=none policy asks for no enforcement anyway, so none of the three answers changed the outcome.

The sending domain deserves a word of defense. It is roughly a quarter-century old, and at the injection hop the message arrived unsigned and SPF-failing for it. Its infrastructure was used as a laundering hop, which makes it a bystander, not the adversary. The injecting address has no reverse-DNS registration record, so no attribution is available.

Nothing In The Path Stopped It

Every control the message passed through waved it on. Microsoft assigned it a spam confidence level of minus one with a skip verdict, the gateway scored it a one, and every impersonation-protection check returned false, including newly observed domain and reply-to mismatch, because there was no lookalike domain or reply-to trick to find.

Themis, our Adaptive AI analyst, flagged the message at 90 percent confidence with a credential-theft classification, drawing on content patterns, sender behavior, and community reputation. That is a classification, not an observation: no harvesting page was ever captured. The incident reached the platform through a community report and surfaced in a retroactive scan weeks after delivery, not inline, and the single affected mailbox shows no mitigation date, no action, and no status. The message sat in an inbox the whole time.

What Defenders Should Take From This

Kit hygiene is a detection surface attackers rarely audit. Duplicate title declarations, unused class definitions, debug styles matching nothing, and campaign-designer markup without a matching delivery hop are all cheap to extract. The 2024 Verizon Data Breach Investigations Report puts phishing in 15 percent of breaches and stolen credentials in 38 percent, and records a median of 21 seconds from opening a phishing message to clicking its link. That is less time than a reader needs to notice a green banner asserting its own trustworthiness.

Treat any in-body trust assertion as hostile until proven otherwise, and say so in awareness training rather than teaching users to hunt for badges. Evaluate authentication per hop, because a clean gateway verdict can be describing a laundered path. And detect on template structure and sender behavior rather than on the pretext, which is the one part of this file the operator changes weekly. CISA's phishing guidance and the NIST definition of phishing frame it the same way: the delivery shell is durable, the story is disposable. The 2023 FBI Internet Crime Report attributes roughly 2.9 billion dollars in reported losses to business email compromise, and campaigns like this one build the inventory of warm mailboxes behind it.

Indicators of Compromise

MITRE ATT&CK Mapping