Masjesu Botnet: Telegram DDoS-for-Hire Targeting Multi-Arch IoT
Just caught the latest report on the Masjesu botnet. It’s fascinating (and terrifying) how these DDoS-for-hire services are maturing. Advertised openly on Telegram since 2023, Masjesu isn't just another Mirai clone; the researchers noted its capability to target a wide range of architectures, specifically hitting routers and gateways. This multi-architecture support means they are aggressively casting a wide net across diverse IoT hardware.
The "DDoS-for-hire" model lowers the barrier to entry for script kiddies, but the technical implementation suggests a dev team that knows how to cross-compile. For those of us in SOC or managing MSPs, the immediate risk is the saturation of bandwidth and the potential collateral damage to edge devices.
Hunting for this involves looking for the usual suspects: unauthorized Telnet/SSH access and suspicious outbound traffic. If you suspect infection on a Linux-based gateway, look for binaries persisting in obscure directories.
Here is a quick bash snippet to check for common botnet process locations:
# Check for suspicious processes often hiding in /dev/shm or /tmp
ps aux | grep -E '/dev/shm|/tmp|/var/tmp' | grep -v grep
# List network connections for binaries not in standard paths
ss -tulwnp | awk '{print $7}' | grep -v "users:" | sort -u
And if you are using Sentinel SIEM, try this KQL to catch potential C2 heartbeats on non-standard ports:
DeviceNetworkEvents
| where RemotePort in (443, 80, 8080) and InitiatingProcessFileName !in ("nginx", "apache2", "httpd")
| where NetworkProtocol == "Tcp"
| summarize count() by DeviceName, RemoteIP, RemotePort
Given the rise of Telegram as a C2 or advertisement channel, are any of you actively blocking Telegram API endpoints on your corporate firewalls to curb the "Hire" aspect, or is that too disruptive for legitimate comms?
We've started seeing similar traffic patterns in our honeypots. The multi-arch support is the real kicker—it implies they are exploiting vulnerabilities that exist across different kernel builds or relying heavily on brute-forcing default credentials which is arch-independent. We're blocking all inbound Telnet (23/TCP) and SSH from the internet at the edge now. It breaks some legacy VPNs, but it's better than being part of a botnet.
Regarding detection, if you are using Zeek, keep an eye on Conn::History strings containing Sf or Sh repeatedly. Masjesu variants often leave a hanging socket or trigger IDS signatures related to CVE-2023-XXX (exploiting router UPnP). I updated our Suricata ruleset last night to include the user-agent strings mentioned in the full IOC report.
The 'DDoS-for-hire' via Telegram is getting brazen. I found a channel advertising 'stress testing' services that align perfectly with the Masjesu timelines. From a pentester perspective, these bots almost always get in via unpatched firmware. If you can't update the router firmware (MPLS/ISP gear), VLAN segmentation is mandatory to keep the botnet from reaching your core servers if the gateway gets owned.
The persistence of Telnet-based exploitation vectors in these multi-arch botnets is concerning. Despite years of warnings, default credentials remain a top entry point. If you're auditing IoT devices, a quick scan for open Telnet services on your internal subnet can reveal vulnerable endpoints immediately.
nmap -p 23 --open 192.168.1.0/24
Blocking outbound Telegram traffic at the firewall for IoT VLANs is also a prudent containment strategy until the specific C2 infrastructure is fully mapped.
Great insights. To add to the auditing discussion, if you suspect a gateway is compromised, checking for processes running from writable directories is a quick win. These multi-arch binaries often hide in /tmp or /var. You can spot anomalies on Linux-based IoT with:
ps aux | awk '{print $11}' | grep -E '^/tmp|^/var' | grep -v grep
Proactively blocking outbound traffic from IoT VLANs to non-essential ports also limits the C2 callbacks effectively.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access