The Fake $479.99 Charge Inside a Real Adobe Sign Envelope

The notification looked exactly like the dozens of Adobe Acrobat Sign envelopes a busy operations team sees every week. The sender read as Adobe, the branding was Adobe's, and the message announced that an agreement had been created and sent for approval. An operations coordinator at a third-party logistics provider opened it expecting a routine document to sign. What sat inside was a charge dispute for money no one had spent, tied to a company that does not exist.

The email claimed a payment of $479.99 had gone through to a merchant called SecurePay LLC and urged the recipient to call a support line immediately if the charge was not recognized. That framing, borrowed from the PayPal receipt-scam playbook, is engineered to trigger a specific reflex. A person who never authorized a $479.99 charge does not stop to question the messenger. They reach for the phone number to make it stop.

A Real Adobe Envelope Around a Fake Charge

The envelope was genuine. This message truly originated from Adobe Acrobat Sign, which is what made it so convincing. The visible sender presented as adobesign@adobesign[.]com under the display name SecurePay LLC via Adobe Acrobat Sign, a real Adobe sending identity that had simply been used to deliver third-party content. Adobe's platform will faithfully generate and sign an envelope for whatever agreement a sender configures, and it did so here without any awareness that the "agreement" was a lure.

The merchant it named, SecurePay LLC, is fictional. So is the charge. The point of naming a plausible-sounding payment processor and attaching a precise dollar figure is to make the dispute feel administrative and urgent at the same time, the kind of thing you resolve in five minutes by calling the number in the notice.

Genuine Authentication, Fabricated Story

The technical record was clean where it counted. DomainKeys Identified Mail (DKIM) passed for adobesign.com. Domain-based Message Authentication, Reporting and Conformance (DMARC) passed as well, under a strict p=reject policy aligned to the adobesign.com header From. Microsoft's compound authentication logged compauth=pass reason=100. Sender Policy Framework (SPF) passed at Adobe's own sending relay and again at the Microsoft protection hop that delivered the mail.

There was a single SPF failure at an intermediate security-gateway hop, measured against a rewritten envelope address, but that is the ordinary result of a message being relayed and its return path rewritten in transit. On its own it proves nothing. Every signal a gateway leans on to decide "this is really Adobe" returned the answer Adobe. And every one of those signals was telling the truth about the platform while the content rode along unexamined.

This is the gap that trusted-platform abuse is built to exploit. Authentication vouches for the domain that sent a message. It does not read the story inside, and it cannot tell that a real Adobe envelope is carrying a charge dispute for a merchant that was invented that week.

The Reply Route Adobe Never Owned

The clearest tell was where a reply would actually go. Although the message came from Adobe's infrastructure, the Reply-To header pointed somewhere Adobe has no presence at all, an anonymous free-mail mailbox on the throwaway domain imails[.]asso[.]st. Its parent country-code zone has existed for years, but the individual mailbox was a disposable account with no tie to any real registrant.

The Return-Path told the same story from a different angle. The bounce address had been rewritten through Sender Rewriting Scheme (SRS) under an unrelated Microsoft tenant, kismetimbakkerijenafhaal[.]onmicrosoft[.]com, a domain with no relationship to Adobe, to the logistics firm, or to any payment processor. That routing is consistent with the message being pushed through a misused or compromised mail tenant on its way to the target. A recipient who hit reply to contest the charge would never reach Adobe. Their message would land on infrastructure the attacker controlled.

Rather than a malicious link, the call to action was a phone number, +1 804-604-4310. Moving the victim onto a live call is deliberate. It sidesteps URL scanning entirely and hands the interaction to a scripted operator who can walk the caller through surrendering card details or account credentials in real time.

The PDF That Was Not the Point

The envelope did carry an attachment, an AES-encrypted PDF that Adobe Acrobat Sign generated as part of the agreement, following the usual "Agreement Created and Approval Sent, unsigned" naming pattern. Inside were interactive AcroForm fields, including several zero-sized hidden widget annotations. Available static analysis found no embedded scripting and no explicit credential-prompt text in the file.

It is worth being precise here, because the instinct is to assume the document is the weapon. In this case the encrypted PDF is mostly stagecraft, a genuine artifact of the real Adobe workflow that makes the whole thing look procedural. The actual hook was always the body text and the phone number.

Mapping to MITRE ATT&CK

The tradecraft lines up with the MITRE ATT&CK framework. Delivery of the encrypted PDF within the notification maps to T1566.001 Spearphishing Attachment. The pressure to open and act on that Adobe-signed file aligns with T1204.002 User Execution: Malicious File. And the core deception, dressing a fraudulent charge dispute in Adobe's and a fictitious processor's identities, is T1036 Masquerading.

Indicators of Compromise

Why This One Needed Behavioral Detection

Signature and reputation checks were never going to stop this. The platform is legitimate, the authentication is genuine, and there is no malicious URL to scan. Detection has to weigh identity and intent instead. Themis, the Adaptive AI analyst on the IRONSCALES platform, flagged the message as Credential Theft at 62 percent confidence, leaning on community-reputation signals rather than a failed auth check. The signals that mattered were a trusted brand paired with a reply path that pointed nowhere near that brand, a charge dispute naming a merchant with no footprint, and a phone-number call to action doing the work a link usually does.

The 2024 Verizon Data Breach Investigations Report found the human element present in 68 percent of breaches, and it clocked the median time to click a phishing link at 21 seconds. When an attacker borrows a name a finance or operations team already trusts, that window closes even faster.

See your risk: find the attacks slipping past your secure email gateway.

The Takeaway

A perfect authentication verdict is a verdict on a domain, not on a story. When DKIM and DMARC pass for Adobe, they are confirming Adobe's platform sent the mail, not that the charge, the merchant, or the reply address is real. Treat brand notifications about money as prompts to verify through a channel you already know, never through the number or the reply button the message hands you, and watch the reply path as closely as the sender line. This is exactly the surface where invoice and payment fraud, a category of business email compromise, thrives, and it is why the same Adobe-branded pattern kept resurfacing against this organization. For a team reference on spotting and stopping these early, CISA's phishing guidance holds up well: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one