VoidLink malware shows why cloud identity visibility is the blind spot

At a glance

What this is: VoidLink is a cloud-native malware framework that targets non-human identities, secrets, and application visibility to keep access after detection.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot shrink blast radius or revoke access effectively if they cannot map which identities exist, what they can reach, and where secrets live.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Orchid Security's analysis of VoidLink malware and cloud identity exposure

Context

VoidLink is a cloud-native malware framework that hunts for non-human identities, cloud metadata credentials, and exposed secrets inside AWS, Kubernetes, Docker, and CI/CD environments. The primary problem is not just code execution, but the attacker’s ability to turn application sprawl and unmanaged credentials into durable access.

For IAM and NHI programmes, the gap is visibility. If teams cannot map which applications own which credentials, where those credentials are stored, and what each identity can reach, they cannot contain post-exploitation activity or revoke the right access with confidence.

Key questions

Q: What breaks when malware steals cloud service account tokens and metadata credentials?

A: The normal assumption that malware removal ends the incident breaks immediately. Once an attacker has valid NHI credentials, they can continue to access cloud resources through legitimate channels, often with the same permissions the workload had. Response then depends on knowing exactly which applications, accounts, and trust relationships were exposed.

Q: Why do cloud-native secrets in code and config files create such a high risk?

A: Because they are often stored close to the runtime context that can already read them. If the secret, its decryption method, and the application that uses it share the same boundary, a local compromise can recover usable credentials. That turns a file read into identity compromise.

Q: How can security teams know whether a stolen NHI can still cause damage?

A: They need an identity-to-application map that shows ownership, permissions, and cross-account trust. The question is not only what was stolen, but what that identity can reach across clusters, accounts, and services. Without that mapping, blast-radius assessment is slow and incomplete.

Q: How should organisations respond when malware attempts to remove local evidence?

A: They should rely on real-time telemetry, not only post-infection host artefacts. If evidence can be wiped from the machine, then login audit logs, token-use records, and workload identity telemetry must already be in central storage. Containment depends on knowing which identities were used before the host was cleaned.

Technical breakdown

Cloud-native credential harvesting across AWS, Kubernetes, and CI/CD

VoidLink is built to identify the environment it is running in and then harvest credentials from the most common cloud identity surfaces. That includes instance metadata APIs for temporary cloud credentials, Kubernetes service account tokens, SSH keys, and secrets buried in environment variables, Git configurations, and application files. The framework is not relying on one fixed path. It adapts its collection logic to the platform it sees, which makes it effective against mixed cloud estates where identity material is scattered across workloads, containers, and pipelines.

Practical implication: teams need inventory and exposure mapping for every place identities and secrets can exist, not just central vaults.

Why encrypted credentials in code and config still fail

VoidLink’s value comes from the fact that many organisations treat encrypted secrets in code or configuration as protection, even when the decryption key or routine sits beside them. In that situation, encryption becomes obfuscation, not access control. Once the malware can read the file system, it can locate the credential, find the method used to decrypt it, and recover plaintext access material. This is a classic cloud identity failure because the secret is technically protected but operationally available to any process with local access.

Practical implication: secret protection must separate storage, decryption, and runtime access paths so a single filesystem compromise cannot reveal usable credentials.

Visibility gaps after infection make remediation unreliable

VoidLink also maps running processes, services, and container configurations, then removes evidence to frustrate later analysis. That makes post-infection forensics weaker than real-time telemetry, especially when security teams rely on host-level artefacts after the fact. The core control problem is not only detection. It is the inability to answer two operational questions fast enough: what identity was stolen, and what could that identity access across accounts, clusters, and applications.

Practical implication: SOC and IAM teams need continuous identity-aware telemetry and cross-account trust mapping before they can contain cloud-native intrusions.

Threat narrative

Attacker objective: The attacker’s objective is to convert local compromise into durable, legitimate-seeming cloud access by stealing non-human identities and the permissions they carry.

1. Entry begins with execution of the VoidLink implant inside a cloud host, container, or Kubernetes pod where it can observe the local identity environment.
2. Credential access escalates when the malware harvests metadata credentials, Kubernetes service account tokens, SSH keys, and pipeline secrets from files, variables, and configs.
3. Impact follows when the attacker reuses valid NHI credentials to persist, move laterally, and retain legitimate-looking access even after the malware is removed.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Cloud identity visibility is the control gap VoidLink exploits. The framework is not just a malware story, it is a proof that attackers can outsee defenders in cloud estates where applications, service accounts, and secrets are poorly inventoried. When teams cannot map which identity belongs to which workload, they cannot tell whether a credential is merely exposed or fully usable. Practitioners should treat application and identity mapping as a baseline operational control, not an advanced maturity goal.

