Accidentally Crashing a Botnet
Executive summary
Akamai researchers have continued their research on KmsdBot, a cryptomining botnet, and witnessed the authors accidentally crash it.
In our controlled environment, we were able to send commands to the bot to test its functionality and attack signatures.
As part of this analysis, a syntax error caused the bot to stop sending commands, effectively killing the botnet.
Since this particular botnet doesn’t seek persistence on a system, it can only continue its mission if it reinfects the system.
Introduction
Earlier this month, Akamai Security Research released a blog post about KmsdBot, a cryptomining botnet that infected victims via SSH and weak credentials. We promptly analyzed and reported on this botnet after it infected one of our honeypots.
However, after that publication, we continued to monitor the botnet, and we have some updates to share in this blog post — like the fact that we rendered it useless. In this post, we will outline the steps we took to inspect KmsdBot, which led to our ability to execute our commands and ultimately led to its demise.
C2ing the C2
The most lethal element of any malicious entity is the ability to gain command and control (C2). Since KmsdBot had C2 functionality, we wanted to test various scenarios related to that. Part of that testing was modifying a recent sample of KmsdBot to talk to an IP address in RFC 1918 address space.
This allowed us to have a controlled environment to play around in — and, as a result, we were able to send the bot our own commands to test its functionality and attack signatures. Interestingly, after one single improperly formatted command, the bot stopped sending commands. Naturally, we began an investigation. It’s not every day you come across a botnet that the threat actors themselves crash their own handiwork.
How we found it
Fig. 1: Disassembly of the sys.main.connect() function
You can see that the string slice is stored at memory location 0x00632f19. We can jump to that address in the binary and modify its contents to point at a network address in RFC 1918 space, namely somewhere in 192.168.0.0/24, which we control.
This way we can act like the C2 and send sample attack commands to direct the attack traffic to a target where we can log the network traffic.
Fig. 2: Writing the address in hex .861.291 backward because of endianness
So, our new C2 is 192.168.0.31 on port 57388 (Figure 2). We know the C2 communicates in clear text, so sending the malware commands can be done using Netcat. We then set up two virtual machines: one on which to detonate the malware and the other to use as our C2.
During the testing, we noticed the botnet stopped sending attack commands after observing a single malformed command that arrived. The command:
!bigdata www.bitcoin.com443 / 30 3 3 100
A keen observer will notice the lack of space between the target website and the port. The bot doesn’t have error-checking built into its code to verify that the commands are properly formatted.
Because of this, an improperly formatted command will cause the Go binary to crash with a stack trace stating an “index out of range” error. This is because the wrong number of arguments were supplied. We tested this theory with our C2 and bot setup (Figure 3).
Fig. 3: Emulating the C2 and reproducing the malformed command being sent
Fig. 4: The bot crashed because the wrong number of arguments were supplied
This malformed command likely crashed all the botnet code that was running on infected machines and talking to the C2 — essentially, killing the botnet. Because the bot doesn’t have any functionality for persistence on an infected machine, the only way to recover is to re-infect and rebuild the botnet from scratch.
Conclusion
It’s not often we get this kind of story in security. In our world of zero-days and burnout, seeing a threat that can be mitigated with the coding equivalent of a typo is a nice story. This botnet has been going after some very large luxury brands and gaming companies, and yet, with one failed command it cannot continue. This is a strong example of the fickle nature of technology and how even the exploiter can be exploited by it.
The goal of Akamai Security Research is to track, detect, document, and publish new discoveries to protect the security and stability of Akamai, Akamai’s customers, and the internet as a whole. We will continue to monitor these attacks and update this blog accordingly. For real-time security research updates, follow us on Twitter.
