ReliaQuest scopre OP-512, cluster cinese su IIS con web shell e AI agentica

OP-512, ReliaQuest, Agentic AI, cluster cinese, web shell IIS, spionaggio cyber, eBPF

ReliaQuest identifica un nuovo cluster di minaccia attribuito con confidenza moderata-alta alla Cina grazie alla propria piattaforma di Agentic AI, capace di correlare in tempo reale eventi sospetti apparentemente scollegati e trasformarli in un unico incidente ad alta priorità. Il cluster, denominato OP-512, conduce attività di spionaggio contro un server Internet Information Services compromesso e utilizza un framework di web shell custom progettato per resistere ai rilevamenti basati su firma. Ogni web shell viene generata in modo crittograficamente unico, si auto-segnala tramite query DNS hex-encoded e combina autenticazione RSA, cifratura RC4, timestomping e notifiche automatiche verso infrastruttura controllata dall’attaccante. L’operazione mostra una permanenza silente di almeno 75 giorni prima del deployment rapido dei payload e prende di mira server IIS legacy esposti su internet con .NET Framework 4.0 end-of-life. OP-512 rappresenta almeno il quarto cluster legato alla Cina osservato nell’ultimo anno contro infrastrutture IIS, ma non coincide con attori già documentati come CL-STA-0048, GhostRedirector o DragonRank. Il caso mostra due elementi centrali della difesa moderna: da un lato la crescente sofisticazione dei framework di accesso persistente su server legacy, dall’altro il valore operativo dell’AI agentica nella ricostruzione di intrusioni che la threat hunting manuale rischia di interpretare come eventi isolati.

L’Agentic AI di ReliaQuest ricostruisce l’intrusione come incidente unico

Il ruolo della Agentic AI di ReliaQuest è decisivo perché l’attività di OP-512 non si presenta inizialmente come una catena lineare evidente. La piattaforma correla un volume elevato di telemetrie sospette, eventi endpoint, anomalie DNS e attività del processo w3wp.exe, trasformando segnali separati in un’unica ricostruzione investigativa. Gli analisti di ReliaQuest validano manualmente i risultati prodotti dall’agente artificiale e confermano la presenza di un framework composto da tre web shell custom distribuite su un server IIS compromesso. L’AI consente di superare uno dei limiti storici della threat hunting tradizionale: l’incapacità di collegare rapidamente eventi deboli ma coerenti quando avvengono su tempi lunghi e attraverso tecniche di evasione differenti. Nel caso OP-512, il sistema identifica una sequenza che comprende accesso iniziale remoto, deployment di web shell, auto-segnalazione DNS, caricamento riflessivo di toolkit post-sfruttamento, tentativi di escalation privilegi e persistenza tramite artefatti compilati ASP.NET. La scoperta evidenzia come l’intelligenza artificiale applicata alla detection non sostituisca gli analisti, ma acceleri la fase di correlazione e riduca il rischio che un’intrusione sofisticata venga spezzata in alert separati e sottovalutati. In ambienti enterprise dove server legacy, applicazioni esposte e telemetrie distribuite convivono con volumi elevati di eventi, questa capacità diventa un vantaggio operativo concreto.

OP-512 si inserisce nel filone cinese contro server IIS legacy

OP-512 viene descritto da ReliaQuest come almeno il quarto cluster legato alla Cina osservato nell’ultimo anno contro server IIS. Il gruppo presenta alcune sovrapposizioni tattiche con operazioni già note, ma non corrisponde pienamente a nessun attore documentato. ReliaQuest assegna all’attribuzione cinese una confidenza moderata-alta sulla base del targeting, delle tecniche osservate, della qualità del tooling e della sovrapposizione parziale con cluster precedenti.

