500.000 datos de pacientes en 96 horas: Informe de incidente anónimo de un grupo de clínicas DACH

10 Min. de lectura

Entre mediados de marzo y principios de abril de 2026, el sector sanitario ha experimentado una ola de brechas de seguridad: CareCloud, Hong Kong Hospital Authority, Signature Healthcare (ANUBIS-Ransomware, 09.04.2026), ACN Healthcare (Lynx-Gruppe, 10.04.2026) y Covenant Health con casi 480.000 afectados. Paralelamente, en nuestra redacción estamos siguiendo un incidente anónimo en un grupo hospitalario DACH (Alemania, Austria, Suiza) con aproximadamente 500.000 registros de pacientes. El siguiente informe detalla las 96 horas desde la Comprometición Inicial hasta la obligación de notificar al BSI (Bundesamt für Sicherheit in der Informationstechnik) según NIS2 (Network and Information Systems Directive) y ofrece las lecciones aprendidas que deben incluirse en cada revisión de los playbooks de Security Operations de las próximas seis semanas.

Qué ha ocurrido: las 96 horas en detalle

¿Qué es un informe de incidentes en el contexto sanitario? Un informe de incidentes es la reconstrucción escrita estructurada de un incidente de seguridad o protección de datos, construida a lo largo de las fases de Compromiso Inicial, Ejecución, Persistencia, Movimiento Lateral, Exfiltración de Datos e Impacto. En el sector sanitario, el informe tiene además la tarea de documentar la obligación de notificación NIS2 al BSI (Federal Office for Information Security), la notificación de la RGPD a la autoridad de supervisión y, en su caso, la información a los pacientes. Un informe de incidentes completo suele comprender entre 40 y 120 páginas y es la base para el seguimiento interno y la revisión externa por parte de instancias de protección de datos y cumplimiento normativo.

En el caso anónimo, el grupo de clínicas con aproximadamente 500.000 registros de pacientes fue objetivo de un grupo de ransomware cuya firma mostraba varios patrones que también aparecieron en las oleadas de abril de ANUBIS y Lynx. El compromiso inicial se produjo en el día -4 a través de una puerta de escritorio remota sin parches con una configuración de MFA débil (basada en SMS, sin factor resistente a phishing). Los atacantes utilizaron un paquete de relleno de credenciales de una brecha anterior de un tercero y obtuvieron acceso a una cuenta de mantenimiento con amplios derechos de lectura sobre el KIS (sistema de información hospitalaria).

Los días -3 y -2 se utilizaron para reconocimiento y movimiento lateral. Los atacantes establecieron una cadena de proxy SOCKS, instalaron un beacon ligero en tres servidores de administración centrales y buscararon recursos compartidos de archivos hasta localizar las copias de seguridad. El día -1 fue la exfiltración real: unos 2,4 TB de datos, comprimidos en aproximadamente 420 GB, a través de la cadena SOCKS hacia un almacenamiento en la nube externo. El día 0 a las 04:12 horas comenzó la fase de cifrado, y al mismo tiempo se eliminaron las copias de seguridad en línea. A las 07:30 horas cayeron los primeros sistemas, y a las 08:45 horas la dirección de TI fue alertada.

Por qué la red KIS juega un papel especial

Los sistemas de información clínica (KIS) son consorcios históricamente evolucionados que incluyen bases de datos de pacientes, servidores DICOM, sistemas de laboratorio y de informes, así como dispositivos médicos especializados. La arquitectura en muchos centros sigue siendo hoy más bien un «plano» que una red estrictamente segmentada. Esto tiene consecuencias: quien tiene un pie en la administración a menudo alcanza con pocos pasos laterales también las bases de datos de pacientes. En el caso anónimo, ahí radicaba precisamente la crítica brecha, porque aunque existía la segmentación VLAN, la red de copias de seguridad del KIS era accesible a través de un host de salto heredado que nadie había documentado en la revisión de seguridad actual.

Las cuatro lecciones aprendidas en detalle

