Detecting SHA1-Hulud: the logs must flow

Sha1-Hulud has burrowed back into our lives, spreading rapidly and causing more destruction than ever. Named after the famous worm from the Dune franchise, this attack is also impacting global organizations. Since its first widescale spread on September 16, 2025, this worm has demonstrated its ability to propagate rapidly with high impact using the following techniques:

• Exploit the compromised GitHub credentials of npm package developers to weaponize popular npm packages. As of this writing, there are approximately 800 infected packages reported, many of them widely used.
• Once the compromised npm packages are downloaded and installed, harvest credentials for GitHub, NPM package repositories and cloud providers such as AWS and Azure.
• Publish harvested credentials on public GitHub repositories. As of this writing, over 25,000 such repositories have been created.
• Employ the harvested credentials to compromise more NPM packages.

This variant includes some new behavior, including:

1. Deleting data in the home directory of the machine if no useful credentials are harvested
2. Using GitHub repository discussions to execute C2 commands on a compromised host, using a self-hosted GitHub actions runner for the code execution.
3. Using a new naming convention for the git repository containing exfiltrated credentials: a UUID, such as “aoy7angy5kwcq64fb7” for the name and different descriptions including “Sha1-Hulud: The Second Coming”

Detection opportunities and required logs

There are various opportunities for the detection of SHA1-Hulud provided you are collecting logs from the appropriate vantage points:

GitHub

GitHub Enterprise Audit logging is essential. Detection opportunities include:

1. Creation of a new public repo named with a random UUID, with description “Sha1-Hulud: The Second Coming”
2. Registration of a self-hosted runner with the name “SHA1HULUD”
3. Creation of GitHub Actions workflow that interacts with or uses GitHub Discussions

The endpoint

Log sources key to detection on the endpoint include file and process monitoring (process monitoring should include command-line auditing). Detection opportunities include:

1. Process activity showing the execution of setup_bun.js preinstall script
2. File activity indicating downloading or installation of compromised NPM packages
   • Lists of compromised packages can be found here and here 
3. Rapid deletion of files in the user’s home directory on the affected machine
4. Process activity installation of a local runner for github actions

Cloud providers

Key log sources include AWS CloudTrail logs and Microsoft Entra ID logs. The primary detection opportunity with cloud logs is detecting the harvesting of cloud credentials using tools such as Trufflehog.

Note that analysis of the SHA1-Hulud malware is ongoing, and you’re encouraged to revisit the malware analysis references for new information. 

Let’s explore some of the detection opportunities.

Relevant queries and built-in rules for Sumo Logic Cloud SIEM customers

GitHub-focused

These detections are focused on GitHub activity and require GitHub Enterprise Audit logging. Refer to the Sumo Logic documentation for instructions on ingesting GitHub Enterprise Audit logs.

Technique: Exfiltrated secrets are uploaded to a new public repo named after a random UUID, with description “Sha1-Hulud: The Second Coming” 

Per Step Security’s analysis, SHA1_Hulud “fingerprints the host, scavenges cloud vaults, and scans for secrets—all exfiltrated as JSON blobs to a new public repo named after a random UUID, with description “Sha1-Hulud: The Second Coming””

Query: Find repository created for exfiltrated credentials

This query will return new git repositories created over the time period specified. As mentioned above, the name of the repository will be a random string such as “aoy7angy5kwcq64fb7” and its description could be “Sha1-Hulud: The Second Coming.” Ideally, we could search for the description, but the GitHub create-repo.create logs do not include the repository description. You will need to scan the output for repository names that are UUIDs, perhaps refining your search for repositories with names of 18 or more characters.

_index=sec_record_audit metadata_product="GitHub Enterprise Audit" normalizedAction="create"
| where metadata_deviceEventId = "create-repo.create"
| count by user_username, repository 

Technique: New self-hosted runner named ‘SHA1HULUD’ created on compromised host to execute C2 commands

