Ammar JokhadarMost of the samples I work with, as a reverse engineer and malware analyst, are various x86_64 Windows binaries — packed, obfuscated, and always a well-known playground. However, in recent times, the picture has changed. The number of incidents I deal with continues to grow toward IoT/bots, and nearly all of them belong to the same nagging family: Mirai.
I’ve known assembly language (ARM) for a very long time. I studied it; I practiced it; I even prototyped and developed projects with it — yet never truly used it. It was like having a driver’s license without a car. Now? The heavy accelerator foot is mine, and I’ve been launched into the dirty guts of one of the most notorious botnets to have ever touched the net.
Mirai malware and its history
Mirai is an infamous malware that was found in 2016 and is intended to target Internet of Things (IoT) devices like IP cameras, routers and DVRs. It searches the internet to identify those systems running on weak or default usernames and passwords, subsequently commandeers them into a huge botnet whose initial use is usually to carry out Distributed Denial of Service (DDoS) attacks. Mirai-based attacks also put the technology into the spotlight when they were applied to disable key services such as Twitter, Netflix, and GitHub as part of Dyn DNS attack, one of the largest DDoS attacks on record at the time. Its source code was later published the same year resulting in an explosion of copycats and derivatives. Although it has existed for several years, Mirai is still alive and ever-changing to date, and thus it is one of the most prolific and adaptive malware families in the IoT threat environment.
Diving into the Sample: First Impressions
This time, I found a sample of the Mirai botnet compiled for ARM architecture. It was obviously labeled by antivirus engines as Mirai and fits perfectly with what was observed in dynamic analysis, threat intelligence feeds, and reverse engineering notes. The best thing about Mirai is its multi-architecture support — it has ARM, MIPS, x64, and so on, making it very versatile and compatible with most IoT devices.
The main insights I had:
- Packed : The ELF binary is packed with UPX, an old-school packer used to obfuscate the actual code and slow down the analysis process by hiding it.
- Startup Mechanisms: Rather than simply relying on primitive persistence, this sample installs hidden scripts and alters system files to ensure it persists across reboots or partial wipes.
- Network Indicators: The sample performed GET and POST requests to multiple servers, most likely its command-and-control (C2) infrastructure.
Running it through VirusTotal.
Mirai is specially crafted to use a number of known exploits on embedded devices to gain maximum reach and penetration rate. As an example, it aims at CVE-2017-17215, a remote code execution vulnerability in huawei routers, which gives attackers the possibility of executing arbitrary code on the device merely by sending a crafted packet to exploit the vulnerability. Besides that, the Mirai types have evolved to tap into other vulnerabilities like CVE-2004-0790, CVE-2005-0068, CVE-2018-10561 and CVE-2014-8361, making it able to subvert a wide range of Linux devices. Mirai has compiled exploits to these CVEs directly into its own code and therefore can automatically locate vulnerable systems on the internet and infect them without human assistance, allowing it to be extremely efficient at building, as well as sustaining massive botnets.
The main reason why Mirai performs these commands is to eliminate and purge the device firewall rules so that whatever traffic is using itself and therefore the malicious traffic is not blocked or detected by the firewall policies. In removing most defenses that might block remote control of or contact to a command-and-control server, the Mirai removes most likely defenses by flushing iptables rules, disabling firewall services, such as ufw and firewalld, and any custom filtering rules applicable to both IPv4 and IPv6. Not only does it assist Mirai in its continued presence on the infected machine but this also simplifies either an attempt at an attack or infection of a further system due to the lack of protection that would otherwise guard against unauthorized or malicious network activity.
Static analysis
Along with the file level, one can check the file in a hex editor or analyze its printable strings and see clear signs that the binary has been stashed with UPX. Additionally, calculating the file’s entropy can offer further evidence of packing, since data that is packed by binaries normally have a high entropy value due to compression and obfuscating done by packers such as the UPX. High entropy and UPX signatures give credence to the fact that the executable is obfuscated in attempt to make it harder to analyze and detect.
Unpacking UPX binaries is usually straightforward because UPX provides an official tool for decompressing files packed with it—running the upx -d <binary> command will usually restore the original binary for analysis. However, it is important to note that some malware authors deliberately modify the UPX packer or add extra layers of obfuscation to hinder such automated unpacking, which can make the process more complex and require additional expertise or manual techniques. Fortunately, in our case, the sample was packed with an unmodified version of UPX, so unpacking it was quick and effortless.
Running Strings
Once a binary gets unpacked and is then examined using the strings utility, one can spot a range of disclosing artifacts. The declarations of service unit files like Type=simple, ExecStart=%s, and Restart=always, which are formatted for systemd, indicate that the malware tries to achieve persistence by installing itself as a system service. In addition, the commands used with cron, such as modifying the contents of files in /etc/cron.d/ and manipulating shell scripts, denote the use of scheduled activities as a secondary persistence method. The frequent execution of its payload—irrespective of system restarts, reboots, or service failures—also reflects the use of commands aimed at enabling and restarting cron and crond services via both systemctl and service commands. The inclusion of default Unix directories and paths, as well as HTTP POST requests, demonstrates the malware’s capability for both file manipulation and network communication. In sum, all these strings highlight the multi-faceted nature of the malware in achieving persistence and facilitating potential command-and-control operations.
Beyond just service and persistence details, running strings on the unpacked binary can reveal even more about what the malware is actually doing. For instance, you might come across snippets of bash scripts that the malware runs—sometimes these scripts lay out exactly how it sets up its environment or spreads itself further. You can often spot the names of functions it calls, which hints at actions like file operations or ways it tries to connect across the network. It’s also common to find user-agent strings, and every so often these will even include the attacker’s team name or campaign, offering clues about who’s behind the threat. Sometimes, you’ll see detailed HTTP headers like
$>strings unpacke.elf | grep "config"
Authorization: Digest username="dslf-config", realm="HuaweiHomeGateway", nonce="88645cefb1f9ede0e336e3569d75ee30", uri="/ctrlt/DeviceUpgrade_1", response="3612f843a42db38f48f59d2a3597e19c", algorithm="MD5", qop="auth", nc=00000001, cnonce="248d1a2560100669"Which can be tied back to well-known vulnerabilities (CVEs) the malware is exploiting. All told, these extra strings help paint a much clearer picture of how the malware operates, the techniques it uses, and sometimes even who wrote it.
Disassembly
After disassembling the Mirai ARM binary, it is important to point out some of its salient attributes. The binary is statically optimized to be fast and small, and generally has its main logic written in C and optimized for embedded Linux hardware. Decompiling, it is known that Mirai runs a wave of preliminary examination, including ascertaining architecture and gathering device data. It is quite aggressive in clearing firewall rules and shutting down security services, as is evidenced in its system calls to many iptables and process control functions. In the malware, the command-and-control (C2) server addresses and part of the operational commands in the binary are hidden using a one-byte XOR-based string obfuscation. They have procedures to scan their networks for vulnerable devices where they can brute-force Telnet credentials via hardcoded usernames and password lists. When it has a base, Mirai is linked to its C2, then awaits and listens to attack advice, and can perpetrate different forms of DDoS assaults by using direct constructions of raw network protocol packets. Interestingly, Mirai does not target some IP ranges and devices, and some of such selected IP ranges are associated with large companies and government agencies, which is evident in the disassembled logic with blacklists. Supplement persistence layers: Mirai has nothing; only the re-infection scripts operate on the restart. On the whole, the disassembly clears up the case that Mirai is an efficient, straight, and goal-oriented ARM malware engaged in large botnet activity. I might drop a full breakdown video of the disassembly and analysis soon, so keep an eye out.
