El primer día de un incidente de ransomware determina cuánto pierde, cuánto tarda la recuperación y si más adelante podrá explicar lo que ocurrió. El instinto es apagarlo todo y empezar a restaurar. Frene lo justo para contener el ataque sin destruir las evidencias que va a necesitar.
Hora 0 a 1: contener sin destruir evidencias
Desconecte de la red los sistemas afectados: desenchufe el cable, desactive la wifi, cierre el puerto del switch o use la función de aislamiento de su herramienta de protección de endpoints. Si parecen afectados varios sistemas o subredes enteras, aísle a nivel de switch en lugar de equipo por equipo.
No apague los equipos salvo que no pueda desconectarlos. La guía #StopRansomware de CISA trata el apagado como último recurso para los dispositivos que no se pueden sacar de la red, porque apagar destruye las evidencias que hay en la memoria. Tampoco borre, reinstale ni ejecute todavía herramientas de limpieza.
Deje la nota de rescate y los archivos cifrados donde están. Haga fotos de las pantallas que muestran la nota.
Saque la comunicación fuera de banda
Dé por hecho que el atacante puede leer su correo y su chat. CISA recomienda métodos fuera de banda, como las llamadas telefónicas, para coordinar la respuesta sin alertarle. Organice una conferencia telefónica o un grupo de mensajería en dispositivos que no formaran parte del entorno afectado.
Designe a un único responsable del incidente. Abra un registro escrito con la hora de cada decisión y cada acción. Lo necesitará para los reguladores, las aseguradoras y su propia revisión posterior al incidente.
Preserve las evidencias
Antes de reconstruir nada, recoja lo que necesitará la investigación:
- una imagen de disco y un volcado de memoria de una muestra de los equipos afectados, como recomienda CISA
- registros de cortafuegos, VPN, protección de endpoints, controladores de dominio, correo y servicios en la nube
- la nota de rescate, algunos archivos cifrados y la extensión que añadió el malware
Los registros de los sistemas afectados pueden haberse modificado o borrado. El Comité Europeo de Protección de Datos advierte de que la falta de una entrada en un registro no demuestra que no se hayan exfiltrado datos, y recomienda reenviar los registros a un servidor central. Exporte lo que tenga antes de que la configuración de retención lo sobrescriba.
Determine el alcance
Los archivos cifrados muestran dónde terminó el ataque, no dónde empezó. CISA aconseja buscar malware de fases anteriores e indicios de robo de datos. Intente responder a cuatro preguntas:
- ¿Qué sistemas y datos están cifrados o afectados?
- ¿Qué cuentas usó el atacante? Busque cuentas nuevas, cuentas con privilegios elevados recientemente y actividad inusual de los administradores.
- ¿Cómo entró? Revise, por ejemplo, el acceso remoto sin MFA, los sistemas expuestos a internet sin parchear y los correos de phishing recientes.
- ¿Se copiaron datos al exterior? Revise los registros del cortafuegos y del proxy en busca de grandes transferencias salientes.
La última pregunta determina en gran medida su situación jurídica, así que trate cualquier duda como un «posiblemente sí» hasta que pueda descartarlo.
Cambie las credenciales en el orden correcto
Dé por hecho que el atacante conoce todas las credenciales que se hayan usado o guardado en un sistema afectado. Haga los cambios desde un dispositivo limpio, nunca desde un equipo de la red afectada.
Cambiar las contraseñas mientras el atacante aún tiene un punto de apoyo puede limitarse a entregarle las nuevas. La lista de comprobación de CISA sitúa el cambio completo después de que el entorno se haya limpiado y reconstruido. Aun así, puede que tenga que hacer antes un cambio de emergencia de las cuentas con más poder para cortar el acceso. Acuerde el orden con sus equipos de respuesta. Una secuencia razonable es:
- Administradores del dominio y de la identidad en la nube, y las cuentas de emergencia (break-glass)
- Administradores de copias de seguridad, hipervisores y almacenamiento
- Administradores del acceso remoto, la VPN y los cortafuegos
- Cuentas de servicio, sobre todo las que tienen permisos amplios
- En Active Directory, la cuenta
krbtgt, dos veces. La guía de recuperación del bosque de Microsoft explica por qué hacen falta dos cambios y cuánto esperar entre ellos. - El resto de los usuarios, revocando las sesiones y los tokens existentes
Compruebe sus copias de seguridad antes de confiar en ellas
CISA señala que muchas variantes de ransomware buscan las copias de seguridad accesibles y las borran o las cifran. Antes de planificar la recuperación, confirme qué copias están intactas, cuándo se hizo la última copia limpia y si puede restaurar a partir de ella.
Restaure primero en un entorno aislado. CISA advierte de que hay que encontrar el malware de tipo dropper y otras herramientas similares de fases anteriores antes de reconstruir a partir de las copias. De lo contrario, puede restaurar el problema junto con los datos.
Plazos legales y regulatorios
Varios plazos pueden empezar a contar en el momento en que tiene conocimiento del incidente. Corren en paralelo.
| Norma | Se aplica cuando | Plazo | A quién se notifica |
|---|---|---|---|
| Artículo 33 del RGPD | Hay datos personales afectados, salvo que sea improbable que la brecha suponga un riesgo para las personas | Sin dilación indebida y, si es posible, en un plazo de 72 horas | Autoridad de control de protección de datos |
| Artículo 23 de NIS2 | Usted es una entidad esencial o importante y el incidente es significativo | Alerta temprana en 24 horas, notificación en 72 horas, informe final en un mes | CSIRT nacional o autoridad competente |
| KVKK (Türkiye) | Hay afectados datos personales tratados conforme a la legislación turca | Sin demora y, a más tardar, en 72 horas | Junta de Protección de Datos Personales |
El ransomware suele ser una brecha de disponibilidad y, a menudo, también de confidencialidad. En los ejemplos prácticos del Comité Europeo de Protección de Datos, un ataque con una buena copia de seguridad y sin exfiltración puede no requerir notificación, pero debe documentarse igualmente de forma interna conforme al artículo 33, apartado 5. Un ataque sin copia de seguridad utilizable, o con robo de datos, por lo general debe notificarse. Si las personas afectadas corren un riesgo alto, por ejemplo por el robo de documentos de identidad, también hay que informarlas.
No necesita respuestas completas para cumplir estos plazos. Las notificaciones de NIS2 se hacen por fases por diseño, y según el artículo 33, apartado 4, del RGPD la información puede facilitarse de forma gradual sin más dilación indebida. Revise también su póliza de ciberseguro, que puede fijar sus propios requisitos de notificación, y denuncie el delito a la policía.
Pagar o no pagar
El NCSC británico y las fuerzas de seguridad del Reino Unido no fomentan ni aprueban el pago. Pagar no garantiza que recupere sus datos. Sus sistemas seguirán infectados y puede volver a convertirse en objetivo. El proyecto No More Ransom, respaldado por Europol y la policía neerlandesa, publica herramientas de descifrado gratuitas para algunas familias de ransomware, así que consúltelo primero.
Pagar también puede ser ilegal. La Oficina de Control de Activos Extranjeros (OFAC) del Departamento del Tesoro de EE. UU. ha advertido de que los pagos de rescates a personas sancionadas pueden infringir las normas de sanciones estadounidenses. Pueden imponerse sanciones civiles en régimen de responsabilidad objetiva. El Reglamento (UE) 2019/796 sobre ciberataques prohíbe poner fondos a disposición de las personas que enumera. Cualquier decisión de pago corresponde a la dirección, a los asesores jurídicos y a las fuerzas de seguridad, no al equipo de TI en plena noche.
Lo que no debe hacer
- No apague los equipos salvo que no pueda aislarlos.
- No vuelva a conectar ni restaure sistemas antes de saber cómo entró el atacante.
- No negocie con el atacante ni le responda sin asesoramiento experto y jurídico.
- No hable del incidente por el correo o el chat de la empresa, que pueden estar vigilados.
- No borre nada, tampoco la nota de rescate.
Por dónde empezar, antes de que ocurra
- Imprima su plan de incidentes y su lista de contactos, y guarde copias fuera de la red.
- Acuerde de antemano quién puede autorizar la desconexión de sistemas.
- Mantenga al menos una copia de seguridad que no se pueda borrar con credenciales de administrador, y pruebe las restauraciones.
- Anote ya sus contactos para las notificaciones del RGPD, NIS2 y la KVKK.
- Cuente con apoyo de respuesta a incidentes antes de necesitarlo.
Si está gestionando un incidente ahora mismo, nuestro equipo de respuesta a incidentes puede ayudarle a contenerlo y a seguir estos pasos.
