¿Cómo un solo token de GitHub eludió el perímetro de un gigante farmacéutico global?

Novo Nordisk mantiene una infraestructura de seguridad de múltiples capas. La empresa emplea detección avanzada de endpoints, segmentación de red y un centro de operaciones de seguridad dedicado. Estas defensas cuestan millones de dólares anualmente. Sin embargo, toda la arquitectura colapsó debido a una sola cadena de texto en un sitio web de acceso público. La brecha en el gigante farmacéutico danés es un estudio de caso sobre la paradoja arquitectónica del desarrollo de software moderno. Una inversión masiva en defensa perimetral falló porque existía un único token de autenticación en el lugar equivocado.

Pasé años comunicándome con investigadores de seguridad a través de Signal y canales cifrados con PGP. La mayoría de ellos no buscan vulnerabilidades complejas de día cero en firewalls reforzados. Buscan el camino de menor resistencia. En el incidente de Novo Nordisk, el camino fue un token de acceso personal (PAT) de GitHub con privilegios elevados que se dejó en el JavaScript del lado del cliente en un subdominio poco conocido. Este no fue un hackeo sofisticado. Fue un ejercicio de descubrimiento. Una vez que el grupo de amenazas, conocido como FulcrumSec, encontró el token en marzo, el perímetro de seguridad formal se volvió irrelevante. El token proporcionó acceso autenticado. Para los sistemas internos, los atacantes eran desarrolladores legítimos.

La anatomía de una intrusión silenciosa

FulcrumSec operó dentro de la red de Novo Nordisk durante más de dos meses antes de ser detectado. Durante este período, el grupo utilizó el token inicial de GitHub para clonar repositorios privados. Estos repositorios contenían más que solo código. Contenían credenciales secundarias, definiciones de infraestructura y documentación interna. Este es un patrón común en las intrusiones modernas. Un atacante utiliza un pequeño punto de apoyo para recolectar secretos más poderosos. No necesitan explotar un error de software cuando tienen las llaves de la puerta principal.

Para cuando Novo Nordisk reveló el incidente el 11 de junio, los atacantes habían exfiltrado 1,3 TB de datos. Este alijo incluía 700.000 archivos. Aunque la empresa describió inicialmente el impacto como limitado a datos de pacientes seudonimizados y registros de profesionales de la salud, la realidad parece más grave. Los datos robados incluyen información patentada sobre medicamentos comercializados y no lanzados, investigación de ensayos clínicos y modelos de IA internos. FulcrumSec afirma que la información podría ahorrar a los competidores entre tres y cinco años de tiempo de desarrollo. Esta es la definición de un fallo sistémico. La brecha pasó de un simple token filtrado a la pérdida de propiedad intelectual central.

Por qué los pipelines de desarrollo son sistemas de producción

Las plataformas de desarrollo son los sistemas de mayor valor en la empresa moderna. La mayoría de los programas de seguridad no reconocen esta realidad. Un repositorio de código ya no es un simple contenedor de almacenamiento para archivos de texto. Es el plano de todo el entorno digital. Contiene las configuraciones para entornos en la nube y los pipelines de despliegue que envían el código a los clientes. Cuando un atacante obtiene acceso a un repositorio, ve el cableado de la organización.

Matt Kimpel, director de seguridad de la información en Magna5, señala que los desarrolladores tienen acceso permanente a los sistemas que más importan. Poseen credenciales para los pipelines de construcción y los entornos en la nube. Estos sistemas están "aguas arriba" del entorno de producción. Si un atacante compromete el código antes de que se compile, controla el producto final. Esto hace que la estación de trabajo del desarrollador y el repositorio sean más críticos que el propio servidor de producción. Las protecciones tradicionales como las aprobaciones de ramas y las revisiones de código asumen que la persona que realiza la acción es un empleado de confianza. Si la identidad se ve comprometida, esos mismos controles facilitan el ataque.

El riesgo invisible de las identidades de máquina

Las organizaciones tratan la gestión de secretos como un problema de herramientas. Compran una bóveda (vault) y asumen que el problema está resuelto. El incidente de Novo Nordisk demuestra que la gestión de secretos es un problema de identidad. El token de GitHub filtrado es una identidad de máquina. A diferencia de las cuentas humanas, las credenciales de máquina a menudo carecen de propietarios claros. No tienen calendarios de rotación consistentes. Con frecuencia carecen de un monitoreo significativo. Estos tokens persisten durante meses o años sin cambios.

Shane Barney, CISO de Keeper Security, señala que esta invisibilidad convierte un solo token en una intrusión a largo plazo. Cuando una credencial de máquina tiene permisos amplios y nadie supervisa su uso, un atacante no necesita escalar privilegios. El acceso ya está ahí. El radio de explosión es todo el entorno. Esta es la razón por la que los atacantes permanecieron sin ser detectados durante 60 días. No estaban irrumpiendo en el sistema. Estaban usando el sistema tal como fue diseñado para ser usado.