L’attore non utilizza strumenti commodity tipici di campagne finanziarie opportunistiche, ma investe in un framework custom con caratteristiche di sicurezza operativa avanzate. Il bersaglio è un server internet-facing che funge da punto di confine tra rete pubblica e ambiente interno, una posizione ideale per attività di spionaggio e pivot laterale. OP-512 condivide con CL-STA-0048 l’uso di query DNS hex-encoded, ma lo scopo tecnico è diverso: nel caso OP-512 la query codifica l’URL della web shell per auto-segnalazione, mentre CL-STA-0048 avrebbe usato la stessa logica per esfiltrare dati rubati. Questa somiglianza suggerisce risorse, playbook o ispirazioni condivise all’interno dell’ecosistema cinese, senza dimostrare una catena di comando unica. La convergenza sui server IIS legacy conferma però una priorità operativa chiara: sfruttare asset esposti, difficili da aggiornare e spesso collocati in zone di rete ad alto valore strategico.

La permanenza di 75 giorni mostra un’operazione paziente

Uno degli aspetti più rilevanti dell’incidente è la finestra temporale. L’attaccante accede al server almeno 75 giorni prima del rilevamento principale, poi resta in apparente latenza fino al momento del deployment rapido delle web shell. Il server compromesso esegue Windows Server 2016 con .NET Framework 4.0, componente end-of-life che non riceve aggiornamenti di sicurezza dal 2016. Questa condizione espone l’organizzazione a rischi strutturali perché combina sistema legacy, applicazione internet-facing e framework non più supportato. La telemetria EDR rileva attività di web shell anche su un host diverso associato al dominio ashx.lhlsjcb[.]com, poi l’attore torna e agisce in modo metodico. Il processo worker w3wp.exe scrive il primo file .aspx nella directory di upload dell’applicazione, attivando un file manager con canale di notifica C2 integrato. Nel giro di pochi secondi la web shell invia la propria posizione all’infrastruttura dell’attaccante tramite query DNS; se il DNS fallisce, il framework ricorre a una richiesta HTTP verso un server C2 separato. Poco dopo vengono distribuiti due handler .ashx per l’esecuzione comandi autenticata. La sequenza indica un avversario paziente nella fase di accesso ma estremamente rapido nella fase operativa, capace di stabilire canali multipli prima che un team di difesa possa reagire.

Il framework di web shell combina unicità, cifratura e timestomping

Il cuore tecnico di OP-512 è un framework composto da tre web shell: un file manager .aspx e due handler di comando .ashx. Ogni deployment risulta generato in modo unico, con nomi di variabili e metodi randomizzati, commenti junk, variabili morte e differenze strutturali sufficienti a produrre hash completamente diversi anche quando la logica operativa resta invariata. Questa unicità rende inefficaci le detection basate su firme statiche. Il framework introduce inoltre un meccanismo di controllo crittografico che limita l’esecuzione dei comandi solo a chi possiede la chiave privata corretta. Gli handler decodificano il body HTTP in base64, decrittano il payload con RC4, verificano la firma RSA con una chiave pubblica incorporata e solo dopo eseguono il comando. I due handler sullo stesso server utilizzano chiavi RSA differenti, creando una compartimentazione che riduce i danni in caso di compromissione di una singola chiave. Il framework integra anche timestomping automatico: scansiona file e sottodirectory circostanti, calcola il timestamp mediano di ultima modifica e sovrascrive i propri tempi di creazione e modifica per apparire vecchio di anni. La funzione accetta anche un timestamp esplicito, permettendo all’operatore di backdatare manualmente gli artefatti. Il risultato è una web shell che non solo evade le firme, ma si nasconde nel contesto storico e operativo dell’applicazione.

La web shell file manager si auto-segnala tramite DNS hex-encoded

Il file manager .aspx svolge una doppia funzione: consente operazioni sul filesystem e notifica automaticamente la propria posizione all’infrastruttura dell’attaccante. Ogni volta che la pagina viene visitata, la web shell codifica il proprio URL e lo trasmette come query DNS verso un dominio controllato da OP-512. La query contiene subdomain hex-segmentati lunghi e anomali, un pattern raro per il traffico legittimo di un server web. Se la notifica DNS non riesce, il framework usa un fallback HTTP verso un C2 separato. Un cooldown di cinque minuti evita trasmissioni troppo ripetitive e riduce il rumore operativo. Oltre alla notifica, il file manager supporta operazioni standard come list, read, write, upload, delete, rename e timestomping. Questa architettura permette all’operatore di distribuire rapidamente la web shell e lasciare che l’infrastruttura cataloghi automaticamente la sua posizione senza richiedere interazione manuale immediata. Il dettaglio ha conseguenze importanti anche per l’incident response: qualsiasi accesso alla web shell, persino da parte dei difensori durante l’analisi, può generare una nuova notifica verso l’attaccante. Per questo la gestione forense di artefatti web shell richiede isolamento preventivo dell’host, blocco del traffico outbound e controllo delle risoluzioni DNS prima di aprire o testare i file sospetti.

