Table of Contents
The message that reached the chief executive of a small independent power and energy company looked like an errand. An e-signature notice, a branded document card, a headline offering to let the reader find disclosures for review, and beneath it the name of a non-disclosure agreement PDF with a file size next to it.
The structured incident record for that message lists an empty attachments array and an empty links array. The first of those is simply true: there was no attachment, and the PDF named in the card existed only as a string of text in the body. The second is where the case lives. The message did have a live external destination. It covered the entire visible card. And the extractor that produced that empty array had nothing of the kind it looks for.
One Region Covering the Entire Card
Rendered, the body is a single branded block: a logo image whose alt and title text both name DocuSign, a headline, a file name, a size line. There is no button, and nothing in it reads visually as a hyperlink: no underline, no accent color on any word.
In the raw HTML that whole block sits inside an image map. One map element named workmap holds exactly one area element, with coords="0,0,10000,10000" and an href pointing at an external host. The rectangle those coordinates describe is far larger than anything actually drawn on screen, so every rendered pixel of the card falls inside it. The logo, the headline, the file name and the size text are not four elements with their own behavior. They are one clickable region, and it navigates off the message.
Why the Extractor Found Nothing to Extract
URL extraction in most pipelines does two things: it walks anchor elements and reads their href attributes, and it pattern-matches body text for anything shaped like a URL. This message offered neither. There is no anchor tag anywhere in it, and the destination string never appears as visible text.
An area element's href is not exotic. HTML image maps have been in the specification since the 1990s and are still widely supported in mail clients. But an area element is not an anchor. A parser built around anchors returns an empty set, that empty set is serialized into the detection record as zero links, and a triage queue sorted on link volume files the message alongside the newsletters.
Our corpus already carries teardowns where an empty links array was honest as far as the markup went: a voicemail lure whose payload was a QR code sitting one MIME level down inside an attached message, and a fake payment receipt whose only hyperlink was a mailto address pointing at a consumer mailbox. In both, the destination genuinely lived outside the parser's reach.
This case inverts that. The destination was inside the markup, absolute, live, and the single largest target in the message. The empty array is a fact about which element types the parser enumerates, not a fact about whether the message can be clicked. Those are two different statements, and only one of them got recorded.
Sent by the Recipient, to the Recipient
The From and To headers carried the same value: the recipient's own mailbox. No account was compromised to achieve that. The sending host was a rented cloud address whose reverse DNS resolved to a Google Cloud hostname, infrastructure with no relationship to the impersonated e-signature brand and none to the recipient's own domain.
Nothing Authenticated, at All
The authentication results were uniformly empty rather than failed. SPF returned none for the sending IP. The message was not DKIM signed. DMARC evaluated to none with action none, and composite authentication also returned none, carrying reason code 905 verbatim in the header.
That absence is the mechanism behind the self-addressed From. A domain publishing an enforced policy gives receivers something to act on, and the alignment guarantee that RFC 9989 exists to provide is what makes an unauthenticated claim on your own domain expensive to send. With no policy in force there was nothing to enforce, which is the ordinary case for DMARC management and monitoring work and the reason a spoof of a chief executive's own address costs an attacker nothing. The 2026 Verizon Data Breach Investigations Report puts phishing at 16 percent of initial access vectors and the human element in 62 percent of breaches, and a message like this is why: every machine-readable signal was either absent or empty, which left a person to decide.
See Your Risk: Calculate how many threats your SEG is missing
Where the Click Actually Went
The area element's href resolved to the root of done4you[.]tv, a domain with no visible connection to the named e-signature brand or to the recipient's business. A WHOIS lookup returned no record at all, so its age, registrant and status cannot be established in either direction. There is no landing-page capture in the record and no scanner verdict on the host, so what happened after a click was never observed.
What is documented is narrower and still bad: a live path off the message to an unrelated external host, delivered without a single anchor element, reachable from any pixel of a card designed to look like a document. That is spearphishing via link and user execution of a malicious link in substance, with the delivery mechanism doing the work of obfuscation at the markup layer rather than in the character stream.
What Actually Flagged It
Not URL analysis. There were no URLs to analyze. The message was surfaced by sender and behavioral signals, tagged as a suspicious sender and weighted by a recipient label marking the mailbox as belonging to a senior executive. No confidence percentage exists in this record, and it is worth saying so plainly rather than inventing one. A human analyst reviewed the report and approved action on it, and both occurrences were quarantined and permanently deleted.
The repetition is the other signal: the same lure reached the same mailbox twice, eleven days apart, with the subject shifting slightly between attempts, which is what a sender does to check whether a mailbox is live and whether a technique survives.
Three changes fall out of this. Extract href attributes from image map area elements and from image elements, not only from anchors, and reconcile the resulting count against what the body actually renders. Treat an empty links array on a message whose body renders as a single branded card as unproven rather than clean, which is the discipline behind malicious URL analysis that reasons about the whole message instead of one field. And weight the header contradiction: an inbound message whose From and To are the same local mailbox, arriving with no authentication of any kind, is an anomaly before anyone reads a word of it, and behavior-led Adaptive AI scoring is what catches it when every field a gateway checks comes back empty. The habit CISA's phishing guidance and the NIST definition of phishing both return to still applies: an unexpected document notice gets verified inside the application it claims to come from, never through the card in the mail.
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Domain | done4you[.]tv | Sole href target of the body-wide image map; WHOIS returned no record, so ownership and age are unresolved |
| IP | 34[.]141[.]226[.]210 | Sending IP, rented cloud address |
| PTR | 210[.]226[.]141[.]34[.]bc[.]googleusercontent[.]com | Reverse DNS for the sending IP |
| HTML attribute | coords="0,0,10000,10000" | Single image-map region, far larger than the rendered card, covering every visible pixel |
| HTML attribute | name="workmap" | Image map holding the one clickable area element |
| Subject | [EXT]: [Review] NDA Paperwork for [company] | Recipient company name removed here; the earlier attempt read "NDA Agreement" instead of "NDA Paperwork" |
| Filename string | [company] NDA Agreement v2.pdf | Named in the card as if attached; no attachment existed in the message |
| Card copy | Find disclosures for your review | Headline inside the branded document card |
| Image metadata | Logo image alt and title text naming the e-signature brand | Only brand cue in the body, carried by an image rather than by text |
| Auth results | spf=none; dkim=none; dmarc=none action=none; compauth=none reason=905 | Every authentication signal absent rather than failing |
| Header anomaly | From and To both the recipient's own mailbox | Self-addressed spoof arriving from external infrastructure |
MITRE ATT&CK Mapping
| Technique | ID | Application |
|---|---|---|
| Phishing: Spearphishing Link | T1566.002 | Clickable external destination delivered without any anchor element, carried by an image map area href |
| User Execution: Malicious Link | T1204.001 | A click anywhere on the branded card was required to reach the external host |
| Obfuscated Files or Information | T1027 | Destination concealed at the markup layer, invisible to anchor-based URL extraction |
Related attacks
| Attack | What happened |
|---|---|
| A Pixel-Perfect Sephora Delivery Notice Shows Why Email Authentication Alone Can't Protect You | A fully authenticated Sephora delivery notification passed SPF, DKIM, and DMARC with perfect scores. |
| The Phishing Email That Read Backwards in Its Own Source | Every visible line of this e-signature lure was stored backwards in the HTML source and un-reversed only by a CSS bidi override at render time. |
| The Procore Footer Was Real. The Document Was Not. | Every link scanner called the Procore and ExxonMobil URLs clean. |
| The B2B Content Marketing Email That Borrowed a Brand, a Relay Allow-List, and a Security Vendor's Own URL Wrapper | A polished B2B research report offer used SelectHub branding, passed through an allow-listed mail relay at SCL -1. |
| The Email That Passed Every Security Check (Because Adobe Sent It) | A phishing campaign targeting school district staff used Adobe's own sending infrastructure, real DKIM signatures. |
Explore More Articles
Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.