Attacchi PaperCut Assistiti dall’IA Espongono una Seconda RCE e una Rete Globale di Vittime

Sintesi

Un attore di minacce di lingua russa ha condotto una campagna mirata contro l’infrastruttura ucraina, con un focus particolare sull’ecosistema di scambio dati e sui server di log Graylog. L’attaccante ha utilizzato una catena di iniezione JNDI basata su Log4Shell per ottenere l’esecuzione di codice remoto e distribuire shell inverse. Sebbene siano stati tentati diversi exploit contro i sistemi MikroTik e Fortinet, l’accesso principale riuscito si basi su una catena di deserializzazione riutilizzabile CommonsBeanutils2.

Indagine

L’indagine è iniziata dopo che i ricercatori hanno scoperto una directory di staging dell’operatore esposta su un indirizzo IP pubblico per circa 17 ore. Gli analisti hanno recuperato i file di lavoro dell’attaccante, inclusi script di exploit, costruttori di payload, cronologia della shell e output di ricognizione. Questa esposizione ha reso possibile la ricostruzione della catena completa di attacchi, dalla ricognizione masscan iniziale all’esecuzione riuscita del codice sulle istanze Graylog.

Mitigazione

Le organizzazioni dovrebbero dare priorità alla patch delle installazioni di Graylog e garantire che le ricerche JNDI siano disabilitate o strettamente limitate tramite i controlli di sicurezza Java appropriati. Dovrebbero essere applicati filtri egress rigorosi per bloccare connessioni LDAP e RMI non autorizzate dai server applicativi. I team di sicurezza dovrebbero anche monitorare i processi figlio insoliti generati dai servizi basati su Java e imporre protezioni CSRF sugli endpoint API sensibili.

Risposta

Quando viene rilevata un’attività JNDI sospetta o processi figlio imprevisti originati dai servizi web, isolare immediatamente l’host interessato. Rivedere i registri delle applicazioni per modelli di sfruttamento riusciti, con particolare attenzione all’endpoint /api/system/sessions . Condurre un’analisi forense a livello di host per chiavi SSH non autorizzate, shell inverse, o tunnel persistenti che potrebbero essere stati utilizzati per pivotare.

Esecuzione di Simulazione

• Narrativa & Comandi dell’Attacco: L’avversario sta tentando di sfruttare una vulnerabilità in un’applicazione web di scambio statale. Per mimetizzarsi con il traffico amministrativo, utilizzano un’intestazione specifica X-Requested-By: cli. Puntano all’endpoint di gestione delle sessioni /api/system/sessions e tentano di attivare l’esecuzione di uno script shell dannoso denominato fire3.sh. La presenza della stringa UXP Verifier nella risposta è una caratteristica nota dello specifico toolkit utilizzato da questo attore di minacce. L’obiettivo è ottenere l’esecuzione di codice remoto tramite il server web.

• Script di Test di Regressione:

  #!/bin/bash
  # Script di simulazione per attivare la regola di rilevamento
  # Questo simula una richiesta che soddisfa tutti e quattro i criteri di rilevamento
  
  TARGET_URL="http://localhost/api/system/sessions"
  
  echo "[+] Simulazione di richiesta di attacco mirato..."
  
  # Utilizziamo curl per imitare esattamente le intestazioni e il percorso della richiesta.
  # Nota: Poiché non possiamo controllare facilmente il 'ResponseBody' di un server reale 
  # senza ospitare un server mock, questa simulazione presuppone che i log siano 
  # generati da un proxy di intercettazione o da un servizio web mock che 
  # restituisce 'UXP Verifier'.
  
  curl -X POST "$TARGET_URL" 
       -H "X-Requested-By: cli" 
       -H "Content-Type: application/json" 
       -d '{"filename": "fire3.sh", "payload": "echo "UXP Verifier""}' 
       --verbose
  
  echo "[+] Comando di simulazione inviato."

• Comandi di Pulizia:

  # Nessuna modifica persistente effettuata al sistema, ma se un server mock è stato avviato:
  # pkill -f "python3 -m http.server"
  echo "[+] Pulizia completata."