Google Sent This Email. The Law Firm Spelled with Cyrillic Letters Did Not.

The email came from Google. SPF passed. DKIM passed. DMARC passed. The shared file lived on Google's own servers and returned a clean scan verdict. The sending address was drive-shares-noreply@google.com, routed through doclist.bounces.google.com as it always is. By every technical measure available to a gateway, this was a legitimate Google Drive notification.

The display name read "Kirklаnd & Еllis-llP (via Google Drive)." Two of those characters were Cyrillic.

The Unicode Substitution That Authentication Cannot See

The attacker replaced the Latin "a" in "Kirkland" with a Cyrillic character that renders identically in most fonts, and replaced the Latin "E" in "Ellis" with its Cyrillic counterpart. To a human reading the display name at normal speed, this is Kirkland and Ellis, one of the largest law firms in the world. To any system performing Unicode-aware string comparison, it is a different sequence of code points entirely.

This is phishing through Unicode: MITRE ATT&CK T1656 covers impersonation, and T1566.002 covers spearphishing via link. The attack chains them: impersonate a law firm's display name, deliver via Google's authenticated notification system, point to a Google-hosted file that scans clean.

SPF, DKIM, and DMARC check whether the mail server that sent the email was authorized to send for its domain. They check nothing about the display name. Google's mail infrastructure is authorized to send for google.com. Google's authentication passes correctly, because Google did send this email. The question authentication cannot answer is: did Kirkland and Ellis instruct Google to send it?

The Subject Line and the Reply-To Architecture

The subject read: '[EXTERNAL]: Item shared with you: "Caution! | You Have An Arrears Notice | Clear Balance!"' Financial urgency in a file name, attached to an apparent share from a globally recognized law firm. That combination is designed to create pressure to open and act immediately.

The Open button in the notification linked to hxxps://drive[.]google[.]com/file/d/118uAE3T.../view. Real Google infrastructure, real file ID format, clean scan. The file itself is likely a credential-harvest lure or a document requesting the recipient to log in elsewhere, but the delivery URL at the notification layer gives the gateway nothing to block.

The Reply-To header was set to nophilgiadrov1998@dashboard[.]protecteddigitalperimeter[.]com. That domain has no MX record: it cannot receive mail through normal means. It has no SPF record and no DMARC policy. The WHOIS record provides no verifiable ownership. An attacker sets a Reply-To on a notification email so that anything the victim sends in response (a confused reply, an out-of-office auto-response confirming the mailbox is active, a request for clarification) routes to the attacker rather than to the impersonated firm.

The two-stage architecture is deliberate: Google delivers the initial notification cleanly, and the Reply-To harvests whatever follow-on information the victim provides.

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

Why Cloud-Storage Share Notifications Are a Structural Blind Spot

Cloud-storage abuse has become a documented and growing pattern. When attackers trigger a share notification from a platform like Google Drive, they are not sending phishing email themselves. They are instructing a trusted platform to send it on their behalf. The Verizon 2026 Data Breach Investigations Report documents phishing as a primary initial-access method in 16% of breaches, with the human element involved in 62% of all breaches. Cloud-platform abuse is a contributor to both statistics: it delivers phishing through channels humans and gateways have been trained to trust.

The FBI IC3 2024 Annual Report shows business email compromise and phishing continuing to lead financial-loss categories. Display-name impersonation of legal and financial firms is a consistent pattern in both categories: recipients conditioned to respond quickly to law-firm communications are specifically targeted.

When URL-reputation tools evaluate a link to drive.google.com, they return no threat signal. When sandbox analysis opens a file hosted on Google Drive, it sees Google's own infrastructure serving the content. The detection gap is complete: authentication passes, URL reputation passes, file-scan passes. Every control in a traditional gateway validates the wrong thing.

The Signals That Remained

Two indicators survived the authentication and reputation gauntlet. First, the display name contained non-Latin Unicode code points. A system that normalizes display names before rendering them, or that flags Unicode mixing across scripts in display names, catches this. Second, the Reply-To domain failed every passive DNS and authentication check: no MX, no SPF, no DMARC, no ownership trail.

The IRONSCALES AI platform performs Unicode normalization on display names and behavioral analysis on Reply-To domains as part of its detection logic. Themis flagged the script-mixing in the display name and the ownerless Reply-To before the notification reached the end user. The gateway, which validated the notification as a genuine Google send, had passed it through.

The NIST phishing definition frames phishing as a technique that attempts to acquire sensitive information by masquerading as a trustworthy entity. This case illustrates the precise mechanism: Google is the trustworthy entity, and the Cyrillic display name is the masquerade. No current email authentication protocol checks for that gap.

Credential harvesting protection against this attack class requires Unicode-aware display-name analysis and Reply-To domain reputation checking as baseline capabilities. Authentication verdicts, taken alone, do not tell you whether the display name is what it claims to be. This attack proves it.

Defanged IOC Table