How do attackers use right-to-left override?

How right-to-left override changes what people see

Right-to-left override is a display trick, not a file-format trick. It changes the order in which text is rendered, so the visible filename or message can read differently from the underlying characters. Attackers use that mismatch to make a risky file look like a harmless document, image, or archive at a quick glance.

The abuse works best when the viewer relies on the screen preview instead of inspecting the raw filename. That is why the technique shows up in phishing attachments, spoofed downloads, and malware delivery chains. The danger is not the control character itself, but the trust gap it creates between what the user sees and what the system will actually open.

In practice, the trick is most effective where extensions are hidden, file type icons are overtrusted, or the email client or chat app truncates long names. The same visual deception can also be used inside message bodies and archive listings, so defenders need to treat it as a content-sanitisation problem as well as a filename problem.

Why attackers like it in phishing and malware delivery

Attackers use right-to-left override because it is low effort and high payoff. A filename can be arranged so the dangerous part appears near the end of the displayed text, where a user expects to see a safe extension or a benign label. That makes the bait easier to click and harder to spot during a hurried review.

This technique is especially useful when combined with social engineering. A convincing subject line, a familiar sender name, and a misleading filename can reinforce each other, reducing the chance that a user will scrutinise the attachment. It is a presentation-layer deception, but the consequence is still execution of the wrong file.

It also helps attackers blend in with ordinary business traffic. A name that appears to end in a document extension can pass a casual human inspection even when the true file type is executable, script, or double-extension bait. That is why the method remains attractive even though it is simple and well understood.

How defenders should handle bidi control characters

Defensive controls should make the underlying filename visible, not just the rendered one. The most important checks are to normalise filenames, display full extensions, and flag or block bidirectional control characters in attachments, archives, and message content. If the user cannot see the real structure of the name, the attacker has already won part of the interaction.

Validation should happen at more than one layer. Mail gateways, file upload handlers, chat platforms, and endpoint controls should all detect suspicious Unicode directionality markers, because the same payload can move across several systems before a person opens it. Handling it only at the endpoint is too late if the deception has already influenced user trust.

When a platform must preserve rich text or internationalised names, the safer pattern is to render the name in a way that exposes unusual formatting rather than silently accepting it. That means using explicit warnings, showing the raw filename on hover or detail view, and blocking execution-oriented file types wherever policy allows.

Risk and Threat Considerations

Right-to-left override is a user-interface deception with a direct security impact: it increases the chance that a malicious attachment, download, or link target is mistaken for something benign. The control is small, but the consequence can be full compromise if the disguised file is opened and executed.

Failure mechanism: The attacker inserts bidirectional control characters so the displayed order of the filename no longer matches the underlying bytes, then relies on hidden extensions, truncation, or user haste to conceal the true file type.

Impact: Users can launch malware, expose credentials, or approve a malicious action because the visible label looked safe, which makes this a practical phishing and delivery risk rather than a cosmetic anomaly.

Practitioner Guidance

What to verify: Test whether your mail, upload, and endpoint tooling shows the raw filename somewhere a user can inspect before opening the item. If the only visible view is the rendered string, the control is weak.

Common mistake: Blocking only one suspicious extension is not enough. Attackers can pair directionality overrides with double extensions, archive nesting, or misleading suffixes, so the detection logic needs to look for the character class, not just one filename pattern.

What good looks like: Users see the full extension, suspicious Unicode formatting is highlighted or rejected, and security teams can trace the exact filename that reached the inbox or upload endpoint.

Practitioner takeaway: Treat right-to-left override as a deception control issue: the best defence is to remove ambiguity from the filename before the user has a chance to trust it.

Related resources from NHI Mgmt Group

• Guide: Malware Guide
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?