Gli handler .ashx usano RSA e RC4 per bloccare comandi non autorizzati

I due handler .ashx costituiscono il canale operativo per l’esecuzione comandi e mostrano una progettazione orientata alla compartimentazione. Ogni handler include una chiave pubblica RSA unica e accetta soltanto payload firmati dalla corrispondente chiave privata in possesso dell’attaccante. Prima dell’esecuzione, il body HTTP viene decodificato da base64, decrittato tramite RC4 e validato crittograficamente. Questo sistema impedisce a ricercatori, difensori o attori concorrenti di utilizzare facilmente la web shell anche dopo averla individuata. La logica è simile a quella di un impianto offensivo locked: il codice malevolo resta presente sul server, ma non risponde a comandi privi dell’autorizzazione corretta. I nomi randomizzati, i commenti junk e la struttura variabile rendono inoltre difficile creare regole YARA affidabili basate su elementi statici. La presenza di due handler indipendenti offre ridondanza operativa e consente all’attore di mantenere almeno un canale funzionante se l’altro viene rimosso o intercettato. Questa architettura dimostra che OP-512 non usa web shell generiche scaricate da repository pubblici, ma un framework progettato per ambienti ad alto rischio, dove la scoperta di un singolo componente non deve compromettere l’intera operazione.

Tool di post-sfruttamento caricati in memoria tentano l’escalation

Dopo il deployment delle web shell, l’attaccante carica quattro toolkit di post-sfruttamento direttamente nella memoria del processo w3wp.exe, evitando la scrittura su disco. Tre toolkit appartengono alla famiglia pubblica Potato: BadPotato, SweetPotato ed EfsPotato, strumenti noti per abusare di servizi Windows integrati e tentare l’elevazione da account limited-service a SYSTEM. Il quarto toolkit appare nella telemetria EDR come GhostKit, nome per il quale non risulta documentazione pubblica disponibile.

Analisi della Minaccia: L’utilizzo massiccio della famiglia di tool “Potato” per l’escalation dei privilegi su macchine Windows è un denominatore comune tra queste campagne. Tuttavia, il divario si crea sul payload finale: mentre i gruppi di spionaggio (come CL-STA-00481) si affidano a classici framework C2 come Cobalt Strike, attori come DragonRank3 sfruttano i server compromessi iniettando malware come BadIIS per intercettare il traffico dei crawler di Google e Bing, creando backlink fraudolenti e manipolando artificialmente il ranking dei siti web.

L’attaccante esegue comandi come whoami e whoami /priv codificati in base64, con una forma che ReliaQuest collega a playbook già osservati in operazioni attribuite a Flax Typhoon. La codifica identica non dimostra necessariamente identità di gruppo, ma suggerisce riuso di procedure, formazione o risorse operative condivise nell’ecosistema cinese. La prevenzione endpoint termina ripetutamente il processo malevolo attraverso rilevamenti comportamentali, ma IIS riavvia automaticamente il worker process e il tooling dell’attaccante può ricaricarsi su istanze successive. Questo loop evidenzia un limite critico della sola prevenzione endpoint: bloccare il processo non basta se il servizio lo rigenera e se le web shell restano accessibili. L’isolamento dell’host diventa quindi misura essenziale per interrompere la catena.

Le DLL ASP.NET compilate restano anche dopo la cancellazione delle web shell

