The Card Was Real, the Button Was Not

Four staff mailboxes at a US faith-based nonprofit received a Paperless Post invitation. The subject carried the sender's own name. The layout was the platform's real layout, the logo was the platform's real logo, and the card artwork was served from the platform's own image hosting.

All of that was genuine, because the message was a genuine invitation. It had been delivered to a personal Gmail mailbox by the platform's mail provider, then answered from inside that mailbox and sent onward.

Two things had changed. The view button and the anchor wrapping the card image both pointed at the same shortener, and that shortener resolved to a domain registered three days earlier. And an all-caps instruction belonging to no e-vite template, "PRESS CARD ON DESKTOP.", was inserted directly above the button.

Two Hrefs and Nothing Else

Nothing was added to this message. No attachment, no extra link, no injected copy beyond one line of instruction. A destination was swapped underneath the two elements a recipient is most likely to click.

That matters because both clickable elements share one href. A recipient who distrusts a button and clicks the picture instead arrives at exactly the same place. MITRE ATT&CK files the vector as spearphishing link, and MITRE also tracks the step that follows: the attack depends entirely on a person clicking. The body asks for no credentials, no payment and no personal information. The whole ask is a click.

Everything else stayed real. Paperless Post's own app-store click-tracking links, its hosted image assets and its one-pixel open beacon were left untouched, and all of them returned clean verdicts. Four platform links, four clean results. The platform was not breached at any point: the tampering was confined to two rewritten hrefs inside a copy of one of its emails.

A Reply Into the Platform's Own Thread

The headers describe how the copy was assembled. Both the References and In-Reply-To fields carry the same message identifier, whose host portion matches the outbound mail-transfer naming used by the provider that delivers this platform's mail. The message was composed as a reply to the original invitation notification sitting in that mailbox. The reused HTML did not have to be rebuilt or scraped. It was already there, waiting to be answered.

The envelope tells the other half. The To field reads as undisclosed recipients, with the targets in blind copy. This was a blast, not a personal note, and it reached four mailboxes at the recipient organization. The reporting mailbox had never heard from this sender before, while other mailboxes at the same organization had. That split is a useful signal precisely because it survives when every cryptographic check passes.

There are assembly tells. The card and its one-word caption render twice in sequence, and the sender's own address sits as body text immediately above the inserted instruction. The card carries no text whatsoever: no occasion, no date, no venue, no host. It is a generic glitter graphic with a single given name beneath it. A real invitation carries event details. This one is a click vehicle with a picture on it.

Authentication Was Never Going to Help

Every check passed. DKIM passed for gmail.com, SPF passed for a designated Google outbound host, DMARC passed with header alignment intact, and ARC passed across the forwarding hop. Reply-To was set to the same address as From, so there is not even a diversion to point at.

None of those results were wrong. A real Gmail mailbox really did send this mail. Alignment as defined in RFC 7489 answers one question, whether a domain authorized a message, and a consumer webmail provider authorizes billions a day without any opinion on their contents. Whether that account was compromised or created for the purpose, the record does not establish; the intact personal signature block argues for the former. Either way the mailbox owner is a bystander, not an operator.

The Bot Check That Ended the Investigation

The shortener resolved to a path on a freshly registered domain in a generic top-level namespace. Registration was three days before delivery, through a privacy service, with the record updated the same day, no DNSSEC, and name servers pointing at Cloudflare. It publishes no mail records at all, which is throwaway-domain registration hygiene rather than a finding in its own right. Standing up disposable web infrastructure this way is acquire infrastructure, domains in ATT&CK terms.

Then the interesting part. The capture of that destination is not the attacker's page. It is a standard Cloudflare human-verification interstitial: a line about checking whether the connection is secure, a card headed with the bare domain name, and an unchecked box asking the visitor to verify they are human. That challenge is Cloudflare's own product working normally, not something the attacker built, and it stopped automated retrieval cold.

So no scanner ever saw what the page does. Not a credential form, not a payload, not a cloned brand. Nothing was observed, and nothing may be assumed. The honest finding is the verdict shape: both hostile URLs came back mixed, or partial, while all four genuine platform links came back clean. A reviewer skimming results sees mostly green and two shrugs. A routine bot check was enough to deny the defender a verdict, and automated URL analysis has to treat unresolvable as unresolved rather than acceptable.

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

What Scored It, and What Did Not Happen

Themis, the IRONSCALES Adaptive AI analyst, returned 54 percent confidence under the label "VIP Recipient", and its insight named the element rather than hedging: one or more links were flagged as malicious, including the view-the-card link. The automated content classifier, meanwhile, scored the body as grey mail at 0.62, which is itself part of the story. Judged as prose, the message genuinely asks for nothing.

The uncomfortable part belongs in the open. This case arrived as a report, it remains open, and no mitigation action is recorded against any of the four mailboxes. Nothing was quarantined and nothing was reverted. Four people were left holding a live invitation whose destination no automated system had been able to read.

Where the Control Has to Sit

Three things come out of this. Resolve every clickable element, not just the ones that look like buttons, because an image anchor and a button sharing one href is the whole trick. Weight verdicts by what they cover, since a message built from genuine platform components will always produce a majority of clean results. And treat a challenge page as a missing verdict, not a passing one, consistent with CISA phishing guidance and the definition NIST uses.

Then give people the rule that fits an invitation from someone they know. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds and a human element in 68 percent of breaches. Twenty-one seconds is not enough time to hover, so the habit has to be built before the message arrives, which is what awareness training is for: open the invitation in the platform's own app instead of through the mail, and an outbound link that no longer matches the platform stops mattering.

Indicators of Compromise

MITRE ATT&CK Mapping

See You Next Time

The best part of this case is what we still do not know. A standard bot check, doing its ordinary job, made the destination unreadable to every automated system that looked at it. Check back tomorrow.