Ransomware: recuperar ràpid no és fer fora l'atacant

De les organitzacions que van patir més d'un atac de ransomware els últims dotze mesos, el 30% els va patir el mateix dia. Un altre 29%, dins la mateixa setmana. Això no és una estadística sobre reincidència a llarg termini: és el rastre d'un accés que no es va arribar a tancar mai. I hi ha una xifra al mateix informe que ho diu sense embuts: gairebé un de cada quatre dels qui van pagar (23%) va pagar perquè no aconseguia treure l'atacant del seu entorn. Tornar el servei i recuperar el control són dues feines diferents, i només una de les dues es mesura en hores.

La dada que no és el titular

L'informe anual de ransomware que Semperis va publicar el 14 d'octubre del 2026 porta el titular que ha circulat tota la setmana: el 69% de les víctimes enquestades va ser atacada amb èxit diverses vegades els dotze mesos previs, i el 31% va fer més d'un pagament. A Espanya la xifra puja al 81%, amb un 29% que va pagar el rescat. Són números cridaners i, per si sols, no canvien cap decisió.

El número que sí que canvia una decisió és unes pàgines més endins, i és el repartiment en el temps d'aquests atacs posteriors. Entre els qui en van patir més d'un:

• 30% va patir dos o més atacs el mateix dia.
• 29%, dins la mateixa setmana.
• 15%, dins el mateix mes; un altre 15%, separats per més d'un mes.
• 11% van ser simultanis.

Gairebé sis de cada deu organitzacions reatacades ho van ser abans que acabés la setmana del primer cop. La taula de freqüència: entre les víctimes, el 31% va ser atacat una sola vegada, el 40% dues vegades, el 24% tres i el 5% quatre. L'habitual, un cop has entrat a la llista, no és un atac: en són dos.

I la dada que juga en contra nostra, abans que la tregui un altre: al requadre de dades destacades per país, el que l'informe subratlla d'Espanya és que el 39% va deixar passar un mes o més entre atacs, davant del 15% global. Dels nou països és, justament, el que menys encaixa amb el patró del mateix dia. Així que l'argument que sosté la resta d'aquest article no és la pressa del segon atac: és que l'accés va continuar obert el temps que va caldre —aquí, amb més freqüència que a fora, setmanes—.

Què va preguntar l'informe, i a qui

L'enquesta recull 1.200 professionals de TI i seguretat de nou països —Espanya entre ells— i vuit sectors, amb el treball de camp fet per una firma internacional d'investigació de mercats. I té un criteri d'inclusió que ho decideix tot: només hi van entrar organitzacions que ja havien patit com a mínim un atac de ransomware amb èxit.

Això converteix cada percentatge en una probabilitat condicionada. El 81% d'Espanya no diu que vuit de cada deu empreses espanyoles hagin patit diversos atacs; diu que, entre les que ja n'havien patit un, vuit de cada deu en van patir més. És una diferència enorme per al titular i cap per a tu, si ets al grup: el que mesura aquesta xifra és exactament el que passa després del primer, que és el tros del problema que sí que és a les teves mans.

Segona cautela, dita en veu alta: un informe sobre com de malament es recupera la identitat el publica una empresa que ven recuperació d'identitat. No el descartem per això —fer-ho seria llençar l'única enquesta amb dades d'Espanya d'aquest mes—, però sí que triem què fem servir: ens quedem amb els números que descriuen conductes (quan van tornar, contra què van anar) i deixem fora els que mesuren la necessitat d'un producte. I tot són respostes declarades pels enquestats, no telemetria. Ja vam fer aquest mateix exercici al juliol amb l'informe d'una altra casa, quan tocava separar >.

Dues lectures del mateix dia, i la mateixa solució

Un segon atac el mateix dia admet dues explicacions, i l'enquesta no permet distingir-les. Una: l'atacant no se'n va anar mai. Conservava un compte, una tasca programada, un túnel de suport remot o un tiquet de Kerberos vàlid, i va tornar a xifrar sobre el que s'acabava de restaurar. Dues: la via d'entrada va continuar oberta, i hi va entrar un altre —l'accés a una xarxa compromesa es revèn, i una víctima recent és una víctima barata i ràpida—.

