Brecha de seguridad de Northflank: Qué secretos rotar

Brecha de seguridad de Northflank: Qué rotar tras el incidente

Última actualización: 5 de noviembre de 2026. La página del incidente de Northflank se volvió a comprobar el 5 de noviembre; su última actualización publicada seguía siendo la del 2 de noviembre de 2026.

En la brecha de seguridad de Northflank, que la empresa denomina incidente de seguridad y que hizo pública el 30 de octubre de 2026, la plataforma pidió a los clientes, como medida de precaución, que dieran por desencriptadas todas las variables de entorno, es decir, desbloqueadas de modo que los atacantes pudieran leerlas.

Las variables de entorno son ajustes almacenados que las aplicaciones leen al ejecutarse. A menudo contienen claves de API, los códigos secretos que permiten a un software utilizar un servicio. Los usuarios también informaron del uso no autorizado de sus claves de API de IA. La página de estado no indica que se robaran todas las variables almacenadas.

A continuación: lo que han comunicado Northflank, Railway y Huntress, y las comprobaciones que conviene hacer ya.

Northflank: el 30 de octubre de 2026 pidió a los clientes que dieran por desencriptadas todas las variables de entorno y que rotaran todos los secretos (Northflank).
Black October: Wiz, una empresa de seguridad en la nube, contabilizó al menos nueve plataformas para desarrolladores de IA (servicios para crear y ejecutar aplicaciones de IA) que comunicaron incidentes entre el 6 y el 30 de octubre. Sus explicaciones públicas diferían, varias eran preliminares y algunas causas raíz se desconocían (Wiz).
Railway: el 21 de octubre de 2026 indicó que un tercero no autorizado podría haber accedido a variables de entorno encriptadas de los clientes y, en algunos casos, haber obtenido su contenido desencriptado (Railway).
Token spraying: Huntress detectó que tokens de sesión robados de Microsoft 365 (M365), que mantienen la sesión del usuario iniciada, se reutilizaron en 79 organizaciones entre el 14 de julio y el 22 de septiembre de 2026 (Huntress).

Brecha de seguridad de Northflank: Toda variable de entorno debe darse por desencriptada

Qué ocurrió: Northflank es una plataforma en la nube en la que los equipos ejecutan aplicaciones y bases de datos. El 30 de octubre de 2026 abrió un incidente de seguridad en su página de estado. Los momentos clave, en UTC:

11:43: llegó una alerta de amenaza de Wiz.
13:40: Northflank pidió a los clientes que rotaran de inmediato sus variables de entorno. Rotar un secreto significa sustituirlo por uno nuevo y anular el anterior.
13:58: como medida de precaución, pidió a los clientes que dieran por desencriptadas todas las variables de entorno y que desactivaran y rotaran todas las claves.
Más tarde, el 30 de octubre: añadió que los usuarios habían informado del uso no autorizado de claves de API de IA proporcionadas a la plataforma.
01:04 del 31 de octubre: activó los registros de auditoría para todos los clientes, incluidos los usuarios gratuitos. Los registros de auditoría documentan quién hizo qué en una cuenta.
30 y 31 de octubre: activó por fases la rotación de secretos para bases de datos y otros complementos.

La página no indica cuántos clientes se vieron afectados.

En una actualización del 2 de noviembre, Northflank afirmó lo siguiente:

Creía que el vector de ataque se había contenido en menos de una hora desde la primera alerta
No veía indicios, en ese momento, de que se hubiera accedido a las cargas de trabajo ni a sus datos
Las pruebas apuntaban a que el ataque se centró en los secretos guardados en su plano de control, la parte de la plataforma que gestiona los proyectos de los clientes
Auditores forenses independientes seguían analizando el ataque
Los clientes debían seguir rotando todos los secretos, y se publicaría un análisis de la causa raíz una vez confirmados los hallazgos

Seguía sin indicar cuántos clientes se vieron afectados.

Por qué es importante: Wiz contabilizó al menos nueve plataformas para desarrolladores de IA que comunicaron incidentes entre el 6 y el 30 de octubre: Fireworks AI, Andromeda, Zeabur, Lightning AI, OpenCode, Railway, Warp, CommandCode y Northflank. Wiz actualizó después su publicación el 2 y el 3 de noviembre para añadir los incidentes comunicados en Brev, Trigger.dev y Chainstack.

