IoT Botnets: Perspectives from a Residential Router
I know a lot of us are currently wrapped up in the SolarWinds and ProxyLogon events. Still, I just wanted to take a moment to quickly highlight the risk residential routers face from the propagation of IoT botnets and the problem devices present once they are infected.
To start, it’s truly amazing to see how many malicious events a residential router experiences every single day—from scanners looking for vulnerable services to exploitation attempts from all over the world. If you want to get into threat hunting and monitoring traffic yourself, I suggest installing the T-pot Honeypot by Deutsche Telekom. It’s a straightforward, easy-to-use, all-in-one solution that allows users to quickly deploy and review network events. If you are looking for a tutorial, I recommend Veronica Valeros’s blog, Installing T-pot Honeypot Framework in the Cloud. If you are interested in going a step further, you can report, track and analyze samples captured in your honeypot with URLhaus from Abuse.Ch and Intezer’s malware analysis platform.
For this blog, though, I’m going to focus on events strictly related to IoT Botnets. For disclosure, the specific residential sensor used in this blog is located in Texas on a major ISP. In February, this sensor saw millions of events. Of that, 2,227 events were related to the propagation of malware for IoT botnets. Of which, a majority of these events came from China, Hong Kong, and South Korea. But this is no surprise as the Mozi campaign has been generating a large amount of malicious traffic from Asia for quite some time now. Surprisingly, a huge amount of the malicious traffic can reach your residential device.
While one would assume that these threat actors (known as bot herders) would want to live below the radar, the fact is, most of their campaigns are very loud and noticeable, deployed in a spray and pray fashion.
On an average day in February, the residential sensor saw about 50 malicious attempts to propagate IoT malware. Still, as we can see in the graph below, some days were busier than others. These spikes, in general, can be caused by the successful and rapid spread of malware or a scanner that’s merely spamming out multiple attempts to compromise a device. Either way, these events are very noticeable and get reported for a takedown almost immediately.
Common alerts seen from the residential sensor include Mirai Variant User-Agent, WebShell Generic, and 401TRG Generic Webshell request from a signature base perspective. Below is a more detailed graph of the top 10 signatures seen for IoT malware distribution in February.
For example, this recent event below was flagged and tagged with the signature SURICATA HTTP Unexpected Request Body, which originated from Guangdong, China.
The Uri POST /soap.cgi?service=WANIPConn1 tells us that this malware is propagating via a D-Link exploit that allows an attacker to leverage a command injection via the UPnP SOAP interface in multiple D-Link devices. One of the things that stand out here is that CVE-2013-7471 is eight years old and still used to distribute one of the more notorious P2P botnets, Mozi.
Note: You can find a list of captured payloads collected from a variety of sources during February on my Github page.
Another point of interest while looking at these network events is the ports that the malware is targeting. These kinds of indicators can often help identify the device and/or service that is being targeted. For example, in February, the top 5 ports targeted by IoT malware were 80, 23, 60001, 7574, 49152.
So, what does this tell us? Other than the apparent ports, 23 and 80,port 60001 indicated that the malware is attempting to propagate and deliver a payload via a four-year-old vulnerability targeting JAWS DVR web servers.
One of my favorite indicators to look at is the User-Agent. Bot herders have egos and a sense of humor, and sometimes this is displayed via User-Agents. For example, in February, the residential sensor saw several attempts to distribute IoT malware with the User-Agent, KrebsOnSecurity. Obviously, this is not the work of Brian Krebs. But this month, the same herder has replaced the User-Agents with ImSowwyForUsingMrCrabs and HelloBadPacketZ. Likely in an attempt for attention.
Another notable User-Agent leveraged by a bot herder was XTC and part of the Hoaxcall botnet campaign in 2020. Just to note, there are infected Hoaxcall routers still online. Even after the takedown to Hoaxcall’s C2 servers, the payload is yet being distributed a year later and a subject I focused on in a blog, Ghost Bots: The Story of Hoaxcalls Failures.
Finally, once a residential router becomes infected, it can become weaponized to launch DDoS attacks, mine cryptocurrency, or leveraged as a proxy for fraudulent ad requests. For example, the herder with a sense of humor from above has been running a fairly extensive campaign for the last few months. The payloads being retrieved from 45.14.149.204, 7069f495263a57733d787745246f5fbf34f6f9164f87cad5d11a810b6c718005, is designed to abuse IoT devices for the purpose of launching Distributed Denial of Service attacks. The payload contains over twenty denial of service attack vectors and is hosted on several domains. Additional IOCs/IPs about this campaign are located at the end of the blog.
As you can see, the threat landscape directed at residential routers is one of despair. The topic, in general, opens up too many ongoing debates about who should clean up and regulate the standards of security for IoT devices and if we, as a community, should be doing more to target bot herders. One thing is certain; our industry could use more threat hunters, especially after recent events. I encourage anyone interested in threat hunting to jump right in. The community is very active and willing to help others. Regardless of skill set, the more eyes we have on the problem, the better off we will become.
IP addresses seen in the referenced campaign above:
(take into account that some attacking IP addresses are from residential devices connected through dynamic IP address pools, as such the IP could be moved to another innocent device in the mean time).
January
February
March
