Ransomware: recuperar rápido no es echar al atacante

De las organizaciones que sufrieron más de un ataque de ransomware en los últimos doce meses, el 30% los sufrió el mismo día. Otro 29%, dentro de la misma semana. Eso no es una estadística sobre reincidencia a largo plazo: es la huella de un acceso que nunca llegó a cerrarse. Y hay una cifra en el mismo informe que lo dice sin rodeos: casi uno de cada cuatro de los que pagaron (23%) pagó porque no conseguía sacar al atacante de su entorno. Devolver el servicio y recuperar el control son dos trabajos distintos, y solo uno de los dos se mide en horas.

El dato que no es el titular

El informe anual de ransomware que Semperis publicó el 14 de octubre de 2026 trae el titular que ha circulado toda la semana: el 69% de las víctimas encuestadas fue atacada con éxito varias veces en los doce meses previos, y el 31% hizo más de un pago. En España la cifra sube al 81%, con un 29% que pagó el rescate. Son números llamativos y, por sí solos, no cambian ninguna decisión.

El número que sí cambia una decisión está unas páginas más adentro, y es el reparto en el tiempo de esos ataques posteriores. Entre quienes sufrieron más de uno:

• 30% sufrió dos o más ataques el mismo día.
• 29%, dentro de la misma semana.
• 15%, dentro del mismo mes; otro 15%, separados por más de un mes.
• 11% fueron simultáneos.

Casi seis de cada diez organizaciones reatacadas lo fueron antes de que terminara la semana del primer golpe. La tabla de frecuencia: entre las víctimas, el 31% fue atacado una sola vez, el 40% dos veces, el 24% tres y el 5% cuatro. Lo habitual, una vez has entrado en la lista, no es un ataque: son dos.

Y el dato que juega en nuestra contra, antes de que lo saque otro: en el recuadro de datos destacados por país, lo que el informe subraya de España es que el 39% dejó pasar un mes o más entre ataques, frente al 15% global. De los nueve países es, justamente, el que menos encaja con el patrón del mismo día. Así que el argumento que sostiene el resto de este artículo no es la prisa del segundo ataque: es que el acceso siguió abierto el tiempo que hizo falta —aquí, con más frecuencia que fuera, semanas—.

Qué preguntó el informe, y a quién

La encuesta recoge 1.200 profesionales de TI y seguridad de nueve países —España entre ellos— y ocho sectores, con el trabajo de campo hecho por una firma internacional de investigación de mercados. Y tiene un criterio de inclusión que lo decide todo: solo entraron organizaciones que ya habían sufrido al menos un ataque de ransomware con éxito.

Eso convierte cada porcentaje en una probabilidad condicionada. El 81% de España no dice que ocho de cada diez empresas españolas hayan sufrido varios ataques; dice que, entre las que ya habían sufrido uno, ocho de cada diez sufrieron más. Es una diferencia enorme para el titular y ninguna para ti, si estás en el grupo: lo que mide esa cifra es exactamente lo que pasa después del primero, que es el trozo del problema que sí está en tus manos.

Segunda cautela, dicha en voz alta: un informe sobre lo mal que se recupera la identidad lo publica una empresa que vende recuperación de identidad. No lo descartamos por eso —hacerlo sería tirar a la basura la única encuesta con datos de España de este mes—, pero sí elegimos qué usar: nos quedamos con los números que describen conductas (cuándo volvieron, contra qué fueron) y dejamos fuera los que miden la necesidad de un producto. Y todo son respuestas declaradas por los encuestados, no telemetría. Ya hicimos este mismo ejercicio en julio con el informe de otra casa, cuando tocaba separar >.

Dos lecturas del mismo día, y el mismo arreglo

Un segundo ataque el mismo día admite dos explicaciones, y la encuesta no permite distinguirlas. Una: el atacante nunca se fue. Conservaba una cuenta, una tarea programada, un túnel de soporte remoto o un tique de Kerberos válido, y volvió a cifrar sobre lo recién restaurado. Dos: la vía de entrada siguió abierta, y por ella entró otro —el acceso a una red comprometida se revende, y una víctima reciente es una víctima barata y rápida—.

