HAMMERTHROW is an aggressor script for CobaltStrike. It runs as an agent in the background by connecting to the teamserver and controls the listener. HAMMERTHROW accepts a defined list of domain names, that will then be randomly selected and used as the stager name, and beacon domain names. HAMMERTHROW automatically modifies the listener on a regular basis - creating an effect whereby newly spawned beacons utilize new domains.
What this meant was that when moving laterally, an operator could utilize new domains without the significant overhead of creating a new teamserver, or constantly manually modifying the listener.
CobaltStrike has always let us use the beacon domains in a round robin fashion. If a domain could not beacon out, it would move onto the next and eventually at least one domain would beacon out successfully. HAMMERTHROW is not supposed to replicate this. HAMMERTHROW is aimed to ensure that automatic randomization of the domain names is performed so that the operator can focus on the operation and create an additional layer of difficulty for the blue team to block the communications channels.
I created HAMMERTHROW because I was researching domain fronting a lot for command and control usage. Of course, we all have our favorite domains to use for each CDN provider. However, now we can just put in a large list of 1000 domains, and it will randomly select a new set of domains for configuration every 10 seconds!
There are a few variables in the script that I have added, and I will explain them here briefly.
$quiet Set to True to keep the event log quiet@domains Put in a large list of domains$num How many domains would you like to use for each spin?
Of course, the number of domains in your array must be bigger than the amount you choose in $num. This is because if you only have 3 domains and you want to use 5, it's sort of impossible right?
You can also change up the period between domain changes by modifying the
on heartbeat_10s event handler. You can set it to any of the following (https://www.cobaltstrike.com/aggressor-script/events.html):
heartbeat_10m Fired every ten minutes
heartbeat_10s Fired every ten seconds
heartbeat_15m Fired every fifteen minutes
heartbeat_15s Fired every fifteen seconds
heartbeat_1m Fired every minute
heartbeat_1s Fired every second
heartbeat_20m Fired every twenty minutes
heartbeat_30m Fired every thirty minutes
heartbeat_30s Fired every thirty seconds
heartbeat_5m Fired every five minutes
heartbeat_5s Fired every five seconds
heartbeat_60m Fired every sixty minutes
After you've edited the script
HAMMERTHROW.cna, you can proceed to running it. I usually stick it on the teamserver instead of running it on the operator machine for various reasons.
If it's ran on multiple operator machines, there's conflict.
If it's ran on the operator machine, it can lag the operator's client.
To run the script with the agent client on the teamserver type:
./agscript 127.0.0.1 50050 HAMMERTHROW <password> HAMMERTHROW.cna
The script will then proceed to connect to the teamserver, and you will see a notification in the event log as shown below:
You will proceed to see the domains being rotated on a periodic basis as shown below:
I like to keep the log as I can see exactly at what time it rotated and what beacons I was spawning or using at that moment in time.
Any newly spawned beacons, or payloads that require staging, will utilize the randomized beacon list that was present at the time of it staging. Stageless beacons will remain static and use the domains set at the time of generation.
I've got a video, check it out at https://youtu.be/LJbMy_13b7E if you're interested instead of reading.
Boot up Wireshark and have a beacon running on the server. Spawn beacons while it's running.
Set up the following filter in Wireshark so that you can see clearly what's happening:
You can also set up a new column in Wireshark to show the Server Name under Server Name Indication (SNI).
As you spawn more beacons, you can see that an entirely new set of domains are being used for new beacons. You'll also notice that the existing beacons can still communicate back because the infrastructure is still technically pointing to your server.
If you own a large number of domains, or subdomains, let's say thousands, then you can hook them up to thousands of cloud instances that can be used as redirectors. Then those redirectors all point to the same origin, your teamserver. What you could do is use HAMMERTHROW to automatically rotate randomly through those thousands of domains to distribute the domain usage for C2.
Previously if you were a defender who would discover domains and try to block them one at a time, it'll prove difficult to block. Instead, try to perform TLS inspection and look for C2 traffic patterns to determine domains in mass.