Following Mirai: How Trojans Infect IoT Devices

It’s time to retire the old joke that to get malware running on Linux, you first have to compile it from source, make sure all the right libraries are installed, and only then try to launch it with root privileges. Today, the market is flooded with smart devices running Linux, making them a favorite target for malware creators. But why are these devices so attractive, and how do these malicious programs work?

Why IoT Devices Are Prime Targets

For a modern trojan to be effective, it needs to easily infiltrate a system, maintain a stable internet connection, and remain undetected for as long as possible. IoT devices—like routers, TV boxes, network storage, media centers, and single-board computers—fit these criteria perfectly. They’re usually always online, making them ideal tools for launching DDoS attacks.

Infiltration is often easy. Most IoT device owners are everyday users who treat these gadgets like any other household appliance, rarely changing default settings. As a result, factory-set logins and passwords make brute-forcing access child’s play.

As for stealth, few people think to look for malware on a TV box or router, especially since antivirus solutions for such devices are rare, and remote checking is difficult for the average user. Many even believe Linux is immune to malware, allowing trojans to operate freely and undetected.

Manufacturers also share the blame: many smart devices with known firmware vulnerabilities never receive updates, making even old exploits highly effective. The odds of compromising such devices are much higher than for regularly updated Windows PCs or Linux servers.

Why Attackers Target IoT Devices

Malware authors typically use IoT trojans for three main purposes:

• DDoS bots: These devices flood target servers with network packets on command. While one infected device isn’t much, a network of them can be devastating.
• SOCKS proxy servers: Attackers use compromised devices to anonymize their internet activity.
• DNS hijacking: Some trojans change DNS settings on routers to inject ads into users’ browsing sessions. The user’s computer remains clean, so antivirus scans show nothing.

Resetting DNS settings manually doesn’t help—after a reboot, the trojan restores its changes. Only a factory reset or firmware reinstallation can fix the issue, which is daunting for most users. Occasionally, IoT devices are used for cryptocurrency mining, but this has become less common as the crypto market has cooled.

How Trojans Infect IoT Devices

Security researchers use honeypots to study how IoT trojans spread. Typically, attackers connect to a device via SSH or Telnet, brute-force the password, disable the firewall (iptables), find a writable folder, upload the malware for the device’s architecture, and launch it.

Attackers maintain ready-made malware builds for various architectures: ARM, MIPS, SPARC, M68K, SuperH, PowerPC, SH-4, and more. On some devices, they set the trojan to auto-start by editing /etc/rc.local and use /etc/cron.minutely to monitor and restart the process if needed.

Because many users never change default credentials, brute-force dictionaries are simple. Here are some of the most common SSH and Telnet login/password combinations used to hack devices:

• SSH logins: ubnt, user, oracle, bin, support, postgres
• Telnet logins/passwords: root/xc3511, root/vizxv, root/anko, root/5up, root/XA1bac0MX

These combinations are often used to target the admin panels of surveillance cameras and other devices. Attackers also try common logins like admin, test, and telnet.

Some trojans automate the process further by extracting host information from files like ssh/known_hosts or bash_history and attempting to brute-force those hosts. Others simply generate random IP ranges and try to connect to standard SSH and Telnet ports, creating a lot of unwanted traffic.

The Rise of Mirai

About three years ago, there were at least a dozen different IoT malware variants, including Fgt, Mrblack, Mirai, and various DDoS bots. But after Mirai’s source code was leaked in September 2016, countless clones flooded the market, pushing out most competitors. Variants like BrickBot, Sora, Wicked, Omni, and Owari are all based on Mirai, each with new features added by different authors.

How Mirai Works

According to researchers Sam Edwards and Ioannis Profetis from Rapidity Networks, Mirai infected over 380,000 smart devices worldwide in 2016, causing numerous high-profile DDoS attacks. Once the source code was public, both security experts and malware authors began studying and modifying it.

