Every e, o, and p Was Cyrillic. The Adobe Logo Was Real.

A document-share notification reached a dedicated HR alias at a mid-size organization in mid-July 2026. It carried an Adobe Document Cloud header, an Adobe logo, a blue button reading "Viеw Filе", and the complete Adobe Ireland legal footer, trademark disclaimer and registered-office line included. On screen it was flawless English. As bytes, almost none of it was English at all.

The subject line arrived as "Signеd Agrееmеnt Documеnt.рdf" has been shared with you. Codepoint inspection confirms that every "e" in that string is U+0435, Cyrillic small letter ie, and the "p" in the file extension is U+0440, Cyrillic small letter er. Themis flagged the message as credential theft at 90 percent confidence and the incident auto-resolved as phishing against a single mailbox, with no attachments involved.

The Substitution Ran All the Way Through the Legal Footer

Homoglyph abuse is usually surgical: one lookalike character in a registered domain, or a swapped vowel in a display name. That narrow pattern is what most detection stacks are built around, which is why brand and keyword rules still bite on the rest of a message even when the domain slips through.

This message broke that assumption at scale. Codepoint inspection of the rendered body found the same substitution set applied nearly everywhere a Latin e, o, or p appeared: the header wordmark alt text, the body copy, the CTA button label, the footer navigation links ("Managе Accоunt", "Custоmеr Suppоrt", "Fоrums"), the product names ("Crеativе Clоud", "Documеnt Clоud"), the words of the trademark disclaimer itself ("rеgistеrеd tradеmarks"), and the copied Irish registered-office block, down to a Cyrillic capital Р sitting inside the street address. Cyrillic е (U+0435) covered every e. Cyrillic о (U+043E) and О (U+041E) covered every o. Cyrillic р (U+0440) and Р (U+0420) covered every p.

There is no partial credit in that outcome. A rule searching for the exact string "Adobe" finds nothing. A rule searching for "Document Cloud" finds nothing. A rule fingerprinting copied trademark boilerplate finds nothing. Each of those strings is fully present to a human reader and completely absent to a text matcher, simultaneously, across the whole template.

The Only Authentic Brand Signal Was a Hotlinked Adobe Asset

The header and footer logo was not a screenshot and not a spoof. Its image source was literally hxxps://auth[.]services[.]adobe[.]com/img/generic/adobe_logo[.]svg, a genuine Adobe-owned hostname, hotlinked live at render time.

So the one element a scanner could positively tie to Adobe was the one element that actually belonged to Adobe. Everything readable had been made unmatchable, and the single verifiable piece of brand content was authentic. Real and counterfeit assets sat side by side in one frame, which is exactly what makes asset provenance a poor proxy for message legitimacy.

A Spoofed Envelope Sender With No Policy Standing Behind It

The visible envelope-from address belonged to an unrelated, long-established accounting firm, a real business operating a domain registered in 2001 with no connection whatsoever to this campaign. That firm was not compromised. Its SPF record did not authorize the sending IP, which produced a softfail rather than a hard failure, and the receiving provider delivered the message anyway. DKIM passed, but only for the sending platform's own signing domain, never aligned to the visible sender or to any Adobe domain.

Because the spoofed domain publishes no DMARC policy, that misalignment had nothing to enforce against it. RFC 9989, the current DMARC specification, only helps a receiver when the domain owner has published an instruction; absent a record, a softfail is a suggestion. Delivery rode a commercial bulk-mail relay operated by SMTP.com, one-click unsubscribe headers and all, deliverability hygiene the sender inherited for free.

Registered Five Months Earlier, Reactivated Six Days Before the Send

The one functioning link, behind the button, pointed at files[.]cloudacrobat[.]com. The reflex is to call that a freshly registered throwaway. It was not. The apex domain cloudacrobat[.]com was registered in February 2026, roughly five months before this message went out, behind a privacy-protection registrant and fronted by Cloudflare nameservers.

What was recent was the WHOIS update. That record changed six days before delivery. An aged registration touched immediately before a campaign is the signature of domain warehousing: buy early, sit on it, activate on the day. Reputation systems that weight creation date read five months of silence as maturity, with no fresh-registration risk to score. Update recency is the signal that survives, and it is rarely weighted at all.

Two further footer links pointed at a sibling domain, acrobat-file[.]com, which has no resolvable WHOIS record: a trademark-guidelines reference and an unsubscribe path, neither of which needed to function. Legitimacy padding. The record also noted nested and malformed anchor tags with repeated template blocks, plus a fabricated document reference planted in the body to imply a paper trail.

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

Why the Structural Impersonation Check Read False

The platform's own structural impersonation flag came back false, and that is the second lesson here. The sender alias read as a generic cloud file-sharing name and the envelope domain belonged to an accounting firm, so nothing in the sender identity claimed to be Adobe and an identity-comparison check had nothing to compare. The impersonation lived entirely in rendered body content: layout, color, the hotlinked asset, the copied legal text.

What caught it was content and infrastructure analysis rather than identity matching. Adaptive AI weighed template structure against first-time-sender status, an elevated sender risk score, an actionable host with no relationship to the impersonated brand, and footer domains that do not resolve, and returned 90 percent confidence on credential theft even though the individual link scans came back clean and mixed. Worth stating plainly: no rendered capture of the destination page exists in the record, so the finding rests on infrastructure and context rather than a photographed credential form. In live triage that is frequently all the evidence available, and here it was sufficient.

What Defenders Should Take From This

The 2026 Verizon Data Breach Investigations Report attributes 16 percent of breach initial-access vectors to phishing and finds credentials involved in 39 percent of breaches, the outcome credential harvesting campaigns like this one are built to produce. Both CISA phishing guidance and the NIST definition of phishing frame the problem around deceptive presentation rather than technical payload, which is precisely the surface in play here.

Four adjustments follow. Normalize text before matching it, so brand rules run against a script-checked copy rather than the raw string. Score mixed-script tokens directly: Cyrillic and Latin inside one word is cheap to compute and letter-agnostic. Weight WHOIS update recency alongside creation date, so a warehoused domain cannot launder dormancy into trust. And stop treating a brand-hosted asset as a trust input, because hotlinking is available to anyone with an image tag.

Indicators of Compromise

MITRE ATT&CK Mapping