AN1461: Analytic 1461
Execution of files containing right-to-left override characters (U+202E) to masquerade true file extensions. Often found in phishing payloads or file downloads.
Analyst context for executives and security teams
This analytic matters because right-to-left override characters can make a file name appear to have a safer extension than it really does, creating a practical phishing and download risk for Windows users. For leaders, the decision point is whether the organization can see and investigate suspicious file executions where the displayed name may mislead users, help desks, or responders.
Executive priority
Prioritize this as a user-facing execution and incident triage concern: it can affect phishing resilience, SOC visibility, and evidence quality during investigations. Executives should ask whether Windows endpoint telemetry preserves the true filename, path, and Unicode characters, and whether response teams can quickly determine the actual executable type when a downloaded or emailed file is involved.
Technical view
Validate Windows coverage for execution of files whose names contain the Unicode right-to-left override character U+202E. Because ATT&CK provides no official detection logic and no relationship context for this analytic, teams should focus on confirming data availability first: process creation events, file creation/download evidence, original command line, full image path, and any normalized versus raw filename handling. Detection engineering should test whether existing pipelines retain U+202E rather than stripping, normalizing, or rendering it invisibly.
Likely telemetry
- Windows process creation telemetry with full image path and command line
- File creation or modification events for downloaded or user-accessible files
- Endpoint security alerts or file reputation events that include raw filenames
- Email or web download metadata where available for phishing or file-download investigations
- Case management or SIEM records that preserve Unicode characters in filenames
Detection direction
- Search for process execution where filename or path contains U+202E.
- Validate that SIEM, EDR, log forwarders, and analyst consoles preserve and display Unicode control characters accurately.
- Tune for context: user download directories, email attachment locations, temporary folders, and recently created files can raise investigative priority, while legitimate Unicode-heavy environments may require allowlisting or review workflows.
- Compare displayed extension, actual file type, and executed image metadata during triage to avoid being misled by filename rendering.
- Because no official ATT&CK detection is supplied, treat any rule as locally validated detection logic rather than MITRE-provided coverage.
Mitigation priorities
- Ensure Windows endpoint logging and EDR policies capture process execution and full file paths.
- Harden email and web download handling for suspicious attachments and files with deceptive names where existing controls support that policy.
- Train SOC and help desk responders to inspect raw filenames and actual file types, not only rendered names.
- Review user awareness and phishing reporting workflows for deceptive filenames.
- Use incident response playbooks to preserve the original file, path, and download or delivery context when this pattern is observed.
Analyst notes and limits
This is a detection analytic object, not a technique object, and the supplied ATT&CK fields do not specify tactics, relationships, mitigations, or official detection logic. The most defensible use is as a validation prompt for Windows telemetry and Unicode-safe investigation workflows.
Assessment is limited to the supplied STIX fields and external reference. No claims can be made about active exploitation, actor attribution, prevalence, business impact, or guaranteed detection coverage without local telemetry and additional intelligence.
Analytic 1461
Execution of files containing right-to-left override characters (U+202E) to masquerade true file extensions. Often found in phishing payloads or file downloads.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | ed60a979be08… |
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 AN1461Open 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.