Safeguard
Application Security•

Junk Data in C2 Traffic and How to Spot It (T1001.001)

Junk data pads command and control traffic so simple decoding fails. Learn what MITRE says about it and which network signals give it away.

Safeguard Security Team
3 min read

Junk Data (T1001.001) is a command and control sub-technique under Data Obfuscation. Adversaries add random or meaningless data to the protocols used for C2 so that trivial methods of decoding or analysis stop working. It applies to Windows, Linux, macOS and ESXi.

How attackers use it

MITRE gives the simple picture. Junk characters can be added at the start or end of a message, or written between the significant characters. The real message is still in there. It just no longer matches the clean pattern an analyst or a basic tool expects.

How to detect it

The strategy MITRE documents is behavioral. It looks for connections whose shape is wrong for the process making them:

  • Large outbound connections with a lopsided send and receive ratio, often to uncommon ports or hosts.
  • Non-networking processes producing outbound payloads of odd size or pattern.
  • Previously unseen applications sending a lot of data with no return response.
  • On ESXi, management daemons such as hostd or vpxa embedding non-standard payloads in management protocols, or beaconing.

The data you need is connection logs, packet inspection where you have it, and process attribution. Start with the ESXi case if you run hypervisors, because few legitimate reasons exist for those daemons to talk to the internet.

How to reduce the risk

MITRE's mitigation is Network Intrusion Prevention. Signature-based network tools can mitigate some obfuscation activity. Add egress filtering so servers and hypervisor management networks can only reach destinations you have approved.

Reading the ratio

A send and receive imbalance is the easiest junk data signal to turn into a query. Normal client behavior sends a small request and gets a larger response. Padding and bulk outbound messages push the ratio the other way, and a process that sends far more than it receives, again and again, is unusual.

Start with a list of processes on a server that make outbound connections, along with total bytes out and bytes in per day. Look at the top few by bytes out. For each, ask whether you can explain it. Backups, log shippers and monitoring agents will dominate the list, and that is fine. The value is in the item you cannot explain.

Quick check

What network pattern points to junk data?

Disproportionate send and receive ratios from a process that should not be a heavy network user, especially to uncommon ports or hosts.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.