Runtime defense for Gafgyt shows why cloud AI workloads stay exposed

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Aqua Security's blog post: A newer Gafgyt variant targets Linux cloud AI workloads through weak SSH passwords and fileless cryptomining execution.

Why it matters: It matters because IAM, workload identity and runtime teams need to treat exposed access paths and compute misuse as one control problem, not separate issues.

By the numbers:

• Aqua Security says over 500 of the world’s largest enterprises are protected by its platform.

Context

Gafgyt is a malware family that has shifted from IoT abuse toward cloud native Linux environments where exposed SSH access and high-capacity compute make monetisation easier. In this article, the primary governance gap is not malware novelty. It is the combination of weak access control, workload exposure and runtime blind spots around AI infrastructure.

For IAM and NHI practitioners, the important question is how often cloud workloads inherit the same credential weaknesses and access sprawl that used to expose servers and devices. When AI environments are reachable through weak SSH passwords, the issue becomes identity hygiene, workload protection and runtime enforcement at the same time.

Key questions

Q: What breaks when weak SSH passwords are left on cloud AI workloads?

A: Weak SSH passwords turn cloud AI workloads into easy entry points for low-complexity malware. Once an attacker can log in, they can deploy miners or other payloads directly onto compute-rich hosts. The control failure is not only authentication. It is also exposure management, because an unnecessary reachable login path becomes the easiest route into valuable infrastructure.

Q: Why do cryptomining payloads matter in AI infrastructure?

A: Cryptomining matters because it converts compute capacity into attacker profit while degrading the workload that the business actually needs. In AI environments, that can mean higher cloud bills, reduced performance and noisy operational signals that mask other compromise. The security issue is therefore both financial and operational, not just a malware detection problem.

Q: What are the signs that fileless execution controls are failing?

A: The main signs are processes that appear and disappear without leaving clear file artefacts, unexplained memory-resident activity, and resource spikes that do not match application demand. If those indicators are present on AI workloads, the runtime layer is not seeing enough of what the host is actually doing. That is where container and kernel telemetry become essential.

Q: Should teams prioritise runtime blocking or access hardening first for Gafgyt-like threats?

A: Access hardening should come first because runtime blocking only contains what has already slipped through. If workloads remain reachable through weak SSH access, the attacker still has an entry path. Runtime enforcement then becomes the backstop that limits damage, but it cannot compensate for exposed login surfaces and poor credential hygiene.

Technical breakdown

Weak SSH credentials as the entry path

This Gafgyt variant follows a familiar compromise pattern: it gets initial access through weak SSH passwords on Linux-based systems, then uses that foothold to place cryptomining software. SSH remains a high-value access path because it often connects directly to administrative shells and container hosts. When credentials are weak or reused, the attacker does not need a sophisticated exploit chain. They only need one reachable login surface and a workload with enough CPU or GPU capacity to be worth abusing.

Practical implication: expose SSH only where it is operationally necessary and remove weak credential pathways from AI workload hosts.

Fileless execution and miner deployment

Fileless execution matters because it reduces the number of durable artefacts defenders can inspect on disk. The malware can stage and run a miner such as XMRIG in memory, which makes traditional file-based detection less reliable. In cloud AI environments, that is especially relevant because runtime abuse can look like ordinary workload consumption until resource usage spikes or kernel-level behaviour changes. Runtime visibility therefore becomes part of identity and access governance, not just endpoint detection.

Practical implication: monitor runtime behaviour for memory-based execution and unusual compute consumption on AI workloads.

Cryptomining against AI infrastructure

The miner payload is the end state of the attack because AI infrastructure offers the CPU and GPU capacity the botnet needs to monetise access. That changes the governance question from simple compromise to infrastructure abuse. Even if the malware does not exfiltrate data, it still creates direct financial cost, degraded performance and operational instability. For cloud AI teams, the risk sits at the intersection of workload identity, host exposure and runtime control boundaries.

Practical implication: treat unexplained GPU or CPU saturation as a governance signal, not only an infrastructure performance issue.

Threat narrative

Attacker objective: The attacker wants persistent access to compute-rich cloud AI environments so the malware can mine cryptocurrency and consume hosted resources.

1. Entry occurs through weak SSH passwords on Linux-based systems that expose AI workloads to unauthorised login.
2. The malware deploys a cryptomining payload using fileless execution, reducing disk artefacts and making static detection harder.
3. The attacker objective is to convert exposed cloud AI compute into cryptocurrency mining capacity while degrading workload performance and increasing cloud cost.

