Universidad de Copenhague: brecha en un entorno de pruebas

La Universidad de Copenhague (UCPH), la más antigua de Dinamarca, ha confirmado que unos atacantes entraron en uno de sus entornos de pruebas y obtuvieron datos personales de unas 525.000 personas. El mismo ataque comprometió también los códigos PIN de las tarjetas identificativas de unos 20.000 empleados y estudiantes. Los hechos los recogen BleepingComputer, Help Net Security, Infosecurity Magazine y DataBreaches.net, que citan los comunicados de la universidad.

Qué pasó, día a día

• 20 de octubre: se detecta la intrusión y, según la universidad, se contiene; se bloquea el acceso de los atacantes.
• 23 de octubre: UCPH comunica públicamente el ataque al entorno de pruebas. Esa misma tarde, tras una evaluación de seguridad, limita el acceso físico a algunos lugares del campus.
• 25 de octubre: una actualización revela que el ataque comprometió los PIN de las tarjetas identificativas de unas 20.000 personas. La universidad explica que no lo dijo antes por motivos de seguridad, hasta haber cambiado los códigos. Con los nuevos PIN, los lugares cerrados vuelven a abrir.
• 26 de octubre: UCPH apaga de forma preventiva y controlada Workzone, Nimbus y otros sistemas administrativos, y avisa de posibles problemas para acceder a sus webs. En un primer momento habla de un nuevo ataque.
• 27 de octubre: la evaluación se revisa. Según la universidad no hubo un segundo ataque, sino actividad en el sistema que al principio parecía indicarlo; el apagado sigue siendo necesario y vinculado al ataque original, y algunos sistemas todavía sufren interrupciones.

La universidad afirma que no tiene indicios de que los atacantes llegaran a los sistemas que sostienen la actividad diaria. El incidente se ha notificado a la autoridad danesa de protección de datos, porque entra en el ámbito del RGPD.

Qué datos

Según Help Net Security, los datos incluyen nombres, números de identidad nacional (CPR), teléfonos del trabajo y particulares y direcciones de correo personales; BleepingComputer recoge la misma lista de forma más breve. La universidad sigue analizando el alcance exacto de la brecha. Infosecurity Magazine habla de «más de 520.000» personas.

Las fuentes difieren en un punto: BleepingComputer describe los 20.000 PIN como personas «adicionales», mientras que la universidad, citada por Help Net Security, precisa que no se trata de una nueva brecha respecto a la comunicada el 23 de octubre. No está claro si esas 20.000 personas están incluidas en las 525.000.

Un dato a tener en cuenta: según BleepingComputer, la universidad tiene unos 36.800 estudiantes y 10.700 empleados. El número de personas afectadas es, por tanto, muy superior a la población actual; las fuentes no dicen a quién pertenecen los demás registros.

Qué no se sabe

Las fuentes no indican el vector de acceso, el tipo de entorno de pruebas, el autor del ataque ni reivindicaciones o peticiones de rescate. No se han publicado indicadores de compromiso. Cualquier hipótesis sobre la técnica usada sería, hoy, una especulación.

Por qué importa: datos reales fuera de producción

El caso pone de relieve un problema muy extendido. Los entornos de pruebas, preproducción y desarrollo contienen a menudo copias de datos de producción, pero reciben menos atención: parches más lentos, cuentas compartidas, accesos más amplios para desarrolladores o proveedores, registros escasos o inexistentes. Si contienen datos reales, su valor para un atacante es el mismo que el de producción.

Dos elementos hacen que este incidente sea especialmente delicado:

• el CPR es un identificador permanente, que en Dinamarca se usa para muchísimos servicios; como el DNI en España, no se puede «cambiar» como una contraseña. Las fuentes subrayan el riesgo de phishing e ingeniería social contra las personas afectadas;
• los PIN de las tarjetas vinculan el incidente informático con la seguridad física: la universidad tuvo que cerrar algunas zonas y redistribuir los códigos antes de reabrirlas.

Impacto para las empresas europeas e italianas

Quien trata datos personales tiene las mismas obligaciones del RGPD: notificación a la autoridad de control en 72 horas (art. 33), comunicación a los interesados cuando el riesgo es alto (art. 34) y, antes de todo, protección de datos desde el diseño, minimización y seudonimización (arts. 25 y 32), que también se aplican a los entornos de pruebas. Para las entidades sujetas a NIS2 (en Italia, el Decreto Legislativo 138/2024), un incidente significativo exige además una alerta temprana al CSIRT Italia en 24 horas. Universidades, centros de investigación y organizaciones sanitarias, que gestionan grandes archivos históricos de personas, están entre los más expuestos.

Qué hacer ya

• Haz inventario de los entornos que no son de producción (pruebas, preproducción, desarrollo, formación) y comprueba cuáles contienen datos personales reales.
• Sustituye los datos reales por datos enmascarados, seudonimizados o sintéticos; borra las copias antiguas que ya no se usan.
• Separa los entornos: ni credenciales, ni claves, ni cuentas de servicio, ni conexiones compartidas con producción; MFA en todos los accesos administrativos, también en pruebas.
• Lleva los registros de los entornos de pruebas a la monitorización y configura alertas para exportaciones masivas, consultas inusuales y accesos desde direcciones nuevas.
• Mantén los sistemas de acceso físico (PIN, tarjetas) fuera de las redes y bases de datos accesibles desde los entornos de pruebas, y prepara un procedimiento para cambiar los códigos rápidamente.
• Si se han filtrado identificadores como el CPR o el número fiscal, avisa a las personas del riesgo de phishing dirigido e indica cómo verificar las solicitudes por otro canal.
• En tu plan de respuesta, prevé el apagado controlado de los sistemas y una comunicación que se pueda corregir sobre la marcha, como hizo UCPH.

Cómo ayuda ARXDOME

Con ARX Sentry, el agente de ARXDOME se instala también en los servidores de pruebas: registros, eventos de seguridad, accesos e integridad de los archivos llegan a las mismas páginas del SOC que producción. ARX Shield muestra las vulnerabilidades abiertas y permite aislar una máquina sospechosa, mientras que ARX Expose señala los servicios expuestos en internet y las cuentas de la empresa implicadas en brechas.

Última actualización: 27 de octubre de 2026