Threat Simulation – Beacons

Intro

This article is number 5 of 8 in a series on testing Threat Hunting software to make sure that it’s configured correctly and working successfully. If you’ve not already read the “Threat Simulation Overview and Setup” article, start there and return here to test whether your Threat hunting platform can detect beacon traffic.

 

What Traffic Are We Trying to Find?

“Beacon” is the name given to an application making a regular check-in to a remote server. These can be benign (time synchronization done over NTP, monitoring software checking to see if a server or service is live, patching software asking if new versions are available, etc.) or malicious (malware regularly connecting to a Command and Control (C2) server).

Malicious beacons not only have a regular interval between them, but also commonly have payloads of similar size. Most of the beacons are of the minimum size, which are likely to be a conversation like “Do you have anything for me to do?”, “Nope, go back to sleep.”. Larger payloads usually signal that a request has been placed or results are being sent back.

Normally beacons are small, occasional, and quiet, hoping to sneak under the network radar. There are exceptions to this; beacons that trigger more than once a second. Once we jump beyond 250K connections a day, it’s impractical to try to analyze each connection; we classify beacons with more than that many connections to be “strobes” and present them all for inspection.

For reference, we don’t attempt to simulate and test detection of strobe traffic in this blog series. The load on the network is far too high; connection tracking firewalls and routers can experience high load in trying to track these and depending on the type of connection used, this can be an appreciable amount of network bandwidth. If you feel your Internal server, External server, and the networks and routers in the middle can comfortably handle hundreds of thousands of connections, we’d suggest using “ab”, the apache benchmark tool (it’s included in the “apache2-utils” package on Ubuntu, and the “httpd-tools” package on Redhat, RHEL, and Centos). This is capable of generating extreme numbers of simultaneous connections to your test web server and should only be used when you are sure its load will not affect any of the systems or networks involved.

 

You’ve Already Sent Beacon Traffic!

If you’ve done the steps in either the “Threat simulation – Unexpected Protocol on Non-standard Port” or “Threat simulation – DNS” blogs, you’ve already sent beacon traffic past your Threat hunting platform.

 

What You Should See on the Threat Hunting Platform

Look for beacons from the Internal server to the External server. If you’ve done the steps for testing DNS, you should see DNS connections 4 seconds apart. If you’ve tested “Unexpected protocol on non-standard port” you should also have ssh connections on port 110 that are 207 seconds apart.

Remember to look for both the IPv4 address pair and the IPv6 address pair.

How to Troubleshoot It If You Don’t

With tcpdump

If you are not seeing beacon traffic after going through the steps on the “DNS” or “Unexpected protocol on non-standard port” blogs, check that the conversation is successfully being started on the Internal server (substitute the name of the Internal system’s ethernet port for eth0):

sudo tcpdump -i eth0 -qtnp '(host Ext4 or host Ext6) and port 110'

and if it is, run the same command on the External server (substitute the name of the External system’s ethernet port for eth0):

sudo tcpdump -i eth0 -qtnp '(host Ext4 or host Ext6) and port 110'

You should see at least one IPv4 and one IPv6 conversation on that port between the two pairs of IP addresses for those systems. If you don’t, see if there’s a firewall that’s blocking this traffic.

If you have command-line access to the Threat hunting system, run the same command there, changing “eth0” to the name of the interface that’s capturing traffic:

sudo tcpdump -i eth0 -qtnp '(host Ext4 or host Ext6) and port 110'

If the traffic shows up on the Internal and External systems, but not when you run the sniffer command on the Threat hunting system, recheck that the Threat Hunting system is plugged into a span/mirror/copy port on a switch that sees the traffic from Internal to External.

With Zeek

Unfortunately, Zeek doesn’t have a way to use the time delta between sessions or the payload size to identify beacons.

The open-source RITA package can import Zeek logs and identify beacon behavior by looking at the connection payload sizes and time delta between connections.

More details on RITA

With tshark and R

Chris Brenton has a blog on using tshark and R (specifically the Rscript utility) to do statistical analysis on the time delta and packet size to identify beacons. Read here.

There’s a more general discussion of the process – including finding beacon traffic with open-source RITA – Here.

 

Ways to Obfuscate the Traffic

The primary techniques used to find beacons are the time delta between sessions and the payload size. Both the “Threat simulation – Unexpected protocol on non-standard port” and “Threat simulation – DNS” blogs show techniques for randomizing both the time delta and payload size for the individual connections. Ideally, your Threat Hunting platform will still identify these as beacons even when these vary

 

Links to All Posts in “Threat Simulation” Series

1. Unexpected Protocol on Non-Standard Port
2. Long Connections
3. Client Signatures (User Agent)
4. DNS
5. Beacons
6. Threat Intel
7. Certificate Issues
8. Client Signatures (TLS Signature)