ShadowRay 2.0 shows how AI workload exposure becomes botnet scale

At a glance

What this is: ShadowRay 2.0 is an active campaign that turns exposed Ray AI clusters into a self-propagating botnet, with attackers abusing runtime access, persistence, and compute resources.

Why it matters: IAM, NHI, and platform teams need to treat AI workloads as governed identities because exposed orchestration layers can become durable attack surfaces when isolation and runtime controls are missing.

By the numbers:

• Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly.

👉 Read Oligo Security's analysis of ShadowRay 2.0 and Ray cluster abuse

Context

ShadowRay 2.0 is a reminder that exposed AI infrastructure behaves like an identity problem as much as a software problem. When a framework exposes unauthenticated execution paths, the issue is not only code execution but who or what can act inside the compute environment, what it can persist, and how far that access can spread. That is the core governance gap for AI workloads and the NHI controls wrapped around them.

The article describes an active campaign that uses Ray dashboards, GitLab, and GitHub to update payloads, hide miner activity, and keep compromised clusters in play. That combination matters because it shows how runtime access, software delivery, and workload identity can collapse into one attack surface when the environment is assumed to be trusted instead of continuously verified.

Key questions

Q: What breaks when Ray clusters are exposed to the internet without isolation?

A: When Ray clusters are internet-facing, unauthenticated job execution becomes a remote control path for attackers. They can submit code, establish persistence, and turn the cluster into an abuse platform for mining or exfiltration. The failure is not only technical exposure, but the absence of a trust boundary around privileged compute.

Q: Why do exposed AI workloads create NHI-style governance risk?

A: Exposed AI workloads behave like powerful non-human identities because they can execute actions, hold operational authority, and reach surrounding systems. If access is not tightly scoped and isolated, the workload itself becomes a reusable identity with a wide blast radius. That is why NHI governance has to extend to AI infrastructure.

Q: How do security teams know if persistence has been established on a compromised AI node?

A: Look for process names that imitate system services, shell profile edits, cron-style polling, and startup hooks that survive reboots. Those signals show the attacker is maintaining control rather than just running a one-time payload. Runtime telemetry is more reliable than file-only detection in this environment.

Q: How should organisations respond when AI compute is being used as delivery infrastructure?

A: They should contain the cluster, revoke any exposed access paths, inspect repository-driven update channels, and separate build and runtime authority immediately. The goal is to cut off the delivery mechanism before the attacker can refresh payloads or spread laterally to additional clusters.

Technical breakdown

Exposed Ray dashboards and unauthenticated job execution

Ray exposes a jobs API that can accept commands when clusters are deployed without strong isolation. In the ShadowRay case, attackers used that reachable interface to submit jobs remotely and trigger code execution on internet-facing clusters. The technical issue is not just the flaw itself, but the deployment pattern: a framework designed for trusted networks being placed into an untrusted one. Once the dashboard is reachable, the cluster behaves like a privileged execution surface with no built-in trust boundary.

Practical implication: restrict Ray exposure to private networks and treat every dashboard or jobs endpoint as a high-risk execution interface.

Payload delivery, persistence, and process masquerading

After entry, the attackers used scripts and repositories to pull miners, update payloads, and reapply persistence. They hid activity by naming processes after legitimate system services, modifying shell profiles, and using cron-like polling to keep control durable. This is a classic post-exploitation pattern for NHI environments: the attacker is no longer just executing commands, but turning the workload into an ongoing identity under hostile control. Monitoring that only watches for binaries or ports misses the more durable layer of process and service abuse.

Practical implication: detect persistence through process lineage, startup hooks, and service-name deception, not only through file hashes or network indicators.

Botnet propagation through shared compute and delivery infrastructure

The campaign used GitLab and GitHub as update channels, allowing the payloads to evolve quickly and spread across multiple regions. That matters technically because the attack is no longer bounded to one cluster compromise. It becomes a distributed delivery system where compromised Ray nodes are both victims and infrastructure. The result is a self-propagating compute abuse model that can support cryptomining today and DDoS or exfiltration tomorrow. For identity teams, the important detail is that the compromised workload now acts with persistent operational authority inside cloud environments.

Practical implication: monitor for abuse of code-hosting and update channels as part of workload identity governance, not as a separate DevOps concern.

Threat narrative

Attacker objective: The attackers aim to monetise exposed AI compute at scale while preserving a reusable botnet platform for mining, disruption, and follow-on abuse.

1. Entry occurred through exposed Ray dashboards and the unauthenticated jobs API, which allowed attackers to submit remote commands to internet-facing clusters.
2. Credential access and abuse followed when the attackers gained persistent operational control over the workloads, added SSH keys, and used the environment to pull and execute new payloads.
3. Escalation and impact came through self-replicating deployment, cryptomining, process masquerading, and use of compromised clusters as botnet infrastructure for broader abuse.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing execution trust was designed for clusters assumed to be private. That assumption fails when Ray dashboards are internet-facing because the actor can invoke jobs, persist payloads, and re-enter the environment without crossing a traditional human approval boundary. The implication is that workload governance must stop treating cluster reachability as a benign deployment detail.