Escribimos sobre revistas, no sobre respuesta a incidentes. Aun así, aprendemos cada día lo delgada que es la línea entre una TI funcional y una noticia. En el sector sanitario, las noticias no son la consecuencia más grave, sino la parte más sencilla de las consecuencias.

Lección 1: El endurecimiento de la puerta de enlace RDP en 2026 no es negociable

Las puertas de enlace de escritorio remoto son una de las vías de entrada más comunes en el sector sanitario. En el caso anónimo, la vulnerabilidad residía en una combinación de tres factores: una falta de parche de seguridad desde otoño de 2025, MFA basada en SMS (vulnerable al phishing y no resistente a ataques Adversary-in-the-Middle) y una cuenta de mantenimiento que provenía de una brecha externa de un tercero en un paquete de Credential Stuffing. Las medidas concretas para clínicas con su propia puerta de enlace RDP: Primero, estado de parches mensuales en un ciclo de ventana de mantenimiento definido, con escalado para vulnerabilidades de más de 30 días. Segundo, Passkeys FIDO2 o de plataforma obligatorios para todas las cuentas administrativas con acceso RDP. Tercero, monitoreo de Credential Stuffing mediante la API de Have-I-Been-Pwned más fuentes propias de inteligencia de amenazas para detectar compromisos a tiempo.

Lección 2: Redes de copia de seguridad segmentadas con hosts bastión explícitos

La segunda lección se refería a la cadena de copia de seguridad. En el caso, la red de copia de seguridad en línea era accesible a través de un Jumphost heredado, cuyo significado ya nadie documentaba activamente. Esto no es inusual: la TI de las clínicas a menudo tiene rutas de administración históricamente crecidas que no se trazan claramente en la topología de red oficial. La medida correctora es una estricta separación de las redes de copia de seguridad con hosts bastión explícitos, derechos de acceso documentados y una copia de seguridad sin conexión que está físicamente separada de la red en línea. En el caso, el proceso de copia de seguridad sin conexión se introdujo en las semanas siguientes a la brecha y redujo el tiempo de recuperación en la prueba de seguimiento simulada de 14 días a 4 días.

Lección 3: Política de registro de auditoría uniforme en todos los sistemas médicos especializados

Una de los mayores desafíos en la fase de respuesta a incidentes fue la reconstrucción de la exfiltración. Los sistemas especializados (KIS, PACS, LIS, AIS) llevaban cada uno sus propios registros de auditoría con diferentes formatos y plazos de conservación. La consolidación costó unas 40 horas, de las cuales unas 25 eran evitables con una política de registro de auditoría uniforme. La recomendación concreta: un proyecto SIEM central que alimente los sistemas médicos especializados y fuerce una taxonomía de eventos uniforme. Para grupos de clínicas de tamaño mediano (3 a 8 ubicaciones), la inversión en el año 1 oscila entre 150.000 y 350.000 euros, típicamente con una tasa de subvención del 30 al 40% a través del programa sucesor de KHZG.

Lección 4: Cadena de respuesta a incidentes ensayada con BSI, protección de datos y comunicación

La obligación de notificación de NIS2 entra en vigor dentro de las 24 horas tras el conocimiento del incidente significativo. La notificación de la DSGVO a la autoridad de supervisión debe realizarse dentro de las 72 horas. Paralelamente, se ejecutan cascadas de comunicación internas (dirección de la clínica, dirección médica, comité de empresa) y partes interesadas externas (representantes de pacientes, para cotizadas en bolsa además comunicados ad-hoc). Quien no practique estas cascadas en el marco de ejercicios de mesa anuales, perderá los plazos en caso real. En el caso, el grupo de clínicas había establecido una simulación semestral; exactamente esta rutina fue la razón por la que la notificación inicial al BSI ya se presentó después de 21 horas, la notificación de la DSGVO después de 58 horas, y la información a los pacientes se envió después de 9 días.

Qué significa esto para la propia organización

La ola de brechas de seguridad en el sector sanitario en abril de 2026 no es casual. Los grupos de ransomware han identificado este segmento como un objetivo lucrativo, porque la combinación de infraestructura crítica, alta disposición a pagar rescates y redes históricamente poco segmentadas resulta atractiva para los atacantes. La consecuencia para la TI de los hospitales del DACH: las cuatro lecciones aprendidas deberían ser visibles en las propias medidas antes de finales del segundo trimestre de 2026, no solo después de sufrir un incidente propio.

