Database delle minacce Malware Attacco alla catena di approvvigionamento di Miasma

Attacco alla catena di approvvigionamento di Miasma

Una nuova campagna di attacchi alla catena di fornitura del software, denominata Miasma, ha compromesso diversi pacchetti npm di @redhat-cloud-services. L'operazione è progettata per raccogliere credenziali e informazioni sensibili dagli ambienti di sviluppo, diffondendo al contempo un worm auto-propagante in grado di propagarsi ulteriormente negli ecosistemi di sviluppo software.

La campagna ricalca fedelmente le tattiche precedentemente associate a Mini Shai-Hulud , sfruttando l'esecuzione in fase di installazione, il furto di credenziali, la compromissione dei sistemi CI/CD, l'esfiltrazione di dati crittografati e meccanismi che consentono la propagazione a valle.

L’attribuzione rimane incerta

L'autore della minaccia Miasma non è stato ancora identificato in modo definitivo. L'attribuzione è complicata dal fatto che TeamPCP, noto anche come Replicating Marauder, TGR-CRI-1135 e UNC6780, aveva precedentemente rilasciato gli strumenti di attacco associati al worm Shai-Hulud come progetti open source. Questo sviluppo ha permesso ad altri gruppi di criminali informatici di replicare tecniche simili, rendendo l'attribuzione definitiva significativamente più difficile.

Pacchetti npm compromessi

I seguenti pacchetti npm sono stati identificati come interessati:

@redhat-cloud-services/vulnerabilities-client

@redhat-cloud-services/tsc-transform-imports

@redhat-cloud-services/topological-inventory-client

@redhat-cloud-services/sources-client

@redhat-cloud-services/rule-components

@redhat-cloud-services/remediations-client

@redhat-cloud-services/rbac-client

Raccolta di credenziali tramite logica di installazione offuscata

I ricercatori di sicurezza hanno scoperto che i pacchetti dannosi contengono un hook di preinstallazione offuscato, progettato per essere eseguito automaticamente durante l'installazione del pacchetto. Il malware prende di mira un'ampia gamma di risorse sensibili, tra cui segreti di GitHub Actions, token di autenticazione npm, credenziali cloud, segreti di Kubernetes e HashiCorp Vault, chiavi SSH, credenziali Git e altri file riservati archiviati sui sistemi compromessi.

Come osservato nelle precedenti campagne di Mini Shai-Hulud, il malware incorpora routine di esfiltrazione crittografate. Le informazioni rubate vengono trasmesse a api.anthropic.com:443/v1/api, mentre GitHub funge da canale di esfiltrazione alternativo. Questa strategia a duplice scopo dimostra l'intento non solo di rubare le credenziali, ma anche di utilizzarle come arma per compromettere ulteriormente la catena di fornitura del software.

I pacchetti di dati crittografati vengono inviati tramite l'API di GitHub e i messaggi di commit possono contenere la stringa:

'Se invalidi questo token, il computer del proprietario verrà distrutto.'

Tecniche di occultamento e meccanismi di propagazione

Il malware include diverse strategie volte a massimizzare la persistenza, eludere il rilevamento ed espandere l'accesso. Una caratteristica degna di nota è l'evitamento deliberato dell'esecuzione su sistemi in lingua russa, un comportamento già osservato nelle campagne GlassWorm nella catena di approvvigionamento.

Negli ambienti npm, il codice dannoso interagisce con gli endpoint di scambio di token OIDC e whoami, riconfeziona gli archivi software in tarball aggiornati e firma gli artefatti modificati utilizzando Sigstore. Le credenziali rubate vengono quindi esfiltrate in repository GitHub pubblici controllati dall'attaccante con la descrizione "Miasma: The Spreading Blight".

Gli investigatori hanno identificato il primo commit noto contenente questa descrizione, risalente al 29 maggio 2026, il che suggerisce l'inizio delle operazioni attive o una fase di test iniziale intorno a quella data.

