Exfiltration Over Asymmetric Encrypted Non-C2 Protocol

Where T1041 sends stolen data back over the same channel the attacker is already using for commands, this technique deliberately uses a different one, and specifically a different one that's asymmetrically encrypted, like a fresh HTTPS/TLS connection distinct from whatever protocol carries C2 traffic. The separation is the point: bulk data exfiltration is bandwidth-hungry, and cramming it into a low-bandwidth channel built for occasional check-ins, like DNS, is slow and conspicuous. A dedicated encrypted channel moves the data fast and the encryption gives the attacker plausible cover, since encrypted HTTPS traffic is everywhere and rarely inspected in detail.

This shows up as a genuine two-channel operation: one channel, often something low-bandwidth and hard to fully block like DNS, handles command and control, while a separate connection, opened specifically when there's data ready to move, handles the actual transfer. The two channels can go to entirely different destinations, which is deliberate: even an analyst who's fully mapped the C2 channel might miss the second one if they're not specifically looking for a new destination appearing right around the same time.

The asymmetric encryption itself, standard TLS is the common case, isn't unusual on its own. Nearly all legitimate traffic is encrypted the same way. What's unusual is a brand new encrypted connection to a destination that has no other relationship to the host, appearing shortly after other suspicious activity, carrying a volume of data that doesn't match anything routine.

Data source: the network sensor's TLS handshake record (server name, JA3), paired with the same process's host-side name lookup and outbound connection record with byte counts

{
  "host": {
    "name": "APP01"
  },
  "event": {
    "action": "network_flow",
    "category": "network"
  },
  "network": {
    "protocol": "tls"
  },
  "destination": {
    "ip": "198.51.100.23",
    "port": 443,
    "bytes": 62914560
  }
}

Prebuilt Elastic rule: Potential Data Exfiltration Activity to an Unusual Destination Port

Start from the C2 channel if you've already found one, and look for a second, independent connection opened around the same time, to a different destination, carrying real data volume rather than the small, regular pattern of a check-in. A host that's been beaconing over DNS suddenly opening a large encrypted connection to a brand-new destination is exactly this pattern.

Hunting manually: for a host already flagged for suspicious C2 activity, look at every other outbound connection in the same session window, sorted by destination.bytes. A new TLS connection to an unfamiliar destination, carrying meaningfully more data than the host's baseline, is the signal, even though the connection itself is "just HTTPS" at the protocol level.

New encrypted connections to new destinations happen constantly for entirely normal reasons, software updates, CDN traffic, a user visiting a new website. Volume and timing are what separate this from noise, not the mere presence of a new TLS connection.

The distinguishing signal is correlation with other suspicious activity and a transfer volume that doesn't match the destination: a large upload to an unfamiliar destination, especially one immediately following other flagged activity on the same host, is very different from routine browsing or an update check-in, which are typically downloads, not uploads, and don't cluster suspiciously with other findings. If the host has no other suspicious activity and the destination resolves to a known, reputable service, this is much more likely routine traffic than exfiltration.

• MITRE ATT&CK T1048.002: Exfiltration Over Asymmetric Encrypted Non-C2 Protocol
• Elastic Security: Data Exfiltration Detection integration

1 scenario in this catalog covers T1048.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →