MITRE ATT&CK T1001 Data Obfuscation: Detecting Disguised Command and Control Traffic

Malware that talks to its operator over HTTP or DNS rarely sends commands in the clear: it pads them with junk, hides them inside images and XML, or makes them look like a trusted product's own traffic. MITRE ATT&CK T1001 Data Obfuscation, a Command and Control (TA0011) technique for Windows, Linux, macOS and ESXi, covers that hiding: C2 content that is concealed, though not necessarily encrypted, so it is harder to find and decipher. This guide covers the three sub-techniques, the procedures ATT&CK records, the v20 detection strategy and its data sources, mitigations and testing. It is for detection engineers, network security teams and threat hunters. For C2 in general, see the Command and Control (C2) Guide.

Key takeaways

• It hides the content, not the connection. The flow still exists, so process-to-network attribution and behaviour over time beat content signatures.
• Three sub-techniques, three detection angles. Junk data defeats fixed signatures, steganography moves commands into media and markup, and protocol impersonation borrows a trusted product's look.
• Impersonation targets what you allowlist. SUNBURST posed as the SolarWinds Orion Improvement Program and FRAMESTING reused the Ivanti DSID session cookie name.
• ATT&CK's mitigation is narrow. M1031 Network Intrusion Prevention catches known families; ATT&CK itself warns that adversaries change signatures over time.
• Edge and management devices are where it hides best. Appliances and monitoring servers are trusted, poorly instrumented and talk to the internet by design.

What T1001 covers

ATT&CK v20 (technique version 1.2) describes C2 communications hidden to make content harder to discover or decipher and to make the communication less conspicuous, by adding junk data, using steganography or impersonating legitimate protocols. The boundaries with neighbouring techniques matter for mapping detections correctly:

For file and script obfuscation, see the T1027 Obfuscated Files or Information Defensive Guide. For carrier analysis in depth, see the Steganography in Attacks Guide.

How adversaries use it

• SUNBURST (SolarWinds supply chain compromise): Mandiant's December 2020 analysis says the backdoor masqueraded its traffic as the Orion Improvement Program protocol, hid command data across GUID and hex strings in HTTP responses made to look like benign .NET assembly XML, and padded messages with optional junk bytes. In outbound JSON, only objects with a particular flag carried real data; the rest were random and discarded. It also waited up to two weeks before acting. ATT&CK maps these behaviours to all three sub-techniques. See the SolarWinds supply chain compromise analysis.
• FRAMESTING (Ivanti Connect Secure exploitation): Mandiant reported in January 2024 that this Python web shell, linked with moderate confidence to UNC5221, read encrypted commands from a cookie named DSID, the name the appliance uses for VPN sessions, or from zlib-compressed JSON in POST requests to an endpoint that legitimately accepts only GET. See the Ivanti Connect Secure exploitation analysis.
• Okrum (Ke3chang): ESET reported in July 2019 that Okrum hid C2 messages in the Cookie and Set-Cookie headers of HTTP requests over port 80, against diplomatic missions.
• TrailBlazer: ATT&CK records it masquerading C2 as legitimate Google Notifications HTTP requests and using random identifier strings to obscure operations.
• Uroburos (Snake): ATT&CK records custom communication methods riding over TCP, UDP, HTTP, SMTP and DNS to blend with normal traffic, and extra characters in encoded strings to mimic legitimate DNS requests, citing joint advisory AA23-129A.
• FakeTLS: ATT&CK records Lazarus Group malware and BADCALL using a FakeTLS method that mimics TLS while using different encryption, and Mustang Panda tooling using TLS record headers to impersonate TLS versions.
• Steganographic C2: ATT&CK records LunarWeb receiving commands hidden in the structure of JPG and GIF images, HAMMERTOSS commands appended to image files, and the Sliver framework able to encode binary data into PNG files for C2.

What to detect and where

ATT&CK v20 assigns detection strategy DET0053 Detect Obfuscated C2 via Network Traffic Analysis to the technique, with sub-technique strategies DET0235 for steganography and DET0470 for protocol impersonation. The analytics and their data components:

Turning the analytics into hunts

• Process to destination: join endpoint network events (Sysmon Event ID 3 for connections, 22 for DNS queries, or EDR equivalents) to proxy and flow records, then ask whether this binary normally talks to this destination. A product's updater talking to a new domain is the SUNBURST pattern.
• Protocol consistency: compare what a session claims to be with how it behaves. A TLS record header on a port with no proper handshake, a browser User-Agent from a non-browser process, or a POST to an endpoint the application only serves by GET (the FRAMESTING pattern) are all strong signals.
• Size and timing: junk data changes payload sizes but rarely hides regular check-ins; pair this with beacon scoring. See the Beaconing and C2 Detection Guide.
• Cookie and header anomalies: unusually long or high-entropy cookie values, cookies sent to endpoints that never set them, or headers that never vary across requests.
• Appliance and server egress: management servers, VPN gateways and hypervisors should have a short, known list of destinations; anything else deserves review.

Network detection and response tools and Zeek-style HTTP, TLS and DNS logs provide most of the content-level fields. See the NDR Guide.

Mitigations

For the mitigation itself, see M1031 Network Intrusion Prevention.

Where identity fits

