UAT-10147 utilizza SPECTRE per la persistenza e l’evasione cross-platform

Riepilogo

UAT-10147 è un attore di minacce sinofono che opera un sofisticato ecosistema di post-exploitazione multi-piattaforma. Il suo toolkit include la backdoor multipiattaforma SPECTRE, il rootkit Specter per Linux e strumenti di frode SEO come BadIIS. L’attore utilizza anche tecniche avanzate tra cui Bring Your Own Vulnerable Driver (BYOVD) per disabilitare le protezioni EDR e incorpora workflow di sviluppo assistiti dall’intelligenza artificiale.

Indagine

Cisco Talos ha analizzato il codice sorgente recuperato e i campioni di malware per tracciare l’evoluzione degli strumenti di UAT-10147. L’indagine ha identificato segni di generazione di codice assistita da AI all’interno del rootkit Linux e distinti artefatti di sviluppo nel malware BadIIS. I ricercatori hanno anche documentato le strutture di comando dell’impianto SPECTRE, le tecniche di iniezione e le capacità di evasione della difesa a livello di kernel.

Mitigazione

Le organizzazioni devono rafforzare i server IIS e Linux esposti a internet e monitorare il dispiegamento di driver vulnerabili noti come RTCore64.sys and DBUtil_2_3.sys. Le configurazioni EDR forti dovrebbero essere applicate, con il monitoraggio per il caricamento non autorizzato di moduli kernel e la creazione sospetta di servizi systemd. Le difese dei server web dovrebbero includere anche l’audit per handler ASHX non autorizzati e intestazioni HTTP inaspettate come X-ID.

Risposta

Se viene rilevata un’attività UAT-10147, i server IIS o Linux compromessi devono essere immediatamente isolati per limitare il movimento laterale. I soccorritori dovrebbero condurre un’analisi forense dell’integrità del kernel e cercare flussi di dati alternativi NTFS non autorizzati. I log di sistema dovrebbero anche essere rivisti per l’installazione di servizi sospetti e il potenziale furto di credenziali tramite dumping dell’alveare del registro o enumerazione del gestore delle credenziali.

Esecuzione della Simulazione

Prerequisito: Il Telemetry & Baseline Pre-flight Check deve essere stato superato.

Motivo: Questa sezione dettaglia l’esecuzione precisa della tecnica avversaria (TTP) progettata per attivare la regola di rilevamento. I comandi e la narrazione DEVONO riflettere direttamente le TTP identificate e mirare a generare esattamente la telemetria che ci si aspetta dalla logica di rilevamento. Esempi astratti o non correlati porteranno a diagnosi errate.

• Narrazione e Comandi dell’Attacco: L’avversario ha ottenuto l’accesso iniziale tramite una vulnerabilità web. Per stabilire una persistenza profonda ed evitare il rilevamento, intendono distribuire un rootkit. L’attaccante prima genera una shell per stabilizzare la propria sessione. Poi esegue ps per vedere se sono in esecuzione processi di monitoraggio della sicurezza. Infine, usa insmod per caricare un modulo kernel dummy, imitando il metodo della variante SPECTRE di alterare il comportamento del kernel per il controllo remoto.

• Script di Test di Regressione:

  #!/bin/bash
  # Script di Simulazione Variante Linux di SPECTRE
  
  echo "[+] Avvio della simulazione della variante Linux di SPECTRE..."
  
  # 1. Simula l'Esecuzione della Shell (selection_shell)
  echo "[+] Passo 1: Esecuzione del comando shell..."
  /bin/sh -c "echo 'Accesso shell stabilito'"
  
  # 2. Simula la Scoperta dei Processi (selection_ps)
  echo "[+] Passo 2: Esecuzione della scoperta dei processi..."
  ps -ef | grep "simulazione"
  
  # 3. Simula il Caricamento del Modulo Kernel (selection_kernel_module)
  # Nota: Questo richiede sudo. Tenteremo di caricare un modulo dummy o di simulare il comando.
  # Per evitare di causare crash al sistema, useremo un nome di modulo inesistente 
  # che genera comunque la telemetria della riga di comando 'insmod'.
  echo "[+] Passo 3: Tentativo di caricare il modulo kernel tramite insmod..."
  sudo insmod spectre_rootkit_test.ko || echo "[!] insmod fallito come previsto (modulo non trovato), ma la telemetria dovrebbe essere generata."
  
  echo "[+] Simulazione completata."

• Comandi di Pulizia:

  # La pulizia è minima poiché abbiamo usato un nome di modulo inesistente per evitare l'instabilità del sistema.
  # Se è stato caricato un modulo reale, usare:
  # sudo rmmod spectre_rootkit_test
  echo "[+] Pulizia: Nessuna modifica persistente effettuata al kernel."