How can I check if my IoT devices are infected with the Mirai worm?

Question

I've recently heard about the Mirai worm, which infects vulnerable routers, IoT devices and other internet-connected appliances with insecure passwords. Mirai is suspected of being the cause of some of the largest DDoS attacks in history:

Dyn estimated that the attack had involved “100,000 malicious endpoints”, and the company, which is still investigating the attack, said there had been reports of an extraordinary attack strength of 1.2Tbps.

The question Can I monitor my network for rogue IoT device activity? provides some useful generic tips for spotting malware on my IoT network, but how can I check if my devices are infected with the malware? Incapsula provide a tool to run which can scan for devices vulnerable to Mirai, but is there a way of autonomously checking if any devices on my network are infected (or provide real-time protection) so that I don't have to keep running the tool when I remember?

Answer 1

Detecting the infected device

These devices-turned-botnet will still function correctly for the unsuspecting owner, apart from the occasional sluggish bandwidth, and their botnet behavior may go unnoticed indefinitely.

Webroot.com: Source Code for Mirai IoT Malware Released

This tells us how the device changes its behavior. Occasional sluggish bandwidth is unfortunately a really bad indicator to be on the lookout for. The other thing Mirai does is to block ports to avoid monitoring tools to detect it.

These two features can be looked for. The first needs a very sophisticated network traffic monitoring solution and intricate knowledge about what kind of traffic you expect in your network. If your IoT device does not communicate via a WiFi connection but over 3G or other mobile telecommunication standards you are pretty much out of luck because you cannot monitor those. At least not easily and in most jurisdictions not legally.

The second Mirai feature is the thing Incapsula also scans for. If the ports are closed there is a possible Mirai infection. Since rebooting temporarily frees the device from Mirai's clutches the change in port availability in the time after a reboot can be taken as a very likely sign that the device has been compromised.

Do keep in mind, that Incapsula does not provide certainty but only gives your information about devices that are possible targets and devices that might have been infected. This is why it is important to realize that the Mirai however powerful attacks it can field it is not an unbeatable enemy on a small scope, it's even easy to prevent infections.

The next two sections will show that detecting is way too much effort compared to securing a device in the first place or securing your device on a hunch.

Recapturing your device

However, Mirai acts as an end point for a bot net and the worm is not changing the persistent memory of the IoT device. I.e. the firmware is not infected. This is the reason why a reboot and an immediate password change gives you back control over your device.

Infected systems can be cleaned by rebooting them, but since scanning for these devices happens at a constant rate, it’s possible for them to be reinfected within minutes of a reboot. This means users have to change the default password immediately after rebooting, or prevent the device from accessing the internet until they can reset the firmware and change the password locally.

Webroot.com: Source Code for Mirai IoT Malware Released

Prevent being compromised in the first place

Mirai does not hack your devices!

Mirai continuously scans the internet for IoT devices and logs into them using the factory default or hard-coded usernames and passwords.

Webroot.com: Source Code for Mirai IoT Malware Released

Mirai uses factory default logins to compromise your devices. Change the password before giving your IoT device any Internet connection for the first time and you'll live in a Mirai free zone.

If your device password cannot be changed and it's a potential Mirai target consider switching to the competition.

Answer 2

If you have any vulnerable devices on your network, you should assume they are compromised. By definition, the login credentials are public, and I believe you need to assume the firmware has been tampered with. There is no need to wait to observe communication with the command-control server or malicious activity.

Clean the device now, ensure you give every new device a new password, and scan it on installation.

Maybe the subtext is how to scan for newly discovered remote-access vulnerabilities on existing devices, but I don't read the question as asking that specifically.

Answer 3

Instead of searching for an autonomous solution. You can try to automate Incapsula's tool. Unfortunately it is a service available through a webpage button, so you must open that page and click on the button autonomously.

From the page source you can obtain information about the button itself.

<div class="btn-toolbar">
  <a class="cta-green-button scan-btn" href="#" id="mirai-scanner-scan-btn" role="button" style="max-width: 288px;margin: 32px auto 4px;">Scan My Network Now</a>
</div>

So maybe with a script you could create a periodically running task which opens the site, finds the button by the ID and clicks on it and runs a scan.

I do not know the exact way of doing this, but maybe Selenium or Mechanize Python package can be used.

Answer 4

Mirai attacks embedded linux. You would first need to get command line access to your IoT device. After that you can check the checksums of the read-only filesystem, and compare them to clean firmware versions. Sometimes companies have the original firmware online, or you can contact them for a copy. If you want to understand how firmware is usually packaged, I suggest looking into the program Binwalk. OpenWrt has good documentation about flash memory. When you flash/reflash firmware onto the IoT device, sections of the firmware (kernel, read only root filesystem, writable config section) are stored in MTD partitions on the IoT's flash chip. You can copy/download these partitions (/dev/mtdblock1 is linux example) and compare those to the original firmware, via checksums. If you fear a rootkit and don't trust the command line, you can download & examine the firmware directly off the flash chip with hardware tools, like a Bus Pirate and SOIC8 clip