Look for shell-cascade execution, unexpected script downloads, background daemons, cron creation and unusual CPU or GPU consumption. Those signals matter because botnet operators want persistence and scale, not a one-off exploit. If the cluster begins fetching scripts and staying busy outside normal job windows, assume malicious repurposing until proven otherwise.
What AI botnet activity looks like in infrastructure telemetry
Security teams should treat the infrastructure as compromised when ordinary AI workloads start behaving like a persistence platform instead of a compute service. The most telling signal is not a single malicious process, but a cluster of behaviours that appear together: shell-cascade execution, unexpected script retrieval, new background daemons, cron-based recurrence, and compute that stays busy outside normal job windows.
Those patterns matter because botnet operators are trying to keep the environment available for repeated tasking, not to finish one exploit and leave. In AI infrastructure, that often means abuse of notebooks, job runners, containers, orchestration hooks, or GPU nodes to keep commands alive and to survive restarts.
For teams that need a broader frame of reference on securing AI platforms, AI Infrastructure Workload Identity Guide is useful because the same platforms that run models also run the identities and access paths that can be abused for persistence.
How to separate normal AI workload variance from botnet repurposing
Normal AI infrastructure can be bursty, especially during training, batch inference, or scheduled evaluation. The distinction is whether the activity is explainable by the expected job lifecycle. A GPU node that is active because a training run is still progressing is different from a node that keeps spawning shells, pulling scripts from unfamiliar locations, and re-establishing execution after process restarts.
Look for deviations across time and across layers. Network telemetry may show outbound fetches to script hosts that do not belong in the pipeline. Host telemetry may show new startup entries, cron jobs, or persistence under service accounts that should not be creating them. Orchestration logs may show jobs or pods that reappear without a corresponding deployment event. When those signals align, the safest assumption is malicious repurposing until proven otherwise.
When the suspected path involves exposed AI platforms, ShadowRay 2024 is a strong analogue because it shows how exposed cluster services can be turned into infrastructure for abuse, including cryptomining and credential exposure.
If the environment includes agentic components, Carbonato botnet 2026 is a useful reminder that attackers may use AI hosts not only for compute theft but also to harvest credentials and widen control over the environment.
Which evidence best supports containment and remediation decisions
Once the pattern looks real, the question becomes whether the compromise is limited to one node or reflects shared access across the platform. Evidence of cron creation, shell-cascade execution, or daemon installation suggests persistence on the host. Evidence of repeated script downloads or busy loops outside expected windows suggests the host is now being task-driven. Evidence of unusual CPU or GPU load, especially when paired with process restarts or job re-creation, can indicate the attacker is using the infrastructure as a botnet worker or relay.
At that point, the priority is to confirm the entry path, preserve volatile evidence, and determine whether the compromise is still active. Teams should also check whether the same access path can reach other clusters, registries, buckets, or control planes. In AI environments, a single foothold often expands because the same credentials and orchestration privileges are reused across jobs, environments, and services.
For exposure patterns involving stolen keys or over-permissive tokens, LiteLLM MCP auth bypass 2026 is a relevant reference point because it connects platform access failures to key theft and broader AI infrastructure abuse.
When you need to compare the symptom set against known attack behaviour, the external view from MITRE ATT&CK Enterprise Matrix helps map shell execution, persistence, and scheduled task abuse to recognizable adversary techniques.
Risk and Threat Considerations
AI infrastructure is attractive to botnet operators because it offers high compute density, long-lived workloads, and centralised orchestration. That combination makes abuse efficient: one compromise can produce persistent execution, scale out across many nodes, and hide in traffic that operators assume is routine pipeline activity.
Failure mechanism: Attackers gain a foothold through exposed services, stolen credentials, or unsafe execution paths, then establish persistence with scripts, daemons, cron entries, or re-launched jobs so the cluster keeps executing attacker-controlled commands.
Impact: The result can include compute hijacking, service degradation, lateral spread into adjacent AI systems, and secondary theft of secrets or cloud access material that extends the compromise beyond the original host.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Botnet persistence often survives identity and access that were never fully removed. |
| NHI-02 — Secret Leakage | Script fetches and host compromise frequently expose keys that extend botnet control. | |
| NHI-05 — Overprivileged NHI | Abuse spreads faster when AI workloads have excessive permissions on compute and storage. | |
| Recommendation — Revoke orphaned AI service access and rotate any credentials that can still reach the cluster. Scan AI hosts and pipelines for exposed secrets and rotate any leaked material immediately. Reduce AI workload privileges so a compromised host cannot reach unrelated systems. | ||
| MITRE ATT&CK | T1053 — Scheduled Task/Job | Cron creation is a classic persistence mechanism visible in the question's signals. |
| T1059 — Command and Scripting Interpreter | Shell-cascade execution and script downloads indicate scripted command execution on hosts. | |
| T1057 — Process Discovery | Botnet operators often inspect running processes before persistence or lateral movement. | |
| Recommendation — Hunt for unexpected scheduled tasks and remove attacker-created recurrence points. Inspect script interpreters and command chains for attacker-driven execution. Look for hostile process enumeration that precedes persistence or spread. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Exposed AI infrastructure is often abused before operators notice persistence signals. |
| CIS-10 — Malware Defenses | Botnet activity on AI hosts is a malware and persistence problem requiring detection and containment. | |
| Recommendation — Continuously inventory AI nodes and remediate exposures that enable unauthorized execution. Deploy host and workload malware detection tuned for persistence and script abuse. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | The question relies on monitoring abnormal fetches, execution, and compute usage. |
| DE.AE-03 — Potential adverse events are analyzed to better understand associated events | Teams must interpret combined host and workload signals to judge malicious repurposing. | |
| Recommendation — Monitor AI infrastructure traffic and runtime patterns for hostile deviations from expected jobs. Correlate script downloads, persistence, and resource anomalies before declaring an incident. | ||
Practitioner Guidance
What to prioritise: Start with the nodes that show both persistence and abnormal compute use, not the loudest alert. A single GPU host that repeatedly fetches scripts and recreates execution is often a better containment priority than a generic spike in utilisation.
What to verify: Confirm whether the observed activity matches an approved job, deployment, or automation window. If there is no matching change record, treat the behaviour as hostile until the owner can explain the process lineage and the source of the downloaded code.
Decision rule: If the environment is fetching scripts and staying busy outside normal job windows, isolate the host or node group first, then rotate any credentials, tokens, or service identities that could have been used to reach adjacent AI systems.
Practitioner takeaway: The key judgement is not whether the workload is “using a lot of compute,” but whether its execution pattern still matches an authorised AI lifecycle. Once persistence and script retrieval appear together, assume the platform is being repurposed for attacker-controlled scale, not legitimate model work.
Related resources from NHI Mgmt Group
- How should security teams respond when exposed AI or cloud infrastructure is being used to build a self-propagating botnet?
- What steps should security teams take to prevent Shadow AI risks?
- How can security teams tell if a repository is being used for malicious update activity?
- How can security teams tell normal AI agent activity from misuse?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org