Ransomware en una alcaldía: las primeras seis horas

Ante un ransomware en una institución pública, las primeras seis horas se dedican a aislar sin apagar, preservar memoria y discos antes de restaurar, activar el comité de crisis con mandato escrito, notificar a quien corresponda dentro de plazo y documentar cada decisión. No se paga sin decisión formal y asesoría jurídica.

Lo que sigue es un runbook por bloques horarios. Está escrito para el escenario más incómodo que existe en este trabajo: una organización que no puede parar el servicio al ciudadano y que, a la vez, tendrá que demostrar en una auditoría —o ante un tribunal— exactamente qué hizo, quién lo autorizó y con qué evidencia.

¿Por qué las primeras seis horas deciden el resto del incidente?

Porque en esas horas se toman, casi siempre por instinto, tres decisiones irreversibles:

• Si se apaga o no. Apagar borra la memoria, y con ella información que no se recupera después.
• Si se restaura encima o no. Restaurar sobre los discos originales destruye la escena.
• Si se cuenta o no. El silencio de las primeras horas condiciona todas las notificaciones posteriores y su credibilidad.

En el sector público hay además una tensión que no existe igual en una empresa privada: la continuidad del servicio es innegociable y la preservación probatoria también. Un padrón, un registro civil, un sistema de emergencias o un portal de trámites no se puede dejar caído «hasta que termine el análisis»; pero cualquier atajo que borre evidencia deja al funcionario que actuó de buena fe sin forma de acreditar que actuó bien.

Esa tensión es la razón por la que este tipo de incidentes necesita ingeniería y criterio jurídico en la misma sala, y no en reuniones distintas. Es el planteamiento con el que trabajamos el sector público e infraestructura crítica.

¿Qué no hay que hacer en los primeros minutos?

Reacción habitual	Por qué es un error
Apagar todos los equipos	Destruye memoria volátil: procesos, conexiones y, en ocasiones, material criptográfico
Restaurar la copia de seguridad de inmediato	Sobrescribe la escena y suele reintroducir el sistema en la red con el acceso del atacante intacto
Borrar la nota de rescate	Es evidencia, y con frecuencia identifica la familia de ransomware
Escribir al atacante para «ganar tiempo»	Abre una negociación no autorizada y crea constancia de una interlocución que nadie aprobó
Coordinar la respuesta por el correo corporativo	Si el atacante sigue dentro, está leyendo el plan de respuesta
Anunciar en redes que «no hubo fuga de datos»	Todavía no se sabe, y desdecirse después cuesta más que callar

Un principio que ahorra disgustos: en las primeras horas se afirma solo lo verificado. Todo lo demás es «en investigación».

Hora 0 a 1: ¿cómo se aísla sin destruir evidencia?

Objetivo del bloque: detener la propagación conservando el estado.

1. Declara el incidente. Alguien con nombre y apellidos pasa a ser responsable de la respuesta. Sin declaración formal, todo el mundo actúa y nadie decide.
2. Aísla a nivel de red, no de alimentación. Desconecta el cable, deshabilita el puerto del conmutador o segmenta la VLAN. Mantén el equipo encendido salvo que el cifrado esté avanzando en ese momento y no haya otra forma de detenerlo.
3. Corta las rutas de propagación: accesos remotos, VPN de administración, sincronizaciones de ficheros y, muy importante, desconecta o pon en solo lectura las copias de seguridad antes de que las alcance.
4. Abre un canal de comunicación fuera de banda. Un grupo por un canal ajeno a la infraestructura afectada y una lista telefónica en papel. Si el correo corporativo está comprometido, el plan de respuesta se filtra solo.
5. Empieza la bitácora. Hora, acción, quién la ejecuta, sobre qué activo, con qué autorización. En papel o en un documento fuera del entorno afectado. Esta bitácora será, meses después, el documento más consultado del expediente.

La lógica de fases —preparación, detección y análisis, contención, erradicación y recuperación— está desarrollada en el NIST SP 800-61 Rev. 3, que en 2025 reencuadró la respuesta a incidentes dentro del marco de gestión de riesgo del NIST CSF 2.0.

Hora 1 a 2: ¿qué se preserva y en qué orden?

Objetivo del bloque: que exista evidencia utilizable dentro de un año.

