Is decrypting packet payloads operationally effective or efficient at helping defenders find signs of advanced nation state attacks or manually executed attacks like RansomOps in a network?
The short answer is no.
- Passively decrypting standard encryption such as TLS is operationally expensive (with TLS 1.3, it requires an agent to be installed on any and all endpoints connected).
- Decryption provides little benefit to the defender that active decryption with firewalls or proxies doesn’t already provide.
- And neither actually helps defenders track down an advanced attacker’s C2 channel or data exfiltration.
We consider traffic at an organization’s network boundary, where encryption is prevalent, and look for signs of command-and-control and data exfiltration. What we find is decryption offers very little if any benefit to defenders when it comes to detecting advanced nation state attacks or manually executed criminal attacks like RansomOps. Here’s why.
Nation state attacker tools are customized
Nation-state actors typically assemble tool chains for use by their attack teams. These tool chains often include tools which are developed in-house and tools which are more off-the-shelf. The off-the-shelf tools will be highly customized to avoid detection via simple methods which look for their mere presence.
And the most capable nation-state actors will add further entropy – they will configure the custom and off-the-shelf tools they use differently for each target they pursue, and will not reuse any of the infrastructure (for C2 and Exfil) used to carry out attacks on different targets. Therefore, decrypting payloads to run signatures has no meaningful detection benefit.
Criminal (RansomOps) attacker tools are modified
Manually executed attacks like those used to carry out most RansomOps attacks are in service of a for-profit business model. It makes little sense to spend a lot of R&D to build tooling from scratch as that simply cuts into potential profits.
Instead, almost all criminal attacks make heavy use of off-the-shelf tools, but these actors know enough not to use these tools with the shipped default settings, which most signature products would detect.
Instead, they will override the standard configuration that off-the-shelf tools ship with rendering signatures useless. Infrastructure is more commonly re-used but can be identified via domains and/or IPs without decrypting. Just as in the nation-state case, then, decrypting payloads to run signatures has no meaningful detection benefit.
The inner workings of Cobalt Strike
Let’s look at what it means to override the standard settings of Cobalt Strike, which is one of the more widely known off-the-shelf pen testing frameworks. This example is illustrative – the same degree of configurability exists in any mature pen testing tool, making it trivial to override default settings to evade signatures.
The user guide for Cobalt Strike can be found here. Let’s look at the Malleable Command and Control capability that is part of this package. To use the malleable C2 feature, you compose all the options you want to use in a profile.
In the profile, every element of the HTTPS request and response used for C2 communication is (as the title implies) malleable. This includes the certificate that you use to secure the TLS channel carrying the HTTP traffic, the URI coded into the HTTP request, the User-Agent specified, the presence or absence of a referrer tag, and anything else the attacker wants to put into the request to either make it look normal or to make it look unintelligible.
Any actual data that needs to be transferred across the C2 channel can be encoded in a variety of formats (Base64, NetBIOS, etc.) and can easily be masked by XORing in a random key known only by the attacker (think of this as a lightweight but effective form of “inner” encryption).
Summary
Whether encountering a nation-state or RansomOps attacker (one who applies good security hygiene by not reusing the same tags/values and keys for different targets), breaking the outer TLS encryption to gain access to the inner HTTP request doesn’t help the defender. There is no fixed pattern for a signature to target and the actual payload (commands sent, command results returned, software downloaded, etc.) is obscured by lightweight encryption using the attacker’s randomly generated key.
So, unless an organization is willing to run a very restrictive internet access policy (effectively whitelisting the part of the internet they trust), C2 channels cannot be detected by searching for byte patterns in decrypted HTTP payloads. Detecting exfiltration follows much the same logic. Encrypted inner payloads are impervious to standard DLP approaches. The only other means of C2 or Exfil detection is based on the analysis of time-series info of data transfers or the observance of simple volume anomalies – neither of which require decrypting the outer wrapper.