Hay un tercer matiz que nos obliga a bajar el tono, y está en el mismo informe: solo el 28% volvió a la normalidad en menos de un día, y la mitad necesitó hasta una semana. En buena parte de esos segundos ataques del mismo día no había todavía nada recuperado que celebrar: había un acceso abierto. Lo que el dato prueba no es que recuperar rápido falle; es que recuperar y cerrar son cosas distintas.

Para lo que hay que hacer mañana, da igual cuál de las dos sea: ninguna se arregla restaurando más rápido. Sarah Armstrong-Smith, del consejo asesor de ciberseguridad del Gobierno británico, lo resume así en el propio informe: «después de un ataque, la mayoría de las empresas se centran en cómo recuperarse lo más rápido posible, no en cómo expulsar al atacante y recuperar el control del sistema operativo». Y remata: «nunca podrás volver a confiar en ese sistema operativo, porque no sabes qué le han hecho los malos. Han metido malware, han metido puertas traseras; así que, pagues el rescate y recibas la clave o no, vas a tener que reconstruir tu entorno hasta un estado bueno conocido».

Lo que atacan no es lo que restauras

En el 87% de los casos de la encuesta el ataque fue contra el sistema de identidad: Active Directory en más de la mitad (51%), Entra ID muy cerca (48%) y Okta en más de una cuarta parte (27%). Mientras tanto, solo alrededor de la mitad de las organizaciones encuestadas mantiene copias dedicadas de la identidad o herramientas que automaticen su recuperación, y solo un 60% tenía documentada la recuperación de AD, un 52% la de Entra ID y un 28% la de Okta.

Tu plan de recuperación, casi con seguridad, restaura máquinas: la máquina virtual del ERP, el servidor de ficheros, la base de datos. Eso es lo que tiene RTO, lo que se ensaya y lo que sale en el acta. Pero lo que atacaron es la pieza que dice quién es quién. Y la identidad tiene una propiedad desagradable que no tiene un servidor de ficheros: restaurar una copia anterior al ataque no invalida lo que se llevaron. Si robaron el hash de la cuenta >krbtgt, esa clave sigue firmando tiques de Kerberos válidos en el directorio recién restaurado, porque es la misma clave. Has devuelto el estado; no has cambiado las cerraduras.

Tomer Bar, responsable de investigación de seguridad en la casa que firma el informe, lo dice sin rodeos: «una operación de ransomware puede usar Active Directory para cifrar toda tu organización; con los permisos adecuados, pueden moverse lateralmente de máquina a máquina». El directorio no es una víctima más del incidente: es el vehículo.

El procedimiento que Microsoft publica y casi nadie tiene escrito

Nada de esto es secreto de consultoría cara. Microsoft publica la guía de recuperación de un bosque de Active Directory con los pasos y el orden, y conviene leerla aunque solo sea para comprobar cuántos de ellos están en tu plan. Resumida, la parte inicial dice:

• Restaurar un solo controlador de dominio escribible por dominio, empezando por el dominio raíz del bosque. Y la condición que lo gobierna todo: «el controlador debe tener una base de datos que no haya sido influida por aquello que hizo caer el bosque»; hace falta una copia de confianza, probada a fondo antes de meterla en producción.
• Hacerlo aislado de la red de producción: cable desconectado en un servidor físico, adaptador retirado o en otra red si es una máquina virtual. Y no unirlo a producción hasta haber restaurado y verificado los datos.
• Si se sospecha intrusión, restablecer las contraseñas de todas las cuentas administrativas —Enterprise Admins, Domain Admins, Schema Admins, Server Operators, Account Operators— antes de instalar el resto de controladores, y reemplazar las cuentas gMSA, porque un atacante con control administrativo pudo llevarse el material para generar sus contraseñas.
• Limpiar los metadatos de todos los demás controladores que no se restauran, apropiarse de los roles de operaciones maestras, rehacer DNS… y un paso que delata si alguien ha leído de verdad el documento: subir en 100.000 el fondo de RID disponible. El motivo es fino: los objetos creados después de la copia desaparecen al restaurar, pero sus permisos sobre los objetos a los que tenían acceso no; si el fondo no se eleva, un usuario nuevo puede recibir el mismo SID que uno de aquellos y heredar accesos que nadie le dio.
• Restablecer dos veces la contraseña de la cuenta de equipo de ese controlador y dos veces la de krbtgt —dos, porque el historial guarda las dos últimas y con una sola la anterior seguiría siendo válida—. Y, si la recuperación responde a una brecha, restablecer también las contraseñas de las relaciones de confianza.
• Y al final, cuando el bosque está en pie: hacer una copia nueva de cada controlador restaurado. La copia con la que has recuperado ya no sirve para la próxima vez.

