MITRE ATT&CK Matrix – Custom C2 Protocol
We are going to continue working down the command and control (C2) column of the MITRE ATT&CK Matrix. In this blog entry we’ll cover “Custom Command and Control Protocol”. This technique has been used by everything from rudimentary keystroke loggers to nation state Advanced Persistent Threats (APT). Luckily, there are a few techniques you can leverage to detect this type of activity.
What Is a Custom Command and Control (C2) Protocol?
A custom C2 protocol is simply a network communication method that does not follow the transmission rules of the well known service associated with the communication port. For example, the malware may transmit traffic to TCP/80, but not actually communicate using the HTTP protocol which is usually associated with that port. Using a custom C2 protocol is far more rudimentary than other communication techniques like using a connection proxy. This (usually) makes detecting this C2 method much easier. To understand why custom C2 protocols get used, you need to understand the business model behind the overall attack. This also helps you to understand why custom C2 protocols work the way they do.
Attackers are looking to extract value from their ability to compromise systems
System Compromise as a Business Model
You can boil down the motivations of an attacker into one simple statement: Attackers are looking to extract value from their ability to compromise systems. Besides the fact that this activity is illegal, it is not all that different from a standard business model. Companies also look to extract value (money) from the goods or services they offer. This means the business models are actually quite similar.
Looking at it from this perspective, in order for the attacker to extract value from compromised systems, there needs to be a number of components to their business model. In short, these include:
- Some way to deliver the malware to remote systems. This may be vulnerability scanning of exposed systems, or spear phishing user systems behind a firewall.
- The attacker needs functional malware that permits them to control the remote system. Further, this malware needs to be difficult to detect. This may require unique malware strains for each network being targeted.
- The attacker needs a way to maintain communication with the compromised system. This is the C2 component that is the focus on this blog post.
- They need some way to derive value from the illicit access. This could be stealing information that has value elsewhere (trade secrets, credit cards, encrypt and extort data for money, rent access to other attackers, etc.).
Each of these four components must be addressed in order for the attacker’s business model to be successful. Note that some of them are kind of hard. For example, most people don’t fall for canned phishing attempts anymore, so research and customization must be performed prior to launching a phishing campaign. This can be both labor and time intensive. Further, it must be repeated for each unique network being targeted.
In fact, the easiest item on this list is arguably the C2 component. Most environments permit outbound access on TCP/80 (HTTP), TCP/443 (HTTPS) and both TCP and UDP 53 (DNS). If I simply have my malware attempt to connect home on each of these common ports, it is highly probable that at least one of them is going to work.
What Makes Custom Protocol C2 Traffic Different?
What makes custom C2 protocols unique is that they do not follow the protocol associated with the port they are using. As an example, TCP/443 is the well known port for HTTPS. The HTTPS protocol identifies a specific series of handshakes that must take place at the beginning of every SSL or TLS session. Immediately after the TCP three packet handshake, the client is required to send a ClientHello. The server must then respond with a ServerHello followed by a copy of the server’s digital certificate. The Hello packets are part of the negotiation to determine what authentication and data privacy algorithms will be used to protect the session.
With this in mind, consider the following packet capture:
Note that the tool I’m using, tcpdump, is identifying the captured communications as HTTPS. So I would expect to see the client negotiating security protocols immediately after the TCP three packet handshake (ClientHello). However, the decode shows cleartext that obviously has nothing to do with SSL or TLS. Tcpdump is simply assuming that any traffic headed to TCP/443 must be HTTPS. This is clearly not the case. So the reason many C2 channels do not bother following the protocol guidelines is because many tools will incorrectly label them based on the target port. This is true of many packet filtering firewalls as well.
How to Detect Custom C2 Communications
In order to detect when custom protocols are being used over a well known port, we need to use a tool that actually analyzes the protocol being used. Any application proxy would be able to both identify and block C2 communications that are not protocol compliant. We can also use tools like Zeek that analyze the protocol in order to properly identify it. Here’s an example:
Note that Zeek is labeling the protocol as “ssl” because it has observed both the ClientHello and ServerHello exchange. Also note that this could be SSL or TLS,as Zeek labels both as “ssl”.
Now, consider the following output:
In this case, Zeek does not recognize the protocol as being SSL compliant. In fact, Zeek tests for 50+ different protocols and only prints a “-” when the protocol is not recognized. So in this last Figure, some form of non-standard protocol is in use and clearly warrants further investigation.
Since RITA, our open source threat hunting tool, derives its data from Zeek, it is also capable of identifying when a protocol using a well known port is not compliant.
C2 traffic based on custom protocols can be detected, but you need to ensure you are using the right tools. Make sure you understand whether your tool is labeling the protocol based on the well known port that is being used (tcpdump, many packet filtering firewalls, etc.) or whether the tool actually inspects the protocol (proxies, Zeek, RITA, AI-Hunter, etc.) to perform proper identification. When a communication session is using a well known port, but not the protocol that is normally associated with it, the traffic warrants deeper investigation.
Chris has been a leader in the IT and security industry for over 20 years. He’s a published author of multiple security books and the primary author of the Cloud Security Alliance’s online training material. As a Fellow Instructor, Chris developed and delivered multiple courses for the SANS Institute. As an alumni of Y-Combinator, Chris has assisted multiple startups, helping them to improve their product security through continuous development and identifying their product market fit.