Hi ha un tercer matís que ens obliga a abaixar el to, i és al mateix informe: només el 28% va tornar a la normalitat en menys d'un dia, i la meitat va necessitar fins a una setmana. En bona part d'aquells segons atacs del mateix dia encara no hi havia res recuperat per celebrar: hi havia un accés obert. El que la dada prova no és que recuperar de pressa falli; és que recuperar i tancar són coses diferents.

Per al que cal fer demà, tant és quina de les dues sigui: cap es resol restaurant més de pressa. Sarah Armstrong-Smith, del consell assessor de ciberseguretat del Govern britànic, ho resumeix així al mateix informe: «després d'un atac, la majoria d'empreses se centren en com recuperar-se com més ràpid millor, no en com fer fora l'atacant i recuperar el control del sistema operatiu». I remata: «mai més no podràs confiar en aquell sistema operatiu, perquè no saps què li han fet els dolents. Hi han posat programari maliciós, hi han posat portes del darrere; així doncs, paguis el rescat i rebis la clau o no, hauràs de reconstruir el teu entorn fins a un estat bo conegut».

El que ataquen no és el que restaures

En el 87% dels casos de l'enquesta l'atac va ser contra el sistema d'identitat: Active Directory en més de la meitat (51%), Entra ID molt a prop (48%) i Okta en més d'una quarta part (27%). Mentrestant, només al voltant de la meitat de les organitzacions enquestades manté còpies dedicades de la identitat o eines que n'automatitzin la recuperació, i només un 60% tenia documentada la recuperació d'AD, un 52% la d'Entra ID i un 28% la d'Okta.

El teu pla de recuperació, gairebé amb seguretat, restaura màquines: la màquina virtual de l'ERP, el servidor de fitxers, la base de dades. Això és el que té RTO, el que s'assaja i el que surt a l'acta. Però el que van atacar és la peça que diu qui és qui. I la identitat té una propietat desagradable que no té un servidor de fitxers: restaurar una còpia anterior a l'atac no invalida el que es van endur. Si van robar el hash del compte >krbtgt, aquella clau continua signant tiquets de Kerberos vàlids al directori acabat de restaurar, perquè és la mateixa clau. Has tornat l'estat; no has canviat els panys.

Tomer Bar, responsable d'investigació de seguretat a la casa que signa l'informe, ho diu sense rodeigs: «una operació de ransomware pot fer servir Active Directory per xifrar tota la teva organització; amb els permisos adequats, es poden moure lateralment de màquina a màquina». El directori no és una víctima més de l'incident: és el vehicle.

El procediment que Microsoft publica i gairebé ningú no té escrit

Res de tot això no és cap secret de consultoria cara. Microsoft publica la guia de recuperació d'un bosc d'Active Directory amb els passos i l'ordre, i convé llegir-la encara que només sigui per comprovar quants d'ells són al teu pla. Resumida, la part inicial diu:

• Restaurar un sol controlador de domini escrivible per domini, començant pel domini arrel del bosc. I la condició que ho governa tot: «el controlador ha de tenir una base de dades que no hagi estat influïda per allò que va fer caure el bosc»; cal una còpia de confiança, provada a fons abans de posar-la en producció.
• Fer-ho aïllat de la xarxa de producció: cable desconnectat en un servidor físic, adaptador retirat o en una altra xarxa si és una màquina virtual. I no unir-lo a producció fins a haver restaurat i verificat les dades.
• Si se sospita intrusió, restablir les contrasenyes de tots els comptes administratius —Enterprise Admins, Domain Admins, Schema Admins, Server Operators, Account Operators— abans d'instal·lar la resta de controladors, i reemplaçar els comptes gMSA, perquè un atacant amb control administratiu va poder endur-se el material per generar-ne les contrasenyes.
• Netejar les metadades de tots els altres controladors que no es restauren, apropiar-se dels rols d'operacions mestres, refer el DNS… i un pas que delata si algú ha llegit de debò el document: apujar en 100.000 el fons de RID disponible. El motiu és fi: els objectes creats després de la còpia desapareixen en restaurar, però els seus permisos sobre els objectes als quals tenien accés no; si el fons no s'eleva, un usuari nou pot rebre el mateix SID que un d'aquells i heretar accessos que ningú no li ha donat.
• Restablir dues vegades la contrasenya del compte d'equip d'aquell controlador i dues vegades la de krbtgt —dues, perquè l'historial en guarda les dues últimes i amb una de sola l'anterior continuaria sent vàlida—. I, si la recuperació respon a una bretxa, restablir també les contrasenyes de les relacions de confiança.
• I al final, quan el bosc és dret: fer una còpia nova de cada controlador restaurat. La còpia amb què has recuperat ja no serveix per a la pròxima vegada.

