Listen to this Post
Introduction:
The open-source ecosystem is facing a sophisticated new attack chain that targets developers working with SAP’s CAP (Cloud Application Program) framework. Attackers have successfully compromised popular npm packages, embedding credential-stealing malware that executes during installation, self-propagates through GitHub Actions, and even weaponizes AI coding agent configurations to ensure persistence. This technical deep dive provides a playbook for detection, analysis, and defense against this “Mini Shai-Hulud” campaign.
Learning Objectives:
- Detect and analyze malicious `preinstall` hooks and `setup.mjs` loaders in npm packages.
- Identify and block the malware’s self-propagation mechanisms, including rogue GitHub Actions and AI agent config injections.
- Harden CI/CD pipelines and OIDC configurations to prevent unauthorized token exchanges and publish rights.
You Should Know:
1. Initial Compromise and Payload Delivery Analysis
The attack begins when a developer installs a compromised package version (e.g., [email protected], @cap-js/[email protected], @cap-js/[email protected], @cap-js/[email protected]). The malicious `preinstall` script in `package.json` triggers setup.mjs, which downloads and executes a 11.6 MB Bun-based payload from GitHub Releases. Below are commands to inspect your environment and block the initial callbacks.
Linux (Inspect package.json for anomalies):
Check for suspicious preinstall scripts
grep -A 5 -B 5 "preinstall" package.json
Recursively search for 'setup.mjs' references
find . -name ".mjs" -exec grep -l "setup" {} \;
Windows (PowerShell – Identify malicious activity):
Look for PowerShell downloads with Bypass policy
Get-WinEvent -LogName "Windows PowerShell" | Where-Object { $<em>.Message -match "ExecutionPolicy Bypass" -and $</em>.Message -match "download" }
Check for recently created .mjs files recursively
Get-ChildItem -Recurse -Filter ".mjs" | Select-String "bun"
Step‑by‑step guide to detect and isolate the payload:
- Review package.json Changes: Immediately after any
npm install, run `git diff package.json` to spot newly added `preinstall` or `postinstall` scripts. - Network Monitoring: Block outbound connections to raw GitHub user content URLs (e.g., `https://raw.githubusercontent.com/`). Use a local firewall or egress proxy to alert on any `curl` or `wget` calls to these domains.
- Payload Carving: If compromise is suspected, extract the `setup.mjs` file and the downloaded Bun binary. Run a YARA rule to hunt for encoded strings referencing “Shai-Hulud” or “RSA-4096” public keys.
2. Credential Harvesting and Exfiltration via Victim-Owned Repos
Once executed, the malware scans for local developer credentials, GitHub and npm tokens, GitHub Actions secrets, and cloud provider keys (AWS, Azure, GCP, Kubernetes). It then encrypts this data using AES-256-GCM and wraps the key with an attacker-controlled RSA-4096 public key, making decryption impossible without the private key. Exfiltrated data is stored in public GitHub repositories created on the victim’s own account, with the description “A Mini Shai-Hulud has Appeared”.
Linux (Search for exposed tokens and keys):
Check for GitHub tokens in .git/config or environment grep -r "github_pat_" ~/.config/ grep -r "ghp_" ~/.bashrc ~/.zshrc Audit cloud credential files ls -la ~/.aws/credentials ~/.config/gcloud/ ~/.azure/
Windows (Audit credential managers):
Check for stored GitHub credentials in Windows Credential Manager cmdkey /list | findstr "github" Review environment variables for tokens Get-ChildItem Env: | findstr "TOKEN KEY SECRET"
Step‑by‑step guide to detect and block exfiltration:
- Scan Public Repositories: Use GitHub’s search API to locate repos with the suspicious description.
curl -H "Accept: application/vnd.github.v3+json" "https://api.github.com/search/repositories?q=%22A%20Mini%20Shai-Hulud%20has%20Appeared%22"
Any results in your org require immediate incident response.
-
Monitor GitHub Audit Logs: For enterprise accounts, query for `repo.create` events with an anomalous description.
- Egress Filtering: Implement a network rule to block HTTPS POST requests to `api.github.com/user/repos` from CI runners unless explicitly required.
3. Self‑Propagation Through Malicious GitHub Actions Workflows
The malware exploits the stolen GitHub and npm tokens to inject a rogue GitHub Actions workflow into the victim’s repositories. This workflow, when triggered, steals repository secrets and publishes new poisoned versions of the npm packages to the registry. The attack is particularly insidious because the malicious OIDC token exchange can occur from any branch—not just the main branch—due to overly permissive trust policies.
Step‑by‑step guide to detect and remediate:
- Inspect CI/CD Logs: Look for workflows that unexpectedly request `id-token: write` permissions.
Search for suspicious workflow files find .github/workflows -name ".yml" -exec grep -l "id-token: write" {} \; - Review OIDC Trust Policies: Ensure npm trusted publishers are restricted to specific workflow files and branches. The attack succeeded because the configuration for `@cap-js/sqlite` trusted any workflow in the repository, not just the canonical `release-please.yml` on main.
- Revoke and Rotate Tokens: Immediately revoke any compromised npm OIDC tokens and rotate GitHub personal access tokens (PATs).
-
Weaponizing AI Coding Agents ( Code & VS Code) for Persistence
In a novel twist, the malware persists by injecting a `./settings.json` file that abuses Code’s `SessionStart` hook and a `.vscode/tasks.json` file with the `”runOn”: “folderOpen”` setting. Any attempt to open the infected repository in VS Code or Code will re‑execute the malware. This is one of the first supply chain attacks to target AI coding agent configurations as a persistence vector.
Step‑by‑step guide to clean AI agent configs:
- Remove Malicious Hooks: Delete any `./settings.json` and `.vscode/tasks.json` that contain `”SessionStart”` or `”folderOpen”` with unknown commands.
find . -name "settings.json" -path "/./" -delete find . -name "tasks.json" -path "/.vscode/" -exec grep -l "folderOpen" {} \; -delete - Disable Automatic Execution: Configure VS Code to require confirmation before running tasks on folder open. Set `”task.autoDetect”: “off”` in your user settings.
- Audit AI Agent Logs: Check Code logs for unexpected session starts or command executions.
-
Cloud Hardening: AWS, Azure, GCP, and Kubernetes Secrets Protection
The malware specifically targets cloud provider secrets. Stolen AWS access keys, Azure service principals, GCP service account keys, and Kubernetes `kubeconfig` files are encrypted and exfiltrated. The following mitigations are critical.
Step‑by‑step hardening commands:
1. AWS (Restrict Key Usage):
List all IAM users with access keys older than 90 days aws iam list-access-keys --user-name <username> --query "AccessKeyMetadata[?CreateDate<='$(date -d '90 days ago' --iso-8601=seconds)']"
Enforce a policy that denies actions unless MFA is present.
2. Azure (Restrict Service Principals):
List all service principals with high privileges
Get-AzADServicePrincipal | Where-Object {$_.DisplayName -like "highly-privileged"}
3. GCP (Audit Service Account Keys):
gcloud iam service-accounts keys list --iam-account=<SA_EMAIL> --managed-by=user
4. Kubernetes (Audit Secrets Mounts):
kubectl get secrets --all-namespaces -o json | jq '.items[].metadata.name'
6. Hardening npm OIDC Trusted Publisher Configurations
The root cause of this incident was an overly permissive OIDC trust policy that allowed any workflow in the repository to exchange a token for the package.
Step‑by‑step guide to secure OIDC:
- Pin Trusted Publishers to Specific Workflows: In the npm trusted publisher settings, specify the exact workflow file (e.g.,
.github/workflows/release-please.yml) and branch (e.g.,main). - Restrict `id-token` Permissions: Keep the `id-token: write` permission in a dedicated, locked-down environment, not a broad build workflow.
- Rotate Compromised Tokens: For the `mbt` package, which relied on a static “cloudmtabot” token, rotate to OIDC without any static secrets.
What Undercode Say:
- Key Takeaway 1: The shift-left movement has introduced dangerous new attack surfaces. Preinstall hooks are powerful and must be treated as untrusted code. Always review `package.json` changes before running
npm install, and consider using `npm install –ignore-scripts` in CI/CD pipelines for untrusted packages. - Key Takeaway 2: The weaponization of AI coding agents ( Code, VS Code) represents an emerging class of persistence mechanisms. Organizations must extend supply chain security to include IDE and AI tool configurations, treating them as part of the trusted compute base.
The “Mini Shai-Hulud” campaign is not just another npm malware scare; it’s a blueprint for multi-stage, cross‑platform supply chain attack that exploits the deepest layers of modern development workflows. By combining classic credential stealing with novel propagation and AI agent persistence, the attackers have raised the bar for what a “sophisticated” supply chain attack looks like. The security community must respond with equally adaptive defenses, including runtime application self-protection (RASP) for package managers and immutable CI/CD environments.
Prediction:
This attack will catalyze a wave of similar campaigns targeting other package managers and AI coding tools. Expect to see malware that specifically targets `.cursor` and `.copilot` configurations, as well as supply chain attacks that leverage OIDC misconfigurations to publish malicious packages from any branch. The industry will accelerate toward “zero-trust for CI/CD,” requiring signed provenance for all artifacts and mandatory OIDC branch pinning by default. Organizations that fail to harden their npm OIDC configurations and audit AI agent hooks will be the primary victims in the next 12 months.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Hackermohitkumar Alert – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
