MITRE ATT&CK Matrix – C2 Connection Proxy

Let’s keep working down the Command and Control column of the MITRE ATT&CK Matrix. In this blog entry we’ll explore “Connection Proxy”. We will discuss what threat vectors are covered under this category as well as how you can detect this activity on your network.

 

What Is a “Connection Proxy”?

A connection proxy is simply when an attacker relays their commands through a server using a well known service. The server then connects to other resources (like a command and control server) on behalf of the client or compromised system. This is a common connection technique that has been used for years by legitimate network administrators. In this context however, the bad guys are leveraging it to help hide their tracks.

 

A Legitimate Proxy Server

Let’s start with an example of a legitimate proxy server, and then we’ll dive into how the technique can be leveraged for nefarious purposes. Imagine I have a bunch of users that want access to the Internet. If I let them connect to Web sites directly, I have no control over the content their view or whether they inadvertently download malicious code. A possible solution, is to setup a Web proxy server. In this configuration, my users connect to the proxy server and identify what information they are looking for and where it’s located (example: show me the homepage for www.google.com). The proxy server then connects to the resource on behalf of the client, retrieves the requested information, and then sends this data back to the client. There a number of benefits to this configuration, but the above description gives you the basics.

 

Using Proxies to Hide Command and Control Servers

Let’s look at how a reverse proxy connection can be used by an attacker to help hide their tracks. Consider the following network drawing:

In this configuration, the attacker is leveraging the Content Delivery Network (CDN) of a well known provider such as Amazon, Google or Akamai.These requests are then sent by the CDN to the Command and Control server (C2). This setup is nearly identical to how you may leverage a CDN to improve the performance of your company’s Web server. The only difference is that the CDN is specifically configured not to serve up cached information, but rather to forward all requests to the C2 server. There are some good articles out there on how exactly this would be configured. You will frequently hear this technique referred to as domain fronting.

The benefit of this setup for the attacker is that it helps them to obfuscate their C2 traffic. If you were to check the firewall logs, you would not see any traffic going to evil-example.com. Rather, you would see traffic headed to the well known CDN provider, and that traffic would also be mixed in with legitimate CDN traffic. Further, if HTTPS is used, the digital certificate seen at the firewall would be that of the trusted CDN provider! Needless to say, this makes identifying the C2 communications that much more difficult.

 

Detecting Domain Fronting

We posted a blog entry about a year ago that documents how to identify when reverse connection proxies are being used for domain fronting. In short, the compromised system is still going to exhibit the same beaconing traits we see in most C2 traffic. So by performing a beacon analysis on your network, you will still be able to catch this obfuscation technique. Note that even though the traffic gets routed through the CDN network, the DNS queries are still going to be against the domain hosting the C2 server. So by analyzing your queries, you may be able to detect this activity as well.

 

Using Proxies to Escape the Target Network

Another way attackers can leverage connection proxies is to bounce their traffic through a local system in order to get their C2 traffic out of the network where the compromised system resides. Consider the problem from the attacker’s perspective. If they can trick one of your users into installing malicious software on their system, that software still needs some way of connecting to the C2 server. Your network is a bit of a black box to the attacker. They don’t know what firewall policies are in place. For example, if they have the malware call home on TCP/1234, you may very well have that port blocked outbound. This will prevent them from being able to send marching orders to the malicious software.

With the above in mind, the attacker is going to want to use a protocol that you are likely to permit outbound, and try and rely that traffic through a local server that is most likely to have Internet access. A natural choice is to bounce DNS traffic off of the local name servers. If I can make my traffic look like legitimate DNS traffic, and I can send it to the local resolver name servers, those servers will most likely forward the traffic out to the Internet, and ultimately the C2 server.

To see how this would work, consider the following drawing:

In this example the compromised system sends TXT queries for hosts within the domain controlled by the attacker. The authoritative name server for that domain is actually the C2 server. Provided the compromised system does a good job at making the queries look like normal DNS traffic, the local name server will happily proxy that traffic and pass it out to the Internet.

