Dentro un attacco ransomware

Negli ultimi mesi il panorama del ransomware ha subito un cambiamento profondo. Non parliamo più di poche gang dominanti facilmente riconoscibili dai loro “marchi di fabbrica”, ma di un ecosistema frammentato in cui broker di accesso iniziale, affiliati e sviluppatori si dividono i compiti come in una catena di montaggio criminale. Il risultato? Attacchi sempre più difficili da prevedere e da bloccare con i metodi tradizionali.

Un caso analizzato di recente dagli analisti di Darktrace, azienda specializzata in cybersecurity basata su intelligenza artificiale, offre uno spaccato molto concreto di come si sviluppa oggi un’intrusione ransomware — e soprattutto di quante occasioni ci siano, lungo il percorso, per fermarla prima che sia troppo tardi.

Un attacco che non assomiglia a nessun gruppo noto

Nel caso in questione, l’attacco non è stato attribuito a nessuna gang ransomware conosciuta. Nessun payload malevolo riconoscibile è comparso fino all’ultimissima fase. Questo è precisamente il punto: gli attaccanti moderni preferiscono sempre più spesso strumenti legittimi — di amministrazione IT, di penetration testing, di accesso remoto — piuttosto che malware “firmato” e quindi facilmente intercettabile dagli antivirus tradizionali.

Tra gli strumenti coinvolti c’era anche un framework di emulazione avversaria open source, nato per scopi di red teaming legittimo ma sempre più adottato dai criminali informatici come alternativa più “silenziosa” rispetto a soluzioni più note e ormai ben monitorate dai difensori.

Come si è sviluppata l’intrusione, giorno per giorno

L’attacco si è consumato nell’arco di pochi giorni, con una progressione quasi chirurgica:

Ingresso e ricognizione. Tutto è partito da credenziali VPN compromesse — probabilmente ottenute settimane prima tramite un broker di accesso iniziale. Nelle prime ore, gli attaccanti hanno condotto una scansione estesa della rete interna, sondando decine di porte e servizi con strumenti di penetration testing molto diffusi, mescolandosi così al traffico “normale”.

Escalation dei privilegi. Il giorno successivo, alcuni dispositivi hanno iniziato a usare credenziali amministrative in modo del tutto anomalo rispetto alle abitudini dell’ambiente. È stata rilevata anche una tecnica di abuso della replica di Active Directory, che permette di estrarre hash di password direttamente da un domain controller senza dover interagire con i singoli account utente — una tecnica nota per essere associata agli attacchi di tipo “DCSync” e molto efficace per ottenere credenziali privilegiate.

Movimento laterale e comando e controllo. Con tecniche “living-off-the-land” — cioè sfruttando strumenti di sistema legittimi come l’esecuzione remota via WMI, il protocollo RDP e la distribuzione di eseguibili tramite condivisioni amministrative — gli attaccanti si sono spostati lateralmente nella rete. In parallelo, sono comparse comunicazioni di comando e controllo instradate attraverso infrastrutture cloud pubbliche, un accorgimento sempre più comune per mimetizzarsi ed eludere i controlli basati su liste di IP sospetti.

Esfiltrazione dei dati. Prima ancora che partisse la cifratura, oltre 200 MB di dati sono stati trasferiti verso uno spazio di archiviazione cloud esterno mai osservato prima in quell’ambiente — un chiaro segnale di una strategia di doppia estorsione, in cui i criminali minacciano sia di bloccare i sistemi sia di pubblicare i dati rubati.

Cifratura. Solo nell’ultima fase è arrivato l’attacco vero e proprio: propagazione via SMB (compreso l’uso del vecchio e vulnerabile protocollo SMBv1) e cifratura massiva di migliaia di file in tutta la rete.

La lezione più importante: il problema non era il rilevamento

Il dato più significativo di questo caso non riguarda la sofisticazione dell’attacco, ma la sua tempistica. Le anomalie comportamentali erano visibili fin dal primo giorno: scansioni insolite, uso anomalo di credenziali privilegiate, connessioni verso destinazioni mai viste prima. Il sistema di rilevamento aveva individuato l’attività sospetta, ma le capacità di risposta automatica non erano state configurate su tutti i dispositivi coinvolti — lasciando che l’attacco proseguisse fino alla cifratura.

