Simulating a Beacon

When it comes time to test a Threat Hunting platform, we need a way to generate traffic that looks like a threat to see if the platform can detect it. When we did a blog series on Threat Simulation, we offered a series of commands to run. It would be nice if we had a standalone program that could generate this traffic.

 

Threat-Tools and Beacon-simulator.sh

We put together a collection of tools called “threat-tools”. At the moment, it consists of a single program, “beacon-simulator.sh”, that generates regular connections to a target server. Let’s look at an example.

I’d like to generate a series of connections from a client system to a server. I’d like these to be generally 60 seconds apart, but I don’t want them exactly 60 seconds apart; the time between connections might be as low as 55 seconds and as high as 65 seconds – this tests whether the Threat Hunting platform can recognize the beacon when the timing has a bit of jitter. To do this, I’m going to request a 60-second interval and a 10-second jitter range.

 

Step by Step

First, you need a command line running the bash shell. If you have access to a Mac or Linux command line, you’re all set. If you’re on Windows, you’ll need to install cygwin or ssh over to a Linux box.

Once you have a bash command prompt, run the following commands:

mkdir -p $HOME/bin
cd $HOME/bin
wget https://raw.githubusercontent.com/activecm/threat-tools/main/beacon-simulator.sh
chmod 755 $HOME/bin/beacon-simulator.sh

To see the available options, run:

beacon-simulator.sh -h
Parameters:
1: target ip
2: port
3: interval
4: jitter
5: optional protocol (default is tcp ; put udp here if you want that)

Examples:
beacon-simulator.sh 192.168.0.1 9999 150 12
beacon-simulator.sh 192.168.0.7 514 200 10 udp

To actually generate this traffic, we’ll need a listening port on a server somewhere¹. Make sure this is not a critical or production server, and double-check that you have permission to send this. I’m going to pick a server nearby running a squid cache, which listens on tcp port 3128. This will open up a series of connections about once a minute, sending requests that make no sense to squid (but that just means the squid request log will have a lot of odd request strings).

beacon-simulator 10.0.0.185 3128 60 10
Will connect to host 10.0.0.185, tcp port 3128 every 60 +/-(10/2) seconds
.....

Each time a connection is sent to that port, you’ll see a “.” printed to the screen.

Because of the way the shell works, if you close the ssh connection to this host, the beacon-simulator.sh script will be killed. If you want to allow it to run in the background even when you close the ssh connection, do the following:

screen -S beacon1 -R
beacon-simulator 10.0.0.185 3128 60 10

Now press <ctrl>-<a> , release it, and press <d> . This will disconnect you from the screen session, but allow beacon-simulator.sh to continue to run. To reconnect later and kill it, run

screen -S beacon1 -R

again and press <ctrl>-<c> , then run

exit

(If you’ve not used “screen” before and would like a little more background, please see http://www.stearns.org/doc/screen-for-detachable-sessions.html )

 

Detection

We’re assuming this traffic is going back and forth between the system running beacon-simulator.sh and the chosen server, and it’s being monitored by your Threat Hunting platform. If that’s the case, take a look at your list of potential threats – do you see this traffic between the client and server? Is it recognized at all as a beacon? Did the slight jitter on the timing – and the jitter on the payload size – affect the scoring so it wasn’t clearly a beacon?

 

UDP

If you want to simulate UDP traffic, add ” udp” to the end of the beacon-simulator.sh command line:

beacon-simulator 10.0.0.185 111 60 10 udp
Will connect to host 10.0.0.185, udp port 111 every 60 +/-(10/2) seconds
.....

Does your Threat Hunting platform detect this as well?

 

¹You generally want an open port; while a closed port will still have a connection attempt every N seconds, it’s immediately closed, so it looks different on the network.