Two Brands in One Message, One URL Built at Runtime

A shared remittance mailbox at a medical device manufacturer received a payment notice earlier this summer, styled as a DocuSign alert announcing that a completed document was ready for review, its subject referencing a check remittance service request and a reference number.

Nothing about the sending path supported it. The visible call to action in the body was an empty anchor pointing at nothing. The single attachment scanned clean. And the phishing URL this attack depends on existed nowhere in the message, because the code only builds it on form submission.

A Send With No Sending Domain

The connection arrived directly from a raw IP address that offered a loopback address literal, [127[.]0[.]0[.]1], as its HELO name. Not a domain, so nothing to align against or look up.

SPF returned fail. DKIM was absent, the message never signed. DMARC recorded no policy and no action, the header From value blank in the authentication results. The Return-Path was empty, the Message-ID terminated at localhost, and Exchange scored the message at spam confidence level 8. A single hop from an unauthenticated host, not a relay laundered through a compromised service.

Under RFC 9989, the DMARCbis specification that replaced RFC 7489 in May 2026, a sender with no published policy gives a receiver nothing to enforce, and here there was no sending domain to publish one. Which is why NIST defines phishing by deception and objective rather than header mechanics.

The Envelope Brand and the Attachment Brand Are Different

The body was DocuSign work: the familiar review-a-document framing, a reference number for an electronic funds transfer remittance, one prominent button. That button pointed at #, an anchor with no destination, so the lure sits elsewhere.

Here it was the one attachment, a 16,462 byte HTML file whose name opened with the letters ck, an unusual hash character mid-filename, then a long hexadecimal string echoing the subject reference. The file scanner returned a verdict of Clean.

Opening it produces an entirely different brand. The document title reads as a secure access page for SharePoint, and the header presents a SharePoint secure link service. Microsoft, not DocuSign. The page renders a locked document chip labelled CheckRemit-requestedDocuments.pdf, a file never attached to anything, above a short form asking the reader to confirm access by entering a work address.

Two impersonations, stacked. The envelope borrows one trusted brand to make opening the attachment feel routine, and the attachment borrows a second to make the credential prompt feel routine. A recipient trained to check that branding matches the sender finds the mismatch as the form appears, and the form's own branding quietly resets the question.

The Destination Does Not Exist Until the Form Is Submitted

The attachment contains no hyperlink to the phishing destination. Not a wrapped one, not an obfuscated one, none. What it contains is an inline script that fires on form submission, runs two scripted pauses totalling about two seconds, shows a fake verifying state followed by a fake success message, and only then assigns a freshly assembled string to the browser's location.

That string is concatenated at runtime. It is not in the file as an attribute any parser would read as a link, and not in the email body at all. The consequence sits in the incident record: the platform's static link extraction for this message returned an empty array. Zero hyperlinks, so nothing to reputation-check.

That is the whole technique, closer to obfuscated information than to clever infrastructure. Delivery is a plain spearphishing attachment, and everything else happens client-side.

A Chain Built to Launder Through Google's Own Endpoints

Reconstructing the string the script assembles produces a nested redirect. The outermost hop is hxxps://meet[.]google[.]com/linkredirect, its dest parameter set to a second Google redirect, hxxps://www[.]google[.]com/url?q=, whose own value is a heavily percent-encoded blob. Unwinding it across several passes yields a string dressed as an advertising click tracker, with a ddm/clk path under adservice[.]google[.]com[.]ph and a plausible gclid parameter, terminating on radio11[.]org.

What can be stated is what the code is built to do. What cannot be stated is that it works: the decoded value handed to the second redirect does not begin with a URL scheme, so whether Google's real endpoints would forward a browser through to the terminal domain as intended, or reject a malformed value, is not established. The chain was not navigated. Read this as intent recovered from source code, not a confirmed working redirect.

The intent still explains the shape. Both outer hops are genuine, unmodified Google endpoints, neither compromised nor attacker owned, and their real redirect features are what the design leans on, so the first hostname any reputation check meets belongs to Google. The terminal domain has been registered since 2013, not the profile of fresh attacker infrastructure, and its WHOIS record was updated five days before the send. Prior cases here have called that warehousing, though WHOIS alone cannot separate a compromised site from one bought secondhand.

The assembled string ends in a fragment formatted like a query: a parameter named abcfamily set to a base64 value. Decoded, that value is the exact address the message was sent to. Whatever waits at the end is designed to know who submitted the form before reading anything else.

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

A Clean File Verdict Alongside a Phishing Disposition

File reputation scanning had nothing to object to, which is a category error, not a scanner failure. No macros, no embedded executable, no exploit attempt. The file is markup, styling and script, and the page is the payload.

Adaptive AI returned a recommendation confidence of 90 with a label of invoice phishing, drawing on community insights, sender analysis and content insights together. The state is recorded as automatically resolved as phishing. For the affected mailbox, the mitigation record logs an action of no action taken alongside a status of email was mitigated or reverted; those two fields read as inconsistent in the source record and both are reported as recorded, not reconciled. Nothing indicates anyone entered an address into the form.

What This Changes About Attachment and URL Controls

The 2026 Verizon Data Breach Investigations Report puts the human element in 62% of breaches and phishing as the initial access vector in 16%. The 2025 FBI IC3 report records $3,046,598,558 in business email compromise losses, and remittance pretexts are the raw material for that figure.

Two controls follow. A message with no extractable links is not a low-risk message, and an attachment that scans clean is not a cleared attachment. Advanced URL and malware protection has to reason about what an attachment does when rendered, including script that builds destinations after user interaction. CISA's phishing guidance separates payload handling from sender validation for exactly this reason.

Then treat a credential prompt as suspect whenever its branding differs from the branding that delivered it. Credential harvesting protection is what matters once a page has rendered locally, past the gateway, in a browser the recipient trusts. The brand switch between envelope and attachment is the clearest signal, available before anyone types.

Indicators of Compromise

MITRE ATT&CK Mapping