Erkennen von SHA1-Hulud: Die Logs müssen fließen

Sha1-Hulud hat sich wieder in unser Leben eingegraben, breitet sich schnell aus und verursacht mehr Zerstörung als je zuvor. Benannt nach dem berühmten Wurm aus dem Dune-Universum, betrifft dieser Angriff auch globale Unternehmen. Seit seiner ersten großflächigen Verbreitung am 16. September 2025 hat dieser Wurm seine Fähigkeit gezeigt, sich schnell und wirkungsvoll zu verbreiten – unter Nutzung der folgenden Techniken:

• Ausnutzen kompromittierter GitHub-Zugangsdaten von npm-Package-Entwicklern, um populäre npm-Pakete zu weaponizen. Zum Zeitpunkt der Erstellung dieses Artikels sind etwa 800 infizierte Pakete gemeldet, viele von ihnen sind weit verbreitet.
• Sobald die kompromittierten npm-Pakete heruntergeladen und installiert wurden, werden Zugangsdaten für GitHub, NPM-Package-Repositories und Cloud-Provider wie AWS und Azure gesammelt.
• Veröffentlichung der gesammelten Zugangsdaten in öffentlichen GitHub-Repositories. Bis jetzt wurden über 25.000 solcher Repositories eingerichtet.
• Verwendung der erbeuteten Zugangsdaten, um weitere NPM-Pakete zu kompromittieren.

Diese Variante enthält einige neue Verhaltensweisen, darunter:

1. Löschen von Daten im Home-Verzeichnis des Rechners, wenn keine verwertbaren Zugangsdaten gefunden werden
2. Nutzung von GitHub-Repository-Discussions zur Ausführung von C2-Kommandos auf einem kompromittierten Host – unter Verwendung eines selbst gehosteten GitHub-Actions-Runners für die Codeausführung.
3. Nutzung eines neuen Namensschemas für das Git-Repository, das exfiltrierte Zugangsdaten enthält: eine UUID, z. B. „aoy7angy5kwcq64fb7“, sowie verschiedene Beschreibungen wie „Sha1-Hulud: The Second Coming“.

Erkennungsmöglichkeiten und benötigte Logs

Es gibt verschiedene Möglichkeiten, SHA1-Hulud aufzuspüren, vorausgesetzt, Sie sammeln Logs aus den relevanten Quellen:

GitHub

GitHub Enterprise Audit Logging ist essenziell. Erkennungsmöglichkeiten umfassen:

1. Erstellung eines neuen öffentlichen Repositories mit einer zufälligen UUID als Namen und der Beschreibung „Sha1-Hulud: The Second Coming“.
2. Registrierung eines selbst gehosteten Runners mit dem Namen „SHA1HULUD“.
3. Erstellung eines GitHub-Actions-Workflows, der mit GitHub Discussions interagiert oder diese nutzt.

Endpoint

Wichtige Log-Quellen für die Erkennung am Endpoint umfassen Datei- und Prozessüberwachung (einschließlich Überwachung von Befehlszeilenparametern). Erkennungsmöglichkeiten umfassen:

1. Prozessaktivität, die die Ausführung des vorinstallierten Skripts setup_bun.js zeigt
2. Dateiaktivitäten, die auf das Herunterladen oder die Installation kompromittierter NPM-Pakete hinweisen
   • Listen der kompromittierten Pakete finden Sie hier und hier 
3. Schnelles Löschen von Dateien im Home-Verzeichnis des Benutzers auf dem betroffenen Rechner
4. Prozessaktivität Installation eines lokalen Runners für Github-Aktionen

Cloud-Anbieter

Wichtige Log-Quellen umfassen AWS CloudTrail Logs und Microsoft Entra ID Logs. Die wichtigste Erkennungsmöglichkeit in Cloud-Logs ist das Auffinden der Ernte von Cloud-Zugangsdaten durch Tools wie Trufflehog.

Beachten Sie, dass die Analyse der SHA1-Hulud-Malware andauert; es wird empfohlen, die Malware-Analysequellen regelmäßig auf neue Erkenntnisse zu überprüfen. 

Lassen Sie uns einige der Erkennungsmöglichkeiten genauer betrachten.

Relevante Queries und integrierte Regeln für Sumo Logic Cloud-SIEM-Kunden

GitHub-fokussiert

Diese Detection-Regeln konzentrieren sich auf GitHub-Aktivitäten und erfordern GitHub Enterprise Audit Logging. In der Sumo Logic-Dokumentation finden Sie Anweisungen zur Einbindung von GitHub Enterprise Audit-Logs.

Technik: Exfiltrierte Secrets werden in ein neues öffentliches Repository mit einer zufälligen UUID hochgeladen, mit der Beschreibung „Sha1-Hulud: The Second Coming“. 