All'interno degli ambienti GitHub, il malware enumera i repository accessibili tramite token compromessi, analizza le definizioni dei flussi di lavoro attraverso query GraphQL e inietta flussi di lavoro dannosi utilizzando la mutazione createCommitOnBranch. Questo approccio consente alle modifiche dannose di apparire come commit verificati e firmati crittograficamente.

Funzionalità avanzate di persistenza e escalation dei privilegi

L'analisi ha rivelato diverse funzionalità aggiuntive incorporate nel malware:

Tentativi di elevare i privilegi avviando container che montano la directory /etc/sudoers.d dell'host e concedono l'accesso sudo senza password ai runner CI.

Rilevamento di soluzioni di sicurezza per endpoint, tra cui CrowdStrike, SentinelOne, Carbon Black e StepSecurity Harden-Runner, prima dell'avvio di attività dannose.

Meccanismi di persistenza che iniettano un hook SessionStart in Anthropic Claude Code e creano file tasks.json dannosi configurati con 'runOn': 'folderOpen' per i progetti di Microsoft Visual Studio Code, garantendo l'esecuzione durante le sessioni di sviluppo future.

Maggiore attenzione alla compromissione dell’identità nel cloud

Una delle principali evoluzioni della variante Miasma è la maggiore attenzione alla raccolta di identità cloud. I nuovi moduli, mirati agli ambienti Google Cloud Platform (GCP) e Microsoft Azure, raccolgono informazioni su tutte le identità cloud accessibili da una macchina infetta.

Le varianti precedenti si concentravano principalmente sull'estrazione di segreti dagli ambienti cloud. L'aggiunta di strumenti di raccolta focalizzati sull'identità indica un cambiamento strategico verso l'ottenimento di accesso diretto al cloud e lo sfruttamento delle identità privilegiate all'interno delle infrastrutture cloud.

A complicare ulteriormente le operazioni di rilevamento, ogni infezione genera un payload crittografato in modo univoco. Questa personalizzazione ostacola significativamente il rilevamento basato sulle firme, il tracciamento del malware e la correlazione delle versioni tra i diversi incidenti.

Compromissione iniziale e infiltrazione nella catena di approvvigionamento

Le prove disponibili suggeriscono che la campagna abbia avuto origine dalla compromissione dell'account GitHub di un dipendente di Red Hat. Gli investigatori ritengono che l'account sia servito come punto di infezione iniziale, consentendo agli aggressori di iniettare codice dannoso nei pacchetti interessati.

Secondo quanto riferito, l'account compromesso avrebbe inserito commit orfani dannosi in due repository di Red Hat Insights, aggirando le procedure di revisione del codice stabilite e introducendo il payload dannoso nella catena di fornitura del software.

Linee guida per la risposta agli incidenti e la risoluzione dei problemi

Le organizzazioni che hanno installato le versioni dei pacchetti interessati devono isolare immediatamente i sistemi coinvolti, rimuovere i pacchetti dannosi, ruotare tutte le credenziali potenzialmente esposte, esaminare l'attività su GitHub e npm per individuare segni di accesso non autorizzato e verificare gli ambienti per individuare meccanismi di persistenza. Particolare attenzione deve essere prestata alle modifiche non autorizzate che coinvolgono:

~/.claude/settings.json, .vscode/tasks.json, .github/workflows/codeql.yml e .github/setup.js.

È inoltre necessario implementare rigorosi controlli di accesso sia negli ambienti di sviluppo che in quelli cloud.

Poiché il malware acquisisce capacità di esecuzione in background e persistenza all'interno degli strumenti di sviluppo, la semplice disinstallazione dei pacchetti npm interessati o l'eliminazione della directory node_modules non dovrebbero essere considerate una soluzione sufficiente.

Negli ambienti CI/CD, le esecuzioni dei flussi di lavoro interessati devono essere sospese immediatamente. Le organizzazioni devono invalidare gli artefatti di build creati durante il periodo di esposizione e verificare attentamente se release, immagini container, pacchetti npm, artefatti di distribuzione o altri componenti software siano stati generati dopo l'introduzione del pacchetto dannoso nell'ambiente.

Tendenza

I più visti

Caricamento in corso...