Según Wiz, los informes públicos apuntaban de forma coherente a intentos dirigidos de obtener variables de entorno almacenadas, en especial claves que dan acceso a servicios de IA. No encontró ninguna vulnerabilidad única ni dependencia compartida que vinculara los incidentes. Ese patrón no demuestra que haya un atacante común ni una única campaña.

Wiz también resumió las primeras explicaciones:

Acceso a credenciales en Fireworks, Zeabur y Lightning
Posible escalada de privilegios en los sistemas de compilación de Railway
Un problema de un proveedor en Warp
Acceso a través de un sistema antiguo en OpenCode

Varias de ellas eran preliminares y algunas causas raíz seguían sin conocerse.

Wiz también describió lo que puede valer una clave robada. Detectó la primera actividad no autorizada en cada una de dos claves empresariales menos de 30 minutos después del acceso a credenciales comunicado en el lado del proveedor. En uno de los casos, el actor realizó unas 800 000 llamadas a Amazon Bedrock, el servicio de Amazon para ejecutar modelos de IA, en 30 horas, y alrededor del 90 % tuvieron éxito.

Wiz estimó que, entre los dos casos, probablemente se generó un consumo de más de 100 000 dólares a precios de lista, es decir, según la lista de precios pública. Se trata de una estimación, no de una factura confirmada.

La conclusión defensiva: las indicaciones de Northflank constan de tres partes:

Revocar, es decir, anular, las credenciales existentes ante la empresa que las emitió. Crear credenciales de sustitución y actualizar los secretos y las cargas de trabajo afectados en Northflank.
Revisar los registros de uso y facturación del proveedor de IA en busca de actividad que no reconozca.
Desactivar el acceso público a los complementos (add-ons), los servicios adicionales como las bases de datos, donde esté activado.

Recomendación de Passwork: si el proveedor lo permite, asigne a cada plataforma su propia clave, limitada a los permisos que esa plataforma necesita. Configure alertas de uso y, si se ofrece, un límite estricto, es decir, un tope que detiene las solicitudes al alcanzar un gasto determinado.

Tener claves separadas facilita su anulación. Los controles de gasto varían según el proveedor y puede que no detengan todos los excesos, así que compruebe cómo se comporta el suyo.

Fuentes: Página de estado de Northflank; Wiz

Incidente de seguridad de Railway: Renovar cada variable de entorno, credenciales de registro incluidas

Qué ocurrió: Railway es otra plataforma para ejecutar aplicaciones. El 21 de octubre de 2026 indicó que había detectado actividad inusual en los sistemas que almacenan las variables de entorno de los clientes. Un tercero no autorizado podría haber accedido a las variables encriptadas y, en algunos casos, haber obtenido su contenido desencriptado.

Railway dijo en un primer momento que el impacto podría limitarse a un subconjunto de usuarios. Su informe preliminar del 22 de octubre añadía lo siguiente:

Como máximo, el 1,85 % de los espacios de trabajo, unos 100 000, tenían alguna variable de entorno potencialmente comprometida.
Railway no podía determinar qué variables concretas se habían desencriptado.
Las implementaciones existentes, es decir, las versiones de las aplicaciones que ya estaban en ejecución, siguieron en línea. Las nuevas compilaciones e implementaciones quedaron en pausa.

Railway afirmó que creía que el incidente formaba parte de «una serie de ataques dirigidos recientemente contra empresas de plataformas» con el objetivo de comprometer a proveedores de inferencia de IA, es decir, empresas que ejecutan modelos de IA para sus clientes. Indicó que había avisado a esos proveedores de origen para que revocaran las claves de forma preventiva.

Por qué es importante: la Cloud Security Alliance, un grupo de investigación del sector, señaló el 23 de octubre que ninguna empresa había vinculado públicamente los incidentes a un único atacante. También indicó que la idea de una campaña procedía únicamente de Railway. Según esa evaluación, no estaba demostrado que se tratara de una sola campaña.

