The notification looked like any other Google Drive share. A law firm, Alston & Bird LLP, had shared a document. The subject was blunt in the way legal correspondence tends to be: "Our Counsel Notifies -> Arrears Identified." Someone at the firm wanted your attention, and they had paperwork to back it up.
Except the "о" in "Alston" was Cyrillic. And "LLP" was spelled with Unicode small capital letters. And every reply you sent would have gone to a domain registered the day before.
See how IRONSCALES catches attacks that pass every auth check
On March 27, 2026, a healthcare outcomes firm received a Google Drive share notification addressed to 23 recipients, a mix of Gmail accounts, Hotmail addresses, and institutional emails including an .edu domain. Three of those recipients worked at the healthcare firm. All three had the email land in their inboxes.
The display name read: "Alstоn & Bird ʟʟᴘ֍ Stо..."
That's not a typo in this post. The "о" characters in "Alston" and "Sto" are Cyrillic (Unicode U+043E), not Latin. The "ʟ," "ʟ," and "ᴘ" in what should read "LLP" are Unicode small-capital letters, visually near-identical to their Latin counterparts but occupying entirely different code points. Rendered in a standard email client, the name looks convincing enough. Submitted to a blocklist or an impersonation rule built on Latin string-matching, it matches nothing.
This technique, cataloged by MITRE ATT&CK as T1027: Obfuscated Files or Information, exploits the gap between how humans perceive characters and how software compares them. The FBI's 2024 Internet Crime Report documented over $2.9 billion in losses from BEC and email impersonation schemes, and display-name spoofing remains one of the most consistent delivery mechanisms because it targets the recipient's eyes rather than the filter's logic.
Alston & Bird LLP is a real firm. The attacker chose it deliberately: a recognized legal brand carries built-in authority, and a subject line about "arrears identified" carries built-in urgency. Neither the firm nor its counsel had anything to do with this email.
The envelope from address was drive-shares-noreply@google[.]com.
That isn't a spoof. The attacker created a real Google Workspace account, used it to share a file on Google Drive, and Google's own notification pipeline sent the email. The authentication results were exactly what you'd expect from a message that genuinely came from Google:
Every link in the email resolved to legitimate Google infrastructure. The "Open" button pointed to a Google Drive file. URL scanners returned clean verdicts. As MITRE ATT&CK documents under T1608.001: Stage Capabilities: Upload Malware to Cloud Storage, hosting payloads on trusted cloud infrastructure specifically exploits the implicit trust organizations extend to services like Google Drive. There was nothing for a traditional scanner to flag because there was nothing technically wrong with the envelope.
The Proofpoint 2025 State of the Phish report found that 84% of organizations experienced at least one successful phishing attack in 2024, with attackers increasingly abusing cloud storage and collaboration platforms to bypass detection. Google Drive, OneDrive, and Dropbox have all been weaponized as delivery infrastructure precisely because security tools trust them by default.
This is what trust laundering looks like in practice. Borrow Google's credibility to deliver your message. Route the replies somewhere else entirely.
Buried in the headers, visible only if you knew to look, was a Reply-To address: nannestplicag2001@login[.]cloudsecurityaccess[.]com.
The domain, login[.]cloudsecurityaccess[.]com, was registered on March 26, 2026. One day before the attack landed. It had no A record, no DMARC policy, no DKIM selectors, and no visible web presence. The only DNS record was a site-verification TXT entry, the bare minimum needed to pass a Google Workspace domain verification check.
Learn how Themis analyzes sender behavior
The attacker's workflow was well-documented: register a domain that sounds plausible, verify it with Google to create a Workspace account, share a Google Drive file, and let Google's notification system do the delivery. MITRE ATT&CK T1583.001: Acquire Infrastructure: Domains describes exactly this pattern, acquiring fresh infrastructure to stage an attack before defenders can build blocklists against it. CISA's 2024 guidance on phishing infrastructure notes that attacker domains registered within 48 hours of use appear in the majority of sophisticated targeted phishing campaigns.
If a recipient had clicked "Open," reviewed the Google Drive file, and then replied or submitted information, every response would have gone to the attacker. The Google envelope was the vehicle. The attacker-controlled Reply-To was the destination.
The email rendered as a pixel-perfect Google Drive share notification. The header read: "Alston & Bird LLP□ Stop Access shared an item." The small box character, a rendering artifact of one of the homoglyph characters, was the only visible anomaly. In a busy inbox, easy to miss.
The sender line displayed the attacker's email address in plain text: nannestplicag2001@login.cloudsecurityaccess.com. That detail was visible to anyone who looked, but it required looking. Recipient organizations had injected a yellow caution banner noting the message originated outside their network. One recipient, to their credit, reported it anyway. The behavioral training to flag suspicious external email worked. What didn't work was every technical control upstream of the human.
The single call to action was a blue "Open" button, indistinguishable from any legitimate Google Drive notification. Below it sat Google's standard footer: 1600 Amphitheatre Parkway, Mountain View, CA. The attacker borrowed that too.
Themis, the IRONSCALES Adaptive AI virtual SOC analyst, resolved this case in approximately 3.5 minutes across three affected mailboxes. The detection didn't come from authentication headers. It came from the signals the attacker couldn't fake.
First, display name Unicode analysis. Homoglyph substitution in brand display names is a known evasion technique, and character-level inspection identified the Cyrillic and small-capital substitutions that made "Alston & Bird LLP" look right without being right.
Second, Reply-To domain age. A domain registered the previous day with no authentication infrastructure and no web presence is not how law firms communicate with clients. The mismatch between Google's trusted envelope and a one-day-old attacker domain in the Reply-To header was the behavioral fingerprint of trust laundering.
Third, the structural contradiction. Legitimate Google Drive notifications don't route replies to external domains. The combination of a real Google envelope and an attacker-controlled Reply-To is not a pattern that appears in normal organizational communication. Verizon's 2025 Data Breach Investigations Report found that phishing campaigns exploiting trusted third-party infrastructure have grown steadily as a share of total BEC-adjacent incidents, precisely because they defeat authentication-dependent defenses.
All three mailboxes were quarantined and mitigated before any recipient clicked.
The lesson this attack leaves is precise. SPF, DKIM, and DMARC answered one question: did Google send this email? The answer was yes. They were never designed to answer the harder question: is the person claiming to be Alston & Bird LLP actually Alston & Bird LLP?
Those are different questions. Most email security stacks treat them as the same one.
Display name impersonation through Unicode substitution targets the gap between those two questions. The attacker doesn't need to compromise Google. They don't need to spoof a header. They need to register a domain, create an account, share a file, and craft a name that human eyes will parse as familiar while filters parse it as unknown.
For security teams, three controls close this gap. Unicode-aware display name analysis that flags non-Latin character substitution in recognized brand names. Reply-To domain inspection that surfaces mismatches between envelope sender and reply destination, including domain registration age. And behavioral AI that correlates those signals in real time rather than waiting for a blocklist entry that will never come, because the infrastructure was built yesterday and abandoned tomorrow.
The attacker's domain is already gone. The technique is still running.
Book a demo to see it in action
---
| Type | Indicator | Context |
|---|---|---|
| Reply-To Domain | login[.]cloudsecurityaccess[.]com | Attacker-controlled; registered March 26, 2026 (one day before attack) |
| Reply-To Email | nannestplicag2001@login[.]cloudsecurityaccess[.]com | Attacker reply destination embedded in Google Drive notification |
| Envelope From | drive-shares-noreply@google[.]com | Legitimate Google address (notification infrastructure abused) |
| Display Name | "Alstоn & Bird ʟʟᴘ" | Contains Cyrillic "о" (U+043E) and Unicode small-capital L/P characters |
| Subject | "[EXTERNAL]: Item shared with you: 'Our Counsel Notifies -> Arrears Identified'" | Legal urgency lure; external sender warning injected by recipient org |
| Attack Date | March 27, 2026 | Three mailboxes affected at a healthcare outcomes firm |