Detecting Beacons by System Name with RITA and AC-Hunter

Both RITA and AC-Hunter have had the ability to detect beacons by Fully Qualified Domain Name (FQDN) for a while now, but the latest version of both tools now include the ability to detect beacons based on Server Name Indication (SNI). These features seem pretty similar, so why would you use one over the other? That is exactly the topic of this blog entry. 🙂

 

Beacon-FQDN and How It Works

The original beacon FQDN feature in both RITA and AC-Hunter uses DNS information to identify the target system. Imagine an attacker is using DNS round robin to load balance across multiple Command and Control (C2) servers. If I’m only checking for beacons between two specific source and destination IP addresses, I may miss a load balanced C2 server because I would only see a portion of the sessions. This is because the other portion of the C2 traffic is going to different destination IP addresses. By targeting the destination FQDN instead of a single IP, those multiple sessions can be tied together so that a full view of the C2 traffic can be analyzed.

 

Beacon-SNI/Web and How It Works

Beacon-FQDN works great, unless the attacker is sitting behind a Content Delivery Network (CDN) like Akamai, CloudFront, or similar. The challenge here is that legitimate services may be using the same CDN systems as the attacker. Beacon-FQDN tries to use the timing of when queries took place to resolve conflicts, but due to DNS caching this may not always be accurate. So with a CDN network, beacon-FQDN will still tie together multiple destination IP addresses into a single target, but there may be errors due to legitimate servers using these same systems.

This is where beacon-SNI steps in. Beacon-SNI uses application layer information in the data stream to identify the target system. Since this is the same data the CDN servers use to forward the traffic, it has to be accurate. This permits the beacon-SNI feature to distinguish between multiple services using the same set of CDN servers.

In the case of HTTP traffic, the “Host” parameter is used as shown in the following decode:

With HTTPS traffic, the SNI or server name is used as shown in the following decode:

Since the CDNs rely on this information to properly forward traffic, RITA and AC-Hunter can also leverage it for beacon detection.

 

When to Use Beacon-FQDN versus Beacon-SNI

So when may you want to use one feature versus another? Here’s some simple steps to guide you:

• If you want to check for C2 traffic based on HTTP, regardless of the target port (TCP/80 or something else), use the beacon-SNI/Web feature.
• If you want to check for C2 traffic based on HTTPS, regardless of the target port (TCP/443 or something else), use the beacon-SNI/Web feature.
• If you want to check for beacons not based on HTTP or HTTPS, and you suspect the traffic could be load balanced across multiple IPs, use the beacon-FQDN feature.

That’s it! Happy hunting and we hope you find this new feature useful.