Exfiltration‍

The malware builds a comprehensive JSON payload containing system information, environment variables, and data from all modules. It then creates a public repository via the GitHub /repos POST endpoint using the function makeRepo('Shai-Hulud'). The repository is public by default to ensure easy access for the command and control infrastructure.

The attack employs several evasion techniques including silent error handling (swallowed via catch {} blocks), no logging output, and disguising TruffleHog execution as a legitimate "security scan."

Indicators of Compromise

The following indicators can help identify systems affected by this attack:

GitHub Search Queries for Detection

Use these GitHub search queries to identify potentially compromised repositories across your organization:

Search for malicious workflow file

Replace ACME with your GitHub organization name and use the following GitHub search query to discover all instance of shai-hulud-workflow.yml in your GitHub environment.

https://github.com/search?q=org%3AACME+path%3A**%2Fshai-hulud-workflow.yml&type=code

Search for malicious branch

To find malicious branches, you can use the following Bash script:

# List all repos and check for shai-hulud branch
gh repo list YOUR_ORG_NAME --limit 1000 --json nameWithOwner --jq '.[].nameWithOwner' | while read repo; do
  gh api "repos/$repo/branches" --jq '.[] | select(.name == "shai-hulud") | "'$repo' has branch: " + .name'
done

File Hashes

• The malicious bundle.js file has a SHA-256 hash of: 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09

Network Indicators

• Exfiltration endpoint: https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7

File System Indicators

• Presence of malicious workflow file: .github/workflows/shai-hulud-workflow.yml

Suspicious Function Calls

• Calls to NpmModule.updatePackage function

Suspicious API Calls

• AWS API calls to secretsmanager.*.amazonaws.com endpoints, particularly BatchGetSecretValueCommand
• GCP API calls to secretmanager.googleapis.com
• NPM registry queries to registry.npmjs.org/v1/search
• GitHub API calls to api.github.com/repos

Suspicious Process Executions

• TruffleHog execution with arguments filesystem /
• NPM publish commands with --force flag
• Curl commands targeting webhook.site domains

Affected Packages

The following packages have been confirmed as compromised:

Immediate Actions Required

If you use any of the affected packages, take these actions immediately:

Identify and Remove Compromised Packages

# Check for affected packages in your project
npm ls @ctrl/tinycolor

# Remove compromised packages
npm uninstall @ctrl/tinycolor

# Search for the known malicious bundle.js by hash
find . -type f -name "*.js" -exec sha256sum {} \; | grep "46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09"

‍

Clean Infected Repositories

Remove Malicious GitHub Actions Workflow

# Check for and remove the backdoor workflow
rm -f .github/workflows/shai-hulud-workflow.yml

# Look for suspicious 'shai-hulud' branches in all repositories
git ls-remote --heads origin | grep shai-hulud

# Delete any malicious branches found
git push origin --delete shai-hulud

‍

Rotate All Credentials Immediately

The malware harvests credentials from multiple sources. Rotate ALL of the following:

• NPM tokens (automation and publish tokens)
• GitHub personal access tokens
• GitHub Actions secrets in all repositories
• SSH keys used for Git operations
• AWS IAM credentials, access keys, and session tokens
• Google Cloud service account keys and OAuth tokens
• Azure service principals and access tokens
• Any credentials stored in AWS Secrets Manager or GCP Secret Manager
• API keys found in environment variables
• Database connection strings
• Third-party service tokens
• CI/CD pipeline secrets

Audit Cloud Infrastructure for Compromise

Since the malware specifically targets AWS Secrets Manager and GCP Secret Manager, you need to audit your cloud infrastructure for unauthorized access. The malware uses API calls to enumerate and exfiltrate secrets, so reviewing audit logs is critical to understanding the scope of compromise.

AWS Security Audit

Start by examining your CloudTrail logs for any suspicious secret access patterns. Look specifically for BatchGetSecretValue, ListSecrets, and GetSecretValue API calls that occurred during the time window when the compromised package may have been installed. Also generate and review IAM credential reports to identify any unusual authentication patterns or newly created access keys.

# Check CloudTrail for suspicious secret access
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=BatchGetSecretValue
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ListSecrets
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue

# Review IAM credential reports for unusual activity
aws iam get-credential-report --query 'Content'

GCP Security Audit

For Google Cloud Platform, review your audit logs for any access to the Secret Manager service. The malware uses the @google-cloud/secret-manager library to enumerate secrets, so look for unusual patterns of secret access. Additionally, check for any unauthorized service account key creation, as these could be used for persistent access.

# Review secret manager access logs
gcloud logging read "resource.type=secretmanager.googleapis.com" --limit=50 --format=json

# Check for unauthorized service account key creation
gcloud logging read "protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey"

Monitor for Active Exploitation

Network Monitoring

• Block outbound connections to webhook.site domains immediately
• Monitor firewall logs for connections to https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7

Implement Security Controls

GitHub Security Hardening

• Review and remove unnecessary GitHub Apps and OAuth applications
• Audit all repository webhooks for unauthorized additions
• Check deploy keys and repository secrets for all projects
• Enable branch protection rules to prevent force-pushes
• Turn on GitHub Secret Scanning alerts
• Enable Dependabot security updates

Ongoing Monitoring

• Set up alerts for any new npm publishes from your organization
• Monitor CloudTrail/GCP audit logs for secret access patterns
• Implement regular credential rotation policies
• Use separate, limited-scope tokens for CI/CD pipelines

‍

For StepSecurity Enterprise Customers

The following steps are applicable only for StepSecurity enterprise customers. If you are not an existing enterprise customer, you can start our 14 day free trial by installing the StepSecurity GitHub App to complete the following recovery step.

‍
Use NPM Package Cooldown Check

The NPM Cooldown check automatically fails a pull request if it introduces an npm package version that was released within the organization’s configured cooldown period (default: 2 days). Once the cooldown period has passed, the check will clear automatically with no action required. The rationale is simple - most supply chain attacks are detected within the first 24 hours of a malicious package release, and the projects that get compromised are often the ones that rushed to adopt the version immediately. By introducing a short waiting period before allowing new dependencies, teams can reduce their exposure to fresh attacks while still keeping their dependencies up to date.

Here is an example showing how this check protected a project from using the compromised versions of packages involved in this incident:

https://github.com/step-security/test-reporting/pull/16/checks?check_run_id=49850926488