Has obfuscated HTTP Post request communications utilizing XOR with a designated key, followed by Base64 encoding.1
- Tactic
- Command and Control
- Platforms
- ESXi, Linux, macOS, Windows
- Version
- 1.1
- Created
- 14 March 2020
- Last modified
- 12 May 2026
Adversaries may encode data with a non-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 non-standard data encoding system that diverges from existing protocol specifications. Non-standard data encoding schemes may be based on or related to standard data encoding schemes, such as a modified Base64 encoding for the message body of an HTTP request.[1][2]
Non-Standard Encoding MITRE reference T1132.002
1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
All 1 groups for this technique
17 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Has obfuscated HTTP POST request communications utilizing XOR with a designated key of 0x56, followed by Base64 encoding.1
Has encoded a payload with a random 32-byte key using XOR.1 TONESHELL has also encoded payloads with a 256-byte key using XOR.2
Can use modified Base64 encoding to obfuscate communications.1
Can use a custom Base64 alphabet for encoding C2.1
Can encode C2 communications with a base64 algorithm using a custom alphabet.1
Has used a non-standard encoding in DNS tunneling removing any = from the result of base64 encoding, and replacing / characters with -s and + characters with -p.1
All 17 software entries for this technique · 6 newest in this preview
Offense vs defense T1132.002
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
Non-Standard Encoding detection strategy DET0326
MITRE names one behaviour worth catching for this technique and breaks it into 4 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Behavior-chain detection for T1132.002 Data Encoding: Non-Standard Encoding across Windows, Linux, macOS, ESXi
AN0927 · Windows
A process/script constructs or references a custom/alphabet translation table (e.g., 64/85/32+ arbitrary chars, XOR/base-N loops) or emits long high-entropy strings that do NOT validate as standard Base64/Hex → shortly after, the same process (or its child) generates outbound traffic with asymmetric bytes_out:bytes_in, fixed-size beacons, or protocol/header mismatches (e.g., Content-Type says JSON but body fails JSON parse / contains non-standard alphabet).
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Script ExecutionDC0029 | WinEventLog:PowerShell | EventCode=4103, 4104, 4105, 4106 |
| Process CreationDC0032 | WinEventLog:Security | EventCode=4688 |
| Network Traffic FlowDC0078 | m365:defender | NetworkConnection: high out:in ratio, periodic beacons, protocol mismatch |
| Network Connection CreationDC0082 | WinEventLog:Sysmon | EventCode=3, 22 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| EntropyThreshold | Minimum Shannon entropy for the suspected token/payload (e.g., >4.8). |
| TokenLengthThreshold | Minimum continuous token length to treat as potential non-standard payload (e.g., ≥120 chars). |
| BytesOutToInRatio | Out:In ratio considered suspicious (e.g., ≥4:1). |
| FixedPacketStdDevThreshold | Std. dev. threshold (size or interval) to mark packets as 'uniform' (beacon-like). |
| TimeWindow | Correlation window from encode routine to egress (default 10m). |
| KnownLegitEncoders | Legitimate in-house/custom encoders to suppress. |
AN0928 · Linux
Shell scripts or binaries implement custom mapping tables (tr/sed/awk/golang/rust/python encode loops), or emit long high-entropy tokens that fail Base64/Hex validation → correlated with egress showing asymmetric flow, protocol-mismatch payloads, or DNS/HTTP bodies containing low-diversity-but-long custom alphabets.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | auditd:SYSCALL | execve of interpreters (python, perl), custom binaries, or shell utilities with long arguments containing non-standard tokens |
| Network Connection CreationDC0082 | WinEventLog:Sysmon | EventCode=3, 22 |
| Network Traffic ContentDC0085 | NSM:Flow | http: HTTP bodies/headers contain long tokens with non-standard alphabets or constant-size periodic POSTs |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| EntropyThreshold | Payload entropy minimum. |
| TokenLengthThreshold | Length threshold for suspect tokens. |
| BytesOutToInRatio | Asymmetry cutoff for flows. |
| TimeWindow | Correlation join window. |
| KnownEncoders | Legitimate internal tools/agents. |
AN0929 · macOS
EndpointSecurity/Unified Logs show processes generating custom alphabets or long high-entropy, non-standard tokens → network logs (PF/Zeek/EDR) show asymmetric beacons, protocol mismatches, or periodic fixed-size posts.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | macos:endpointsecurity | ES_EVENT_TYPE_NOTIFY_EXEC: arguments contain long, non-standard tokens / custom alphabets |
| Network Traffic FlowDC0078 | PF:Logs | high out:in ratio or fixed-size periodic flows |
| Network Traffic ContentDC0085 | NSM:Flow | http: suspicious long tokens with custom alphabets in body/headers |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| EntropyThreshold | Payload entropy minimum. |
| TokenLengthThreshold | Minimum suspicious token length. |
| BytesOutToInRatio | Asymmetry threshold. |
| TimeWindow | Correlation window. |
| AllowedSignedBinaries | Signed binaries that legitimately implement custom encoders. |
AN0930 · ESXi
ESXi shell or scripts produce long, high-entropy tokens (non-standard alphabets) in shell.log/hostd, followed by outbound flows (NSX/Zeek) with asymmetric ratios or protocol mismatches to non-management endpoints.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | esxi:shell | commands containing long non-standard tokens or custom lookup tables |
| Application Log ContentDC0038 | esxi:hostd | unexpected script invocations producing long encoded strings |
| Network Traffic FlowDC0078 | NSM:Flow | network_flow: bytes_out >> bytes_in, fixed packet sizes/intervals to non-approved CIDRs |
| Network Traffic ContentDC0085 | NSM:Flow | http: HTTP bodies from ESXi host IPs containing long, non-standard tokens |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| MgmtCIDRs | CIDRs allowed for normal ESXi mgmt/backup. |
| BytesOutToInRatio | Asymmetry cutoff (e.g., ≥3). |
| TokenLengthThreshold | Minimum token length. |
| TimeWindow | Correlation window. |
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools.