Sign up to our newsletter
Today we are releasing a research paper about a malware family that primarily targets Linux-based consumer routers but that can infect other Linux-based embedded systems in its path: Dissecting Linux/Moose. This blog post will summarize a few elements of the full report.
Linux/Moose is a standard Linux executable taking the form of a statically-linked ELF binary that was stripped of any debugging symbols. It relies heavily on multithreading for its operation, using as many as 36 threads. This malware can be classified as a worm since most of its threads are used in its attempt to find and infect other devices automatically. Here is a diagram that highlights Moose’s capabilities:
Our monitoring of the botnet indicates that this threat is used to steal unencrypted HTTP Cookies on popular social network sites and perform fraudulent actions such as non-legitimate “follows” and “views” on the same sites via a SOCKS proxy server built into the malware.
Here is an example we captured of an HTTP request going through the proxy operated by the malware:
Notice how the server upgrades the connection to HTTPS right away. Almost all of the traffic is encrypted via HTTPS so we can’t state precisely what actions were performed by the operators.
We monitored an infected host for about a month and noticed traffic going to the following social network sites:
We were able to ascertain the domain of the targeted social network using the certificate’s subject field of the TLS handshake of the HTTPS traffic.
Here are the requests going daily to social network sites from a single infected router:
Below is depicted which social networks were the most targeted during that interval:
During our analysis we often asked ourselves, “Why so much effort in order to interact with social networks?” But of course there is a market for follows, likes, views and whatnot. The operators of this botnet are generating revenue by performing social network fraud. The consumer routers under attack provide a means to proxy malicious traffic from the operators through to the social network sites leveraging highly reputable Internet Service Providers’ (ISPs) IP addresses.
The threat displays out-of-the-ordinary network penetration capabilities compared to other router-based malware. Moose also has DNS hijacking capabilities and will kill the processes of other malware families competing for the limited resources offered by the infected embedded system. More details are available in the report, including details about the network protocol used to communicate with the Command and Control servers (C&C).
Along with our whitepaper, we are releasing some resources to the community. First, we have decided to release on our malware-research github repository all the code we’ve developed in order to monitor this threat. We think that there is little value in keeping these scripts to ourselves. The tradeoff here is that this is code that was produced from a research lab and it isn’t as polished as the code that ends up in our finished products. We hope that our peers in the industry, the Linux embedded community, and future malware analysts will get value out of it.
Second, we are looking for help in confirming which vendors and models are affected. We provide instructions on how to confirm whether Linux/Moose could infect your own devices. We will keep this list of affected vendors updated.
Finally, Indicators of Compromise (IoCs) are also available. They include all hardcoded C&C IP addresses, the current list of dynamic C&C IP addresses, instructions on how to confirm infection, the hashes of malicious files, and Yara rules. Instructions are also provided if you want to verify whether some arbitrary files are Linux/Moose binaries.
Reboot the affected device then change its password as soon as possible. Keep in mind, however, that the compromised system was accessible via credentials that the operators knew, that they were aware of its IP address and they had means to access its interactive console. They might have had manual access, which means that further infection is possible, including permanent firmware modifications (the link is in German). A factory reset, firmware update or reinstall and password change is probably best.
Change default passwords on network equipment even if it is not reachable from the Internet. Disable Telnet login and use SSH where possible.
Make sure that your router is not accessible from the Internet on ports 22 (SSH), 23 (Telnet), 80 (HTTP) and 443 (HTTPS). If you are unsure about how to perform this test, when you are at home, use the “common ports” scan from the ShieldsUP service from GRC.com. Make sure that the ports mentioned above receive a Stealth or Closed status.
Running the latest firmware available from your embedded device vendor is also recommended.
The white paper with all the technical details is available for download on WeLiveSecurity.
Author Olivier Bilodeau, ESET