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

We put together a collection of tools called “threat-tools”. At the moment, it consists of a single program, “”, 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
chmod 755 $HOME/bin/

To see the available options, run: -h
1: target ip
2: port
3: interval
4: jitter
5: optional protocol (default is tcp ; put udp here if you want that)

Examples: 9999 150 12 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 3128 60 10
Will connect to host, 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 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 3128 60 10

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

screen -S beacon1 -R

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


(If you’ve not used “screen” before and would like a little more background, please see )



We’re assuming this traffic is going back and forth between the system running 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?



If you want to simulate UDP traffic, add ” udp” to the end of the command line:

beacon-simulator 111 60 10 udp
Will connect to host, 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.



Interested in threat hunting tools? Check out AC-Hunter

Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!

Share this:
AC-Hunter Datasheet
AC-Hunter Personal Demo
What We’re up To