wiz.io’s analysis reports that SHA1-Hulud “registers the infected machine as a self-hosted runner named ‘SHA1HULUD’”.

Query: Review self-hosted runner registration

This query will return self-hosted runners registered within the specified time period. As with the create repo query above, the GitHub logs are missing one useful piece of information: the name of the runner. So, you will need to scan the repository, user names and other metadata such as user agent strings for unusual activity.

_index=sec_record_audit metadata_product="GitHub Enterprise Audit"
| where metadata_deviceEventId = "create-repo.register_self_hosted_runner"
| count by repository, user_username

Endpoint-focused

Technique: Malware installation via the npm preinstall script

As StepSecurity explains in their writeup, compromised npm packages install SHA1-Hulud on the victim machine via a preinstall script: “The attack begins the moment npm install the package, triggered by this entry in package.json:

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

Query: Command Line of SHA1-Hulud Preinstall script

The following query will search for process creation records matching the command line of the SHA1-Hulud preinstall script:

_index=sec_record_endpoint action="ProcessCreate"
| where commandLine matches /node\s+setup_bun\.js/

Technique: Writable files deleted from the user’s home directory

Per Koi’s writeup, “if the malware fails to authenticate or establish persistence, it attempts to destroy the victim’s entire home directory. Specifically, the malware deletes every writable file owned by the current user under their home folder.”

Query: Count of file deletions from users’ home directories (Windows)

The following query will search for Microsoft Sysmon logs with event ID 23 or 26 (file delete events) with the file deletion occurring in the user’s home directory:

_index=sec_record_endpoint
| where metadata_deviceeventId = "Microsoft-Windows-Sysmon/Operational-23" or metadata_deviceeventid = "Microsoft-Windows-Sysmon/Operational-26"
| where changetarget matches /C:\\Users.*/
| count by device_hostname

Note: Ideally, file activity of interest is detected with filesystem monitoring via log sources such as Microsoft Sysmon (event ID 23) or Microsoft Object Access Auditing (event ID 4600 and 4663). However, we have to ensure that the directories of interest are configured for auditing. In other words, it is difficult to ensure that all file activity is being logged. We may need to depend on other log source types. In this case, we will search for the command line noted in Koi’s writeup: 

Query: Command lines indicating file deletion from the home directory (Windows)

The following query will search for process creation records with a command line matching (via regex) a known command line used by SHA1-Hulud:

_index=sec_record_endpoint action="ProcessCreate"
| where commandLine matches /del\s+\/F\s+\/Q\s+\/S\s+C:\\Users/

Cloud-focused

Technique: Use of Trufflehog to harvest cloud credentials

Per Aikido, “It then uses an automated tool (TruffleHog) to search for sensitive information like passwords, API keys, cloud tokens, and GitHub or NPM credentials.”

Rules: Sumo Logic rules detecting Trufflehog use and cloud secret enumeration

Sumo Logic provides several SIEM rules to detect the harvesting of secrets, including the use of Trufflehog. Examples include:

– Trufflehog AWS Credential Verification Detected: MATCH-S00925

– First Seen IP Address Performing Trufflehog AWS Credential Verification: FIRST-S00086

– AWS CloudTrail – GetSecretValue from non Amazon IP: MATCH-S00246

– AWS Secrets Manager Enumeration: MATCH-S00825

Recommended mitigation and remediation steps

Multiple articles referenced here, such as those by Panther Labs, StepSecurity and Akido contained detailed remediation guidance such as the rotation of secret keys, deleting of the self-hosted runner, auditing npm package use, reviewing CI/CD logs and reviewing repository creation.

Final thoughts

The SHA1-Hulud attack is yet another example of the criticality of comprehensive logging, which spans the various technologies in use in your organization, including not only the endpoints but also your CI/CD pipeline and cloud presence. Comprehensive logging helps you take advantage of detection rules best-suited to the vantage point of the log source and provides you with the best chance of detecting complex attacks early.