Mirai’s code borrows from earlier DDoS bots, especially the Fgt family dating back to 2014. Early Mirai versions were statically compiled for different hardware architectures using the uClibc.so library for embedded systems. The trojan loaded its configuration into memory, with some strings (like the command-and-control server address) encrypted in the ELF file and decrypted at runtime.

One notable feature: Mirai could kill processes of competing bots by scanning the /proc/ directory. The process names were listed in the config, but a bug meant that if a name was split across a buffer boundary, it was missed. To avoid killing itself, Mirai created a .shinigami file in its directory; if found, the process was spared. However, Mirai also had a built-in lifespan—after a week, it would automatically terminate.

Early Mirai could execute about ten commands, including establishing or closing TCP connections and launching various floods (HTTP, UDP, UDP over GRE, DNS flood, TSource Query Flood). When connecting to its command server, Mirai reported the infected device’s IP, MAC address, and architecture, then awaited commands, each executed in a separate process with a set lifespan.

If multiple commands arrived at once, they were executed sequentially. DDoS commands could target multiple hosts, with Mirai constructing and sending packets as specified, then moving to the next target. For DNS floods, Mirai sent 100 random domain queries per cycle, easily overwhelming servers with just a hundred bots.

Operators could fine-tune attack parameters, such as TCP flags, packet size, target port, and more. Mirai could also flood targets with encapsulated GRE packets using Transparent Ethernet Bridging, generating random MAC addresses for both sender and receiver.

Mirai included a vulnerable host scanner (borrowed from Fgt) that worked in four stages: scanning for hosts, brute-forcing logins, sending a shell script to compromised devices, and downloading the appropriate binary. The scanner created 256 data structures with random IPs (excluding private ranges), attempted connections, and reported results to the command server. If successful, it used wget to download a shell script to /tmp/, which then fetched the trojan binary, enabling Mirai to spread automatically and build its botnet.

Mirai Evolves

Like any software, Mirai evolved over time. In the summer 2016 version, the config was stored in a static memory area for stability, and decrypted strings were re-encrypted after use. The bug with process name boundaries was fixed, and the random value generator was rewritten. Mirai began determining the infected device’s IP by querying Google’s DNS server instead of its own command server. It also learned to ignore SIGINT signals to prevent users from stopping it.

New features included changing the command server address via SIGTRAP and processing commands one at a time to avoid queues. Mirai added its own local server, binding a PF_INET socket to port 48101 on localhost. If it couldn’t create the socket, it killed the owning process to avoid hanging. Security experts recommended blocking port 48101 to disrupt Mirai’s server.

Self-protection was improved: instead of the .shinigami file, Mirai checked the process ID and avoided killing itself. DNS Amplification attacks were added, and HTTP floods were temporarily removed (but later returned).

The version leaked on hackforums could disable the system watchdog timer to prevent automatic reboots, and the process name was randomized to make detection harder. After launching, Mirai deleted its own executable from disk. If it found a process named .anime, it not only killed it but also deleted its executable—suggesting a rivalry with another bot’s creators. The x86 version had a bug with the binary name, but the trojan still worked and offered a wide range of features.

The Mirai Legacy

Mirai’s leaked source code spawned countless clones, each adding new features. One version implemented a Domain Generation Algorithm (DGA) from the Ranbyus trojan, allowing Mirai to generate new command server addresses automatically. This made botnets more resilient—if one server went down, the bots could connect to another.

Later versions added a local proxy server, self-updating capabilities, and encrypted communications with the command center. Mirai also began using exploits for known Linux IoT vulnerabilities. Some enthusiasts created their own Linux trojans based on Mirai, like the infamous BrickBot, which exploited vulnerabilities CVE-2018-10561 and CVE-2018-10562 and could “brick” devices by running destructive shell scripts.

Thanks to its open-source code, Mirai remains the most popular IoT malware family. Only unique creations like Hajime can compete—but that’s a story for another time.