Invisible Letters Hid a Mailbox Verification Phish

The most dangerous character in this phishing email was one nobody could see. Between every letter of the VERIFY MAILBOX NOW button sat an invisible right-to-left override mark, Unicode code point U+200F, a control instruction that renders as nothing on screen but quietly reorders the underlying text. To a human it read as a plain button. To any filter hunting for that exact string, it read as gibberish.

The message landed in four mailboxes at a large U.S. automotive manufacturer, addressed by name to a senior finance analyst. It posed as an internal mailbox-verification notice, complete with a Microsoft-style footer, and it arrived with a perfect authentication record. This is the uncomfortable part of the case: nothing at the transport layer was broken. The attacker did not spoof anything. They authenticated legitimately, then hid the con inside the characters.

Full Authentication, No Legitimacy

The mail was sent through Amazon Simple Email Service (SES) out of the us-east-2 region, using the sending identity granite-part[.]com. SPF passed, DKIM passed on both granite-part[.]com and amazonses.com, and DMARC passed with compauth=pass reason=100. On a scorecard, this message is flawless.

That is exactly the trap. SES signs and authenticates for whatever sending identity is configured in the account, not for the brand a reader thinks they see. A clean SPF and DKIM result proves the message left an authorized server. It says nothing about whether an internal IT team actually sent a mailbox-verification request. Attackers have learned that the cheapest way to inherit deliverability is to stop fighting authentication and start passing it, by standing up their own domain inside a reputable sending platform.

The Letters You Cannot See

Two layers of obfuscation did the real work. The subject line borrowed the recipient company's own initials and framed the message as an internal Request Approved notice, but the text was seeded with Cyrillic homoglyphs. Characters that look identical to Latin e, a, p and o were swapped in from the Cyrillic block, so an exact-string rule scanning for the English words never fired on a match. The subject looked completely normal to the analyst and completely foreign to the filter.

The button pushed the same idea further. The visible call to action read VERIFY MAILBOX NOW, but the raw display text carried a U+200F right-to-left override between every single character. This is a verified artifact from the message, not an inference. The override marks are invisible on render, contribute nothing a person notices, and reduce the machine-readable string to something no keyword rule recognizes. It is credential harvesting with a coat of Unicode paint, and the paint is the point.

A Redirect Chain Borrowed From Reputation

If the letters got the message read, the link chain got the click delivered. The button did not point at the final page. It routed through click.mailersend[.]net, then a Mailjet tracker at 1shrz.mjt[.]lu, then a Proofpoint urldefense wrapper, and only then to the real destination: scale.bursanurotokiralama[.]com, a repurposed Turkish car-rental-themed domain with no PTR record and no DMARC policy, serving a credential-harvest page.

Every hop in that chain except the last is a legitimate service. A marketing platform tracker, a second email service provider redirector, and a security vendor's own URL-rewriting wrapper all lent their reputation to the click and buried the true landing page behind three trusted names. A scanner that judges only the first URL it sees clears the message on the strength of mailersend or proofpoint alone. The malicious host, sitting at the end of the tunnel with no reverse DNS and no published policy, never gets inspected.

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

Mapping to MITRE ATT&CK

The tradecraft lines up with a few techniques in the MITRE ATT&CK framework:

• T1566.002 Spearphishing Link covers the core delivery, a targeted mailbox-verification lure whose payload is a redirect chain to a harvesting page.
• T1027 Obfuscated Files or Information covers both the Cyrillic homoglyph subject and the invisible right-to-left override marks inside the button text.
• T1036 Masquerading covers the internal-notice framing and the Microsoft-style footer used to make an external message feel like routine IT.

Indicators of Compromise

Why Static Checks Missed It

Authentication cleared this message, keyword rules never saw the strings they were built to catch, and reputation scanners approved the redirectors instead of the destination. Every static control did its job and still let the attack through, because the attack was designed around what those controls measure.

Detection has to move to relationships and intent. The signals that matter here are a mailbox-verification demand from an external sending identity unrelated to the recipient's own IT, a subject and button whose rendered text and raw bytes disagree, and a click path that leans on stacked third-party redirectors to reach a policy-less host. Themis, the Adaptive AI analyst on the IRONSCALES platform, reads those relationships the way a trained analyst would, weighing the claimed context against the actual sender and the shape of the redirect chain, and flags the impersonation even when every server-level check comes back green.

That gap is well documented. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and stolen credentials behind 38 percent of them, and the Microsoft Digital Defense Report 2024 traces the same shift toward abusing trusted services rather than breaking them. The FBI's 2023 Internet Crime Report likewise ranks business and credential-focused fraud among the costliest categories, which is precisely the lever a mailbox-verification harvest pulls. Across 35,000+ security professionals at 17,000+ organizations, the pattern is consistent: the phish that authenticates cleanly is the one that reaches the desk.

The Takeaway

A credential-harvest page that captures a corporate mailbox login is not the end of the attack, it is the start of the next one, which is why account takeover protection belongs in the same conversation as inbound filtering. Treat internal-looking verification requests as claims to be checked, not facts to be obeyed, especially when the sender lives outside your own tenant. When the text on screen and the bytes underneath it tell different stories, believe the bytes. CISA's guidance on recognizing and stopping phishing early is a good reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one