Breaches seen in the wild

• ShadowRay 2024: Attackers took over internet-exposed Ray AI clusters via the disputed CVE-2023-48022, exposing cloud keys, AI API tokens and GPU compute.
• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposed cloud AI workloads create identity risk before they create malware risk: The real problem is not that Gafgyt is novel. It is that reachable SSH access, weak credentials and compute-rich workloads create an easy monetisation path for low-complexity malware. That means AI infrastructure exposure is an access governance issue as much as a runtime security issue. Practitioners should treat workload reachability as part of the identity attack surface.

Runtime policy now sits inside the control boundary for NHI governance: A workload that can be logged into and then instructed to run fileless code has already crossed the line from access control into execution control. That is why runtime defense matters for cloud AI environments even when the malware itself is unsophisticated. The practitioner takeaway is to align workload access, runtime enforcement and exposure management as one control plane.

Compute abuse is the named concept here: Gafgyt is not only a malware problem, it is a compute abuse problem, where the adversary monetises exposed AI infrastructure rather than stealing data. The consequence is cost inflation, degraded performance and operational noise that can hide other compromise signals. Security teams should map that abuse pattern to workload governance rather than treating it as a niche cryptomining event.

Configuration creep is the control gap that keeps primitive threats viable: The article describes a threat that succeeds by capitalising on forgotten exposures and weak SSH hygiene. That is a governance failure, not an advanced adversary capability. The field implication is that cloud AI programmes need tighter exposure management across hosts, containers and access paths because simple abuse remains profitable wherever controls drift.

Runtime enforcement changes the containment model but not the trust model: Blocking fileless execution and miners can stop this specific payload, yet the underlying assumption still fails if workloads remain reachable with weak credentials. The broader lesson is that runtime policy is a last line, not a substitute for hardened access boundaries. Practitioners should use containment to limit blast radius, then remove the exposure that made containment necessary.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Compute-rich AI environments attract primitive abuse because the economics work for attackers: malware does not need sophisticated exploitation if weak SSH access already exists. For defenders, that means workload reachability and runtime monitoring need to be evaluated together, not as separate control domains.

Cloud AI teams should treat cryptomining as a governance signal, not a housekeeping event: when a host can be logged into weakly and then instructed to mine in memory, the programme has already lost control of both access and execution boundaries. The practical response is to collapse that exposure window before the next botnet variant finds it.

For practitioners

• Harden SSH exposure on AI workloads Inventory every Linux host that can reach AI workloads and remove public or unnecessary SSH access. Replace weak passwords with strong authentication and ensure administrative access is limited to approved management paths.
• Block fileless execution paths Add runtime rules that flag and prevent memory-based execution patterns associated with cryptomining payloads. Tune these rules for container and host contexts where legitimate processes may also run in memory.
• Treat unexplained GPU usage as a security signal Correlate sudden CPU or GPU spikes with login activity, new processes and container runtime events so cryptomining does not hide inside normal AI workload growth.
• Separate AI workload exposure from general infrastructure exposure Review whether AI clusters inherit the same access paths, firewall rules and admin accounts as general compute. Split those pathways where the business function justifies stricter control.

Key takeaways

• Gafgyt in cloud AI environments shows that weak SSH access still gives low-complexity malware a direct path into high-value compute.
• Fileless execution reduces visibility and lets cryptomining run with fewer disk artefacts, so runtime telemetry matters more than file scanning alone.
• The decisive control question is whether organisations can close exposed access paths before runtime enforcement has to do containment work.

Key terms

• Fileless Execution: Fileless execution is malicious activity that runs without leaving a conventional on-disk payload for scanners to inspect. It reduces obvious forensic artefacts and shifts detection toward behavioural controls, memory inspection, and runtime enforcement rather than file-based hygiene alone.
• Cryptomining Payload: A cryptomining payload is malicious software that uses enterprise compute to mine cryptocurrency for the attacker. The main harm is resource theft, degraded performance, and higher cloud cost, often with little immediate data exposure but substantial operational impact.
• Runtime Defense: Runtime defense is the set of controls that inspect, constrain, and stop unsafe AI behavior while the system is operating. For hospitality deployments, it covers both incoming prompts and outgoing responses, plus the tool calls that agents may trigger after a model decides to act.
• SSH Exposure: SSH exposure is the presence of reachable SSH services that can be used to access servers or workloads remotely. When credentials are weak or unmanaged, SSH becomes a direct entry path for attackers, so exposure scope and authentication strength must be governed together.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.