Laut der Analyse von Step Security„fingerprintet SHA1_Hulud den Host, durchsucht Cloud-Vaults und scannt nach Secrets – alles exfiltriert als JSON-Blobs in ein neues öffentliches Repository mit zufälliger UUID und der Beschreibung ‚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 

Technik: Neuer selbst gehosteter Runner namens ‘SHA1HULUD’ auf kompromittiertem Host erstellt, um C2-Befehle auszuführen

Die Analyse von wiz.io berichtet, dass SHA1-Hulud „die infizierte Maschine als selbst gehosteten Runner namens ‘SHA1HULUD’ registriert“.

Query: Review self-hosted runner registration

Diese Query liefert selbst gehostete Runner, die innerhalb des angegebenen Zeitraums registriert wurden. Wie bei der oben genannten Repository-Query fehlt in den GitHub-Logs ein wichtiges Detail: der Name des Runners. Daher müssen Sie Repository-Namen, Benutzernamen und andere Metadaten wie User-Agent-Strings auf ungewöhnliche Aktivitäten prüfen.

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

Endpoint-fokussiert

Technik: Malware-Installation über das npm-Preinstall-Skript

Wie StepSecurity in der Analyse erklärt, installieren kompromittierte npm-Pakete SHA1-Hulud auf der Zielmaschine über ein Preinstall-Skript: „Der Angriff beginnt in dem Moment, in dem npm das Paket installiert, ausgelöst durch diesen Eintrag in der package.json:“

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

Query: Command Line of SHA1-Hulud Preinstall script

Die folgende Query durchsucht Prozess-Erstellungslogs nach Befehlszeilen, die dem Preinstall-Skript von SHA1-Hulud entsprechen:

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

Technik: Löschung beschreibbarer Dateien im Home-Verzeichnis des Nutzers

Laut dem Bericht von Koi:„Wenn die Malware sich nicht authentifizieren oder Persistenz aufbauen kann, versucht sie, das komplette Home-Verzeichnis des Opfers zu zerstören. Konkret löscht die Malware jede beschreibbare Datei, die dem aktuellen Nutzer in dessen Home-Ordner gehört.“

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

Die folgende Query durchsucht Microsoft-Sysmon-Logs mit Event-ID 23 oder 26 (File-Delete-Events), bei denen die gelöschte Datei im Home-Verzeichnis des Nutzers liegt:

_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

Hinweis: Idealerweise werden relevante Dateiaktivitäten bei der Dateisystemüberwachung über Logquellen wie Microsoft Sysmon (Event ID 23) oder Microsoft Object Access Auditing (Event ID 4600 und 4663) erkannt. Wir müssen jedoch sicherstellen, dass die Verzeichnisse, die uns interessieren, für Audits konfiguriert sind. Mit anderen Worten: Es ist schwierig, sicherzustellen, dass alle Dateiaktivitäten protokolliert werden. Es kann sein, dass wir uns auf andere Log-Quellen verlassen müssen. In diesem Fall suchen wir nach der Befehlszeile, die in Kois Analyse steht: 

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

Die folgende Query durchsucht Prozess-Erstellungslogs nach einer per Regex passenden Befehlszeile, die für SHA1-Hulud dokumentiert ist:

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

Cloud-fokussiert

Technik: Verwendung von Trufflehog zum Sammeln von Cloud-Zugangsdaten

Laut Aikido: „Die Malware nutzt anschließend ein automatisiertes Tool (TruffleHog), um nach sensiblen Informationen wie Passwörtern, API-Keys, Cloud-Tokens sowie GitHub- oder NPM-Zugangsdaten zu suchen.“

Regeln: Sumo-Logic-Regeln zur Erkennung von Trufflehog und Cloud-Secret-Enumeration

Sumo Logic stellt mehrere SIEM-Regeln zur Verfügung, um das Abgreifen von Geheimnissen zu erkennen, darunter auch die Verwendung von Trufflehog. Beispiele:

– 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

Empfohlene Schritte zur Schadensbegrenzung und -behebung

Mehrere der hier zitierten Analysen – darunter Panther Labs, StepSecurity und Akido – enthalten detaillierte Empfehlungen für die Behebung, z. B. Rotation von Secret-Keys, Löschen des selbst gehosteten Runners, Überprüfung der Nutzung von npm-Paketen, Analyse der CI/CD-Logs sowie Überprüfung von Repository-Erstellungen.

Fazit

Der SHA1-Hulud-Angriff ist ein weiteres Beispiel dafür, wie wichtig eine umfassende Protokollierung ist, die nicht nur die Endpunkte, sondern auch die CI/CD-Pipeline und die Cloud-Präsenz Ihres Unternehmens umfasst. Umfassende Log-Erfassung ermöglicht den Einsatz von Detection-Regeln, die optimal an die jeweiligen Log-Quellen angepasst sind, und bietet damit die bestmögliche Chance, komplexe Angriffe frühzeitig zu erkennen.