Un paso intermedio pragmático: un ejercicio de simulación basado en el escenario de 96 horas descrito aquí, realizado conjuntamente con TI, protección de datos, dirección del hospital y una empresa externa de respuesta a incidentes. La inversión de tiempo es de medio día, pero el beneficio de conocimientos en la práctica es considerable. Quién después de tal ejercicio no pueda derivar tres medidas concretas, tiene una TI excepcionalmente buena o una dirección hospitalaria excepcionalmente honesta. Ambas cosas son en la realidad menos frecuentes de lo que cabría esperar.

Qué espera la dirección y el consejo de administración después del incidente

Además de la respuesta técnica al incidente, espera un segundo bloque de trabajo que muchas subestiman: el seguimiento en los órganos de supervisión. El consejo de administración de un grupo hospitalario o una empresa farmacéutica espera después de un incidente como este tres artefactos concretos. En primer lugar, un informe de lecciones aprendidas que nombre sin rodeos las causas y no disimule medias verdades. En segundo lugar, un plan de medidas con claras responsabilidades y plazos hasta la próxima reunión. En tercer lugar, una plantilla de presupuesto que priorice inversiones adicionales para el refuerzo de la seguridad y justifique la notificación NIS2.

Quién no entregue estos tres artefactos en las primeras dos semanas después de contener el incidente, perderá la iniciativa frente a los interrogadores externos (aseguradoras, auditores, autoridades supervisorias). Los seguimientos más exitosos combinan profundidad técnica con comunicación honesta de la dirección. Los peores seguimientos son una mezcla de «fue mala suerte» y «habíamos hecho todo correctamente», y ambas frases son rara vez verdaderas en un informe de incidente de esta magnitud.

El vistazo a la ola de abril: lo que se muestra entre los incidentes

Los cinco incidentes conocidos públicamente, desde CareCloud hasta Covenant Health y las víctimas de los grupos ANUBIS y Lynx, muestran tres patrones comunes. En primer lugar, la compromisión inicial suele ocurrir a través de vías de acceso remoto (RDP, VPN, portales de teletrabajo). En segundo lugar, la exfiltración como principal medio de presión antes del cifrado, no al revés. En tercer lugar, los grupos de ransomware no solo publican demandas de rescate, sino también ejemplos de prueba de brecha en sitios de filtración para aumentar su poder de negociación. Cada uno de estos tres puntos de patrón tiene contramedidas relevantes; cada organización debería evaluarlos en su propia situación.

La dimensión del seguro cibernético que a menudo falta en las conversaciones con el consejo de administración

Una dimensión que muchos grupos hospitalarios solo toman en serio en el segundo o tercer incidente: el papel del seguro cibernético y las obligaciones asociadas. Muchas pólizas exigen como requisito para la prestación no solo estándares básicos de seguridad, sino también ejercicios de simulación demostrables y procesos de respuesta a incidentes documentados. Quién en un caso real descubre que estas obligaciones no se han cumplido correctamente, pierde hasta el 100% de la cobertura del seguro, aunque las primas se han pagado durante años. La recomendación: revisar anualmente con el corredor las obligaciones de la propia póliza cibernética y documentar la comparación con la operación de seguridad real.

Un segundo aspecto que cada vez es más relevante en el seguro cibernético sanitario en 2026: los límites de cobertura para fallos de dispositivos biomédicos están limitados al alza en muchas pólizas. Las organizaciones que solo pueden restaurar parcialmente sistemas OT (dispositivos médicos, equipos de laboratorio, sistemas de imagen) en un caso de ransomware, a veces se enfrentan a daños subasegurados. La consecuencia operativa es un mapeo de riesgos granular del propio paisaje OT con evaluación explícita de las consecuencias de fallo por categoría de dispositivo. Quién no tiene este mapeo, argumenta en caso de siniestro sin fundamentos. Una tarde de mapeo protege de un trimestre de discusiones con el asegurador.

