Saikin – a new IoT botnet campaign?
Since the Mirai source code release and our subsequent investigation, many variants have appeared, each with small evolutionary changes. Examples include adding SSH support, improving username and password wordlists, and adding router web management vulnerabilities (for example this Huawei exploit and these exploits on Netgear routers). Using honeypots to monitor these campaigns can be very useful and lend insight into changes in near real-time speed. We can not only see how the attack trends are changing, but also leverage them to gather new samples for analysis. Monitoring collected data and periodically analyzing trends can bring into light valuable insight that otherwise might have been overlooked. Mirai-based bots in the past have had a Japanese Manga name theme, like Mirai, Owari, Okiru, and Satori. Today we're going to look at one we've dubbed Saikin.
Honeypot Hits Tracking IoT Campaigns Over the Last Year
What caught my eye and turned my focus to this campaign was that, by looking at the logs for the past 2 weeks, I could see that there were two items that started showing up at the same time with very similar strings (SAIKIN and SAIAKINA). The difference between them seems to be that one (SAIAKINA) is used for identifying vulnerable devices and performs no malicious loading of binaries, while the other (SAIKIN) is used for dropping malware on the infected devices. The difference in the number of events can be seen in the figures below.
We dubbed this campaign Saikin due to the message shown when running the binary: “Infected By Saikin xoxo”.
In the following figure, we can see all the download options on one particular server. Interestingly, most download servers for malware will block access to their index.html in order to hide all download options. This way, if you don’t know where to go to download the binary, you will get a 404 message or forbidden access message. In this case however, we were able to download the index.html and grab all available binaries.
In this variant, binaries no longer use only XOR for evading detection. Instead, some of them are now packed using UPX. Even more interesting is that, even though there are binaries for multiple architectures, UPX packing is only used for some of them.
We can easily determine which of the files are UPX packed using the upx-ucl package in Linux.
Also of note is that the UPX packed binaries have very few detections, most of them showing up on VirusTotal with an average of 6 detections. In the case of the unpacked binaries, at the time of writing this article, none have shown up on VirusTotal. This indicates that this campaign has, so far, gone with few detections in the wild.
Diving into Saikin
If we run strings on the unpacked binary, we can easily see that the CNC server is the same as the download server. This will be confirmed later on as we try to run the binary and monitor its connections. We can discover some more Mirai artifacts by XORing the binary as well. It’s fairly easy to run a XOR bruteforce on the binary and identify some interesting strings: “dvrHelper”, “Saikin: applet not found”, “Source Engine Query”, “Infected by Saikin xoxo”. If you remember, dvrHelper was the name Mirai binaries had to be called to execute properly. Source Engine Query is a protocol developed by Valve and was used as a vector of attack for many distributed denial of service (DDoS) attacks seen last year. These strings not only assist our detection engines, but provide insight into code reuse and changes in these IoT bots over time.
The fact that it downloads all binaries and executes them all is of no surprise; there have been other campaigns that used the same technique of spray and pray. The interesting item is that the binaries are run using an argument “Saikin.scan”. This seems like an artifact from the original Mirai source code, where it would accept an argument and send it to the CNC server to “identify” itself to the server. However, in practice, we haven’t seen any binaries that did this in the past, and this is the first one to leverage this feature. Also, this indicates that filename checking for execution no longer is enabled since the file is not renamed to "dvrHelper" prior to execution.
One would expect since it is explicitly specified as an argument, it would impact the way it runs somehow. However, executing the binary with or without it seems to make no difference as to behavior. The only difference is that using the argument will cause the bot to send the string to the server on the CNC channel reporting. The scanning module works similar to Mirai. Once it starts running, it will start scanning for targets, by sending SYN packets on port 23 and 2323: for every 10 SYN packets to port 23, it will send one to port 2323. At the same time, it will start communicating with the CNC server and use \x00\x00 as a heartbeat.
Since the initial analysis of this botnet, we noticed that on Friday, March 23rd, the botnet stopped hitting our honeypots, the CNC has been taken offline, and the download URLs have stopped working. Since then, we noticed a couple of hits in our honeypots suggesting that the operator added a new url download link, this time for a shell script, which ultimately would try to download the original samples from the original links.
We're still researching this one, but it’s interesting to see how using an old trick like a UPX packer is now used in IoT campaigns and, even worse, providing such good results in evading anti-virus solutions. These investigations allow us to understand how IoT botnet operators work and evolve, so we can create the necessary infrastructure to trace and block their attacks. As a result, we’re able to protect our customers better and better. Customers of many Ixia products (like ThreatARMOR and BreakingPoint) benefit from this type of research, where we identify the command and control infrastructure used by the attackers.
LEVERAGE SUBSCRIPTION SERVICE TO STAY AHEAD OF ATTACKS
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia test platforms.