A les 06:29:21 UTC del 4 d'agost, algú que era a dins des de tres quarts de quatre de la matinada va obrir msconfig.exe i va forçar un reinici. La màquina va tornar en Mode segur amb funcions de xarxa, que és una arrencada on Windows no carrega els serveis de tercers. L'agent d'EDR es va quedar fora. Defender va apuntar el seu propi error, 0x8007043c: «aquest servei no es pot iniciar en Mode segur».
El cas el va publicar Huntress el 12 d'agost, i hi ha una cosa que convé dir d'entrada: l'agent que es va quedar apagat era el seu. Ho expliquen igualment, amb els identificadors d'esdeveniment i les hores. Nosaltres gestionem EDR/MDR en parcs informàtics aliens i atenem guàrdies, així que l'informe es llegeix des d'aquí com una llista del que havíem d'haver vist.
La cronologia, amb les hores que hi ha i les que no
Tot el que segueix va en UTC, que és com ho publica Huntress. Dues fases de l'atac no porten hora a l'informe, i aquí tampoc no l'hi posarem.
- 03:45Ràfega d'intents fallits contra diversos usuaris de la VPN SSL d'un SonicWall, des de diverses IP externes. Una polvorització de credencials de llibre.
- 03:52:42Un compte vàlid entra des de
72.23.77[.]35. Uns set minuts després del primer intent, sense segon factor al davant. - +2 h«Gairebé dues hores» de silenci, diu l'informe, i llavors RDP al controlador de domini:
cmd.exeelevat, un ping i el bolcat complet del directori ambGet-ADUseriGet-ADComputeraAdUsers.txtiAdComp.txt. Sense hora publicada. - sense horaSalt al servidor d'aplicacions, WinRAR instal·lat a mitja intrusió per empaquetar les comparticions mapades i pujada a un bucket S3 de l'atacant amb
s5cmd. Tampoc no porta hora. - 06:29:21
msconfig.exei reinici forçat. L'arrencada escriuKernel-Boot27 ambLoadOptions = NOEXECUTE=OPTOUT SAFEBOOT:NETWORKiKernel-General12 ambBootMode = 2. Poc abans —l'informe no diu quant— havien registrat AnyDesk a la brancaSafeBoot\Networkper no quedar-se ells també fora. - 06:34:29Arrenca
akira.exe. A les 06:36:33 el sistema registra l'esdeveniment 26, «memòria virtual exhaurida», i un segon després PowerShell cau perquè no pot crear una pàgina de guarda per a la pila. - 07:43:50Una anàlisi programada de Defender identifica el binari com a
Ransom:Win32/Akira.B!ibt. La neteja falla un cop i un altre amb0x80004005: hi ha detecció i no hi ha remeiació, perquè la protecció en temps real continua morta. - 08:10:38L'atacant reinicia el host de tornada a mode normal. A les 08:12:28, amb la protecció en temps real carregada altra vegada, el fitxer cau en quarantena. El va treure del mig qui l'hi havia posat.
Una hora i quaranta-un minuts, no deu
Part de la cobertura del cas situa la finestra sense EDR en deu minuts. Aquesta xifra és a l'informe, però mesura una altra cosa: Huntress diu que la sessió d'AnyDesk, inclòs el reinici en Mode segur que la precedeix, va durar menys de deu minuts. La finestra cega és una altra frase, dos paràgrafs més amunt: durant tota la finestra de Mode segur, el host no va tenir EDR funcionant i l'antivirus estava encegat.
Aquesta finestra comença a les 06:29:21 i acaba a les 08:10:38. Són una hora, quaranta-un minuts i disset segons amb la màquina en xarxa, responent, sense agent i sense antivirus en temps real. La resta l'hem feta nosaltres sobre les hores que publica Huntress, perquè l'informe no dóna la durada.
El que va aturar el xifratge va ser la memòria
El Mode segur arrenca amb un entorn retallat i amb memòria virtual limitada. Huntress ho formula amb cura i nosaltres els copiarem la cautela: l'arbre de processos d'Akira sembla haver-la exhaurit, i el quadre de «memòria virtual exhaurida» encaixa exactament amb el moment en què el binari va intentar posar-se a treballar. La seva frase sobre això va sencera, perquè la segona meitat és la que importa: «un efecte secundari afortunat de l'error del mateix atacant en aquestes circumstàncies, no una defensa amb la qual es pugui comptar».
I hi afegeixen el detall que remata l'argument: un host amb més memòria física o amb un fitxer de paginació més gran podria haver donat a akira.exe memòria virtual suficient per xifrar en Mode segur. La mateixa intrusió, en un servidor amb 256 GB, acaba en un altre lloc. Així que el resum honest d'aquest incident inclou la paraula sort, i aquesta paraula no descriu mai l'incident: descriu el programa de seguretat que hi havia a sota.
Els fitxers van marxar abans del reinici
L'informe no data l'exfiltració, però sí que l'ordena: WinRAR sobre les comparticions mapades i pujada amb s5cmd abans del reinici de les 06:29:21, que al seu torn és anterior al xifrador de les 06:34:29. Quan l'atacant toca el binari, els fitxers ja són en un bucket que no és teu. Doble extorsió de llibre: el xifratge serveix per posar pressa a qui ja ha perdut les dades.
Convé dir-ho encara que ens deixi pitjor: una còpia de seguretat impecable no hauria canviat res del que va passar aquell dia. Et torna els fitxers i deixa intacta la palanca del xantatge. Venem backup gestionat i tot i així l'ordre correcte d'aquest post és l'accés primer, la vigilància després i la còpia com a xarxa de seguretat de sota. Si a més el teu servidor de còpies viu dins del mateix domini que acaben de bolcar sencer amb Get-ADComputer, això ja és un altre problema que vam escriure a part.
En Mode segur el teu agent no és imprescindible per a Windows
No hi va haver exploit, ni driver vulnerable signat, ni trucs de kernel. Hi va haver un msconfig.exe i un reinici, i la resta la va posar el disseny del sistema operatiu: el conjunt mínim de drivers i serveis exclou per definició els productes de seguretat de tercers. MITRE en té fitxa, la T1688, i Huntress recorda que famílies com Snatch i AvosLocker fa anys que ho fan. El que ells veuen per primera vegada és Akira fent-ho servir.
Encaixa amb el que es veu en el trimestre. Al seu informe del segon trimestre del 2026, Halcyon va comptar 1.988 atacs reivindicats públicament i 89 grups actius, amb Akira quart per volum amb 119. Infosecurity obria la seva peça sobre aquest informe resumint-ho així: apagar les eines de detecció abans de començar a xifrar s'ha convertit en procediment habitual a tot l'ecosistema del ransomware.
La línia que gairebé ningú no ha citat
És a l'apartat de mitigacions i es llegeix ràpid: en aquest entorn, l'agent era en una fracció de les màquines que l'atacant va enumerar. Aquí és on es prepara un atac, als hosts que ningú no mira, i per això el Get-ADComputer del principi no és una curiositat forense: és el mapa que li diu a l'atacant quins són. Un desplegament d'EDR amb forats converteix el teu inventari en l'inventari de l'altre.
Aquesta part ens toca de ple. Quan entrem en un parc informàtic aliè, el primer càlcul que fem a EDR/MDR gestionat és quants hosts hi ha al directori i quants tenen agent. La diferència entre aquests dos números és l'atac que encara no ha passat.
Les hores són UTC, i això canvia la conversa
Huntress no diu on era la víctima, així que traduir a hora local és un exercici nostre i no una dada del cas. Si això hagués passat a l'Espanya peninsular, la polvorització cau a les 05:45 i l'accés vàlid a les 05:52 —de matinada, sense ningú al davant—, i la finestra cega aniria de les 08:29 a les 10:10. A mig matí. Amb l'oficina oberta.
Preferim aquest escenari al del titular fàcil, perquè incomoda més. Una màquina que es reinicia sola i es queda sense agent durant una hora i tres quarts pot passar desapercebuda a les deu del matí d'un dimarts, amb tothom al seu lloc, i això no s'arregla contractant algú de nit. S'arregla amb el suport 24x7 connectat a la consola i amb una regla que digui que un agent callat desperta algú, sigui l'hora que sigui.
Set minuts a la porta
Tot l'anterior passa després. La porta era una VPN SSL amb usuari i contrasenya, i es va obrir en uns set minuts de polvorització. Tant se val com sigui de bo la resta si el perímetre cedeix amb una contrasenya reutilitzada, i d'això n'hem escrit ja amb un altre vestit: quan el que falla és el mateix equip del perímetre i quan hi ha camins d'autenticació que no arriben mai a demanar el segon factor.
Les mitigacions, en l'ordre en què les posa Huntress
La llista és seva i l'ordre també. Entre parèntesis hi va el que fem nosaltres amb cada punt, que és l'única cosa que hi posem de la nostra part:
- 1Caçar la polvorització abans que sigui un punt de suport. Alertar per ràfegues d'errors contra diversos usuaris des d'un mateix origen, i correlacionar-les amb un accés vàlid de la mateixa IP o el mateix ASN en una finestra curta. (Nosaltres ho muntem sobre els registres del mateix concentrador de VPN, que gairebé sempre hi són sense que ningú els miri.)
- 2Tancar la porta. MFA a tots els comptes de VPN, llista d'IP permeses mentre duri un atac, i rotació de credencials de VPN i de domini si hi ha hagut compromís, donant per exposat tot el que surti al bolcat de
Get-ADUser. (L'excepció «aquest compte de servei no pot portar MFA» és la que acaba sent la norma.) - 3Tancar els forats de cobertura. EDR a tots els hosts, i registres de VPN i de Windows en un SIEM: els primers accessos a la VPN es van veure hores abans de la detonació. (Aquest marge d'hores només existeix si algú rep l'alerta.)
- 4Vigilar la jugada del Mode segur. Canvis de configuració d'arrencada (
msconfig.exe,bcdedit),Kernel-Boot27 amb opcióSAFEBOOT,Kernel-General12 ambBootMode=2, serveis de seguretat aturant-se (esdeveniment 7036 del sistema) i eines afegides a la branca de serveis mínims. (De totes, la que més vegades ens ha servit és la de l'agent que deixa de parlar.)
El que NO et direm
- ✗Que canviïs d'EDR. L'agent que es va quedar fora d'aquella arrencada era bo, i en Mode segur hauria desaparegut qualsevol altre de tercers. Canviar de marca aquí només canvia el nom del que faltava.
- ✗Que això s'arregli comprant. Tres de les quatre mitigacions són configuració del que ja tens i de registres que ja s'estan escrivint. El que costa diners és que algú rebi l'alerta.
- ✗Que aquest atac sortís malament. Es van endur les comparticions de fitxers i el mapa complet del directori. Que el xifratge caigués va estalviar feina als de restaurar, i als de negociar no els en va estalviar gens.
En curt
Una VPN sense segon factor, un bolcat del directori sencer, unes comparticions empaquetades amb WinRAR i pujades a S3, i un reinici que va deixar el host una hora i quaranta-un minuts sense agent ni antivirus. El xifrador el va tombar la memòria virtual del Mode segur, i Huntress avisa que en un host amb més RAM això no hauria passat. Tota la resta del cas —els esdeveniments 27, 12, 26 i 7036, la ràfega contra la VPN, l'agent que calla— s'estava escrivint en registres que la majoria d'entorns ja generen.
Fonts: cronologia, marques de temps, ordres (Get-ADUser, Get-ADComputer, WinRAR, s5cmd, reg.exe add sobre SafeBoot\Network, msconfig.exe), esdeveniments Kernel-Boot 27, Kernel-General 12, sistema 26 i Defender 3002 / 0x8007043c, detecció Ransom:Win32/Akira.B!ibt amb neteja fallida 0x80004005, l'agent propi afectat, la tècnica T1688 amb els precedents de Snatch i AvosLocker, la cobertura parcial de l'EDR i les mitigacions amb el seu ordre, a més de la cita sobre l'efecte secundari afortunat — Huntress, 12 d'agost de 2026, llegit en la versió original i no en resums. Cobertura que situa la finestra sense EDR en deu minuts — BleepingComputer; reproducció de la cita de l'efecte secundari — SC Media. Xifres del trimestre (1.988 atacs, 89 grups, Akira quart amb 119) i resum d'obertura sobre l'apagada de l'EDR — informe del segon trimestre del 2026 de Halcyon, recollit per Infosecurity Magazine. Càlculs propis: la finestra d'1 h 41 min 17 s (06:29:21 → 08:10:38) i la conversió a hora peninsular espanyola, que Huntress no publica.
Quants hosts tens al directori i quants tenen agent?
A everyWAN despleguem i vigilem EDR/MDR gestionat, amb suport 24x7 al darrere perquè l'alerta arribi a una persona. Revisem la cobertura de l'agent, l'MFA del teu accés remot i què passa quan un host deixa de reportar — i també et diem quan ja ho tens bé.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN