MITRE ATT&CK T1132 Data Encoding: Finding Encoded C2 Traffic Across Hosts and Networks

Almost every implant encodes what it sends home, so Base64 in a cookie or a hex string in a URL is not proof of compromise, but encoding produced by the wrong process and sent to the wrong place usually is. MITRE ATT&CK v20 tracks this as T1132 Data Encoding, a Command and Control technique on Windows, Linux, macOS and ESXi: adversaries encode C2 data with standard schemes such as ASCII, Unicode, Base64, MIME or hexadecimal (T1132.001) or with modified or custom schemes (T1132.002), and some encodings, such as gzip, also compress. This guide covers the two sub-techniques, the procedure examples ATT&CK records, the v20 detection strategies and their data sources, the single mitigation ATT&CK lists, and how to test and measure detection. It is written for detection engineers, SOC analysts and network security teams, and stays defensive. For C2 as a whole see the Command and Control (C2) Guide; for encoding as an application security control (the opposite use of the same word) see the Input Validation and Output Encoding Guide.

Key takeaways

• Encoding is near universal in C2. ATT&CK v20 lists well over a hundred groups, campaigns and software families under T1132.001, from Cobalt Strike and Sliver to SUNBURST and BRICKSTORM.
• Do not alert on Base64 alone. Legitimate web, mail and API traffic is full of it; the v20 detection strategies pair an encoder or encoded payload with the process that sent it and where it went.
• Non-standard encoding is a gift to defenders. A custom alphabet that fails Base64 or hex validation, inside a protocol field that should hold JSON or a session ID, is rarer and higher fidelity than standard Base64.
• Network signatures are the listed mitigation. M1031 Network Intrusion Prevention works because a family's encoding is often stable and unique enough to write a signature for.
• Appliances and hypervisors are blind spots. ATT&CK records Velvet Ant sending encoded commands to compromised F5 BIG-IP devices, and v20 adds ESXi analytics, where EDR rarely runs.

What T1132 covers and what it does not

Encoding changes representation; it does not protect secrecy, and anyone who knows the scheme can reverse it. That separates T1132 from its neighbours in ATT&CK v20:

Malware frequently stacks these. ATT&CK records ADVSTORESHELL encrypting C2 traffic and then Base64 encoding it, BADNEWS converting encrypted data to hexadecimal and then Base64, and Troll Stealer applying XOR before Base64. The encoding layer exists so binary ciphertext survives text protocols such as HTTP headers, URLs and DNS labels.

How adversaries use it: procedure examples from ATT&CK v20

Standard encoding (T1132.001)

• In HTTP bodies and headers: APT38 used Base64 encoded HTTP POST communications to C2; Helminth placed Base64 data in the HTTP Cookie field; Elise exfiltrated data in Base64 encoded cookie values; Carbanak encoded HTTP message bodies with Base64.
• In URLs: Stuxnet transformed encrypted binary data into an ASCII string to use as a URL parameter value; Zebrocy used URL (percent) encoding on data exfiltrated over HTTP POST.
• In DNS: RDAT communicated through Base32 encoded subdomains; RogueRobin Base64 encoded strings sent over its DNS tunnel; Kessel exfiltrated data in hexadecimal encoded subdomain fields. These overlap with T1071.004 DNS; see the DNS Logging and Detection Guide.
• Frameworks: Cobalt Strike can use Base64, URL-safe Base64 or NetBIOS encoding; Sliver can use gzip and hex to ASCII; Mythic provides transform functions to encode or randomise C2 data. See the Cobalt Strike Abuse Detection Guide, the Sliver, Havoc and Brute Ratel C2 Frameworks Detection Guide and Detecting Mythic C2.
• Edge and network devices: ATT&CK records Salt Typhoon using double encoding with hexadecimals to obscure requested command paths (citing CISA advisory AA25-239A), and BRICKSTORM, SLIGHTPULSE and WIREFIRE, implants found on appliances, Base64 encoding C2 content.
• Supply chain: SUNBURST used Base64 encoding in its C2 traffic, which travelled inside the trusted Orion update path described in the SolarWinds supply chain compromise breach analysis.

Non-standard encoding (T1132.002)