Llegeix-ho un altre cop pensant en el dia real: això no s'improvisa a les tres de la matinada amb el director general preguntant quan torna l'ERP. Són hores de feina deliberada, amb equips apagats expressament, mentre l'empresa està aturada i tota la pressió empeny en direcció contrària —engegar, engegar, engegar—. Si aquest ordre no està escrit i assajat abans, no se seguirà.

L'anterior és per a Active Directory a casa teva. Si la teva identitat viu a Entra ID o en un proveïdor com Okta, no hi ha cap cable per desendollar ni cap bosc per aixecar, i el procediment és un altre —comptes d'emergència fora de les polítiques d'accés condicional, revocació de tokens i sessions, reemplaçament de secrets d'aplicacions i d'identitats de càrrega de treball, reversió de polítiques—. Un altre procediment, però igual d'escrit. La pregunta no canvia de forma: qui es podrà continuar autenticant demà al matí?

La còpia neta és una decisió de dates

Torna a la condició de Microsoft: una còpia «no influïda per allò que va fer caure el bosc». Per triar-la cal saber quan van entrar, no quan van xifrar. I aquestes dues dates solen estar separades per setmanes. Aquí és on una decisió administrativa presa fa mesos —la retenció de registres— es converteix en una decisió tècnica del pitjor dia: si el teu registre d'identitat guarda 30 dies i l'entrada va ser fa 47, no hi ha manera de saber quina còpia està neta, i la tria es fa a ull. D'això en vam parlar diumenge a propòsit d'un cas concret: >.

I hi ha un parany anterior, el que converteix aquest problema en un carreró: la còpia de la identitat no pot dependre de la identitat. Un servidor de còpies unit al domini que ha de restaurar fa servir les mateixes credencials que l'atacant ja controla; la seva consola, les seves tasques i les seves retencions són a l'abast de qui s'ha fet administrador del domini. Ho expliquem sencer a >, i és el primer lloc on mirem quan algú ens ensenya el seu pla.

Quan no cal res de tot això

Si ets una empresa de vint persones sense Active Directory, amb els portàtils a Entra ID i el negoci sencer en SaaS, no et muntis un pla de recuperació de bosc: no tens bosc. Escriure un procediment que no es correspon amb la teva infraestructura és pitjor que no tenir-lo, perquè dona per cobert el que no ho està. El que et toca a tu són dos comptes d'emergència guardats en paper en una caixa forta, la revocació de sessions provada una vegada, i saber a quin telèfon trucar si l'inquilí deixa de respondre't.

I si tens domini però no tens mans per a tot això, hi ha dues coses que rendeixen més que totes les altres juntes: una còpia de la identitat que visqui fora del domini i sigui immutable, i un assaig amb cronòmetre a l'any en què algú restauri aquesta còpia sense ajuda del directori que intenta recuperar. La resta es pot anar escrivint. Aquestes dues, no.

Quan donem un incident per tancat

Les vuit que fem servir nosaltres, que no són les de l'informe. Un incident no es tanca perquè l'ERP torni a obrir-se:

• Sabem la data d'entrada, no només la de xifratge, i està sostinguda per un registre que hi arriba.
• La identitat s'ha tornat a un estat bo conegut: krbtgt i el compte d'equip del controlador restaurat rotats dues vegades, contrasenyes administratives i gMSA restablertes, confiances renovades, comptes de servei i secrets d'aplicació reemplaçats —no revisats—.
• La via d'entrada és tancada i verificada des de fora, no «apedaçada» en un tiquet.
• Cap equip restaurat no es va unir a producció abans de verificar-se, i hi ha constància de qui ho va verificar.
• Hi ha vigilància al lloc de treball i al servidor durant les setmanes següents, amb algú mirant. La finestra en què més falta fa la detecció és just la que es dedica a respirar.
• Hi ha una còpia nova, posterior a la recuperació, i l'anterior es conserva a part per al peritatge i per a l'asseguradora.
• Si hi ha AD CS, l'autoritat emissora està revisada i els certificats sospitosos revocats. Un certificat robat o falsificat sobreviu al doble restabliment de krbtgt i a la restauració sencera, i continua autenticant durant els anys que li quedin de validesa. És el forat que més vegades hem vist quedar-se obert; en vam parlar en repassar l'autoritat de certificació que gairebé ningú no audita.
• Algú ha posat data al pròxim simulacre i aquella acta té un responsable amb nom i cognoms.

Nosaltres cronometrem aquests assajos: el nostre últim simulacre de recuperació completa es va tancar en 14 minuts. És una dada interna i la donem com el que és —una prova que el procediment existeix i s'executa, no una promesa contractual ni un número que s'hagi de repetir a casa teva—. I la meitat del valor d'aquell cronòmetre no és en el temps, sinó en el que descobreix: la primera vegada que algú intenta restaurar la identitat sense el directori al davant, apareixen les dependències que ningú no havia escrit.

Venem disaster recovery i venem detecció i resposta gestionada. El que no venem són llicències de ningú, així que la recomanació de la qual menys diners traiem —escriure l'ordre de recuperació i assajar-lo— és justament la que més insistim que facis, la portis amb nosaltres o amb qui vulguis. El principi de mínim privilegi que evita que un compte ofimàtic acabi tocant un controlador de domini tampoc no és un producte: és una decisió de disseny que es pren un dimarts qualsevol, abans que calgui.

La pregunta que deixa el 30%

Si demà recuperessis del tot, què hauria canviat respecte al dia anterior a l'atac, a banda de la factura? Si la resposta honesta és «res, però ja funciona», l'informe té un número reservat per a tu, i no espera un any a cobrar-te'l: espera aquella mateixa setmana.

Fonts i mètode: les xifres globals (69% atacats diverses vegades, 31% amb pagaments múltiples, repartiment temporal 30/29/15/15/11, freqüència 31/40/24/5, 23% que va pagar perquè no aconseguia fer fora l'atacant, 87% d'atacs contra sistemes d'identitat amb AD 51%, Entra ID 48% i Okta 27%, 50% amb còpies dedicades d'identitat i 42% amb recuperació automatitzada, 60%/52%/28% amb procediments documentats de recuperació d'AD, Entra ID i Okta, 28% que va tornar a la normalitat en menys d'un dia i la meitat que va necessitar fins a una setmana, i el requadre per països on Espanya figura amb un 39% que va deixar passar un mes o més entre atacs) i les dues citacions —Sarah Armstrong-Smith i Tomer Bar— estan preses del Ransomware Risk Report 2026 de Semperis (publicat el 14 d'octubre del 2026; 1.200 professionals de TI i seguretat, nou països, vuit sectors, només organitzacions amb com a mínim un atac reeixit), descarregat i llegit el 20 d'octubre del 2026; les traduccions al català són nostres. Les dades d'Espanya (81% atacades amb èxit en diverses ocasions, 29% va pagar, 25% d'atacs amb amenaces físiques) procedeixen del teletip d'Europa Press del 16 d'octubre del 2026 sobre aquest mateix informe. El procediment de recuperació —còpia no influïda per la fallada, aïllament de xarxa, restabliment de comptes administratius i gMSA, doble restabliment del compte d'equip i de krbtgt, contrasenyes de confiances, neteja de metadades, elevació del fons de RID en 100.000 i còpia nova al final— és la guia oficial de Microsoft Active Directory Forest Recovery — Perform initial recovery, consultada el 20 d'octubre del 2026. No tenim telemetria pròpia d'aquests incidents: el que és nostre aquí és la lectura (el repartiment temporal com a senyal de recuperacions sense expulsió, la cautela sobre la mostra condicionada i sobre qui publica l'informe) i la llista de set condicions, que és de collita pròpia. La dada dels 14 minuts és un simulacre intern d'everyWAN: una prova, no una garantia.