In altre parole: non è stata la visibilità a mancare, ma la velocità di reazione.

Come fa Darktrace a intercettare attacchi come questo

La ragione per cui Darktrace è riuscita a individuare l’anomalia fin dal primo giorno non è un caso isolato, ma il risultato diretto del proprio approccio tecnologico. Invece di basarsi su firme di malware note o su elenchi di minacce già catalogate — l’approccio classico di molti antivirus ed EDR — la piattaforma costruisce continuamente un modello di ciò che è “normale” per ogni utente, dispositivo e sistema all’interno di una determinata rete. Quando qualcosa si discosta da quel comportamento consueto, anche in modo sottile, il sistema è in grado di segnalarlo indipendentemente dal fatto che quella specifica tecnica sia già stata vista altrove o meno.

Questo approccio “self-learning” è ciò che ha permesso di intercettare, in questo caso, segnali che un sistema basato solo su firme avrebbe ignorato: una scansione di rete leggermente più ampia del solito, un account che usa privilegi amministrativi in modo insolito, una connessione verso uno storage cloud mai osservato prima. Nessuno di questi singoli eventi è di per sé “malevolo” in senso stretto — ma la loro combinazione, letta nel contesto del comportamento abituale di quella rete, racconta una storia molto diversa.

Alla parte di rilevamento si affianca poi la componente di risposta autonoma della piattaforma, pensata per intervenire in tempo reale senza attendere l’azione di un analista umano. In pratica, quando viene identificata un’attività sospetta, il sistema può isolare in modo mirato solo il dispositivo o l’account coinvolto — bloccando ad esempio una connessione anomala o impedendo l’esecuzione di un processo — cercando di limitare il danno senza interrompere il resto dell’operatività aziendale. È proprio questa capacità di intervenire “a bisturi” lungo ogni fase della catena d’attacco, dalla ricognizione iniziale fino alla cifratura, a fare la differenza rispetto a un approccio puramente basato su alert da analizzare manualmente.

Il caso descritto in apertura mostra però anche il limite pratico di questo modello: la tecnologia aveva rilevato l’anomalia fin dalle prime ore, ma la risposta autonoma non era stata attivata su tutti i dispositivi della rete. È la conferma di un principio che vale per qualunque strumento di difesa, per quanto avanzato: il rilevamento da solo non basta, se la capacità di reagire non è configurata per coprire l’intero perimetro.

Cosa possono imparare le aziende

Alcuni spunti pratici emergono con chiarezza da questo tipo di incidenti:

• Puntare sull’anomalia, non solo sulla firma. Se gli attaccanti usano strumenti legittimi già presenti in azienda, le difese basate su firme di malware noto diventano quasi inutili. Serve capire cosa è “normale” per la propria rete e accorgersi quando qualcosa si discosta da quel comportamento.
• Dare priorità alla ricognizione e all’escalation dei privilegi. Scansioni di rete insolite e abusi di Active Directory sono spesso i primi segnali concreti, ben prima che si arrivi a un vero danno.
• Isolare rapidamente le credenziali e i dispositivi sospetti. Disattivare credenziali VPN compromesse e mettere in quarantena i dispositivi coinvolti in attività anomale può interrompere l’attacco prima che si diffonda.
• Monitorare le destinazioni esterne insolite. Connessioni verso infrastrutture cloud mai viste prima, specialmente se seguite da trasferimenti di dati consistenti, meritano un’attenzione immediata.
• Colmare il divario tra rilevamento e risposta. Avere sistemi che generano allarmi non basta: la capacità di risposta automatica deve coprire l’intero ambiente, non solo una parte di esso.

In sintesi

Questo tipo di attacco conferma una tendenza ormai consolidata: gli aggressori investono sempre meno in malware personalizzato e sempre più nell’abuso di credenziali legittime, strumenti di amministrazione e infrastrutture cloud affidabili. In un contesto simile, il rilevamento basato sul comportamento diventa una necessità, non un’opzione — ma da solo non basta. Serve anche la capacità organizzativa e tecnologica di trasformare rapidamente un allarme in un’azione di contenimento, perché nella maggior parte dei casi il tempo a disposizione dei difensori si misura in ore, non in giorni.