• Custom alphabets: CHIMNEYSWEEP and Ninja use Base64 with a custom alphabet; Uroburos uses a custom Base62 and a Base32 variant built from digits and lowercase letters.
• Substitution: NightClub removes = padding from Base64 and replaces / with -s and + with -p in DNS tunnelling; RDAT uses Base64 with character substitutions in subdomains.
• XOR then encode: ATT&CK records Kimsuky obfuscating HTTP POST communications with XOR using a designated key followed by Base64, and HTTPTroy doing the same with key 0x56.
• Simple transforms: OceanSalt applies a NOT operation; Small Sieve uses hex byte swapping; ShadowPad encodes data as readable Latin characters.

The appliance case: Velvet Ant

Sygnia's investigation of Velvet Ant, a China-nexus group by Sygnia's attribution, describes legacy F5 BIG-IP load balancers left exposed outside the main corporate firewall. They opened a reverse SSH tunnel to the attacker's server, and commands arrived encoded with a passphrase before the implant ran them through a Unix shell. ATT&CK records this under T1132 and the SSH tunnel under T1573.002. The group stayed for about three years, and Sygnia's recommendations start with restricting outbound traffic from servers and edge devices and monitoring network appliance operating system logs, which it notes are often overlooked.

Encoded queries to AI services

ATT&CK v20 records LAMEHUG encoding queries it sent to large language models. As malware starts using hosted AI APIs as a component, encoded content in prompts to model endpoints becomes another place encoding hides. See the ATLAS Command and Control Tactic.

What to detect and where: the v20 detection strategies

ATT&CK v20 ships three detection strategies: DET0108 for T1132, DET0124 for T1132.001 and DET0326 for T1132.002. All three are behaviour chains rather than string matches: an encoding action, then egress from the same process within a short window, with traffic shape or content that supports the story.

DET0326 adds the signals that make non-standard encoding detectable: a process building a translation table or emitting long high-entropy strings that do not validate as standard Base64 or hex, followed by fixed-size periodic posts, or a protocol mismatch such as a Content-Type of JSON with a body that fails to parse as JSON.

Turning the strategies into analytics

1. Validate, do not just match: on HTTP fields that normally hold known formats (session cookies, JSON bodies, form fields), test whether long tokens decode as standard Base64 or hex. A long token that fails validation but has a small, consistent character set fits DET0326.
2. Measure length and entropy per field: baseline normal lengths for cookies, URI parameters and DNS labels per destination; flag outliers rather than every encoded value.
3. Join process and network: use Sysmon 1 with 3 and 22, or EDR process network events, so an encoded POST from powershell.exe or regsvr32.exe scores higher than the same POST from a browser.
4. Add direction and timing: combine with beacon scoring and the bytes-out ratio. See the Beaconing and C2 Detection Guide.
5. Cover DNS labels: long Base32 or hex subdomains under one parent domain from a non-browser process are a classic combination with T1071.004.
6. Read the appliance logs: forward ESXi shell, hostd and auth logs and network device operating system logs. See the ESXi Logs Detection Guide.

Where encoded content travels over TLS, network sensors see none of it without inspection. Host telemetry (script block logging, EDR) or selective inspection under M1020 restores visibility; see the TLS Inspection Guide. Sensor options are covered in the Zeek Network Monitoring Guide and the Suricata IDS Guide.

Mitigations

ATT&CK v20 lists one mitigation for T1132 and both sub-techniques: M1031 Network Intrusion Prevention, noting that network signatures for specific malware are often based on unique indicators within protocols, and that signatures change across families and versions. Encoding cannot be prevented as such; the aim is to make encoded C2 hard to deliver and easy to see. The practical controls below are NHI Mgmt Group recommendations.

