A new botnet recently started recruiting IoT devices. The botnet uses hosted servers to find and infect new victims leveraging one of two known vulnerabilities that have become popular in IoT botnets recently:
- CVE-2014-8361 “Realtek SDK Miniigd UPnP SOAP Command Execution” vulnerability and related exploit.
- CVE-2017–17215 “Huawei Router HG532 – Arbitrary Command Execution” vulnerability and related exploit.
The malware also uses similar techniques as seen in the recently discovered PureMasuta, which had its source code published in an invite-only dark forum as of late.
Our investigation led us to a C2 server hosted under the domain ‘sancalvicie.com’ of which the site provides GTA San Andreas Multi-Player mod servers with DDoS Services on the side. Below is a screenshot of the services with the details:
The SAMP option provides a multi-player gaming service for GTA San Andreas and explicitly mentions the protection against Source Engine Query and other DDoS floods.
The Corriente Divina (“divine stream”) option is described as “God’s wrath will be employed against the IP that you provide us.” It provides a DDoS service with a guaranteed bandwidth of 90-100Gbps and attack vectors including Valve Source Engine Query and 32bytes floods, TS3 scripts and a “Down OVH” option which most probably refers to attacks targeting the hosting service of OVH, a cloud hosting provider that also was a victim of the original Mirai attacks back in September 2016. OVH is well known for hosting multi-player gaming servers such as Minecraft, which was the target of the Mirai attacks at the time.
Imagine my surprise when I was redacting my initial report for the blog and I visited the site again and found the DDoS attack service description to have changed – they’ve upgraded their service!
Note the new mention of “Bots” and the increased guaranteed DDoS volume of 290-300Gbps. They must be confident of their new botnet they started to deploy just two days ago…
On Jan 30th our IoT honeypots registered multiple exploit attempts from distinct servers, all located in different hosting centers in Europe.
The exploits based on CVE-2014-8361 try to perform an RCE through three individual SOAP posts to port 52869 using the URL /picsdesc.xml
The CVE-2017–17215 based exploits use a POST to /ctrlt/DeviceUpgrade_1 on port 37215 and a slightly different command sequence to download and execute the malware, first attempting to kill any competing bots that might be resident on the device:
The malware binary is called ‘jennifer’ and was in all occurrences downloaded from the same server 220.127.116.11 which is hosted at a different provider compared to the provider of the exploit servers.
The download server hosts samples for MIPS, ARM and x86, all very recently uploaded:
IOCs for the samples at time of analysis:
Untypical for IoT botnets we have witnessed in the past year, this botnet uses servers to perform the scanning and the exploits. Nearly all botnets, including Mirai, Hajime, Persirai, Reaper, Satori and Masuta perform distributed scanning and exploiting. That is, each victim that is infected with the malware will perform its own search for new victims. This distributed scanning provides for an exponential growth of the botnet, but comes at the price of flexibility and sophistication of the malware itself.
Without scanning and exploit payloads, the bot code itself becomes unsophisticated and lighter on the delivery. At the same time, centralizing the scan and exploit functionality provides the maintainers with more flexibility to add and improve the functionality as they go. The scan and exploit functionality can also be coded in higher level languages such as Python or Go and leverage the much richer ecosystem of modules and libraries without fear of impacting the size of the bot. They don’t even have to limit themselves to scripting or programming and can leverage whatever tools are available to create an integrated and automated scan and exploit system.
When providing scanning and exploit capabilities in the bot itself, it must (or should) be implemented in C or another compiled language and should not expect any of the dependencies to be present on the multitude of devices and platforms. For every statically linked library that increases the richness of the core language, the size of the bot and also its fingerprint increases. By identifying the libraries linked with a malware, it is easier on the security researchers to reverse and interpret exploits or techniques used by the malware.
Less nodes scanning and exploiting also means the botnet is less noisy overall and less probable that it will get detected by honeypots. Moreover, they stay under the radar of the autonomous PDoS botnet known as BrickerBot. At the same time, it makes it more difficult for researchers to estimate the size of the botnet without having access to the command and control servers. Finally, the impact on the resources, including the bandwidth of the network connection of the victims will be minimal until the bot is actually instructed to perform an attack.
The drawback of the central approach is a less than linear growth with the number of deployed servers. Much slower compared to the exponential growth rate of and less aggressive than distributed scanning botnets.
Our much denser global Deception Network confirms the global reach of each of the scanning and exploit servers. When filtering on the IP addresses of the exploit servers we discovered SYN scans directed at the port corresponding to the specific exploit the server was equipped with. This confirms the mass scan and surgical approach to exploit in order to not create too much noise and stay undetected.
Upon execution, the Jennifer binary forks three processes and writes the below message to the terminal before exiting.
The three forked processes have their names obfuscated in the process table much like Mirai does. The malware is also protected with anti-debugging detection to prevent running it with tracing or in a debugger. All processes are listening to a port bound to localhost while one for the processes opens a TCP socket to the command and control server located at 18.104.22.168 on port 127. The TCP session is kept alive for the duration of the process’ existence.
Strings in the binary have been obfuscated:
The message “gosh that chinese family at the other table sure ate a lot” which is printed to the terminal is a nice gift from the author(s). The string is 58 characters long and provides a good starting point for finding the obfuscation algorithm and key without having to go through a more painful and lengthy reversing. In the C pseudo code reversed from the binary it is easy to locate a candidate string with the exact same number of characters:
Some very basic cryptanalysis with Python soon revealed the obfuscation algorithm to be a simple XOR with a fixed key 0x45:
Applying the XOR with 0x45 on the obfuscated strings reveals their plain text version:
There is still the question on how to get the string that contains the hostname of the C2 server behind IP 22.214.171.124 which we witnessed earlier. The reverse domain is of no use for making sensible guesses to attribute the botnet:
The string containing the hostname can be found in the reversed pseudo code below:
Passing the string through the XOR with 0x45 does not produce the expected results. Some brute forcing helped us find the key 0x22 – this same XOR obfuscation with the exact same key was used to obfuscate usernames and passwords in PureMasuta – coincidence considering that PureMasuta’s code was shared on an invite-only hacker forum?
Ultimately, we found by XORing with 0x22 the hostname of the C2 server to be ‘skids.sancalvicie.com’.
Verifying the hostname:
This domain is registered by an organization going by the name of ‘Calvos S.L.’
Upon execution, the malware phones home to its hardcoded C2 server located by the hostname ‘skids.sancalvicie.com’ using a TCP session on port 127. The malware sends an initial byte sequence “0x00 0x00 0x00 0x01 0x07” followed by the string that was passed as a first argument to the command line to execute it. In the case of the Realtek exploit, this argument is ‘realtek’. After this initial sequence, the bot and the C2 server are passing back and forth packets with a payload of two null-bytes to keep the session alive.
The C2 server also seems to provide a command line interface, listening on the same port 127. When the initial byte after session establishment is not 0x00, the server responds with a prompt for login:
The reversed code has indicators of a Valve Source Engine Query attack payload, the same attack vector what was included in the original Mirai code, which had its source published back in October 2016.
Investigating deeper into the domain ‘sancalvicie.com’ the answer to the potential Source Engine Query attack payload was pretty soon revealed as the website provides GTA San Andreas multiplayer servers and explicitly mentions its “Anti Query Flood” protection. As a side service, the site also provides DDoS services including the Valve Source Engine Query flood attack.
This brings us to believe that the botnet is being built by the San Calvicie hacker group and will be served up through their Clearnet website. The San Calvicie hacker group has been the talk of some threads in gamer forums in relation to DDoS attacks here and here.
Should you be concerned?
Unless you frequently play GTA San Andreas, you will probably not be directly impacted. The botnet is supposed to serve a specific purpose and be used to disrupt services from competing GTA SA multiplayer servers. I do not believe that this will be the botnet that will take down the internet! But it does contain some interesting new evolutions and it adds to a list of IoT botnets that is growing longer and faster every month! That said, there is nothing that stops one from using the cheap $20 per target service to perform 290Gbps attacks on business targets and even government related targets. I cannot believe the San Calvicie group would oppose to it.
Can we take JenX down?
As of this morning, we received positive replies on some of the abuse notifications that we filed yesterday. Two European providers took down the exploit servers hosted in their datacenters. I can confirm there are still active servers and the command and control server is still alive as I write this. Basically, the botnet is still operational and we only impacted its growth rate.
At the same time, by our actions, we sent the hackers the message that they should get better if they want to hide from us! We will not tolerate anyone starting to build their own weapons of massive destruction and be successful without investing skills and money. By trying to enforce a higher threshold, I believe we can demotivate mister everybody to get into the business of IoT botnets, and that is, agreed, a rather small, but a victory none the same.
JenX, in particular, can be easily concealed and hardened against takedowns. As they opted for a central scan and exploit paradigm, the hackers can easily move their exploit operations to bulletproof hosting providers who provide anonymous VPS and dedicated servers from offshore zones. These providers do not care about abuse. Some are even providing hosting services from the Darknet. If the exploit servers would be move to the Darknet, it would make it much more difficult to track down the servers’ location and take them down. I witnessed at least one IoT botnet using such techniques in the past year and it was BrickerBot.