DET0527: Right-to-Left Override Masquerading Detection via Filename and Execution Context
This detection strategy matters because right-to-left override masquerading is a simple way to make a suspicious filename look harmless to users and analys...
Analyst context for executives and security teams
This detection strategy matters because right-to-left override masquerading is a simple way to make a suspicious filename look harmless to users and analysts. The related ATT&CK technique describes adversaries abusing the Unicode U+202E character so a file’s displayed name appears reversed, such as making an executable or script look like a document or image. For leaders, the key issue is not the character itself; it is whether email, endpoint, file, and SOC workflows preserve the real filename and execution context well enough for defenders to notice deception before or during execution.
Executive priority
Treat this as a control-validation item for user-facing file risk, SOC visibility, and incident response readiness across Windows, macOS, and Linux environments where such files may appear. Executives should ask whether security tools, ticket evidence, audit logs, and analyst views show both the raw filename and the rendered/displayed filename. This is especially relevant to budget and compliance discussions around endpoint telemetry quality, malware triage, and evidence integrity: if filenames are normalized or displayed inconsistently, responders may miss or misclassify suspicious activity.
Technical view
DET0527 is a MITRE detection strategy for detecting T1036.002 Right-to-Left Override using filename and execution context. Because the official detection text is not supplied, teams should validate the concept conservatively: identify files or process executions where filenames contain the Unicode right-to-left override character U+202E, then enrich with execution context such as process creation, command line, parent process, file path, file type/extension mismatch, and user interaction. The related technique is categorized under stealth and applies to Linux, macOS, and Windows, so coverage should be checked wherever endpoint or file telemetry is collected on those platforms.
Likely telemetry
- Raw filenames and file paths preserving Unicode characters, including U+202E
- Endpoint file creation, modification, download, and quarantine events
- Process execution telemetry with command line, image path, parent process, user, and timestamp
- Email attachment, web download, and file transfer metadata where available
- File type or MIME/extension inspection results that can expose extension or content mismatches
Detection direction
- Validate that collection pipelines preserve the raw Unicode filename rather than only the visually rendered name.
- Search for filenames containing U+202E and correlate them with execution events, especially when the apparent extension differs from the actual extension or file type.
- Tune triage to consider execution context; not every Unicode filename is malicious, but RTLO combined with script or executable launch, unusual parent process, or user-download paths should receive higher priority.
- Check analyst tooling and SIEM displays for blind spots where the filename appears benign due to rendering behavior.
- Use the relationship to T1036.002 to align detections with masquerading and stealth review workflows rather than treating this only as a string-matching problem.
Mitigation priorities
- Prioritize visibility first: ensure endpoint, email, and file telemetry retain raw filenames and execution context.
- Harden user-facing file handling by reviewing controls that inspect attachments, downloads, and executable/script launches regardless of displayed filename.
- Improve SOC procedures so analysts compare displayed names, raw names, actual extensions, and file content/type indicators during triage.
- Include RTLO filename examples in detection validation and incident response exercises for Windows, macOS, and Linux where those platforms are in scope.
- Document evidence handling expectations for audits and investigations so filename rendering does not obscure what actually executed.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description or detection text provided. The strongest usable context is its relationship to T1036.002 Right-to-Left Override, including the behavior description, stealth tactic, and Linux/macOS/Windows platform scope. Detection engineering should therefore treat this as a validation pattern: Unicode filename anomaly plus execution context, not a standalone guarantee of maliciousness.
This take is limited to the supplied STIX fields, external reference, and relationship context. It does not assert active exploitation, actor use, impact, or existing detection coverage. Local telemetry quality, filename rendering behavior, endpoint platforms, and control configuration must be verified in the environment.
Right-to-Left Override Masquerading Detection via Filename and Execution Context
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1036.002 | Right-to-Left Override Sub-technique | This object detects Right-to-Left Override. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | aeeaa55ebe5d… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0527Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.