El orden no es arbitrario. El RFC 3227, Guidelines for Evidence Collection and Archiving, define el orden de volatilidad: se recoge primero lo que antes desaparece.

Prioridad	Qué se preserva	Se pierde si…
1	Memoria volátil (RAM) y estado de procesos y conexiones	Se apaga o reinicia el equipo
2	Tablas de red, sesiones activas, caché	Pasa el tiempo o se reconfigura la red
3	Sistemas de ficheros temporales	Se reinicia o se limpia
4	Imagen forense del disco	Se restaura encima o se reinstala
5	Registros de servidores, cortafuegos, correo y directorio	Rotan por antigüedad o por espacio
6	Configuración física y topología	Se «arregla» durante la recuperación

Reglas prácticas para este bloque:

• Imagen antes de tocar. La restauración se hace sobre hardware o almacenamiento distinto del original.
• Hash de cada pieza de evidencia en el momento de la adquisición, con su valor anotado en la bitácora. Sin huella calculada al inicio, la integridad no se puede acreditar después.
• Amplía la retención de registros ahora, antes de que la rotación normal borre los días que interesan. Es el error más común y el más caro.
• Cadena de custodia por escrito: quién adquirió, cuándo, dónde se guarda, quién ha tenido acceso.

La metodología de adquisición y análisis está descrita en el NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response.

Un matiz que en lo público es decisivo: la evidencia no se preserva «por si acaso hay juicio». Se preserva porque el expediente será revisado por un órgano de control, y porque sin ella no se puede demostrar el alcance real de lo ocurrido —lo que a su vez condiciona qué hay que notificar.

Hora 2 a 3: ¿quién manda y con qué mandato?

Objetivo del bloque: que cada actuación tenga autorización trazable.

Se constituye el comité de crisis con roles nombrados, no con cargos genéricos:

Rol	Decide sobre	Documento que produce
Dirección de la respuesta	Prioridades, autorizaciones técnicas	Actas y órdenes de actuación
Técnico responsable	Contención, preservación, recuperación	Bitácora técnica
Asesoría jurídica	Notificaciones, relación con autoridades, pago	Análisis de obligaciones y plazos
Comunicación	Mensaje a ciudadanía, prensa y personal	Mensajes aprobados y fechados
Titular del servicio afectado	Qué procedimiento degradado se activa	Plan de continuidad activado

Cada actuación técnica que altere el estado de un sistema debe tener autorización identificable: quién la pidió, quién la aprobó, con qué alcance. En una institución, un técnico que actúa correctamente pero sin mandato escrito queda expuesto igual que uno que se equivoca.

Hora 3 a 4: ¿a quién hay que notificar?

Objetivo del bloque: cumplir plazos que corren aunque el incidente siga abierto.

Las obligaciones dependen de la jurisdicción, del tipo de entidad y de si hay datos personales implicados. Lo que no depende de nada es que los plazos empiezan a contar desde el conocimiento, no desde la resolución.

• Autoridad de control de protección de datos. En el ámbito del Reglamento (UE) 2016/679, el artículo 33 fija 72 horas desde que se tiene conocimiento de la violación de seguridad para notificar a la autoridad, y permite notificación por fases cuando la información no está completa. Otras jurisdicciones fijan plazos y umbrales distintos.
• Equipo nacional de respuesta a incidentes que corresponda a la entidad. Muchas administraciones tienen obligación de reportar, y además esa vía suele aportar apoyo técnico real.
• Fuerzas y cuerpos de seguridad, según el marco aplicable. La denuncia también fija oficialmente la fecha de conocimiento.
• Órgano de control interno, intervención o auditoría, si el incidente afecta a sistemas económicos.
• Proveedores y entidades conectadas. Si comparten integración, su riesgo cambió hace tres horas.
• Personas afectadas, cuando el análisis determine alto riesgo para sus derechos.

Aquí conviene la notificación por fases: informar de lo que se sabe, declarar explícitamente lo que aún no se sabe y comprometer una actualización. Es preferible a una notificación tardía y completa, y mucho preferible a una temprana e inexacta. Esta parte se prepara antes, no durante: es trabajo de compliance operativo.

Hora 4 a 5: ¿qué se le dice a la ciudadanía?

