A Linux botnet called ToxNetV2 is testing a new boundary between generative AI and real-world intrusion tooling. Its controller sends operational context to an AI service, interprets structured suggestions and places recognized actions into a queue that an authenticated operator can execute.

The malware does not qualify as a fully autonomous AI worm. Researchers found that its most consequential tasks still require human approval, and they did not observe an end-to-end capability to write new code, compile it, distribute it and replace bots independently. Even with those limits, the design demonstrates how AI advice can be connected to an active botnet rather than kept in a separate chat interface.

A peer-to-peer botnet aimed at AArch64 Linux

ToxNetV2 targets AArch64 Linux systems and uses the Tox peer-to-peer network for command and control. Its worker capabilities include host administration, network scanning, propagation and 17 network-attack launchers. HTTP, Telnet and SSH can all appear in its scanning or spreading activity, placing weakly protected servers, routers and other internet-facing devices at risk.

The same binary can act as an ordinary bot or as the controller. When it restores a specific saved Tox state from a file named c2.data, it enters controller mode and initializes the AI-related functions. Regular bots perform the operational work, while the controller collects information and coordinates the wider network.

JOESecurity’s analysis found that the controller communicates with NVIDIA NIM using the z-ai/glm-5.2 model. It can assemble botnet counters and local telemetry such as running processes, CPU load, memory utilization and disk use. It may also incorporate information from a hard-coded remote server when building a broader assessment.

Model responses become pending operational actions

The controller’s prompts include embedded operational instructions and an explicit jailbreak intended to reduce refusals. When a model response contains a correctly structured ACTION record, ToxNetV2 parses it and adds the proposed task to a pending queue. Ordinary conversational replies remain text and do not flow through that action parser.

Supported proposals include status logging, configuration or state changes, local shell execution, file creation, remote commands over SSH as root and a fixed local compilation process. This is the central security concern: model output is not merely displayed to an operator but translated into a format understood by a live malicious controller.

However, the queue is not executed immediately. An authenticated operator must issue the aiexec command, after which the queued tasks run and the list is cleared. Lower-impact actions such as logging, memory updates and some state adjustments may occur automatically during health checks, but system-changing commands retain a human gate.

Assistance is not the same as autonomy

The distinction matters for accurate threat assessment. ToxNetV2 can use AI to summarize conditions and narrow an operator’s choices, potentially reducing the time and expertise needed to manage many infected hosts. It does not, based on the analyzed sample, independently evolve and deploy new bot code. A worker-restart function records a request rather than completing a self-upgrade, while compilation is limited to fixed local source and lacks an automatic rollout stage.

That still represents a meaningful operational experiment. Attackers can iterate on prompts and approval policies more quickly than they can redesign an entire malware family. Future versions could automate additional low-risk decisions, integrate different model providers or impose stronger validation around generated commands.

Detection and hardening opportunities

The botnet’s infection opportunities remain familiar. Exposed remote services, weak credentials and unpatched edge systems allow propagation regardless of whether AI assists the controller. Reducing that conventional attack surface is therefore the most immediate defensive step.

• Disable unnecessary Telnet, HTTP administration and externally reachable SSH services.
• Require key-based SSH authentication, restrict root logins and limit management access by network.
• Monitor AArch64 Linux and IoT devices for new binaries, shell scripts and unexpected persistence.
• Alert on unusual outbound connections to AI APIs, Tox infrastructure and unfamiliar relay endpoints.
• Correlate automated health-check activity with subsequent file creation, shell execution or remote SSH sessions.

Outbound AI-service traffic may be a valuable signal on systems that have no legitimate reason to contact a model endpoint, although defenders should avoid treating such traffic as malicious by itself. Network controls, DNS records, process telemetry and authentication logs become more useful when combined.

ToxNetV2 is noteworthy not because it removes the attacker from the loop, but because it embeds AI into that loop. It offers a concrete preview of operator-guided automation in which a model assesses live conditions and proposes executable actions. Defenders should prepare for this gradual integration while continuing to close the exposed services and weak credentials that botnets still depend on.