Por su parte, Wiz no encontró ninguna vulnerabilidad ni dependencia compartida entre los incidentes. El riesgo es el mismo en cualquier caso: sus secretos se encuentran en una plataforma de la que usted depende, y es posible que otra persona los haya leído.

La conclusión defensiva: Railway recomienda renovar todas las variables de entorno, es decir, sustituir cada una de ellas, incluidas las claves de API y las credenciales de registros privados almacenadas en Railway. Una credencial de registro privado son los datos de acceso que utiliza una aplicación para descargar sus imágenes de contenedor desde un almacén privado. Railway también recomienda revisar los registros de esos servicios en busca de actividad inusual.

Recomendación de Passwork: mantenga una lista de qué claves de proveedores se encuentran en cada plataforma, de modo que la rotación sea una lista de verificación y no una búsqueda.

Fuentes: Comunicado de Railway; Informe preliminar de Railway; Cloud Security Alliance

Robo de tokens de Microsoft 365: Huntress detectó tokens reutilizados en 79 organizaciones

Qué ocurrió: Huntress, una empresa de seguridad, informó el 22 de octubre de 2026 de una campaña que se desarrolló entre el 14 de julio y el 22 de septiembre de 2026. Indicó que respondió a incidentes relacionados en 79 organizaciones. Contabilizó 497 inicios de sesión correctos en Microsoft 365 y más de 200 000 intentos de inicio de sesión fallidos.

Conviene aclarar tres términos:

Token de sesión: datos emitidos tras iniciar sesión que permiten que el dispositivo mantenga la sesión iniciada u obtenga acceso sin repetir todos los pasos de inicio de sesión. Cuánto tiempo funciona depende del token, de la aplicación, de la caducidad, de la revocación y de los controles de directivas.
Token spraying: nombre que da Huntress a la reutilización de tokens de sesión robados en muchas cuentas, del mismo modo que el password spraying prueba contraseñas adivinadas en muchas cuentas.
MFA: abreviatura de autenticación multifactor, un inicio de sesión que comprueba al menos dos tipos distintos de prueba, como una contraseña más un código o una aprobación desde una aplicación de autenticación.

Destacan dos hallazgos:

En 19 organizaciones, los métodos de MFA existentes de la víctima se eliminaron y se registró un método nuevo en menos de tres horas desde el primer inicio de sesión desde una dirección de la campaña
En un caso detallado, se activó un nuevo autenticador con la etiqueta «iPhone 13» unos 38 minutos después del secuestro de la sesión, según las marcas de tiempo de la cronología de Huntress

Por qué es importante: Huntress describió tres orígenes de los tokens:

Un relé adversary-in-the-middle, una página de inicio de sesión falsa que transmite a Microsoft el inicio de sesión real de la víctima
Phishing de código de dispositivo, que engaña al usuario para que apruebe un inicio de sesión iniciado por el atacante
Ingeniería social durante un inicio de sesión real

En los casos de relé, los atacantes conservaron un token emitido después de que la víctima completara la MFA y lo reutilizaron sin que se volviera a solicitar la MFA.

Un token reutilizado puede aprovechar una sesión iniciada, pero cuánto dura el acceso depende del token, de la aplicación, de la caducidad o la revocación y de los controles de directivas o de riesgo. Un token robado acaba caducando o siendo revocado. Un método de MFA añadido por el atacante permanece en la cuenta hasta que alguien lo elimina.

El titular de Help Net Security afirmaba que las cuentas se comprometieron sin necesidad de contraseñas. Eso describe el uso que el atacante hizo de la sesión robada, no todos los pasos de cómo la obtuvo.

La conclusión defensiva: ante una sospecha de compromiso, Huntress recomienda tres pasos:

Revocar las sesiones del usuario.
Restablecer la contraseña.
Eliminar los dispositivos y métodos de MFA que haya añadido el atacante. Restablecer la contraseña por sí solo no los elimina.

Microsoft también recomienda deshabilitar o bloquear la cuenta cuando sea posible y comprobar otras vías que usan los atacantes para mantener el acceso: contraseñas de aplicación, concesiones de consentimiento, roles y reglas de reenvío de correo. Es posible que la revocación de sesiones no cierre todas las sesiones de aplicación de inmediato, ya que los tokens de acceso ya emitidos pueden seguir funcionando hasta que caduquen.