Léelo otra vez pensando en el día real: eso no se improvisa a las tres de la mañana con el director general preguntando cuándo vuelve el ERP. Son horas de trabajo deliberado, con equipos apagados a propósito, mientras la empresa está parada y toda la presión empuja en la dirección contraria —encender, encender, encender—. Si ese orden no está escrito y ensayado antes, no se va a seguir.

Lo anterior es para Active Directory en tu casa. Si tu identidad vive en Entra ID o en un proveedor como Okta, no hay cable que desenchufar ni bosque que levantar, y el procedimiento es otro —cuentas de emergencia fuera de las políticas de acceso condicional, revocación de tokens y sesiones, reemplazo de secretos de aplicaciones y de identidades de carga de trabajo, reversión de políticas—. Otro procedimiento, pero igual de escrito. La pregunta no cambia de forma: ¿quién sigue pudiendo autenticarse mañana por la mañana?

La copia limpia es una decisión de fechas

Vuelve a la condición de Microsoft: una copia «no influida por aquello que hizo caer el bosque». Para elegirla hace falta saber cuándo entraron, no cuándo cifraron. Y esas dos fechas suelen estar separadas por semanas. Aquí es donde una decisión administrativa tomada hace meses —la retención de registros— se convierte en una decisión técnica del peor día: si tu registro de identidad guarda 30 días y la entrada fue hace 47, no hay forma de saber qué copia está limpia, y la elección se hace a ojo. De eso hablamos el domingo a propósito de un caso concreto: >.

Y hay una trampa anterior, la que convierte este problema en un callejón: la copia de la identidad no puede depender de la identidad. Un servidor de copias unido al dominio que tiene que restaurar usa las mismas credenciales que el atacante ya controla; su consola, sus trabajos y sus retenciones están al alcance de quien se hizo administrador del dominio. Lo contamos entero en >, y es el primer sitio donde miramos cuando alguien nos enseña su plan.

Cuándo no hace falta nada de esto

Si eres una empresa de veinte personas sin Active Directory, con los portátiles en Entra ID y el negocio entero en SaaS, no te montes un plan de recuperación de bosque: no tienes bosque. Escribir un procedimiento que no se corresponde con tu infraestructura es peor que no tenerlo, porque da por cubierto lo que no lo está. Lo tuyo son dos cuentas de emergencia guardadas en papel en una caja fuerte, la revocación de sesiones probada una vez, y saber a qué teléfono llamar si el inquilino deja de responderte.

Y si tienes dominio pero no tienes manos para todo esto, hay dos cosas que rinden más que las demás juntas: una copia de la identidad que viva fuera del dominio y sea inmutable, y un ensayo con cronómetro al año en el que alguien restaure esa copia sin ayuda del directorio que intenta recuperar. Lo demás se puede ir escribiendo. Esas dos, no.

Cuándo damos un incidente por cerrado

Las ocho que usamos nosotros, que no son las del informe. Un incidente no se cierra porque el ERP vuelva a abrir:

