Inside Morte Loader: How Loader as a Service Builds Modern Botnets

Morte is a Loader as a Service (LaaS) that turns vulnerable SOHO routers, IoT devices and web applications into a flexible botnet platform. It does not focus on one payload family. Instead, it offers a loader that other actors can rent and use to deliver Mirai, RondoDoX, cryptominers or backdoors, based on the value of each compromised device.

In our new whitepaper “Morte Loader and the Rise of Loader-as-a-Service in 2025,” we track how Morte gains access, deploys a multi-architecture loader, fingerprints devices, and then hands them off to paying customers inside a three tier cybercrime model.

Key points / TL;DR

• Morte is a Loader-as-a-Service that targets SOHO routers, IoT devices and vulnerable web apps to build multi purpose botnets.
• Initial access uses known CVEs, default credentials and brute force against web panels and network gear.
• A small shell bootstrap script fingerprints the device and downloads the right Morte binary for its CPU architecture.
• The loader establishes HTTP based C2, cleans traces, adds persistence and kills rival botnets, miners and tools.
• Affiliates then deploy modules such as Mirai, RondoDoX, cryptominers or backdoors depending on device value.
• The operation follows a three tier cybercrime model with infrastructure operators, botnet customers and end users of DDoS and access services.
• Infrastructure rotates fast, with open directories that keep the same structure but change file names and binaries often.

This blog gives a high level view. The full IoC set, ATT&CK mapping and YARA rules are available in the whitepaper.

What is the Morte Loader

In recent months, we observed a campaign that targets:

• SOHO routers
• Vulnerable IoT devices
• Public facing web applications

These systems act as the entry point for Morte, the loader at the center of the operation. After initial compromise, operators deploy tools that collect data from the device and then pull in payloads such as Mirai, RondoDoX or miners, depending on device resources and connectivity.

Unlike many classic botnets, Morte follows a service model:

• Level 1 operators run the core infrastructure and control panels.
• Level 2 customers build and manage their own botnets on top of this infrastructure.
• Level 3 actors buy DDoS power, access to networks or stolen credentials that come from these botnets.

This separation of roles lets less skilled actors launch complex campaigns with rented tooling and ready made infrastructure.

How a Morte attack works

Morte attacks follow a six step modus operandi, from broad internet scanning to tailored payload deployment.

Scan for vulnerable devices
Morte operators scan the internet for exposed SOHO routers, IoT gear like gateways and cameras, and public web applications with remote code execution or command injection bugs, building large target lists from known exploits and bad configs on edge devices.

Exploit routers, IoT and web apps
On promising targets, they try weak or default credentials such as admin:admin, abuse router features like NTP or Syslog for command injection, and use known RCE bugs such as CVE-2019-17574, CVE-2019-16759, CVE-2012-1823 and WebLogic exploits, all to gain a shell and run a bootstrap script.

Download tools and prepare the environment
After exploitation, a shell script prepares the ground by using or dropping busybox, then using wget, curl or tftp to fetch Morte binaries for several CPU architectures, making them executable, running the right one and often deleting it to reduce traces, so the device now runs the loader.

Load and fingerprint the device
The Morte agent fingerprints the system by collecting MAC address, firmware, hostname, open ports, services and hardware details, sends this telemetry to the C2, and keeps a beacon running so operators can decide whether to use the device for DDoS, cryptomining, access resale or other tasks.

Cleanup and persistence
While it talks to C2, Morte removes temp files and shell history, clears logs where possible, installs scripts in boot or logon paths for persistence, and protects its foothold by scanning processes, checking /proc and walking temp paths like /tmp, /var/tmp, /dev/shm and /run to find and kill rival botnets or miners.

Post exploitation and payload choice
After profiling, the attack moves into a Loader as a Service phase where many customers can push their own payloads; based on CPU, memory, bandwidth and network position, devices receive different malware families such as Mirai, RondoDoX, miners or backdoors, and become DDoS nodes, mining rigs or entry points for further intrusion.

RondoDoX, Mirai and other payloads

The Morte ecosystem ties into Mirai style botnets at both infrastructure and post exploitation stages. Many binaries reuse Mirai-like naming patterns such as <name>.<architecture>, which often causes mislabeling even though the code and business model differ. RondoDoX is the main payload here, a modular botnet that hits layers 3, 4 and 7 and aims for high impact per node using HTTP/2 and persistent connections. Next to RondoDoX and Mirai variants, operators also deploy miners on capable devices or keep access to sell later through initial access brokers.

Conclusion

Morte Loader turns cheap, often ignored edge devices into shared infrastructure that others can rent and weaponize. Defenders should focus on catching the loader early by spotting router and IoT exploits, flagging suspicious shell download chains, and hunting for unknown binaries that pose as system processes before they power DDoS, mining or access resale.

We linked more than 800 public files to Morte, many still undetected by some engines. The code changes only slightly and keeps the same logic, while open directories reuse URL patterns like http://<ip>/morte.<arch> and http://<ip>/bins/morte.<arch>, which makes hunting easier when combined with YARA and directory scans.

You can find all details in our whitepaper “Morte Loader to Botnet: Loader as a Service (LaaS)”, which includes IoCs, deeper reverse engineering notes, and guidance for detection and response teams.

The complete list of TTPs, IP addresses, hashes for all major architectures, and further correlations is available in the paper and SOCRadar platform.