Para la prevención, Huntress recomienda las directivas de acceso condicional, las reglas de Microsoft que determinan quién puede iniciar sesión y en qué condiciones. Deben exigir la MFA o bloquear el acceso para todos los usuarios, aplicaciones en la nube y tipos de aplicaciones cliente. Aplíquelas con cuidado:

Excluya las cuentas de emergencia «break-glass», las cuentas de administrador reservadas para casos de bloqueo, de las directivas que bloquean o restringen el inicio de sesión. Las indicaciones de Microsoft establecen que se protejan y supervisen por separado.
Puede que las cuentas de sincronización necesiten una exclusión explícita de la directiva de usuarios. Las entidades de servicio, es decir, las identidades de aplicaciones y automatizaciones, no están cubiertas por el acceso condicional orientado a usuarios, así que gestiónelas con controles de identidad de carga de trabajo independientes.
Bloquee la autenticación heredada, los métodos de inicio de sesión antiguos que no admiten MFA, con la condición específica para clientes heredados.
Pruebe el impacto en modo de solo informe antes de aplicarlas.

Fuentes: Huntress; Help Net Security; Infosecurity Magazine; Microsoft: revocar el acceso de usuarios; Microsoft: cuenta de correo electrónico comprometida; Microsoft: cuentas de acceso de emergencia; Microsoft: MFA para todos los usuarios; Microsoft: bloquear la autenticación heredada

Qué rotar tras la brecha de seguridad de Northflank

En estos incidentes, las credenciales y los tokens robados pueden aceptarse como válidos, de modo que las solicitudes no autorizadas pueden parecer actividad normal de una sesión iniciada. Eso no las hace invisibles: los registros de uso, los registros de inicio de sesión y los controles de riesgo pueden mostrar actividad inusual.

Comprobaciones que conviene hacer ya:

Elabore una lista de los secretos que guardan sus plataformas. Anote cada clave de API, contraseña de base de datos y token almacenados como variable de entorno en una plataforma de alojamiento o de CI, así como la empresa que emitió cada uno. La CI son las herramientas automatizadas que compilan e implementan el código.
Revoque primero en el origen y después actualice la plataforma. Siga el orden indicado por Northflank: revoque la credencial existente ante el proveedor que la emitió, cree una de sustitución y, después, actualice el secreto y las cargas de trabajo afectados en Northflank.
Limite lo que una clave robada puede hacer y gastar. Cuando sea posible, utilice una clave o un proyecto distinto para cada plataforma, limitado a los permisos que necesita, con alertas de uso y un límite estricto. Puede que las alertas no detengan las solicitudes, y la aplicación de los límites puede sufrir retrasos. Revise los registros de uso en busca de llamadas que no pueda explicar.
Cierre las sesiones y, después, revise los métodos de inicio de sesión. En cualquier cuenta de Microsoft 365 sospechosa, revoque las sesiones y restablezca la contraseña; después, elimine los dispositivos y autenticadores que no reconozca. Compruebe también las contraseñas de aplicación, las concesiones de consentimiento, los roles y las reglas de reenvío.
Revise la cobertura del acceso condicional. Exija la MFA para los inicios de sesión de usuarios normales en todos los usuarios y recursos. Bloquee la autenticación heredada tras probarlo en modo de solo informe. Documente las exclusiones de las cuentas de emergencia y de las posibles cuentas de sincronización, y protéjalas y supervíselas. Utilice un acceso condicional para identidades de carga de trabajo independiente para las entidades de servicio, en lugar de considerar una exclusión como cobertura.
Active los registros que necesitaría. Habilite los registros de auditoría que ofrecen sus plataformas y confirme qué abarcan y durante cuánto tiempo conservan los datos. Northflank activó los registros de auditoría para todos los clientes, incluidos los usuarios gratuitos, solo el 31 de octubre, después del incidente.

La documentación de Passwork describe el almacenamiento basado en bóvedas para claves de API y tokens, con acceso basado en roles para que cada persona vea solo lo que su rol permite. Su REST API y su CLI permiten que los scripts y los pipelines de CI lean secretos desde la bóveda. Pruebe Passwork gratis y compruebe cómo se adapta a su entorno.