Protocol impersonation works because some traffic is trusted on the basis of what it looks like rather than who sent it. Machine identities fix that: a monitoring server or appliance that authenticates to its vendor's service with its own certificate or token, through a proxy that checks it, leaves impersonated traffic easier to tell apart. The SolarWinds and Ivanti cases also show the payoff of the C2 channel: tokens, service account passwords and signing certificates stored on the compromised system. Inventory the secrets held by management servers and edge devices, keep their service accounts away from domain or cloud admin rights, and be ready to rotate them all on a C2 finding. See the Command and Control (C2) Guide for the response sequence.

Rolling it out

1. Collect the data components: make sure DC0082 (endpoint network connections with process), DC0085 (HTTP, TLS and DNS content from proxy or sensor) and DC0039 (file creation) reach the SIEM from servers, appliances and ESXi hosts, not just workstations.
2. Baseline process to destination: build a list of which binaries talk to which domains, starting with management, monitoring and backup software and edge devices.
3. Deploy the protocol consistency hunts: header, User-Agent, method and port mismatches; run them as scheduled hunts for a month before alerting.
4. Restrict egress: move servers and appliances to allowlisted egress in monitor mode, review the blocks it would have made, then enforce. Keep the previous ruleset for rollback.
5. Tune signatures: enable IPS and IDS rule sets for current C2 families, and track which rules fire and which are suppressed.
6. Write the response path: isolate the host, capture memory and traffic, and rotate every credential the host held.

How to test

• Atomic tests: in an authorised lab or purple team exercise, generate HTTP C2 with junk padding, a mismatched User-Agent and a fake TLS header from a test binary, and confirm which analytics fire.
• C2 framework profiles: red teams using commercial or open-source C2 frameworks can apply traffic profiles that imitate common web services; check whether your proxy and NDR flag the process-to-destination mismatch even when content looks normal.
• Carrier test: send a benign image with appended data out through the proxy and check that file metadata analytics see a type mismatch.
• Appliance test: with the vendor's guidance, send a POST to a GET-only endpoint on a test appliance and confirm it appears in your logs.

Decision guidance

• Signatures or behaviour: signatures are cheap and precise for known families; behaviour analytics catch new ones. Use both, and measure how much detection depends on signatures alone.
• TLS inspection or metadata only: inspection exposes content but adds privacy, legal and breakage costs. Where it is not possible, rely on process attribution, certificate and handshake metadata, and destination reputation.
• Small organisations: egress allowlisting for servers, protective DNS and EDR network telemetry give most of the value without a full NDR deployment.
• Large organisations: NDR or Zeek sensors at internet egress and between zones, a process-to-destination baseline and a hunting cadence for impersonation.

Measurement

• Telemetry coverage: share of servers, appliances and hypervisors sending network connection events with process attribution.
• Egress control: share of server and appliance segments on allowlisted egress.
• Analytic coverage: number of DET0053, DET0235 and DET0470 analytics implemented and tested per platform.
• Purple team detection rate: share of simulated obfuscated C2 sessions detected, and median time to alert.
• Signature dependence: share of confirmed C2 detections that came only from a family signature.

Common failure patterns

• Trusting vendor traffic by name: allowlisting anything that looks like a product's update or telemetry protocol, which is what SUNBURST relied on.
• Appliances outside monitoring: VPN gateways and hypervisors with no endpoint telemetry and no egress review, the setting for FRAMESTING.
• Content signatures as the only control: junk data and changed headers defeat them, as ATT&CK warns for M1031.
• No process attribution: proxy logs without the originating process or host, so a browser and a backdoor look the same.
• Not rotating credentials after a finding: removing the implant but leaving tokens and service account passwords it could read.

Framework mapping

The tactic view is in the ATT&CK Command and Control Tactic guide.

Practitioner checklist

• Collect network connection events with process attribution from servers, appliances and hypervisors.
• Baseline which binaries talk to which destinations, starting with management and monitoring software.
• Hunt for protocol mismatches: User-Agent, HTTP method, TLS header and port inconsistencies.
• Flag long, high-entropy cookies and headers sent to endpoints that never set them.
• Put servers and appliances on allowlisted egress through an authenticated, logging proxy.
• Run file integrity checks on appliance and product code, using vendor tools and an external check.
• Keep IPS and IDS signatures current, and measure how much detection relies on them.
• On a C2 finding, isolate, capture memory and traffic, and rotate every secret the host held.

Standards and references

• MITRE ATT&CK: T1001 Data Obfuscation
• MITRE ATT&CK: T1001.003 Protocol or Service Impersonation
• MITRE ATT&CK: M1031 Network Intrusion Prevention
• Mandiant: Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor
• Mandiant: Cutting Edge, Part 2, Investigating Ivanti Connect Secure VPN Zero-Day Exploitation
• ESET Research: Okrum, Ke3chang group targets diplomatic missions
• NIST: SP 800-53 Rev 5, Security and Privacy Controls for Information Systems and Organizations

Related NHI Mgmt Group resources: Command and Control (C2) Guide, Beaconing and C2 Detection Guide, Steganography in Attacks Guide, MITRE ATT&CK T1071 Application Layer Protocol, TLS Inspection Guide, MITRE ATT&, MITRE ATT&.