T1132.001: Standard Encoding
Adversaries may encode data with a standard data encoding system 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 that adheres to existing protocol specifications. Common data encoding schemes include ASCII, Unicode, hexadecimal, Base64, and MIME.CitationWikipedia Binary-to-text EncodingCitationWikipedia Character Encoding Some data encoding systems may also result in data compression, such as gzip.
Security context for executives and security teams
Standard Encoding matters because normal-looking encodings such as Base64, hex, ASCII, Unicode, MIME, or gzip can be used to make command-and-control content harder to inspect without violating protocol expectations. For leaders, the practical issue is not that encoding is malicious by itself; it is that common business traffic can hide C2 signals unless network inspection, SOC triage, and incident response workflows can correlate encoded content with suspicious behavior.
Executive priority
Treat this as a coverage-validation topic for command-and-control resilience. Ask whether network boundary controls, SOC detections, and IR playbooks can recognize suspicious encoded C2 patterns across Windows, Linux, macOS, and ESXi environments without relying on encoding alone as proof of compromise. The attached mitigation relationship points to network intrusion prevention, so priority should be on proving that boundary IDS/IPS controls are deployed, tuned, and producing usable evidence for investigations and compliance reporting.
Technical view
ATT&CK provides no native detection text for T1132.001, but relationship context identifies DET0124 as a behavior-chain detection strategy for Standard Encoding across Windows, Linux, macOS, and ESXi. SOC teams should validate detections that combine encoded payload indicators with C2 context, such as unusual outbound sessions, repeated encoded-looking parameters or bodies, MIME/Base64/hex-heavy content, and corroborating endpoint or network events. Because standard encodings are legitimate, detection should be correlation-driven rather than simple string matching.
Likely telemetry
- Network IDS/IPS alerts and signatures at network boundaries
- Proxy, firewall, and egress connection logs
- HTTP or other protocol metadata where C2 traffic may carry encoded parameters, headers, or bodies
- Packet capture or retained payload samples where legally and operationally permitted
- Endpoint process, command-line, and network-connection context for Windows, Linux, macOS, and ESXi where available
Detection direction
- Validate DET0124-style behavior-chain analytics rather than standalone Base64, hex, MIME, gzip, ASCII, or Unicode matches.
- Tune for false positives from legitimate applications, APIs, file transfers, email/MIME handling, compression, and administrative tooling.
- Correlate encoded content patterns with destination reputation, egress anomalies, beacon-like behavior, unusual user or host context, and related malware or campaign intelligence where available.
- Confirm visibility across the listed platforms, especially ESXi and non-Windows systems that may have weaker endpoint telemetry.
- Test whether IDS/IPS and SOC workflows preserve enough payload or metadata to explain why an encoded session was escalated.
Mitigation priorities
- Prioritize network intrusion prevention at network boundaries, consistent with ATT&CK mitigation M1031.
- Ensure IDS/IPS signatures and inspection policies can flag suspicious encoded C2 traffic without broadly blocking legitimate encoded business traffic.
- Use egress control and monitoring to limit and review outbound communications from sensitive systems.
- Maintain investigation playbooks for decoding or safely handling captured encoded artifacts during incident response.
- Document detection logic, tuning decisions, and control evidence for audit and compliance readiness.
Additional notes and limits
This technique is a sub-technique of Data Encoding under the command-and-control tactic. Relationship context shows use by multiple ATT&CK groups, software entries, and the Juicy Mix campaign, which supports treating it as a broadly relevant C2 tradecraft pattern. Those relationships should inform threat-informed detection testing, but they do not prove activity in any specific environment.
Official ATT&CK detection guidance is not provided for this object. The object describes standard encoding categories but does not provide protocol-specific indicators, signatures, or guaranteed detection methods. Local traffic baselines, inspection capability, privacy constraints, and platform telemetry determine practical coverage.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Standard Encoding
Adversaries may encode data with a standard data encoding system 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 that adheres to existing protocol specifications. Common data encoding schemes include ASCII, Unicode, hexadecimal, Base64, and MIME.CitationWikipedia Binary-to-text EncodingCitationWikipedia Character Encoding 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.
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.
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.
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.