La aparición de actores de amenazas secundarios

Un segundo grupo de amenazas que se hace llamar TheUSERS007 también reclamó acceso a los sistemas de Novo Nordisk entre el 5 y el 7 de junio. Este grupo se centró en datos relacionados con la investigación de IA. Esto sugiere que una vez que ocurre una filtración importante, otros actores comienzan a sondear la misma infraestructura. Una sola vulnerabilidad en un pipeline de desarrollo a menudo indica debilidades sistémicas más amplias. Si un desarrollador deja un token en un script público, es probable que otros desarrolladores sigan patrones inseguros similares. La superficie de ataque no es un mapa estático. Es un entorno dinámico donde un error invita a un mayor escrutinio por parte de múltiples adversarios.

Esta intrusión secundaria resalta el riesgo para los modelos de IA internos. Estos modelos representan el futuro de la investigación farmacéutica. Se construyen sobre años de datos patentados y una inversión computacional masiva. La pérdida de estos modelos no es solo una brecha de datos. Es una pérdida de ventaja competitiva. El entorno digital no tiene muros físicos. Una vez que la lógica del sistema queda expuesta a través del código fuente y los pesos del modelo, el daño es permanente.

Pasar de herramientas reactivas al control de identidad proactivo

Para mitigar estos riesgos, las organizaciones deben cambiar su forma de ver el acceso de los desarrolladores. Una bóveda es una caja para secretos. La gestión de identidades es el control de quién puede abrir la caja y por cuánto tiempo. El objetivo es reducir la vida útil de cada secreto. Si un token caduca en cuatro horas, una filtración en un archivo JavaScript es una molestia temporal. Si un token dura un año, una filtración es una catástrofe.

Centralizar la gestión de secretos es un paso necesario. Cada identidad en el entorno debe seguir el principio de mínimo privilegio. Esto significa que un token de GitHub solo debe tener acceso a los repositorios específicos requeridos para una tarea. No debe tener permisos administrativos amplios sobre toda la organización. La rotación automatizada garantiza que las credenciales no sobrevivan a su propósito. Esta disciplina no impide que un atacante encuentre un token, pero limita lo que puede hacer con él.

Pasos prácticos para la seguridad del pipeline

Las organizaciones deben comenzar con un inventario de identidades no humanas. La mayoría de las empresas no saben cuántas claves de API o cuentas de servicio existen en su entorno. No puedes proteger lo que no puedes ver. Este inventario debe incluir el alcance de cada clave y su última fecha de uso. Muchas organizaciones descubren que un gran porcentaje de sus tokens activos ya no son necesarios. Estos secretos huérfanos son objetivos de alto valor para los atacantes.

El monitoreo de las identidades de máquina es tan vital como el monitoreo de los inicios de sesión humanos. Los equipos de seguridad deben establecer una línea base del comportamiento normal para las cuentas de servicio. Si un token de GitHub suele acceder a tres repositorios desde una dirección IP conocida y de repente comienza a clonar 500 repositorios desde una región diferente, el sistema debe activar una alerta. La detección debe ocurrir en la capa de identidad. Parchear el software es importante, pero en una era donde las identidades son el objetivo principal, la visibilidad del uso de las credenciales es la única forma de atrapar a un intruso silencioso.

Pasos para la reducción inmediata del riesgo

1. Escanear todos los activos orientados al público en busca de secretos expuestos. Utilizar herramientas automatizadas para encontrar tokens, claves de API y credenciales de bases de datos en el código del lado del cliente.
2. Implementar tokens de corta duración. Reemplazar los tokens de acceso personal de larga duración con credenciales granulares y de tiempo limitado siempre que la plataforma lo admita.
3. Auditar los permisos de los repositorios. Eliminar el acceso administrativo de los tokens de desarrollador. Asegurarse de que ningún token individual tenga el poder de clonar todo el código base.
4. Habilitar el escaneo de secretos en el pipeline de CI/CD. Bloquear cualquier commit que contenga un secreto en texto plano antes de que llegue al repositorio.
5. Monitorear la actividad anómala en los repositorios. Configurar alertas para la clonación masiva o el acceso desde ubicaciones inusuales.

Este incidente es un recordatorio de que el perímetro se ha movido. Ya no está en el borde de la red. Existe al nivel del token individual y la identidad específica. Si no gestionas estas identidades con el mismo rigor que tus servidores de producción, tus defensas son una ilusión.

Fuentes: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), reportes de DataBreaches.net.

Descargo de responsabilidad: Este artículo es solo para fines informativos y educativos. No reemplaza una auditoría de ciberseguridad profesional ni un servicio de respuesta ante incidentes.