Encrypted secrets lose meaning when decryption logic sits next to the secret. VoidLink shows the failure mode clearly: if the secret, key, and execution context all live in the same trust boundary, the attacker needs only file-system access to recover usable credentials. That is not a weakness in encryption itself. It is a governance failure in how secrets are deployed across code, config, and runtime. Practitioners should recognise this as credential co-location risk, not simple secret sprawl.

Identity theft is now a persistence technique, not just an access technique. The framework’s use of metadata credentials, service account tokens, and pipeline secrets demonstrates that cloud attackers increasingly prefer valid access over noisy exploitation. That shifts the security problem from binary removal to identity invalidation. Security teams need to think in terms of blast radius and trust relationships across applications, accounts, and clusters, because the compromised identity often remains useful after the malware disappears.

What fails here is the assumption that endpoint detection closes the incident. EDR can detect the implant, but it does not automatically reveal which identities were harvested or which permissions they retained. That assumption was designed for host-centric malware response. It fails in cloud-native compromise because the malware’s real payload is the stolen identity, not the binary itself. The implication is that post-exploitation governance has to start from identity, not from the infected host.

Identity blast radius is the right named concept for this pattern. VoidLink makes the blast radius visible only if teams already know the relationship between applications, permissions, and secrets. Without that map, remediation becomes guesswork and revocation is delayed or incomplete. The practical conclusion is that cloud identity governance must be built to answer impact questions as fast as it answers authentication questions.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Another finding from the same research shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when credentials are harvested.
• For a broader view of how identity exposure turns into breach impact, see 52 NHI Breaches Analysis for recurring compromise patterns and root causes.

What this signals

Identity blast radius management is becoming a cloud operating requirement. As environments grow more dynamic, the practical question is no longer whether teams can detect malware, but whether they can answer what an identity can reach before an attacker reuses it. The organisations that still treat secrets as isolated artefacts will keep discovering that the real control failure is trust mapping, not detection.

With 96% of organisations storing secrets outside secrets managers in code, config files, or CI/CD tools, according to Ultimate Guide to NHIs, cloud compromise will keep finding identity material at the edge of application delivery. That makes lifecycle visibility, not just rotation policy, the programme pressure point.

Credential co-location risk: when the secret and the means to unlock it sit in the same boundary, defenders have only obscurity between them and compromise. That should change how teams design pipeline controls, application packaging, and incident response for workload identities.

For practitioners

• Map application-to-identity ownership Create and maintain an inventory that ties each workload, container, and pipeline to the exact NHIs and secrets it can use. Without that map, compromise response becomes guesswork and revocation misses the real access path.
• Separate secrets from local decryption logic Remove the decryption key, routine, or token broker from the same boundary as the stored credential. If file-system access exposes both the secret and the means to unlock it, encryption is only hiding the problem.
• Reduce standing privilege on cloud NHIs Review service accounts, metadata roles, and CI/CD tokens for excess permission and long-lived validity. Focus on where temporary credentials can still be reused after initial detection, especially across account and cluster trust relationships.
• Forward identity telemetry in real time Send login, token use, and workload identity audit data to the SIEM as events happen, not after host collection. Malware that deletes evidence on disk makes delayed forensics unreliable and slows containment.

Key takeaways

• VoidLink shows that cloud malware is increasingly built to steal identity rather than simply damage systems.
• The scale of the problem is already visible in NHI research, where secrets sprawl and over-privilege remain common conditions.
• Teams that cannot map identities to applications will struggle to contain, revoke, and measure the impact of cloud-native compromise.

Key terms

• Cloud Metadata Credential: A cloud metadata credential is a temporary access token issued to a workload by the platform’s instance metadata service. It is meant for machine-to-machine use, but if malware can query the metadata endpoint, the token can be stolen and reused as legitimate access.
• Identity Blast Radius: Identity blast radius is the range of systems, accounts, and data that a stolen identity can reach before it is revoked. In cloud environments, it depends on permissions, cross-account trust, and whether teams can quickly map the identity to the applications that use it.
• Credential Co-location Risk: Credential co-location risk occurs when a secret and the means to decrypt or use it are stored in the same trust boundary. This makes local compromise enough to recover usable credentials, turning encryption or obfuscation into only a thin delay rather than a control.

What's in the full article

Orchid Security's full blog post covers the technical sample details this analysis intentionally leaves for the source:

• Step-by-step breakdown of the credential harvesting functions found in the sample binary
• Kubernetes service account token stealing details from /var/run/secrets/kubernetes.io/serviceaccount/token
• Indicators of compromise including file hashes and the network C&C address
• Additional rootkit and evidence-wiping behaviour described in the malware sample

👉 Orchid Security's full post includes the malware sample details, credential paths, and IOCs

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 responsible for identity security strategy or programme maturity, it is worth exploring.