The Phishing Email That Read Backwards in Its Own Source

The message that reached a senior executive at a national home-care services company was the most ordinary thing an inbox receives: an e-signature notice saying a document had been completed and was ready to view, a short sub-heading, and a single button. It rendered cleanly, left to right, plain English. The subject line was one word and a colon, with nothing after it.

The raw HTML source said something else entirely. Search that source for the phrase printed on the button, "View Completed Document", and you get no hits. What is actually stored in the file is tnemucoD detelpmoC weiV. The headline is stored as detelpmoc neeb sah tnemucod ruoY. The sub-heading is stored as tseuqeR gningiS erutangiSe. Every visible line of copy in that email is warehoused as its own mirror image.

The Style Property Doing the Work

Four separate inline spans in the body carry the same declaration: unicode-bidi:bidi-override; direction:rtl; display:inline-block. That combination tells the rendering engine to abandon the normal bidirectional layout algorithm and draw the enclosed characters right to left in the order supplied. Feed it a reversed string and it hands back the original. The recipient reads fluent English. The file holds the reflection.

Nothing about the character stream itself is unusual. No invisible characters, no homoglyphs, no non-Latin script, no image-only body, no macro, no attachment. It is printable ASCII, correctly encoded, with a style property doing the inversion at the last possible moment. That is the whole trick, and it puts a defender and a recipient in front of two different strings.

Not the Unicode Control-Character Variant

This belongs to the broader family of bidirectional-text abuse, and it is worth being precise about which member, because the two are defended against differently. The better-known version, which our corpus already carries a teardown of, injects Unicode right-to-left marks (U+200F) between the individual characters of a string. The phrase stays intact and in reading order, but the invisible control characters break the token boundaries a model relies on, so a button label that still reads "REVIEW DOCUMENT" to a person arrives at a language classifier as a scattering of one-character fragments.

The standard remediation for that is normalization: strip zero-width and directional control characters before classification, and the phrase snaps back together.

Applied here, that remediation is a no-op. There is nothing to strip. The stored bytes are ordinary printable characters, in reverse order, because someone typed them that way, so a normalizer passes them through untouched. Keyword lists have never contained tnemucoD detelpmoC weiV, and the string looks like nothing at all, which is worse than looking suspicious. The inversion is not in the character stream. It sits one layer up, in a style property, and exists only at render time. The property being named unicode-bidi invites exactly the conflation worth avoiding: this is a CSS bidi override, not control-character injection. Both map to MITRE ATT&CK T1027, Obfuscated Files or Information. Only one of them survives a scrubber.

Authenticated, Aligned With Nothing That Mattered

The delivery side was quiet by design. The message was relayed through a large email service provider. SPF passed for the provider's return-path identity, DKIM passed with a provider-issued selector signing for the sending domain, and the ARC seal was present and consistent through the receiving mail exchanger. Every authentication result a gateway looks at came back green, on a single hop, with no relay or sanitization appliance in the chain.

The sending domain was an aged business domain registered back in 2008, registrant redacted, carrying a European business name with no relationship to any e-signature service. Its WHOIS record had been updated a little over two weeks before the send, which is equally consistent with a long-dormant asset quietly compromised and with one that changed hands recently. The record does not settle which. Either way the owner is a bystander, not the attacker, and is genericized here.

Two things did no work at all. There was no DMARC policy in force for the arrangement, so the alignment guarantee that RFC 9989 exists to provide was simply absent. And even a strict policy would have had nothing to say, because the impersonation lived in the display field: the sender alias presented a cloud e-signature service while the authenticated domain was that unrelated aged business domain, which is T1036.005 masquerading in its plainest form. The 2026 Verizon Data Breach Investigations Report puts phishing at 16 percent of initial access vectors and the human element in 62 percent of breaches, and cases like this are why. Every machine-checkable control reported success, which left the decision to a person reading a rendered button.

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

Where the Click Actually Went

The reversed button was a live link, which is T1566.002 spearphishing via link paired with T1204.001 user execution. Clicking it ran through the sending provider's own click-tracker, then through a second commercial tracking service, and finally to a page on a 2012-registered domain sitting on shared hosting whose reverse DNS pointed at an unrelated third-party hostname. That mismatch suggests a page planted on somebody else's infrastructure rather than a purpose-built attacker host, so it is genericized too. The path is worth noting on its own: the file sat inside a folder named after a global news network, on a domain with no connection to that network or to e-signature software.

The platform's link scanner resolved the destination and marked it malicious. What the capture shows is a security-verification card asking the visitor to confirm they are human, with a press-and-hold button and a line about automated protection. No credential entry fields are visible in that capture. A press-and-hold gate is a filter, and what it serves a real browser after the hold was never observed, so the credential-theft label here is the platform model's own classification, not a confirmed harvesting flow.

What Flagged It

Themis returned an 84 percent confidence credential-theft classification, citing the malicious destination alongside structural and language cues, and the incident auto-resolved as phishing with no analyst in the loop. That matters more than usual here, because the strongest signal in the message was invisible to the reader: the reversal is a property of the source, not of the rendering. Behavior-led Adaptive AI scoring and destination analysis carried the verdict where source-level phrase matching had nothing to grab. Two occurrences reached the same mailbox two days apart before the report was filed, consistent with a sender probing whether the mailbox is live.

Three detection notes fall out of the case. Reconcile rendered text against stored text instead of trusting either alone, and treat any inline style carrying unicode-bidi:bidi-override or direction:rtl inside an otherwise left-to-right message as a first-class anomaly worth reversing and re-scoring. Treat a fully authenticated aged domain sending for a brand it has no visible relationship with as a signal rather than an exoneration, the pattern credential-harvesting protection targets, and pair it with malicious URL analysis that follows a chain to its final page instead of stopping at a reputable tracker. And keep teaching the habit that CISA's phishing guidance and the NIST definition of phishing both come back to: an unexpected document notice gets verified inside the application, never through the button in the mail.

Indicators of Compromise

MITRE ATT&CK Mapping