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
(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 )
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?
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.
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!
Bill has authored numerous articles and tools for client use. He also serves as a content author and faculty member at the SANS Institute, teaching the Linux System Administration, Perimeter Protection, Securing Linux and Unix, and Intrusion Detection tracks. Bill’s background is in network and operating system security; he was the chief architect of one commercial and two open source firewalls and is an active contributor to multiple projects in the Linux development effort. Bill’s articles and tools can be found in online journals and at http://github.com/activecm/ and http://www.stearns.org.