Shai-Hulud Infostealer Scans 469 Credential Locations

A recent Shai-Hulud infostealer worm variant has expanded the number of places it searches for credentials from 189 to 469, according to research published by GitGuardian in early August. The new target list covers developer workstations, continuous integration and continuous delivery (CI/CD) systems, cloud configurations, and even configuration files used by artificial intelligence development tools. An infostealer is malware designed to collect passwords, access tokens, and other login details from an infected machine, and credentials are the passwords or tokens that programs and people use to prove their identity. The change matters because attackers are no longer trying to break through trust barriers. They are collecting the existing credentials that already make trusted software systems work.

Software supply chains have always depended on trust. Developers trust package registries such as npm or Docker Hub. Organizations trust project maintainers. CI/CD systems trust the credentials and identities they are given, and applications trust the dependencies they download during a build. Attackers realized they do not need to break any of that trust. They only need to find where credentials and standing privileges already sit. That is why credential harvesting has become the core required element for infostealer worms to succeed. Shai-Hulud belongs to a growing class of supply chain attacks that search an already compromised environment for any credential that can help the attack continue.

The path from one stolen credential to the next is direct. A token found on a developer workstation might open access to source code, and that source code may contain cloud credentials, which can then grant access to infrastructure. A GitHub access token, which is a text string that lets a program or person access a GitHub account, may allow write access to additional repositories, while a package publishing credential can let an attacker publish software through a channel that developers already trust. Credentials become the connective tissue between one compromised environment and the next. Modern developer machines contain far more authentication material than the source repository alone. Credentials appear in expected places such as .env files, shell history, and package manager configuration, but they also hide in command line interface caches, CI/CD configuration files, integrated development environment settings, and increasingly in the configuration used by AI coding assistants. The attacker does not always know which credential matters most before collection begins, so it gathers what is available and sorts out what each one unlocks later.

Defenders should work the problem in the opposite direction, according to the GitGuardian analysis. Security teams need to identify which credentials matter most and address their exposure before an attacker can use them. Package publishing credentials deserve special attention because they turn credential theft into software distribution. Tokens that developers use to publish packages carry authority over a trusted package that other developers, build systems, and organizations will automatically consume. That trust is what attackers abuse. Organizations should reduce the number of standing publishing credentials available to steal and move toward short-lived, verified authentication through OpenID Connect (OIDC), a standard that lets a service verify identity without handing over a long-lived password, or similarly scoped mechanisms. Docker and GitHub Actions have recently pushed the ecosystem in this direction with stronger authentication and greater use of trusted publishing. Any long-lived publishing credential that remains should be treated as highly sensitive infrastructure.

Credentials also connect systems that security teams often manage separately. Security teams traditionally think in terms of source control security, CI/CD security, cloud security, endpoint security, and application security. But a single developer can authenticate to GitHub, npm, AWS, Kubernetes (a system that runs containerized applications across many machines), internal APIs, and build infrastructure in one normal day, and CI/CD pipelines often carry an equally diverse set of credentials. A credential left in a developer environment can represent authority somewhere completely different. The file might sit on a laptop while the credential controls a cloud resource or grants package publication rights. Where a secret is discovered tells only part of the story. Organizations working toward secrets management maturity also need to know whether the credential is valid, what identity it belongs to, what system accepts it, what privileges it carries, which environment it reaches, and who owns its remediation. That turns secrets detection into credential risk management.

Not every exposed secret creates the same risk. A list containing 100,000 secret findings does not represent 100,000 equally urgent incidents. Some credentials are already invalid, others reach disposable development environments, and a smaller number provide access to production databases, cloud infrastructure, deployment systems, or package publication. Treating those findings identically builds queues instead of reducing risk. The first priority should be to remove package publishing keys from cleartext. Developers and pipeline automation often write authentication keys to local configuration files as part of normal workflows, but a secret does not need to have been committed to Git to be available to malware running on the developer machine. That is one reason recent supply chain attacks increasingly target the working developer environment itself. The hardest publishing credential for an attacker to steal is one that does not exist. If it must exist, the shorter the window access can be granted, the better. The goal is to eliminate reusable publishing authority sitting in cleartext and move package publishing toward short-lived, identity-backed mechanisms where supported. OIDC-based trusted publishing is one example. Most cloud platforms are moving toward federated security token services such as AWS STS, which allow workload verification across platforms where artifacts are pushed.

After publishing credentials, organizations should focus on credentials that provide access to critical production systems. An exposed credential tied to an isolated development environment might create limited damage, while a valid credential with write access to production infrastructure is a different incident entirely. A useful short list includes production cloud accounts, databases containing customer information, signing infrastructure, Kubernetes clusters, deployment tooling, and administrative interfaces. The key question is what happens if an attacker does something malicious with stolen access. Validity is a useful filter, and determining the true blast radius helps prioritize which systems to ad