El ataque de ransomware sufrido por Telemadrid dejó una lección especialmente relevante para los equipos de ciberseguridad: sobrevivir al cifrado de los sistemas de producción sirve de poco si el atacante consigue destruir también las copias de seguridad. En este incidente, los backups almacenados en infraestructura Dell PowerProtect Data Domain permanecieron disponibles y permitieron reconstruir los sistemas críticos sin que la cadena pagara el rescate exigido por los ciberdelincuentes.
Las claves del ransomware de Telemadrid en 30 segundos
- El ataque afectó a sistemas de producción y a la emisión de Telemadrid.
- Los backups locales en Dell Data Domain no fueron comprometidos por el ransomware.
- La recuperación se realizó inicialmente desde infraestructura local, sin depender de comunicaciones externas afectadas.
- Los sistemas restaurados se verificaron en un entorno aislado antes de volver a producción.
- Telemadrid recuperó sus sistemas críticos sin pagar a los extorsionadores.
El incidente, documentado posteriormente por SoftwareOne como caso de éxito, resulta interesante porque desplaza el análisis desde la prevención hacia una fase que a menudo recibe menos atención: qué ocurre cuando el atacante ya está dentro y parte de la infraestructura ha sido cifrada.
En ese momento, EDR, antivirus, segmentación o filtrado de correo ya no resuelven por sí solos el problema. La organización necesita determinar qué sistemas están comprometidos, aislarlos, reconstruir un entorno fiable y encontrar un punto de recuperación que el atacante no haya podido manipular.
Telemadrid contaba con una arquitectura de protección basada en sistemas Data Domain DD6400 y Data Protection Suite, además de un servicio gestionado de backup 24/7 proporcionado por SoftwareOne.
Según la información publicada sobre el incidente, otros sistemas de la organización fueron cifrados, pero las copias locales alojadas en Data Domain permanecieron disponibles para iniciar la recuperación.
El ransomware moderno también busca destruir la recuperación
Las copias de seguridad se han convertido en un objetivo prioritario para numerosos operadores de ransomware.
La lógica es sencilla. Si una organización dispone de una copia reciente, íntegra y rápidamente recuperable, disminuye considerablemente la presión para pagar por un descifrador.
El atacante tiene por tanto un incentivo para localizar servidores de backup, consolas de administración, repositorios, snapshots y credenciales con permisos suficientes para borrar o modificar las copias antes de ejecutar el cifrado generalizado.
Para David Carrero Fernández-Baillo, cofundador de Stackscale (Grupo Aire) y experto en infraestructura cloud, este es precisamente uno de los aspectos más relevantes del caso de Telemadrid.
“El detalle que marca la diferencia aquí no es solo tener backup, sino que las copias resistieran al propio ataque. El error clásico en ransomware es que el cifrado alcanza también a las copias de seguridad”.
La consecuencia es que una copia almacenada en otra carpeta o incluso en otro servidor no constituye necesariamente una defensa suficiente.
Si utiliza el mismo dominio de autenticación, las mismas credenciales administrativas o puede ser modificada desde los sistemas comprometidos, puede formar parte del mismo dominio de fallo.
De ahí la importancia que han adquirido mecanismos como la inmutabilidad.
Una copia protegida mediante políticas WORM (Write Once, Read Many) busca impedir su modificación o eliminación durante un periodo establecido. Incluso aunque el ransomware alcance parte de la infraestructura, debería existir un punto de recuperación que no pueda sobrescribirse utilizando los mecanismos habituales de administración.
Pero la inmutabilidad tampoco debería considerarse una solución aislada.
Separación de credenciales, autenticación multifactor, segmentación, almacenamiento externo y diferentes niveles de aislamiento añaden barreras para evitar que una única identidad comprometida permita destruir producción y backup simultáneamente.
La recuperación local fue determinante
El caso de Telemadrid incorpora otra característica interesante desde el punto de vista de la respuesta a incidentes.
Las comunicaciones también estaban afectadas.
Eso podía convertir una recuperación completamente dependiente de servicios externos en un problema adicional. Restaurar varios terabytes desde una nube remota necesita conectividad suficiente y puede alargar el objetivo de tiempo de recuperación (RTO).
La arquitectura permitió realizar una recuperación inicialmente local desde los dispositivos Data Domain, transfiriendo la información directamente hacia la infraestructura reconstruida.
La capa externa seguía teniendo otra función.
Telemadrid había incorporado Azure Cloud Tier para trasladar datos históricos y copias antiguas fuera del centro de datos principal. Esa separación proporciona protección adicional ante incidentes capaces de afectar físicamente al centro de procesamiento de datos o inutilizar completamente la infraestructura local.
Conviene, sin embargo, diferenciar una copia externa de un air gap estricto. Que un backup se encuentre en otra ubicación o en una nube pública no significa automáticamente que esté desconectado lógicamente del entorno atacado. Su resistencia dependerá de permisos, credenciales, políticas de retención, mecanismos de inmutabilidad y arquitectura concreta.
La estrategia efectiva consiste en evitar que todos los caminos de recuperación puedan ser destruidos utilizando el mismo acceso.
Es el principio que hay detrás de la conocida regla 3-2-1: mantener tres copias de los datos, utilizar al menos dos medios o sistemas diferentes y conservar una copia fuera de la ubicación principal.
En entornos expuestos a ransomware, esa estrategia puede reforzarse con una copia inmutable o suficientemente aislada.
Restaurar un servidor no significa que pueda volver a producción
Telemadrid tuvo que resolver además otra cuestión habitual después de un ataque: cómo saber que lo restaurado está limpio.
Recuperar directamente una máquina virtual y volver a conectarla a la red puede reintroducir malware, persistencia o configuraciones comprometidas.
Según SoftwareOne, durante la recuperación se instalaron servidores desde cero dentro de un entorno seguro y aislado. Las máquinas virtuales restauradas desde backup fueron verificadas antes de incorporarlas nuevamente a producción.
Este procedimiento acerca el backup a un proceso completo de recuperación frente a incidentes.
No basta con conocer dónde están los datos. La organización necesita disponer de procedimientos para determinar qué punto temporal es fiable, reconstruir identidades y sistemas, validar las cargas recuperadas y establecer un orden de restauración.
También hay que considerar las dependencias.
Una aplicación puede estar perfectamente restaurada y continuar sin funcionar porque necesita DNS, Active Directory, una base de datos, certificados o algún servicio de red que todavía permanece fuera de servicio.
Aquí entran dos métricas especialmente importantes: RPO y RTO.
El objetivo de punto de recuperación (RPO) establece cuánta información puede perderse. Si una copia se realiza cada seis horas, por ejemplo, podría existir una pérdida de datos desde el último punto recuperable.
El objetivo de tiempo de recuperación (RTO) determina cuánto puede permanecer indisponible el servicio.
En una cadena de televisión que debe emitir las 24 horas, este último indicador adquiere una importancia evidente.
“Con una emisión 24/7 de por medio, lo crítico no es solo el RPO sino el RTO: cada minuto sin restaurar es señal caída”, explica Carrero.
Telemadrid recuperó el acceso completo a la consola después de 48 horas y fue restableciendo progresivamente sus servicios productivos. SoftwareOne asegura que se recuperó el 100 % de la información crítica y que no se pagó ningún rescate.
Un backup sin pruebas de restauración es una apuesta
La existencia de copias tampoco demuestra que puedan recuperarse cuando llegue el incidente.
Una organización puede comprobar cada mañana que su herramienta muestra decenas de tareas completadas correctamente y descubrir durante una emergencia que los datos están corruptos, faltan dependencias, las credenciales necesarias ya no existen o recuperar todo requiere varios días.
Por eso Carrero señala las pruebas periódicas como otra de las enseñanzas del caso.
“Dos cosas suelen decidir un caso así: probar restauraciones de forma periódica, porque un backup no verificado no es un backup, y aplicar la regla 3-2-1 para que ninguna copia comparta el mismo dominio de fallo”.
Las pruebas permiten medir además el RTO real.
No importa demasiado que un plan de continuidad establezca sobre el papel una recuperación en cuatro horas si nunca se ha comprobado cuánto tarda realmente en reconstruirse el servicio completo.
La operación debería contemplar igualmente escenarios en los que las propias herramientas habituales de administración dejan de estar disponibles.
¿Qué ocurre si Active Directory está comprometido? ¿Existen credenciales independientes para acceder al backup? ¿Puede restaurarse sin conexión a Internet? ¿Hay documentación accesible fuera de la red corporativa? ¿Se conoce el orden de recuperación de los sistemas?
Son preguntas que resultan mucho más baratas antes del incidente.
El caso de Telemadrid muestra así una diferencia esencial entre disponer de backup y disponer de capacidad de recuperación frente a ransomware.
La primera puede comprobarse mirando una consola. La segunda solo se demuestra cuando las copias son resistentes al atacante, pueden restaurarse dentro del tiempo necesario y existe un procedimiento para reconstruir un entorno fiable.
Como resume Carrero, “la ciberseguridad se juega en la preparación, no en la reacción”.
Preguntas frecuentes
¿Telemadrid pagó el rescate del ransomware?
No. Según SoftwareOne, la cadena recuperó sus sistemas críticos y no realizó ningún pago a los extorsionadores.
¿Por qué el ransomware intenta borrar también los backups?
Porque unas copias recuperables reducen la capacidad de extorsión del atacante. Por ello, proteger las credenciales y consolas de backup y disponer de copias inmutables o aisladas resulta especialmente importante.
¿Qué significa que un backup sea inmutable?
Significa que la copia está protegida frente a modificaciones o eliminaciones durante un periodo determinado. Tecnologías y políticas WORM pueden utilizarse para crear este tipo de protección.
¿Es suficiente guardar una copia en la nube?
No necesariamente. Una copia remota mejora la resiliencia, pero debe analizarse si un atacante con credenciales comprometidas podría modificarla o eliminarla. Ubicación, inmutabilidad, separación de identidades y capacidad real de restauración deben evaluarse conjuntamente.
