Can malicious communication be hidden reasonably well in encrypted network traffic?

Question

Given that a lot of websites now use TLS/https to encrypt all network traffic: If a client machine is compromised and does need to establish a back channel to a C&C-Server for additional instructions and data exfiltration, can it be successfully hidden in HTTPS traffic?

Network based intrusion detection systems have - unless utilizing a HTTPS proxy - little knowledge of what other resources are to be loaded after an initial page load. If the malware sends a heartbeat by using suspicious header data on an HTTPS request (and gets tasking back in form of maybe an image treated with steganography, can regular network based IDS pick that up if the DNS requests do not trigger anything and the IPs are not on a blacklist?

Additionally, as port 443 is usually allowed in firewalls (and established connections are usually allowed back), this seems to be a good spot to hide in plain sight.

How could this be determined to be malicious content when it's properly encrypted? Could this allow malware to hide it's communication from the sight of most analysis?

What are possible ways to pick up and detect malware that hides its communications in this way, i.e. sending a single request whenever it must and there is a lot of https traffic to different servers ongoing anyways, for example with an initial facebook loading?

Answer 1

While HTTPS makes it much harder to detect malware from traffic payload the communication can also be hidden with plain HTTP. This is done for example by encrypting the transferred messages with a shared secret or by using steganographic techniques.

Still, detection might still be possible by looking at the meta data of the traffic instead of the content. Such meta data are for example the traffic patterns: Even with TLS the direction and size of traffic is still visible, i.e. it can be seen when a request is sent and when a response is received. Visiting a HTML page with a regular browser will result in request+response bursts since the loading of the HTML page will cause a download of the embedded resources. Other meta data are features of the TLS handshake, like which ciphers are offered by the client and in which order, which TLS extensions are used, what kind of certificate is returned etc. Other meta data are target and timing of the request, relation to DNS traffic etc.

There was an interesting research by Cisco about this topic, see for example Detecting Encrypted Malware Traffic (Without Decryption). At the end of this link you will also find references to further research.