Il 4 agosto 2026 un affiliato del ransomware Akira ha spento tutti i sensori di sicurezza di un endpoint aziendale con una mossa nota ma efficace: il riavvio forzato in Safe Mode with Networking tramite msconfig.exe. L'agent Huntress e Microsoft Defender real-time protection non sono partiti. La cifratura però non è avvenuta: il processo akira.exe ha generato errori "Out of Virtual Memory" e una cascata di PowerShell hard errors nel momento stesso in cui tentava di attivarsi. L'intero attacco, dall'accesso iniziale al crash del payload, è durato meno di cinque ore. I dati erano già stati esfiltrati.
- L'accesso iniziale è avvenuto il 4 agosto 2026 tramite credential spraying su una SonicWall SSL VPN priva di MFA.
- L'attaccante ha usato RDP per muoversi lateralmente verso il domain controller, ha enumerato Active Directory e ha esfiltrato i dati con WinRAR e s5cmd verso un bucket S3.
- Il riavvio in Safe Mode with Networking ha disattivato Huntress e Defender real-time protection per circa dieci minuti, creando una finestra senza EDR funzionante.
- Il payload ransomware è crashato per esaurimento della memoria virtuale in ambiente Safe Mode: la cifratura non è avvenuta, ma l'esfiltrazione dei dati era già completata.
Come l'attaccante ha costruito la compromissione
L'attacco inizia con il credential spraying contro un'istanza SonicWall SSL VPN sprovvista di multifactor authentication. Secondo la ricostruzione di Huntress, circa due ore separano il login VPN riuscito dalla prima connessione RDP al domain controller. L'attaccante opera con rapidità: in meno di cinque ore dall'accesso iniziale ha già completato l'intero ciclo offensive.
Una volta sul domain controller, l'attaccante apre in Notepad i file AdUsers.txt e AdComp.txt, prodotti dai comandi Get-ADUser e Get-ADComputer. L'enumerazione di Active Directory serve a mappare la rete e identificare target di valore. Parallelamente, l'attaccante archivia le share di rete con WinRAR e carica il materiale con s5cmd, tool da riga di comando per operazioni su storage S3. Questa è attività di double extorsion classica: rubare prima, cifrare dopo.
AnyDesk viene installato come servizio Windows per garantire accesso remoto persistente. Brinztech, che rielabora l'analisi Huntress con dettagli aggiuntivi sulla persistenza, segnala che l'attaccante ha preconfigurato AnyDesk nel registry hive SafeBoot: il tool di accesso remoto sopravvive al reboot in Safe Mode, mentre i servizi di sicurezza terzi restano offline per design.
La manovra in Safe Mode e il cieco accidentale
Il momento cruciale arriva quando l'attaccante esegue msconfig.exe e forza il reboot in Safe Mode with Networking. Questa modalità avvia solo i driver e i servizi essenziali di Windows: per costruzione, i servizi di terze parti inclusi gli agent EDR non partono. Huntress conferma che il proprio agent e Microsoft Defender real-time protection erano entrambi inattivi per l'intera durata della finestra Safe Mode.
L'ambiente Safe Mode però ha un profilo risorse drasticamente ridotto. La memoria virtuale è vincolata rispetto alla modalità operativa normale. Quando il payload akira.exe tenta di attivarsi, il processo entra in starvation di memoria:
"Safe Mode boots with a stripped-down environment and constrained virtual memory, and the Akira process tree appears to have starved it, getting the 'Out of Virtual Memory' pop-up and the cascade of PowerShell hard errors line up exactly with the moment the payload tried to kick things off"
— Huntress
Il sistema rimane in Safe Mode per circa dieci minuti. Il payload non cifra nulla. Defender, in uno scan schedulato, rileva il file eseguibile ma non può rimuoverlo in Safe Mode: quarantena akira.exe solo dopo che l'attaccante ha riavviato in modalità normale.
Perché il fallimento della cifratura non è una vittoria
Huntress non lascia spazio all'ottimismo:
"The takeaway is a little uncomfortable. While Safe Mode blinded our controls, it may also have prevented the encryption it was meant to enable. That's a lucky side effect of the attacker's own mistake in these circumstances, not a defence you can plan around."
La citazione fissa il limite concettuale: il crash per memory starvation è un artefatto delle circostanze, non una protezione affidabile. Huntress aggiunge una variabile tecnica critica: un host con più memoria fisica o un page file più ampio avrebbe potuto fornire a akira.exe memoria virtuale sufficiente per completare la cifratura in Safe Mode.
Il dato operativo più rilevante è che l'esfiltrazione era già terminata. La vittima conserva i file intatti, ma l'attaccante conserva le copie. La posta in gioco del riscatto non dipende più dalla cifratura: i dati rubati restano un'arma di estorsione indipendentemente dal destino del payload.
Cosa fare adesso
Le raccomandazioni derivano direttamente dai fatti documentati nell'incidente:
- Abilitare il multifactor authentication su tutti i punti di accesso VPN perimetrali: l'assenza di MFA sulla SonicWall SSL VPN è stata la condizione che ha permesso l'accesso iniziale.
- Monitorare l'esecuzione di
msconfig.exee le modifiche alla configurazione di boot, con attenzione specifica agli Event ID 27 e 12 che segnalano cambiamenti della boot configuration. - Controllare il registry SafeBoot per servizi aggiunti in modo anomalo: AnyDesk e tool di accesso remoto simili possono essere preconfigurati per sopravvivere al reboot in Safe Mode.
- Rivedere i criteri di allineamento tra esfiltrazione e risposta: la velocità dell'attacco, meno di cinque ore, comprime drasticamente la finestra temporale per l'intervento manuale prima che i dati siano già fuori rete.
Una tattica che non resterà unica
Questa è la prima osservazione nella telemetry Huntress di Safe Mode impiegato in un attacco Akira. La tattica in sé non è innovazione del panorama ransomware: altri gruppi l'hanno già usata. La novità è la documentazione dettagliata del trade-off operativo. Gli attaccanti che conoscono le architetture EDR sanno che Safe Mode li rende invisibili. Sembrano non aver calcolato che lo stesso ambiente minimale può uccidere il proprio payload per resource starvation.
Il limite del dossier è significativo: non emerge se altri affiliati Akira stiano già usando questa tattica con successo, né se il payload sia stato modificato dopo l'incidente per ridurre i requisiti di memoria. L'identità specifica dell'operatore resta sconosciuta, così come il volume esatto dei dati esfiltrati e l'esito eventuale delle trattative di riscatto.
Per le difese aziendali, l'insegnamento è contro-intuitivo: non contare sulla sfortuna dell'avversario. Il rilevamento deve avvenire nelle fasi iniziali — VPN, RDP, enumerazione AD — perché una volta in Safe Mode l'EDR è spento e la partita si gioca su condizioni tecniche che il difensore non controlla.
Fonti
- https://www.infosecurity-magazine.com/news/akira-affiliate-crashes-ransomware/
- https://www.huntress.com/blog/akira-hits-safe-mode-ransomware-rebooting-around-edr
- https://www.brinztech.com/breach-alerts/brinztech-alert-akira-ransomware-affiliate-blinds-edr-via-safe-mode-reboot-but-memory-starvation-stalls-payload-encryption
- https://www.bleepingcomputer.com/news/security/akira-hackers-disable-edr-with-safe-mode-steal-data-but-fail-to-encrypt/
- https://support.huntress.io/hc/en-us
- https://www.bleepingcomputer.com/
- https://www.bleepingcomputer.com/tutorials/
- https://www.bleepingcomputer.com/download/
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.