Un dettaglio forense importante riguarda la persistenza degli artefatti compilati. ReliaQuest recupera quattro file DLL malevoli dalla directory di compilazione temporanea ASP.NET. Questi file vengono generati automaticamente quando pagine .aspx o handler .ashx vengono acceduti per la prima volta e possono restare su disco anche dopo la cancellazione dei file sorgente originali. Questo comportamento è spesso sottovalutato durante la bonifica di server IIS compromessi. Rimuovere la web shell visibile dalla directory dell’applicazione può non bastare se le DLL compilate persistono nella cache temporanea e conservano evidenze operative o potenziali possibilità di riattivazione. Nel caso OP-512, le DLL vengono rilevate e messe in quarantena circa 19 ore dopo la creazione, ma il dato conferma la necessità di un processo di remediation completo. I responder devono includere nella procedura il controllo delle directory temporanee ASP.NET, la pulizia delle cache di compilazione, il confronto dei timestamp, la revisione dei permessi e il riavvio controllato dei servizi IIS. In assenza di questa attenzione, un’organizzazione rischia di dichiarare rimosso l’impianto quando parte degli artefatti resta ancora sul sistema. La lezione operativa è chiara: nelle compromissioni IIS la web shell è solo la parte più visibile dell’impianto, non necessariamente l’unico componente da eliminare.

Il rilevamento comportamentale resta più efficace delle firme statiche

Il framework di OP-512 riduce quasi a zero l’utilità delle firme statiche tradizionali. Gli hash cambiano a ogni deployment, il codice viene offuscato, i nomi di variabili e metodi sono randomizzati, il traffico di comando è crittografato e i timestamp vengono manipolati per confondere la cronologia dei file. In questo contesto, il rilevamento più utile arriva dal comportamento. Il segnale principale è w3wp.exe che genera query DNS outbound con subdomain esadecimali lunghi e anomali, una condotta insolita per un normale server IIS. Anche il caricamento riflessivo di assembly .NET nel worker process, l’esecuzione di comandi base64, la presenza di toolkit Potato in memoria e la creazione di DLL compilate da file web sospetti costituiscono indicatori comportamentali ad alto valore. Il monitoraggio DNS al bordo di rete o sul resolver interno diventa quindi essenziale, soprattutto per server esposti su internet che normalmente dovrebbero generare pattern di traffico prevedibili. Stabilire baseline operative permette di distinguere tra richieste legittime e anomalie come notifiche hex-encoded. La vicenda OP-512 conferma che contro framework custom e crittograficamente unici la sicurezza deve spostarsi da IOC statici a telemetria, correlazione, comportamento e contesto. Qui l’Agentic AI di ReliaQuest mostra il proprio valore, perché collega segnali deboli e li ricompone in una catena coerente prima che la persistenza produca una compromissione più ampia.

OP-512 dimostra il rischio strutturale dei server IIS non modernizzati

L’incidente OP-512 espone un problema ricorrente nelle infrastrutture enterprise: server legacy ancora esposti su internet, componenti .NET fuori supporto, applicazioni custom difficili da migrare e servizi critici posizionati al confine tra rete pubblica e interna. Questi asset diventano bersagli ideali per attori statali perché garantiscono accesso persistente, possibilità di pivoting e superficie ampia per web shell custom. La sola presenza di un EDR non basta se il server resta raggiungibile, se il framework applicativo non è aggiornabile e se il servizio compromesso si rigenera automaticamente dopo ogni kill del processo. Le organizzazioni devono migrare i server IIS legacy, segmentarli in zone isolate, limitare il traffico outbound, monitorare DNS e HTTP verso domini anomali, rimuovere framework end-of-life e applicare controlli rigorosi sulle directory di upload. In assenza di una migrazione immediata, servono virtual patching, WAF, restrizioni di scrittura, allowlist applicative e log centralizzati ad alta fedeltà. OP-512 conferma che gli attori legati alla Cina continuano a investire su server IIS perché questi sistemi mantengono un valore strategico elevato e spesso sfuggono ai cicli di modernizzazione più rapidi. L’AI agentica accelera la detection, ma la riduzione del rischio passa ancora da igiene infrastrutturale, hardening e rimozione degli asset non supportati.