ToxNetV2: Inside the Linux Botnet That Asks an AI What to Attack Next
A few years ago, "AI-powered malware" mostly meant phishing emails with better grammar. That era is quietly ending. In late August 2026, researchers at JOESecurity pulled apart a Linux botnet called ToxNetV2 and found something that should make every SOC analyst sit up straight: a botnet controller that pipes live system telemetry into a hosted large language model, and gets back structured, machine-parseable attack instructions in return.
This isn't science fiction. It isn't a fully autonomous "AI worm" either — despite what a scary headline might imply. But it's a real, working example of AI-assisted attack tooling running against production infrastructure, and it's worth understanding in detail, because this pattern is not going away. If you run internet-facing Linux systems — especially ARM-based edge devices, routers, or embedded boards — this is the kind of threat model you need on your radar now.
Table of Contents
- What Happened: The Short Version
- How ToxNetV2 Actually Works
- The AI Decision Pipeline: From Telemetry to Attack Command
- The ENI/VEIL Jailbreak Prompt
- Why "Human-in-the-Loop" Doesn't Mean Safe
- Indicators of Compromise
- Detection: What to Hunt For
- Prevention and Hardening Checklist
- Expert Tips From the SOC Floor
- Related Reading
- FAQ
- Conclusion
What Happened: The Short Version
ToxNetV2 is a Linux botnet built around a peer-to-peer command-and-control model using the Tox encrypted messaging protocol instead of a traditional centralized C2 server. It primarily targets AArch64 (ARM64) Linux systems — think routers, NAS boxes, IoT gateways, and other embedded devices that often run outdated software and get far less security scrutiny than a typical enterprise server.
What sets ToxNetV2 apart from the usual Mirai-style botnet clone is its controller component. When the malware restores its Tox identity from a local state file (c2.data), it switches into "controller mode" and boots up an AI-assisted decision layer. That layer talks to NVIDIA NIM, specifically a model identified as z-ai/glm-5.2, sending it a snapshot of system and botnet conditions and receiving structured suggestions in return.
Analysts at JOESecurity, who published the original technical breakdown, were careful to note this is not an autonomous, self-replicating AI worm. The model's suggestions still route through a human approval gate before anything destructive happens. But the plumbing connecting an LLM to real shell execution, file writes, and remote SSH commands is now a documented, working design — not a theoretical risk.
How ToxNetV2 Actually Works
Think of ToxNetV2 as one binary with two personalities. Depending on whether it can restore a valid Tox state, the same code runs as either:
- A regular bot — handling network scanning, self-propagation, host reconnaissance, and executing any of 17 built-in network-attack modules.
- A controller — aggregating telemetry from the wider botnet, coordinating operations, and running the AI-assisted decision layer.
Propagation happens the old-fashioned way: scanning for exposed HTTP, Telnet, and SSH services and trying to get a foothold on poorly secured, internet-facing devices. Nothing exotic there — the entry point is still weak credentials and unpatched services. The innovation is entirely on the "what do we do once we're in and want to scale" side of the operation.
The AI Decision Pipeline: From Telemetry to Attack Command
Here's the part that matters most for defenders. When operating in controller mode, ToxNetV2 collects a mix of local and botnet-wide data:
- Running processes
- CPU load and memory usage
- Disk utilization
- Botnet-wide counters (bot count, status, etc.)
- Additional context pulled from a hard-coded remote server during broader reviews
That snapshot gets bundled into a request and sent to NVIDIA NIM. The response isn't free-form chat text — the controller is looking for a specific structured pattern: an ACTION: record. When the model's reply contains one, the malware parses it and drops a proposed task into a pending queue. Anything that isn't formatted as a recognized ACTION record — like a response to the free-text aiprompt command — is treated as plain informational text and never enters the execution parser.
The task types that can come out of this pipeline include:
- Status logging and configuration updates
- Local shell command execution
- File creation
- Remote commands executed over SSH as root
- A fixed local compilation routine
That last bullet is worth sitting with for a second. This is a real-world case of a botnet operator using an LLM not to generate malware source code in the abstract, but to make live, contextual operational decisions about a running attack infrastructure — then wiring that decision directly into command execution primitives.
The ENI/VEIL Jailbreak Prompt
Commercial AI APIs generally refuse to help with clearly malicious requests, so the ToxNetV2 operators built in workarounds. Requests to NVIDIA NIM include embedded operational prompts along with what researchers identified as an explicit jailbreak, referred to as ENI/VEIL, designed specifically to reduce refusals and coax the model into returning directly actionable output.
This is the same cat-and-mouse dynamic security teams have watched play out with jailbreaks against consumer chatbots for the past couple of years — except here it's embedded in malware talking to a hosted inference API instead of a person typing into a chat window. It's a reminder that prompt-injection-style jailbreak techniques aren't just an academic AI-safety curiosity; they're now a functional component of live attack tooling.
Why "Human-in-the-Loop" Doesn't Mean Safe
To be fair to the researchers' findings: ToxNetV2 is not fully autonomous. Higher-impact actions — the ones that actually touch a filesystem, spawn a shell, or reach out over SSH — sit in a queue until an authenticated operator issues an aiexec command, which executes and clears the whole batch at once.
Some lower-stakes housekeeping tasks — logging, memory bookkeeping, state updates — can run automatically during routine health checks. But the system-changing actions stay gated behind explicit operator approval. Researchers also found no evidence that ToxNetV2 can independently write new malware code, compile it, and redeploy it to replace existing bots on its own. Its "restart worker" function only records a restart request, and its compilation routine builds fixed local source without an automated deployment step.
Here's the defender's takeaway, though: a human approval gate reduces risk, it doesn't eliminate it. The moment an operator clicks "approve," AI-suggested commands reach the same shell, SSH, and file-write primitives any other malware would use. From a detection standpoint, what matters is that the model output ultimately terminates in real execution — and that's a design pattern that will only get more common as more threat actors experiment with wiring LLMs into operational tooling.
Indicators of Compromise
The following indicators were published in JOESecurity's original analysis. As always, treat these as defanged and re-fang only inside a controlled threat-intel platform such as MISP, VirusTotal, or your SIEM.
| Type | Indicator | Description |
|---|---|---|
| Network endpoint | 45.130.151[.]214:33445 | Embedded Tox bootstrap/relay endpoint, actor-controlled infrastructure |
| Network endpoint | 45.130.151[.]214:443 | Embedded Tox bootstrap/relay endpoint, actor-controlled infrastructure |
| URL | http://45.151.139[.]113/z0l1mxjm4mdl4jjfjf7sb2vdmv/kaf.sh | HTTP/Telnet propagation path used to fetch and run a shell script (payload unavailable at analysis time) |
Detection: What to Hunt For
Because the AI component sits between telemetry collection and execution, your best detection opportunities are at the network edge and in process/command auditing — not in trying to spot "AI-generated" commands, which will often look like ordinary shell activity.
Practical things to check on Linux systems, especially ARM64 edge devices and servers with exposed SSH:
\# Look for outbound connections to unusual high ports or unfamiliar IPs
ss -tupn | grep -v ESTABLISHED
\# Check for unexpected outbound traffic to AI/inference API endpoints
sudo tcpdump -i any -n host 45.130.151.214
\# Review recently modified or created files outside normal package management
find / -xdev -type f -mtime -1 -newer /etc/hostname 2>/dev/null
\# Check for unauthorized SSH key additions (a common persistence step)
find / -name "authorized_keys" -newer /etc/passwd 2>/dev/null
\# Review auth logs for root logins or SSH key-based access from unfamiliar sources
sudo grep -E "Accepted|Failed" /var/log/auth.log | tail -100What each of these does: the ss command surfaces active outbound connections so you can spot beaconing to unfamiliar IPs; tcpdump lets you confirm whether a host is actually talking to known ToxNetV2 infrastructure; the two find commands flag recently modified files and freshly dropped SSH keys, both common footholds for propagation; and the auth.log grep highlights successful or failed logins that don't match your normal access patterns. None of these commands are destructive — they're read-only investigative steps, safe to run on production systems.
If you have EDR or auditd deployed, also watch for:
- A single process making repeated outbound HTTPS calls to inference-API-style endpoints on an unusual schedule (health-check cadence).
- Shell commands spawned by a parent process with no interactive terminal — a hallmark of automated, queue-driven execution rather than a human typing at a console.
- Compilation activity (gcc, cross-compilers) on devices that should never be building software locally, such as routers or IoT gateways.
Prevention and Hardening Checklist
The infection vector for ToxNetV2 is unglamorous: exposed services, weak credentials, and unpatched edge devices. That means the fundamentals still do most of the work here.
- Disable Telnet entirely on any device that supports it — there's no legitimate reason to run it on internet-facing infrastructure in 2026.
- Restrict root SSH login (
PermitRootLogin noinsshd_config) and enforce key-based authentication over passwords. - Segment management networks away from general production traffic so a compromised edge device can't pivot freely.
- Patch and update firmware on routers, NAS devices, and other ARM-based appliances on a defined cadence — these are frequently the last devices anyone remembers to update.
- Monitor outbound connections from IoT/embedded devices; these devices rarely need to reach arbitrary external APIs, so unexpected outbound HTTPS traffic is a strong signal.
- Rotate default and weak credentials across all internet-facing services, not just the ones your asset inventory happens to track.
- Log and alert on new SSH keys and configuration changes on critical Linux hosts.
None of this is exotic. It's the same hardening checklist that would have stopped a thousand other Linux botnets before ToxNetV2. The AI layer changes what happens after compromise; it doesn't change how compromise happens in the first place.
Expert Tips From the SOC Floor
- Treat AI-service traffic as a new log source. If you don't already track outbound connections to LLM/inference API providers from servers and IoT devices, start now — legitimate business traffic to these endpoints from an embedded device is rare, so it's a high-signal indicator.
- Don't chase "AI-generated" signatures. The commands that come out of a pipeline like this look like normal shell or SSH activity because they are normal shell or SSH activity — just chosen by a model instead of typed by a person. Focus detection on the execution behavior, not the origin.
- Assume human-gated doesn't mean rare. An approval workflow slows operators down, but it doesn't cap how many botnets can adopt this pattern. Build detection now rather than waiting for a fully autonomous version to show up.
- Revisit your ARM64/IoT asset inventory. A huge number of organizations have a blind spot here — if you can't list every ARM-based device on your network, you can't defend it.
Related Cybersecurity Topics You Should Explore
- Tata Nexarc Account Takeover Bug: All It Took Was a Phone Number
- Zscaler Client Connector Flaw Lets Hackers Run Code Remotely
- 91 Spring CVEs Impact 209,000+ Components — Critical RCE Flaw Found
- SynkLoader Malware Fakes Windows Lock Screen to Steal Passwords
- SysScan Scam: Fake Microsoft Alert Tricks Users Into Deleting AV
- 768 Leaked AWS Keys Still Have Full Admin Access in 2026
- Enable Maximum Windows Logging for SOC & Ransomware Detection
- OpenBin.ai & OpenAPK.ai Review: Free AI Reverse Engineering Tool
- Grok Zero-Click Hack Steals Your Chats — No Click Needed
- head Command in Linux: Fast Log Triage for SOC Analysts
- Elementor Pro Bug Lets Hackers Upload PHP — No Login Needed
- tac Command Tutorial: Reverse Logs Fast for Faster Threat Detection
- ToxicPanda 2.0: The Android Trojan Now Hacking 349 Banks
FAQ
Is ToxNetV2 a fully autonomous AI botnet?
No. According to JOESecurity's analysis, high-impact actions — shell commands, file writes, remote SSH execution — require an authenticated operator to run an aiexec command before they're carried out. Lower-impact housekeeping tasks can run automatically, but the system-changing actions stay gated behind human approval.
What AI model does ToxNetV2 use?
The controller communicates with NVIDIA NIM using a model identified as z-ai/glm-5.2, sending it system and botnet telemetry and parsing structured responses into actionable tasks.
What platforms does ToxNetV2 target?
It primarily targets AArch64 (ARM64) Linux systems, which commonly include routers, IoT gateways, NAS devices, and other embedded infrastructure.
How does ToxNetV2 spread?
Through scanning and exploitation of exposed HTTP, Telnet, and SSH services — largely relying on weak credentials and unpatched, internet-facing devices rather than novel exploits.
What is the ENI/VEIL jailbreak?
It's an embedded prompt technique the malware uses when querying NVIDIA NIM, designed to reduce the model's refusals and increase the odds of getting directly actionable, structured output back.
Can ToxNetV2 rewrite or update its own code using AI?
Researchers found no evidence of that. Its compilation function builds fixed local source code without an automated deployment step, and its "restart worker" function only logs a restart request rather than executing one autonomously.
How can I tell if a device on my network is compromised by ToxNetV2?
Check for outbound connections to the published IOC infrastructure, unexpected SSH key additions, unexplained compilation activity on devices that shouldn't be building software, and unusual outbound traffic to AI/inference API endpoints.
Conclusion
ToxNetV2 isn't the AI apocalypse some headlines might suggest — but it is a genuine, working proof of concept for something security teams have been warning about for a while: attackers wiring live telemetry into an LLM and getting real, executable operational decisions back. The human approval step keeps it from being autonomous today. It won't stop the next version, or the next threat actor who decides to skip that gate entirely.
The good news is that the fundamentals still hold the line. Disable Telnet, gate root SSH access, patch your edge devices, and start treating unexplained outbound traffic to AI service endpoints as a detection signal worth investigating. The attack surface hasn't fundamentally changed — just who's making the decisions on the other side of it.
If your team is responsible for Linux or IoT infrastructure, now's a good time to review your outbound traffic baselines and SSH hardening posture. Have thoughts on AI-assisted malware, or seeing similar telemetry-to-action patterns in your own environment? Drop a comment below or share this with your SOC team.