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

Sha1-Hulud hat sich wieder in unser Leben eingegraben, verbreitet sich rasant und richtet mehr Zerstörung an als je zuvor. Benannt nach dem berühmten Wurm aus dem Dune-Franchise, trifft dieser Angriff auch globale Organisationen. Seit seiner ersten großflächigen Verbreitung am 16. September 2025 hat dieser Wurm seine Fähigkeit unter Beweis gestellt, sich durch die folgenden Techniken schnell und mit hoher Schadwirkung auszubreiten:

• Er nutzt die kompromittierten GitHub-Zugangsdaten von npm-Paketentwicklern aus, um populäre npm-Pakete als Waffe zu missbrauchen. Zum Zeitpunkt der Erstellung dieses Berichts wurden etwa 800 infizierte Pakete gemeldet, von denen viele weit verbreitet sind.
• 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.
• Er veröffentlicht die erbeuteten Zugangsdaten in öffentlichen GitHub-Repositories. Zum Zeitpunkt der Erstellung dieses Berichts wurden bereits über 25.000 solcher Repositories erstellt.
• Er verwendet die 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

Die Protokollierung von GitHub Enterprise Audit ist unerlässlich. Zu den Entdeckungsmöglichkeiten gehören:

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 Erkennungen konzentrieren sich auf GitHub-Aktivitäten und erfordern das GitHub Enterprise Audit Logging. Informationen zum Importieren von GitHub Enterprise Audit-Logs finden Sie in der Sumo Logic-Dokumentation.

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

Diese Query gibt neue Git-Repositories aus, die in dem angegebenen Zeitraum erstellt wurden. Wie oben erwähnt, ist der Name des Repositorys eine zufällige Zeichenfolge wie „aoy7angy5kwcq64fb7“ und die Beschreibung könnte „Sha1-Hulud: The Second Coming“ lauten. Idealerweise könnten wir nach der Beschreibung suchen, aber die GitHub create-repo.create-Logs enthalten keine Repository-Beschreibung. Sie müsen die Ausgabe nach Repository-Namen durchsuchen, die zufällige Zeichenfolgen sind, und vielleicht die Suche nach Repositories mit Namen von 18 oder mehr Zeichen verfeinern.

_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 Abfrage liefert Ihnen alle Self-hosted Runner, die innerhalb des angegebenen Zeitraums registriert wurden. Wie schon bei der Abfrage zur Repository-Erstellung fehlt auch in den GitHub-Logs eine entscheidende Information: der Name des Runners. Daher müssen Sie die Repository- und Benutzernamen sowie weitere Metadaten, wie zum Beispiel User-Agent-Strings, auf ungewöhnliche Aktivitäten hin untersuchen.

_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 gilt: „Wenn es der Schadsoftware nicht gelingt, sich zu authentifizieren oder Persistenz zu etablieren, versucht sie, das gesamte Home-Verzeichnis des Opfers zu zerstören. Konkret löscht die Schadsoftware jede beschreibbare Datei im Besitz des aktuellen Benutzers innerhalb seines Home-Ordners.“

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 wird die relevante Dateiaktivität durch Dateisystem-Monitoring ü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 betreffenden Verzeichnisse auch für das Auditing konfiguriert sind. Mit anderen Worten: Es ist schwierig zu garantieren, dass sämtliche Dateiaktivitäten protokolliert werden. Daher müssen wir uns gegebenenfalls auf andere Logquellentypen verlassen. In diesem Fall suchen wir nach der Befehlszeile, die im Bericht von Koi erwähnt wurde: 

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 Secrets zu erkennen, einschließlich der Verwendung von Trufflehog. Beispiele hierfür sind:

– 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 für die entscheidende Bedeutung eines umfassenden Loggings. Dieses muss sich über alle in Ihrem Unternehmen eingesetzten Technologien erstrecken – von den Endpunkten über Ihre CI/CD-Pipelines bis hin zu Ihrer Cloud-Infrastruktur. Eine lückenlose Protokollierung ermöglicht es Ihnen, Erkennungsregeln optimal zu nutzen, die auf den jeweiligen Blickwinkel der Logquelle zugeschnitten sind. So haben Sie die beste Chance, komplexe Angriffe frühzeitig zu identifizieren.