• Signatures for known families: keep IDS and IPS rule sets current for the C2 profiles you see in intelligence, and write local rules for custom alphabets found during incidents. See M1031 Network Intrusion Prevention.
• Egress by default deny: servers, appliances and hypervisors should reach only named destinations (NIST SP 800-53 SC-7(5)). Velvet Ant's channel worked because the load balancers could reach the internet directly. See M1037 Filter Network Traffic and the Cloud Egress Filtering guide.
• Force traffic through an inspecting proxy: route user and server web traffic through authenticated proxies (SC-7(8)), so encoded content in HTTP is logged and, where policy allows, decrypted.
• Constrain script hosts: PowerShell Constrained Language Mode, script block logging and application control reduce the number of processes that can both encode and send.
• Lock down hypervisors: keep ESXi shell and SSH disabled except under change control and restrict management interface egress.

Where identity fits

Encoded C2 often carries stolen credentials. ATT&CK records WARPWIRE Base64 encoding captured credentials with btoa() before sending them to C2, and Elise using Base64 encoded cookie values to exfiltrate data. Service account passwords, API keys and session tokens leave as an encoded string in a request that looks routine. Two controls help: keep non-human credentials out of reach of the hosts that talk to the internet (vaulting and short-lived tokens), and alert when a service account or workload identity is used from an unexpected source after a suspected encoded exfiltration. See the MITRE ATT&CK T1078 Valid Accounts Guide.

How to test

1. Plan: pick two or three families from your intelligence and list their encoding (for example standard Base64 in POST bodies, Base32 subdomains, a custom alphabet).
2. Emulate safely: in an authorised exercise, generate benign traffic with the same encoding shapes from a lab host using an approved adversary emulation tool, with a test domain you own.
3. Check the chain: confirm the host events (4688 or Sysmon 1, 4104), the network events (Sysmon 3 and 22, proxy logs) and the joined alert all fire.
4. Tune in alert mode: run new analytics for two to four weeks without paging, record legitimate sources (backup agents, monitoring tools, SaaS sync clients) and add narrow exclusions by process and destination, not by encoding type.
5. Roll back cleanly: version analytics in source control so a noisy rule can be reverted while keeping its predecessor.

Detection and measurement

• Telemetry coverage: percentage of Windows hosts with process command lines and PowerShell 4104, and of ESXi hosts and appliances forwarding logs.
• Egress posture: share of servers, appliances and hypervisors with deny-by-default egress.
• Emulation detection rate: encoded C2 test cases detected within one hour, per quarter.
• Signal quality: true positive ratio for encoded-content analytics after tuning.
• Signature currency: median age of the IDS rule set and time to deploy a local rule after an incident.

Common failure patterns

• Alerting on every Base64 string: the SOC drowns and disables the rule. Score the process and destination, not the encoding.
• Network-only detection: without host data, encoded content inside TLS is invisible and cannot be tied to a process.
• Ignoring DNS labels: encoded subdomains slip past web proxies when only HTTP is inspected.
• Unmonitored edge devices: load balancers, VPNs and hypervisors with unrestricted egress and no log forwarding, as in the Velvet Ant investigation.
• Static signatures only: custom alphabets and small changes in later versions defeat yesterday's rules; pair signatures with behaviour analytics.

Framework mapping

Practitioner checklist

• Enable command-line logging (4688 or Sysmon 1) and PowerShell script block logging (4104).
• Deploy the v20 behaviour chain: encoder or encoded literal, then egress from the same process.
• Validate long tokens in cookies, URIs and JSON fields and flag non-standard alphabets.
• Baseline field lengths and DNS label lengths per destination.
• Keep IDS and IPS signatures current and add local rules after incidents.
• Apply deny-by-default egress to servers, appliances and ESXi hosts.
• Forward ESXi and network appliance operating system logs to the SIEM.
• Test with authorised emulation each quarter and track the detection rate.

Standards and references

• MITRE ATT&CK: Data Encoding (T1132)
• MITRE ATT&CK: Standard Encoding (T1132.001)
• MITRE ATT&CK: Non-Standard Encoding (T1132.002)
• MITRE ATT&CK: Network Intrusion Prevention (M1031)
• Sygnia: China-Nexus Threat Group Velvet Ant
• Google Cloud (Mandiant): Another BRICKSTORM
• MITRE D3FEND: Client-server Payload Profiling
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: ATT&CK Command and Control Tactic · Beaconing and C2 Detection Guide · T1027 Obfuscated Files or Information Defensive Guide · NDR Guide · MITRE ATT& · MITRE ATT&