Yet Another Reason for HTTPS Everywhere: Internet Node Based Malware Command and Control Channels

“The source of every crime, is some defect of the understanding; or some error in reasoning; or some sudden force of the passions. Defect in the understanding is ignorance; in reasoning, erroneous opinion.” 

― Thomas Hobbes, Leviathan

Introduction

As most of us know, many of the web sites and services we depend on the Internet are unencrypted, including news, retail, sports, and entertainment. Each one of these sites and services unintentionally provide an avenue for a MitM command and control (C2) infrastructure. In this concept, it is the traffic route that is important and that it can be modified.  Sites could be selected based on the crossing of C2 nodes along geographic lines or routing choke points, which could also help with locating the general area of infected machines. In addition, these sites would be normal in terms of user traffic and would not stand out from an initial DNS based forensic inquiry.

The Concept

Disclaimer: I have no proof this idea is in use as stated in this post.  This is just a proposal of an idea.

A MitM malware Command and Control (C2) channel needs three things to exist:

1. Malware on an infected machine

2. That contacts servers via unencrypted or decrypt-able traffic

3. Which crosses a malicious node that could inspect and inject content into the traffic

Normal Traffic:

Malware Communicating with a Malicious Node:

The MitM malware C2 concept is incredibly simple, but generally difficult to implement, and would be even more difficult to find in use. For a realistic attack, an adversary would need to implement the C2 code within an already existing infrastructure, particularly at advantageous nodes on the Internet.  To solve this problem, let’s consider that a node being used for mass Internet surveillance is multipurpose. Besides traffic capture, the most obvious use is the modification of traffic to stop the flow of information that opposes the view of the political powers that be or for corporate interests. Next is the MitM modification of binaries and code during download. Intelligence leaks have presented systems in place that could re-route client traffic to a server for end point exploitation. Finally I propose the possible implementation of a MitM malware C2 channel.

For an example, let us consider using HTTP for the channel.

The above diagram starts with an infected machine with malware (1) that is built to communicate via this infrastructure using HTTP GET requests.  The malware can be designed to communicate directly out, spoofing its User-Agent during the request. Perhaps the malware works like Superfish or Privdog breaking secure communications. Or it could be designed to parse outbound traffic and modify or tag the HTTP User-Agent header to a slightly different string making it identifiable from other HTTP requests on the web.  Furthermore, this malware will add an additional header; name doesn’t matter as the specifications allow flexibility, which will be used to pass encrypted data that is also base64 encoded. 

Next the HTTP request traverses the Internet from routing node to routing node as it makes it way to the requested HTTP server.  Along this path, a (2) Malicious/Evil Node inspects traffic for the unique User-Agent used by the malware. When the unique User-Agent request passes through this node, the C2 implementation tracks it, decrypts the encrypted message (if there), and waits for the response from the server.  One idea is that it again slightly modifies the User-Agent to avoid another malicious nodes in the route from modifying the request.  The modification could be as simple as removing the known tag from the User-Agent string.

The HTTP server (3) receives and (4) responds to the HTTP GET request.

The server’s HTTP response traverses back to the originating request (5) crossing the malicious node once again. As the response is handled, the malicious node injects a command for the malware into the either the HTML content as a comment with a unique tag or as an added unique HTTP response header that uses the same encryption scheme as the malware.

Finally the (6) HTTP response makes it way back to the originating machine, the malware either handles the request directly or intercepts the request, parses the request for encrypted commands, scrubs the request modifications in memory, then presents the response back to the user. Depending on the command, the malware will wait (sleep) until the next predetermined beaconing (1) attempt to contact the MitM C2 Node with the results of the prior command, if necessary.

I’ve written a POC to test portions of my thoughts; the client and server are written in python, with the C2 using mitmProxy.   After contemplation, I am not releasing the POC.  I believe it would not be useful to the pentester outside of an attacker controlled wireless access point and otherwise difficult to implement.  If I get enough feedback wanting a robust implementation, perhaps I'll build something.

Anti-Forensics

Many malware analysts work in a vacuum. Because of OPSEC, they cannot share their samples and indicators of compromise (IOCs) openly on the Internet. This balkanization of knowledge is not equipped to find a MitM malware C2 infrastructure. To the malware analyst, the contacted web server will appear to be the source of commands, especially for sites that are not popular (Ex: http://www.millerscleaners.com/). The analyst will write the site up as the C2, finish the network forensics part of the investigation, and continue on to other tasks.  The true C2 will go undetected; the patsy site will be determined as compromised, blocked within that organization, and at worse shared with a closed-source threat intelligence group.

Determining if the web server is compromised in this scenario will depend on the implementation of the malware.  In contrast to the prior example, if the malware uses multiple HTTP servers, especially popular sites, the analyst might determine that not all sites are compromised.  At this point, the analyst could take the risk of checking out of bounds via Tor network or a VPN service.  This would be a calculated risk as Malware authors of traditional end point C2s could have their servers configured to recognize requests from Tor exit nodes or outside of their target networks, thereby alerting that their malware samples have been found.

The other way to catch this type of threat is to monitor the change in server responses from node to node to determine when the C2 injects traffic - currently an impossible task. To stop this potential threat we need HTTPS everywhere and strong host security that is not undermined by vendor implementations. 

In Conclusion

I encourage malware analysts to look at malware C2 implementations differently and consider this as a potential avenue, albeit improbable. For companies with massive amounts of historical malware C2 data, it would be interesting exercise to determine which malware samples and classes could fall into this type of C2.