Identity blast radius now includes compute authority, not just secrets. Once a Ray node is compromised, the attacker can consume resources, mask processes, and distribute new payloads through trusted delivery paths. This is not only a vulnerability story, it is a governance story about how far one exposed workload identity can reach before controls notice.

Runtime visibility failed because the attacker blended into the workload’s own operating model. Process renaming, host-based persistence, TLS-based mining traffic, and repository-driven updates all exploit the gap between configuration-time approval and runtime behaviour. The implication is that security teams must judge AI infrastructure by live behaviour, not by whether the platform was originally intended for a controlled network.

Self-propagating AI workload abuse is now a named concept teams should track: identity-to-compute expansion. The compromise does not stop at a single job or node. It expands from one exposed orchestration endpoint into a reusable compute substrate that can host miners, exfiltration tooling, and other payloads. Practitioners should treat that expansion as a distinct governance failure mode, not as ordinary cloud compromise.

Ray exposure demonstrates that AI platform risk is no longer isolated to model security teams. The campaign crosses platform operations, NHI governance, secrets handling, and runtime defence in one chain. That means the right ownership model is shared, but the control failure is singular: exposed execution authority without enforced isolation. Practitioners need a programme that can govern the workload, the credentials, and the delivery path together.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, showing how quickly delegated access outpaces governance coverage.
• To go deeper on the control gap that makes exposed workloads hard to govern, see 52 NHI Breaches Analysis for repeated breach patterns and root causes.

What this signals

Identity-to-compute expansion: The practical risk is that a single exposed AI execution surface can absorb job submission, persistence, and delivery authority into one compromised workload. Teams should expect AI infrastructure to be treated as a live identity plane, not just a cluster configuration problem.

If your programme still separates platform security from identity governance, ShadowRay 2.0 is a sign that those controls are already misaligned. The next phase of maturity is to review where AI compute inherits trust by default, then tie that trust back to isolation, runtime monitoring, and workload accountability.

The most useful near-term benchmark is not how many AI tools you have, but whether you can prove who or what can execute inside them. That means aligning cluster exposure, secrets governance, and behavioural detection under one operational model, with references such as the 52 NHI Breaches Analysis and MITRE ATLAS adversarial AI threat matrix informing the threat model.

For practitioners

• Constrain Ray to private trust boundaries Keep Ray dashboards, jobs APIs, and related control planes off the public internet, and verify that network segmentation blocks unauthenticated execution paths before production rollout.
• Watch for process masquerading and persistence hooks Alert on renamed system-like processes, shell profile changes, cron polling, and init-style startup artefacts on AI clusters because those are the signs of durable post-exploitation control.
• Inspect code-hosting and update channels used by workloads Review whether GitLab, GitHub, or similar repositories are being used as hidden delivery infrastructure for AI workloads, especially when change frequency is unusually high or region-aware.
• Treat exposed AI compute as an identity governance issue Map who can submit jobs, modify execution paths, and persist artefacts on AI clusters, then align those permissions with the same review discipline used for privileged service accounts.

Key takeaways

• ShadowRay 2.0 shows that exposed AI orchestration can become durable botnet infrastructure when isolation and runtime control are missing.
• The campaign’s scale is reinforced by more than 200,000 exposed Ray servers and by attacker use of persistence, masquerading, and update channels.
• The control that matters most is enforced trust boundary management around AI execution, not after-the-fact cleanup of compromised jobs.

Key terms

• Ray dashboard exposure: Ray dashboard exposure occurs when a Ray cluster's control interface is reachable beyond the intended trust boundary. In practice, that can turn a workload orchestration surface into a remote execution path if authentication, isolation, and network controls are not enforced.
• Identity blast radius: Identity blast radius is the scope of damage a compromised non-human identity can create before controls stop it. For AI workloads, it includes execution rights, reachable services, persistence paths, and downstream delivery channels, not just the secrets stored alongside the workload.
• Process masquerading: Process masquerading is the act of renaming a malicious process so it looks like a legitimate system component. In AI cluster abuse, the goal is to blend into host telemetry and delay detection while the attacker keeps persistence or mining activity alive.
• Self-propagating botnet: A self-propagating botnet is a set of compromised systems that can spread control and updates to additional nodes without manual reinfection. In this context, the botnet is built from AI compute resources that are repeatedly updated and reused as attack infrastructure.

Deepen your knowledge

AI workload exposure and runtime governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for AI clusters, service accounts, or delegated execution paths, it is worth exploring.

This post draws on content published by Oligo Security: ShadowRay 2.0 and the global campaign hijacking AI clusters. Read the original.