T1132: Data Encoding
Adversaries may encode data to make the content of command and control traffic more difficult to detect. Command and control (C2) information can be encoded using a standard data encoding system. Use of data encoding may adhere to existing protocol specifications and includes use of ASCII, Unicode, Base64, MIME, or other binary-to-text and character encoding systems.[1] [2] Some data encoding systems may also result in data compression, such as gzip.
Analyst context for executives and security teams
Data Encoding matters because encoded C2 traffic can make malicious communications look less obvious without needing a novel protocol. For leaders, the practical issue is whether network monitoring and incident response processes can recognize suspicious encoded content in outbound traffic across ESXi, Linux, macOS, and Windows environments, rather than relying only on clear-text indicators.
Executive priority
Prioritize this as a command-and-control visibility and response-readiness question. The key business decision is whether boundary monitoring, network intrusion prevention, and SOC workflows can produce defensible evidence when traffic content is transformed with common encodings such as ASCII, Unicode, Base64, MIME, hexadecimal, or gzip-related compression. This supports resilience, audit evidence, and incident decision-making because encoded C2 may otherwise reduce confidence in containment scope and timeline reconstruction.
Technical view
ATT&CK provides no official detection text for T1132, but the relationship to DET0108 and mitigation M1031 points defenders toward network-focused validation. SOC and detection engineering teams should test whether collected traffic, proxy, IDS/IPS, and packet/flow data can expose suspicious encoded payload patterns, especially in outbound command-and-control contexts. Validate coverage across the stated platforms: ESXi, Linux, macOS, and Windows. Use the sub-technique T1132.001 as context for standard encodings, while avoiding assumptions that every encoded string is malicious.
Likely telemetry
- Network intrusion detection/prevention alerts at network boundaries
- Proxy, firewall, and egress connection logs
- Packet capture or payload inspection where permitted and available
- Network flow metadata to support C2 timing, destination, and volume analysis
- Host-to-network correlation from ESXi, Linux, macOS, and Windows systems
Detection direction
- Confirm whether DET0108-style detection logic is implemented or mapped in local tooling, since the ATT&CK object itself does not provide detection detail.
- Tune for suspicious use of standard encodings in C2-like traffic rather than treating Base64, Unicode, MIME, ASCII, hexadecimal, or compression alone as malicious.
- Correlate encoded content indicators with destination reputation, unusual egress patterns, recurring beacon-like connections, and affected host context to reduce false positives.
- Validate visibility at network boundaries because M1031 specifically references intrusion detection signatures to block traffic there.
- Account for blind spots where encrypted transport, limited payload retention, unmanaged systems, or appliance/server segments reduce inspection depth.
Mitigation priorities
- Start with egress visibility: ensure network boundary IDS/IPS or equivalent monitoring can inspect and alert on suspicious encoded C2 patterns where policy allows.
- Apply network intrusion prevention signatures at boundaries in line with M1031, with testing to avoid blocking legitimate encoded application traffic.
- Improve response playbooks so analysts can preserve traffic samples, decoded artifacts when appropriate, host context, and timeline evidence.
- Prioritize coverage gaps for high-value server, virtualization, and endpoint segments running ESXi, Linux, macOS, or Windows.
- Use threat-intelligence relationships to inform detection hypotheses, but require local telemetry before escalating to incident conclusions.
Analyst notes and limits
T1132 is a parent technique for encoded C2 data and has a standard-encoding sub-technique, T1132.001. Relationships show use by multiple software entries and one group, including examples spanning Windows, Linux, macOS, and identity/cloud-related software context; these mappings are useful for scenario planning but should not be read as proof of current activity in any environment.
The official ATT&CK object does not provide detection text. This take is therefore based on the official description, platforms, command-and-control tactic, external references, and supplied relationships, especially DET0108 and M1031. Local protocol mix, encryption, logging depth, and legal constraints on payload inspection will determine practical coverage.
Data Encoding
Adversaries may encode data to make the content of command and control traffic more difficult to detect. Command and control (C2) information can be encoded using a standard data encoding system. Use of data encoding may adhere to existing protocol specifications and includes use of ASCII, Unicode, Base64, MIME, or other binary-to-text and character encoding systems.[1] [2] Some data encoding systems may also result in data compression, such as gzip.
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 | T1132.001 | Standard Encoding Sub-technique | Standard Encoding subtechnique of this object. |
| Enterprise | T1132.002 | Non-Standard Encoding Sub-technique | Non-Standard Encoding subtechnique of this object. |
Groups, software, and campaigns
G1047: Velvet Ant
Velvet Ant is a threat actor operating since at least 2021. Velvet Ant is associated with complex persistence mechanisms, the targeting of network devices and appliances during operations, and the use of zero day exploits.[1][2]
S9035: LAMEHUG
LAMEHUG is Python-based information stealer first identified in July 2025 by Ukraine's Computer Emergency Response Team (CERT-UA) in phishing emails targeting Ukrainian government officials. LAMEHUG is the first known malware to integrate artificial intelligence (AI) directly into its attack workflow by querying large language models (LLMs) hosted on Hugging Face to dynamically generate reconnaissance, data theft, and system manipulation commands in real time. LAMEHUG has been attributed to APT28. [1][2][3]
S0128: BADNEWS
S0699: Mythic
S0386: Ursnif
Ursnif is a banking trojan and variant of the Gozi malware observed being spread through various automated exploit kits, Spearphishing Attachments, and malicious links.[1][2] Ursnif is associated primarily with data theft, but variants also include components (backdoors, spyware, file injectors, etc.) capable of a wide variety of behaviors.[3]
S9003: evilginx2
S0362: Linux Rabbit
Linux Rabbit is malware that targeted Linux servers and IoT devices in a campaign lasting from August to October 2018. It shares code with another strain of malware known as Rabbot. The goal of the campaign was to install cryptocurrency miners onto the targeted servers and devices.[1]
S0132: H1N1
All related ATT&CK context
Mitigation direction
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.3 | Current bundle | 16c8bfb3a394… |
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]
Wikipedia Binary-to-text Encoding
Wikipedia. (2016, December 26). Binary-to-text encoding. Retrieved March 1, 2017.
Open source URL -
[2]
Wikipedia Character Encoding
Wikipedia. (2017, February 19). Character Encoding. Retrieved March 1, 2017.
Open source URL -
[3]
University of Birmingham C2
Gardiner, J., Cova, M., Nagaraja, S. (2014, February). Command & Control Understanding, Denying and Detecting. Retrieved April 20, 2016.
Open source URL -
[4]
mitre-attack T1132Open 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.