Here’s an example of what those queries may look like. Note the decode in the next Figure which is from a packet capture of dnscat2 traffic. dnscat2 establishes a C2 channel through the local name server.

Note that while the first packet is a CNAME query, the second is a TXT query. dnscat2 can also send MX queries. If you check the payload of the first packet, you’ll see a really long hostname associated with the domain “honestimnotevil.com”. The host name is actually a coded message being sent to the C2 server.

 

Detecting Outbound Connection Proxies

The same beacon analysis techniques discussed above are applicable here as well. The difference is you will see the compromised system beaconing to the local name servers, rather than to a host that is out on the Internet. This would permit you to detect C2 through connection proxies, regardless of which internal system they attempt to proxy through.

If you want to focus on DNS, since that is the most common C2 channel, you may be able to pull the information you need out of your DNS logs or from packet captures at the perimeter. One tell tale sign of C2 over DNS is an excessive number of Fully Qualified Domain Names (FQDNs) within a remote domain. Consider the following question: “How many hosts does it make sense for a network to expose to the Internet and make resolvable via DNS?” For most networks this number is usually 10 or less. For example, there may be a Web server, mail server, a few authoritative name servers, and that may be about it. For very large and recognizable service companies like Google, Amazon, Microsoft, Akamai, etc., they may have a few hundred. If you detect a few thousand host names being queried within a specific domain, it may actually be C2 traffic.

Here’s a slick trick for pulling the info you need right out of a pcap. In an earlier blog entry we discussed how tshark can be used to display only certain fields within IP packets. Here’s an example that shows just the DNS queries being printed:

In this example I tell tshark to only print the DNS query field within the packets. Note that I didn’t need to filter on only DNS traffic. Tshark is smart enough to figure that part out. Now that I can see all of the queries, I just need to count how many unique hosts appear in each domain. In the above output I see two sets of queries for three unique FQDNs. I want to make sure that entries like this do not get double counted. While it’s a bit of a hack, the script shown below will do just nicely.

There is a lot going on in this set of commands, so let me step through each portion of it:

• tshark – This is extracting the FQDNs being queried from the packet capture.
• sort – Sort the data so that matching queries are grouped together.
• uniq – We only want to count each unique hostname once, so this removes duplicates.
• rev – Reverse the characters on the line. So the entry “www.google.com” would become “moc.elgoog.www”. We will want to match on the TLD (com, net, gove, uk, etc) and the domain name. We will also want to remove host names and subdomains. The easiest way to do this is to put the stuff we want to match on at the front of the line.
• cut – We are identifying that a period is a field separator and that we want to match on the first two fields. Since we reversed the line, the first field is the TLD (written backwards) and the second is the domain (also written backwards).
• rev – Reverse the characters on the line again so they are human readable. So “moc.elgoog” would become “google.com”.
• sort – Sort the lines again so matching entries are grouped together.
• uniq – Again, we remove duplicates but the “-c” switch says we want to count how many lines existed before the duplicates were removed. This will give us a count of how many FQDNs were queried in each domain.
• sort – The “-rn” switch tells “sort” to sort the lines in reverse order (highest to lowest value) and that the data is numeric. The previous “uniq -c” counted matching lines and put this value at the beginning of the remaining line. So “-rn” will move domains with the most number of FQDNs to the top of the list.
• head – Used here for presentation purposes only so that everything fit in the screen capture. You would probably want to redirect the output to a file for later review.

As you can see in the output, we now have a list of domains sorted by which domains had the greatest number of FQDNs. As mentioned above, any domain I don’t recognize with more than 1,000 domains is most likely an indication that my name servers are being used as a connection proxy by malware on one or more machines. In the above example, I would want to do further research to identify which internal system(s) keep doing lookups within r-1x.com.

 

Lessons Learned

Attackers can leverage proxies to obfuscate their C2 communications. This could be in the form of a reverse proxy server, which may be hiding the true location of the C2 server. It could also be in the form of a forwarding proxy server, which may permit the attacker to tunnel their C2 traffic out of a target network. In both cases, analyzing traffic patterns to look for beacon activity would help to identify connection proxy traffic.