T1027.018: Invisible Unicode
Adversaries may abuse invisible or non-printing Unicode characters to conceal malicious content within files, scripts, or text. By inserting characters that do not visibly render, adversaries may hide data, alter how content is interpreted, or make malicious code appear as benign text or whitespace. Adversaries may encode these malicious payloads, using binary, Base64, or custom schemes, to be reconstructed at runtime through scripting features such as JavaScript Proxy traps, `eval()`, or other dynamic execution methods. This technique enables adversaries to evade visual inspection and basic static analysis by hiding malicious encoded content in innocuous text.[1][2][3]
Unicode is a standardized character encoding model that assigns a unique numerical value, known as a code point, to every character across writing systems, enabling consistent text representation across platforms, applications, and languages. Code points are represented as `U+` followed by a hexadecimal value and may be encoded using formats such as `UTF-8` or `UTF-16`. Adversaries may abuse the valid code points in Unicode that are not visibly rendered but still take up bytes, such as zero-width spaces, variation selectors, or bidirectional formatting controls, to conceal malicious payloads.[2][4][5]
Adversaries may additionally exploit Private Use Area (PUA) characters, a range of code points reserved for custom assignment. PUA characters that are not defined by a font or application are typically rendered blank.[1]
Unicode characters may also be leveraged in support of other techniques such as Phishing, Right-to-Left Override, or User Execution. For example, some adversaries may embed artificial intelligence (AI) prompt injections using invisible Unicode characters in emails or documents that appear benign when processed by AI systems.[6][7]
Analyst context for executives and security teams
Invisible Unicode matters because malicious content can be present even when a file, script, email, document, repository entry, or prompt looks harmless to a human reviewer. The business risk is not the Unicode standard itself; it is the gap between what people and basic static tools see and what parsers, interpreters, or AI systems may process at runtime.
Executive priority
Treat this as a stealth and assurance problem for environments that rely on code review, email/document inspection, repository scanning, scripting controls, or AI-assisted workflows. Leaders should ask whether security tooling preserves and analyzes raw text bytes, whether review processes can expose hidden characters, and whether incident responders can prove what content was actually executed or processed across Windows, macOS, and Linux systems.
Technical view
ATT&CK identifies this as sub-technique T1027.018 under Obfuscated Files or Information, applicable to Linux, macOS, and Windows, with a stealth tactic. SOC and detection teams should validate coverage for invisible or non-printing Unicode characters in files, scripts, and text, including zero-width characters, variation selectors, bidirectional formatting controls, and Private Use Area characters. Analysis should compare rendered text with raw byte/Unicode code point views and correlate suspicious hidden content with encoded payload reconstruction or dynamic execution patterns such as JavaScript Proxy traps, eval(), or other scripting behavior. The related DET0920 detection strategy indicates a detection relationship exists, but the supplied ATT&CK object does not include the detection logic itself.
Likely telemetry
- Raw file and script contents with byte-preserving collection, not only rendered previews
- Source control and repository diffs that expose Unicode code points or non-printing characters
- Email, calendar invite, document, and text extraction telemetry where hidden characters may be embedded
- Endpoint process, command-line, and script execution logs on Windows, macOS, and Linux
- Web, proxy, or content inspection logs that retain original text encodings where available
Detection direction
- Validate whether existing content inspection normalizes away invisible characters before analysis; normalization can remove the evidence needed for detection.
- Add or tune rules to flag unusual concentrations or suspicious placement of zero-width characters, variation selectors, bidirectional controls, and Private Use Area code points in scripts, repositories, emails, documents, and prompts.
- Correlate hidden Unicode findings with other obfuscation indicators such as Base64, binary/custom encoding, runtime reconstruction, eval-like behavior, or scripting execution.
- Create analyst views that display raw code points beside rendered text so triage is not dependent on visual inspection alone.
- Tune carefully for legitimate uses, including multilingual text handling, formatting controls, emoji variation selectors, and application-specific Private Use Area fonts.
Mitigation priorities
- Prioritize byte-preserving logging and inspection so responders can reconstruct what text or code was actually present.
- Expose non-printing Unicode in secure code review, repository scanning, CI/SAST workflows, and document/email inspection where applicable.
- Apply input validation or sanitization at appropriate trust boundaries for scripts, repositories, documents, prompts, and other text-processing workflows, while accounting for legitimate Unicode business needs.
- Restrict or review risky dynamic execution patterns in scripts where feasible, especially when paired with encoded or reconstructed content.
- Train SOC, IR, and engineering reviewers not to rely solely on rendered text when investigating suspicious files, scripts, repository changes, emails, documents, or AI prompts.
Analyst notes and limits
The supplied ATT&CK object is especially relevant to managed detection, incident response, secure engineering, cloud/software supply-chain review, and AI security governance because it highlights a mismatch between visual review and machine interpretation. The relationship to T1027 reinforces that this should be handled as an obfuscation pattern, not as a standalone malware family. The relationship to GlassWorm supports supply-chain relevance, but does not justify attribution or environment-specific exposure claims by itself.
The official ATT&CK detection field is not provided, and the related DET0920 strategy is named but not detailed in the supplied data. This take therefore provides validation direction rather than guaranteed detections. Local baselines are required to separate malicious or suspicious hidden Unicode from legitimate Unicode usage in languages, documents, fonts, applications, and development workflows.
Invisible Unicode
Adversaries may abuse invisible or non-printing Unicode characters to conceal malicious content within files, scripts, or text. By inserting characters that do not visibly render, adversaries may hide data, alter how content is interpreted, or make malicious code appear as benign text or whitespace. Adversaries may encode these malicious payloads, using binary, Base64, or custom schemes, to be reconstructed at runtime through scripting features such as JavaScript Proxy traps, `eval()`, or other dynamic execution methods. This technique enables adversaries to evade visual inspection and basic static analysis by hiding malicious encoded content in innocuous text.[1][2][3]
Unicode is a standardized character encoding model that assigns a unique numerical value, known as a code point, to every character across writing systems, enabling consistent text representation across platforms, applications, and languages. Code points are represented as `U+` followed by a hexadecimal value and may be encoded using formats such as `UTF-8` or `UTF-16`. Adversaries may abuse the valid code points in Unicode that are not visibly rendered but still take up bytes, such as zero-width spaces, variation selectors, or bidirectional formatting controls, to conceal malicious payloads.[2][4][5]
Adversaries may additionally exploit Private Use Area (PUA) characters, a range of code points reserved for custom assignment. PUA characters that are not defined by a font or application are typically rendered blank.[1]
Unicode characters may also be leveraged in support of other techniques such as Phishing, Right-to-Left Override, or User Execution. For example, some adversaries may embed artificial intelligence (AI) prompt injections using invisible Unicode characters in emails or documents that appear benign when processed by AI systems.[6][7]
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.
Related techniques
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 | T1027 | Obfuscated Files or Information | This object subtechnique of Obfuscated Files or Information. |
Groups, software, and campaigns
S9010: GlassWorm
GlassWorm is a worm that propagated through supply chain attacks by compromising repository credentials from victim environments and having malicious payloads added to those compromised accounts for distribution to victims across the various development ecosystems.[1][2][3] GlassWorm has numerous variants, including Rust binaries, encrypted JavaScript and a variant leveraging invisible Unicode characters that made reverse engineering difficult.[4][1][5] GlassWorm has employed a unique command and control (C2) methodology using Solana blockchain.[6][1] GlassWorm was first reported in October 2025.[6][1][3]
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 | 8af55aa32ff1… |
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]
PUAs Unicode - Eriksen
Charlie Eriksen. (2025, May 13). You're Invited: Delivering malware via Google Calendar invites and PUAs. Retrieved April 21, 2026.
Open source URL -
[2]
Tycoon2FA - Unicode
Rodel Mendrez. (2025, April 10). Tycoon2FA New Evasion Technique for 2025. Retrieved April 21, 2026.
Open source URL -
[3]
Unicode - Veracode
Veracode Threat Research. (2025, June 9). Down the Rabbit Hole of Unicode Obfuscation. Retrieved April 21, 2026.
Open source URL -
[4]
GlassWorm - Unicode
Idan Dardikman. (2025, October 18). GlassWorm: First Self-Propagating Worm Using Invisible Code Hits OpenVSX Marketplace. Retrieved April 21, 2026.
Open source URL -
[5]
Unicode and Hidden Prompts - Perets
Shaked Perets. (2025, December 7). Invisible Code & Hidden Prompts – How Attackers Weaponize Unicode in Repos (and How SAST Can Help). Retrieved April 21, 2026.
Open source URL -
[6]
LLMs and Unicode - Medium
Idan Habler. (2025, September 12). Hiding in Plain Sight: Weaponizing Invisible Unicode to Attack LLMs. Retrieved April 21, 2026.
Open source URL -
[7]
Invisible Prompt Injection - Trend Micro
Ian Ch Lui. (2025, January 22). Invisible Prompt Injection: A Threat to AI Security. Retrieved April 21, 2026.
Open source URL -
[8]
mitre-attack T1027.018Open 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.