Preguntas frecuentes

¿Cómo funciona exactamente la obligación de notificación de NIS2 en caso de una brecha en el sector sanitario?

Las instalaciones esenciales y importantes (a las que pertenecen la mayoría de los grandes hospitales) deben notificar incidentes significativos al BSI en un plazo de 24 horas (alerta temprana), presentar una notificación de incidente con evaluación inicial en 72 horas y entregar un informe final en el plazo de un mes. La notificación se realiza a través del portal de notificación del BSI. Los detalles sobre la cualificación como «incidente significativo» los regula la normativa de desarrollo del BSI.

¿Qué debería hacer el director de un hospital en las primeras dos horas?

Tres pasos clave: Primero, convocar el equipo de crisis (TI, delegado de protección de datos, dirección médica, comunicación, departamento jurídico). Segundo, preparar la documentación para la obligación de notificación de NIS2 y la notificación de RGPD para no perder los plazos. Tercero, activar una empresa externa de respuesta a incidentes, si no existe un equipo interno suficiente. Quien realice estos tres pasos en las primeras dos horas tendrá una clara ventaja sobre las organizaciones que empiezan a coordinarse en la cuarta hora.

¿Cómo gestionar la comunicación con los pacientes sin generar pánico?

El RGPD exige en caso de riesgo elevado la notificación a los afectados en un lenguaje claro y sencillo. En la práctica, han demostrado su eficacia los breves folletos de preguntas frecuentes con tres bloques: qué ha ocurrido, qué datos están afectados y qué deben hacer los afectados ahora. El pánico surge generalmente por una comunicación tardía o defensiva, no por una información clara. Según nuestras observaciones, una comunicación proactiva y objetiva reduce en un 40-60% las llamadas a la centralita del hospital.

¿Debe pagarse el rescate cuando las vidas de los pacientes están en peligro?

Legalmente, el pago no está prohibido en Alemania, pero el BSI y la BKA no lo recomiendan claramente. Ética y prácticamente, la decisión es compleja: un pago financia la siguiente campaña y en aproximadamente el 30% de los casos no conduce a una recuperación completa de los datos. En el caso anónimo no se pagó; la recuperación se realizó mediante copias de seguridad sin conexión con un tiempo de recuperación de 4 días. Una base documentada para la decisión (comisión ética, dirección, dirección médica) debería existir antes de que ocurra la emergencia.

¿Qué papel juega el sucesor de la KHZG para las inversiones en ciberseguridad?

La Ley Hospital del Futuro (KHZG) proporcionó fondos importantes para ciberseguridad de 2020 a 2024. Los programas sucesores (proyectos Bund-Länder para la seguridad TI en el sector sanitario) continúan con la financiación bajo nuevas condiciones marco. Para los hospitales, merece la pena revisar las ventanas de financiación actuales, porque los proyectos SIEM, la segmentación de red y las pruebas de penetración suelen ser cofinanciables en un 30-50%.

¿Qué tiempo realista se necesita para que un hospital esté «preparado para NIS2»?

Para un grupo hospitalario de tamaño medio calculamos de 9 a 15 meses hasta alcanzar la preparación completa para NIS2, dependiendo del grado de madurez actual. Los primeros tres meses suelen ser de análisis de brechas, los meses cuatro a doce la implementación de medidas críticas, y los últimos tres meses ejercicios de simulación y documentación. Quien empiece más tarde se encontrará con las oleadas de inspección del BSI de los años 2026 y 2027 con documentación incompleta.

Red: Siga leyendo en Security Today

• Análisis sobre la ola de autenticación multifactor adaptativa y el ataque de phishing por código de dispositivo
• Vista de cumplimiento sobre DORA 2.0 y la política de la FCA del Reino Unido del 16 de abril de 2026
• Asesoramiento sobre el plan de 72 horas fuera de banda de Microsoft para el CVE de ASP.NET

Fuente imagen de portada: Pexels / Cottonbro Studio (px:3970330)

Sobre el autor: Tobias Massow

Más artículos de Tobias Massow