• Sabemos la fecha de entrada, no solo la de cifrado, y está sostenida por un registro que llega hasta ahí.
• La identidad se ha devuelto a un estado bueno conocido: krbtgt y la cuenta de equipo del controlador restaurado rotadas dos veces, contraseñas administrativas y gMSA restablecidas, confianzas renovadas, cuentas de servicio y secretos de aplicación reemplazados —no revisados—.
• La vía de entrada está cerrada y verificada desde fuera, no «parcheada» en un tique.
• Ningún equipo restaurado se unió a producción antes de verificarse, y hay constancia de quién lo verificó.
• Hay vigilancia en el puesto y en el servidor durante las semanas siguientes, con alguien mirando. La ventana en la que más falta hace la detección es justo la que se dedica a respirar.
• Hay una copia nueva, posterior a la recuperación, y la anterior se conserva aparte para el peritaje y para la aseguradora.
• Si hay AD CS, la autoridad emisora está revisada y los certificados sospechosos revocados. Un certificado robado o forjado sobrevive al doble restablecimiento de krbtgt y a la restauración entera, y sigue autenticando durante los años que le queden de validez. Es el agujero que más veces hemos visto quedarse abierto; hablamos de ello al repasar la autoridad de certificación que casi nadie audita.
• Alguien ha puesto fecha al siguiente simulacro y esa acta tiene dueño con nombre y apellidos.

Nosotros cronometramos esos ensayos: nuestro último simulacro de recuperación completa se cerró en 14 minutos. Es un dato interno y lo damos como lo que es —una prueba de que el procedimiento existe y se ejecuta, no una promesa contractual ni un número que vaya a repetirse en tu casa—. Y la mitad del valor de ese cronómetro no está en el tiempo, sino en lo que descubre: la primera vez que alguien intenta restaurar la identidad sin el directorio delante, aparecen las dependencias que nadie había escrito.

Vendemos disaster recovery y vendemos detección y respuesta gestionada. Lo que no vendemos son licencias de nadie, así que la recomendación de la que menos dinero sacamos —escribir el orden de recuperación y ensayarlo— es justamente la que más insistimos en que hagas, la lleves con nosotros o con quien quieras. El principio de mínimo privilegio que evita que una cuenta ofimática acabe tocando un controlador de dominio tampoco es un producto: es una decisión de diseño que se toma un martes cualquiera, antes de que haga falta.

La pregunta que deja el 30%

Si mañana recuperases del todo, ¿qué habría cambiado respecto al día anterior al ataque, aparte de la factura? Si la respuesta honesta es «nada, pero ya funciona», el informe tiene un número reservado para ti, y no espera un año a cobrártelo: espera a esa misma semana.

Fuentes y método: las cifras globales (69% atacados varias veces, 31% con pagos múltiples, reparto temporal 30/29/15/15/11, frecuencia 31/40/24/5, 23% que pagó porque no conseguía expulsar al atacante, 87% de ataques contra sistemas de identidad con AD 51%, Entra ID 48% y Okta 27%, 50% con copias dedicadas de identidad y 42% con recuperación automatizada, 60%/52%/28% con procedimientos documentados de recuperación de AD, Entra ID y Okta, 28% que volvió a la normalidad en menos de un día y la mitad que necesitó hasta una semana, y el recuadro por países donde España figura con un 39% que dejó pasar un mes o más entre ataques) y las dos citas —Sarah Armstrong-Smith y Tomer Bar— están tomadas del Ransomware Risk Report 2026 de Semperis (publicado el 14 de octubre de 2026; 1.200 profesionales de TI y seguridad, nueve países, ocho sectores, solo organizaciones con al menos un ataque exitoso), descargado y leído el 20 de octubre de 2026; las traducciones al castellano son nuestras. Los datos de España (81% atacadas con éxito en varias ocasiones, 29% pagó, 25% de ataques con amenazas físicas) proceden del teletipo de Europa Press del 16 de octubre de 2026 sobre ese mismo informe. El procedimiento de recuperación —copia no influida por el fallo, aislamiento de red, restablecimiento de cuentas administrativas y gMSA, doble restablecimiento de la cuenta de equipo y de krbtgt, contraseñas de confianzas, limpieza de metadatos, elevación del fondo de RID en 100.000 y copia nueva al final— es la guía oficial de Microsoft Active Directory Forest Recovery — Perform initial recovery, consultada el 20 de octubre de 2026. No tenemos telemetría propia de estos incidentes: lo nuestro aquí es la lectura (el reparto temporal como señal de recuperaciones sin expulsión, la cautela sobre la muestra condicionada y sobre quién publica el informe) y la lista de siete condiciones, que es de cosecha propia. El dato de los 14 minutos es un simulacro interno de everyWAN: una prueba, no una garantía.