Adobe Sign Impersonation Misspelled Its Own Display Name

The message arrived as an Adobe Acrobat Sign invitation to review and sign a contract package. It landed in the mailbox of a director general at a multinational cinema chain, along with other addresses at the same organization. The subject line was the kind of thing that reads as real because it is too tedious to be invented: the company's own name, an agreement and letter of authorization signature packet, the phrase "Execution Versions (Executed)," and a three-digit reference in parentheses.

Every authentication check passed. Not partially, not by best guess. SPF passed, DKIM passed twice, DMARC passed in alignment, and Microsoft's composite authentication returned the highest-confidence value it has. The message scored as ordinary mail on arrival.

The disguise had exactly one flaw. The display name in the From header read Adobesiign System_NA3. There is a second letter i in Adobe's name, sitting in plain view, in plain ASCII.

Nothing in the Header Was Forged

Walk the headers and there is no seam. SPF passed from 54[.]240[.]7[.]20, a shared egress address belonging to Amazon Simple Email Service in its Ireland region. DKIM produced two valid signatures, one for the sending domain itself and a second for amazonses[.]com, which is what a correctly configured tenant on that platform looks like. DMARC passed, aligned to the domain in the From header, with a published policy of none. Composite authentication came back as compauth=pass reason=100, and the receiving Microsoft 365 tenant assigned a spam confidence level of 1.

The critical detail is what that alignment was aligned to. DMARC under RFC 7489 asks whether the domain in the From header authorized the message. Here it did, honestly, because the From domain was never Adobe. The brand appeared only in the display name, a free-form text field no authentication protocol reads or can validate. A defender running DMARC management and monitoring on Adobe's behalf would see nothing, because Adobe's domains were not involved at any layer.

The Sending Domain Was a Bystander, Not a Burner

The obvious next question is who owns the domain that signed the message, and the answer complicates the usual heuristics. Registration records show it created in 2009, close to fifteen years before this send, through Network Solutions, with ordinary status flags and no privacy or suspension anomalies. That is not the profile of a throwaway. It is the profile of a real personal and professional domain that has been quietly in service for a decade and a half, belonging to an individual with no connection to Adobe, to e-signature workflows, or to a cinema business in another hemisphere.

Its sending capability on a large cloud email platform was what the attacker actually wanted. Configure a domain on a shared sending service and the service handles the cryptography and the egress reputation for you. Whoever sent this message inherited both, which is consistent with a compromised or otherwise abused sending identity rather than infrastructure built for the campaign.

Reputation logic has no useful answer here, and the domain-age heuristic that catches same-day registrations and typosquats inverts outright. Age was not evidence of safety. It was the asset being borrowed.

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

A Typo Is Cheaper Than a Character Trick

Impersonation research tends to gravitate toward the clever end of the spectrum, where attackers swap in visually identical characters from other alphabets and force defenders into normalization and confusable-character checks. This message did none of that. Adobesiign is plain, ordinary ASCII with one letter typed twice. There is nothing to normalize, no mixed-script warning to raise, and no confusable mapping that resolves it, because every character in the string is exactly the character it appears to be.

It works because almost nobody reads display names. Most mail clients render the display name as the entire visible sender identity and tuck the actual address behind a click or a hover. A senior executive triaging a signature request between meetings sees a plausible brand, a plausible pretext, and a document they were half-expecting anyway. The System_NA3 suffix does the rest, mimicking the machine-generated naming of an automated notification service, which discourages the closer look a human sender's name might invite.

The doubled letter may not even have been deliberate. Either way it survived into delivery, and that is the finding: a defect visible to any careful reader passed through every automated control in the path untouched.

The Destination Was Never Resolved

The review-and-sign call to action was the one part of the message that could not be pinned down. Its anchor was empty in the HTML, so the real destination was not captured in the scanned link inventory. The links that were scanned were peripheral Microsoft support and help pages, and all of them came back clean, exactly as genuine Microsoft pages should.

That leaves the final stage unverified, and it should stay described that way rather than dressed up as a confirmed phishing kit. What is verified is the platform's own reading of the message. Themis, our Adaptive AI analyst, scored it at 90 percent confidence and labeled it on two axes at once, credential theft and high-value recipient, then the incident was automatically resolved as phishing. That combination is the useful signal. An e-signature lure aimed at the most senior mailbox in an organization, from a domain with no history of contact with it, is anomalous in ways that have nothing to do with cryptography, which is the terrain credential harvesting protection has to cover when authentication offers no help.

Scale is what makes that gap expensive. The 2024 Verizon Data Breach Investigations Report puts stolen credentials in 38 percent of breaches and measures the median time to click a phishing link at 21 seconds, and the 2023 FBI IC3 Internet Crime Report counted roughly $2.9 billion in reported business email compromise losses. Neither figure moves with a stricter authentication posture.

Mapping to MITRE ATT&CK

• T1566.002 Phishing: Spearphishing Link covers the delivery, a targeted e-signature pretext whose payload was a call to action rather than an attachment.
• T1656 Impersonation covers the display-name misspelling of a widely trusted document-signing brand, with no forged domain anywhere in the message.
• T1586.002 Compromise Accounts: Email Accounts is consistent with the use of an unrelated domain's cloud sending identity, though how it was obtained is not established from this evidence.

Indicators of Compromise

The Takeaway

A green authentication result answers one narrow question, whether the domain in the From header authorized this message. It answers nothing about whether that domain has any business claiming to be Adobe, and it never looks at the field the recipient actually reads.

Three practices follow. Compare the claimed brand in the display name against the domain that signed the message, and treat a mismatch as a first-class signal rather than a footnote in the header dump. Weight recipient seniority in triage, because a signature request to the top of an organization from a domain with no prior contact is anomalous on its own terms. And retire domain age as a proxy for trust, since a mature registration on a shared sending platform is now something an attacker rents rather than something a defender can rely on. CISA's phishing guidance and NIST's definition of phishing are useful anchors for building that judgment into a triage workflow.