Objetivo del bloque: que la institución sea la primera fuente, y que no tenga que desdecirse.

Un mensaje inicial útil contiene cinco elementos y ninguno más:

1. Qué servicios están afectados y cuáles no.
2. Qué alternativa tiene el ciudadano mientras tanto (presencial, telefónica, otro canal).
3. Qué se está haciendo, en términos comprensibles.
4. Qué no se sabe todavía, dicho explícitamente.
5. Cuándo habrá una nueva actualización.

Lo que no debe aparecer: la palabra «total» aplicada a la seguridad, afirmaciones sobre datos no comprometidos antes de saberlo, ni el nombre de la familia de ransomware si aún no está confirmada.

Prevé además un efecto secundario constante en incidentes públicos: aparecerán dominios y perfiles falsos ofreciendo «gestionar» el problema al ciudadano. La suplantación institucional durante una crisis es un vector conocido y se trata como parte de la respuesta, no como un asunto de marketing. Es el cruce entre protección y defensa de marca y reputación.

Hora 5 a 6: ¿se restaura, se negocia o se espera?

Objetivo del bloque: no volver a empezar dentro de dos días.

Antes de restaurar cualquier servicio se comprueban tres condiciones. Si alguna falta, restaurar es reinfectar:

• El vector de entrada está identificado o al menos acotado. Restaurar sin saber por dónde entraron reproduce el escenario.
• Las credenciales privilegiadas han sido rotadas, incluidas cuentas de servicio y accesos de proveedores.
• La copia que se va a restaurar es anterior al compromiso y está verificada, no solo «disponible».

La secuencia de recuperación se ordena por criticidad del servicio ciudadano, con verificación de integridad en cada paso y con vigilancia reforzada sobre lo que se devuelve a producción. La guía conjunta #StopRansomware de CISA, FBI, NSA y MS-ISAC incluye una lista de comprobación de respuesta que sirve como contraste, y en español la guía de aproximación de INCIBE cubre el mismo ciclo con vocabulario de negocio.

Sobre el pago: es una decisión jurídica y presupuestaria, nunca técnica y nunca individual. Debe pasar por asesoría legal —incluido el análisis de sanciones internacionales aplicables—, por el órgano competente y por constancia escrita del razonamiento, se decida lo que se decida. Y conviene recordar lo que un pago no compra: no garantiza el descifrado completo, no elimina la copia de los datos en manos del atacante y no cierra la vía de entrada.

¿Qué hay que dejar escrito esta noche?

Dentro de un año, el expediente valdrá lo que valga su documentación. Deben existir, fechados:

• Bitácora cronológica de actuaciones con autor y autorización.
• Inventario de evidencia con huellas criptográficas y cadena de custodia.
• Actas del comité con las decisiones y su justificación, incluidas las que se descartaron.
• Copia de todas las notificaciones enviadas y sus acuses.
• Mensajes públicos con hora de publicación.
• Lista de sistemas restaurados, desde qué copia y con qué verificación.

La forma de acreditar que un documento existía en una fecha y no ha cambiado desde entonces es el problema que resuelve nuestro producto Veritas UGC, que calcula la huella SHA-256 del original y la ancla en una cadena pública mediante OpenTimestamps, con verificación independiente incluso sin nosotros. El estado de los marcos que aplicamos está publicado en /trust.

Qué hacer ahora

1. Imprime este runbook y guárdalo en papel. Un plan de respuesta que solo existe en la red que se acaba de cifrar no existe.
2. Verifica hoy que tus copias de seguridad están aisladas y que alguien ha probado una restauración completa este año, con fecha anotada.
3. Fija ya el canal fuera de banda del comité de crisis y prueba que todos los miembros pueden usarlo.
4. Escribe la lista de notificaciones obligatorias de tu entidad, con destinatario, plazo y responsable, antes de necesitarla.
5. Reduce la puerta de entrada. La mayoría de estos incidentes empieza en algo publicado que nadie recordaba: revisa tu superficie de ataque y lo que tu organización expone en fuentes abiertas.

Si tu institución necesita preparar este runbook antes del incidente —o está dentro de uno ahora—, escríbenos desde /contacto indicando si hay servicio ciudadano interrumpido.