alta research global

Nueve plataformas PaaS filtran llaves de IA en Black October

Wiz Research documentó cómo llaves de Amazon Bedrock robadas en Northflank, Railway y Zeabur terminaron en mercados de reventa de acceso a modelos frontera, con más de 2,5 millones de invocaciones no autorizadas entre dos casos.

·14 min de lectura ·Equipo Vantis
En 30 segundos
  • Nueve plataformas de desarrollo de IA (PaaS, inferencia, herramientas de código) reportaron incidentes de seguridad en octubre de 2026, racha que Wiz Research bautizó 'Black October'; la más reciente, Northflank, pidió a sus clientes asumir que todas sus variables de entorno fueron descifradas.
  • En dos casos documentados por Wiz sobre llaves de Amazon Bedrock robadas, el uso no autorizado llegó a 800.000 y 1,7 millones de invocaciones de modelo, con un costo estimado superior a US$100.000 a precio de lista en conjunto; Wiz identificó infraestructura de dos operaciones de reventa con acceso a esas llaves, sin poder confirmar que ellas mismas ejecutaron el robo.
  • El patrón relevante para la defensa: la validación de la llave robada ocurrió en minutos, pero el abuso masivo tardó días — esa ventana es la oportunidad real de contención antes de que el gasto se dispare.

Qué pasó

La cadena de incidentes

Entre el 6 y el 30 de octubre de 2026, nueve plataformas usadas para desplegar o construir aplicaciones con IA —entre ellas Fireworks AI, Zeabur, Railway, Lightning AI, Warp y, al cierre del mes, Northflank— reportaron compromisos de seguridad. Wiz Research agrupó estos casos bajo el nombre 'Black October' y señaló que, aunque no hay una vulnerabilidad ni dependencia común que los conecte a todos, el objetivo se repite: las variables de entorno donde los clientes guardan sus credenciales, en particular las llaves de acceso a modelos de IA.

Northflank, un proveedor de plataforma-como-servicio (PaaS) para desplegar contenedores y bases de datos gestionadas, fue alertado por Wiz el 30 de octubre a las 11:43 UTC. Según BleepingComputer, Northflank empezó a revisar la alerta un minuto después y desplegó parches de política de red en las horas siguientes. A las 13:58 UTC, la página de estado de la empresa pasó el incidente a 'Identificado' con una instrucción directa: asumir que todas las variables de entorno fueron descifradas y rotar o deshabilitar todas las llaves. Esa misma noche, clientes reportaron uso no autorizado de sus llaves de proveedores de IA. Northflank afirma —y esto es dato de la empresa, no verificación independiente— que la intrusión quedó contenida en aproximadamente una hora, que no afectó a clientes en planos de control dedicados o 'forward-deployed', y que parchó la vulnerabilidad explotada en toda su flota, incluidos clústeres Bring Your Own Cloud (BYOC). Al momento de esta nota, Northflank no ha publicado un análisis de causa raíz, ni el número de clientes afectados, ni si se abusó de credenciales distintas a las de IA.

Los dos antecedentes con más detalle público

Railway (incidente del 20-22 de octubre) describió escalamiento de privilegios en su infraestructura de build, obtención de variables de entorno cifradas y descifrado de un subconjunto usando credenciales comprometidas dentro de esa misma infraestructura. Railway estimó que hasta un 1,85% de sus espacios de trabajo (unos 100.000) pudo tener variables comprometidas, y pidió a Anthropic, OpenAI, GitHub y Stripe reiniciar llaves de más de 100.000 usuarios por precaución.

Zeabur (reportado el 19 de octubre) describió un compromiso más profundo: un atacante usó credenciales internas filtradas que estaban guardadas en texto plano —incluyendo tokens de administrador de clúster sin fecha de expiración— y leyó cerca de 3,2 millones de registros de variables de entorno de servicios, además de datos de cuenta de 321.810 usuarios. Zeabur observó que el atacante buscaba sobre todo llaves de API directamente utilizables, en especial de servicios de IA, y llegó a intentar invocar Amazon Bedrock con las propias llaves de AWS de Zeabur. De 607 instancias de n8n revisadas, 602 guardaban su llave de cifrado como variable de entorno, por lo que las credenciales de terceros dentro de esos flujos de automatización quedaron igualmente expuestas.

Lo que pasó después del robo

Wiz documentó, sin identificar al proveedor de origen, dos casos de llaves empresariales de Amazon Bedrock robadas. En ambos, la primera invocación de prueba ocurrió dentro de los 30 minutos siguientes a la exposición reportada por el proveedor, desde direcciones IP residenciales. Luego siguió un período de 'goteo' de bajo volumen (consistente con un trabajo de verificación de llave), enumeración de cuotas y catálogo de modelos con scripts boto3, y finalmente una ráfaga de monetización: ~800.000 llamadas en ~30 horas en un caso (90% exitosas), y ~1,7 millones en ~13 horas en el otro (más de un millón exitosas). Wiz calcula que, sumados, esto pudo superar los US$100.000 de consumo a precio de lista.

Wiz identificó infraestructura de dos operaciones de reventa de acceso a modelos frontera —una asociada a la IP 23.106.46.239 ('momo') y otra a 38.246.114.118 ('Xingjiabi')— con acceso a ambas llaves robadas, incluyendo enumeración de perfiles de inferencia y un intento de modificar la configuración de retención de datos de una de las cuentas víctimas. Esto es una correlación de infraestructura, no una atribución confirmada: Wiz es explícito en que no pudo vincular de forma definitiva a estos revendedores con el robo original ni con las ráfagas de abuso. Lo que sí queda documentado es que llaves robadas en incidentes de plataforma llegan, en cuestión de días, a mercados secundarios que las revenden mientras aún están siendo explotadas.

Por qué importa acá

Esta nota es un análisis de Vantis a partir de una publicación de Cloud Security Alliance (CSA Labs), que a su vez sintetiza principalmente investigación de Wiz Research junto con los reportes propios de Northflank, Railway y Zeabur. CSA Labs opera con un pipeline de análisis automatizado y no es fuente primaria de los hechos: cada dato de este artículo proviene de los reportes originales citados en la fuente CSA, y los listamos en referencias.

No tenemos evidencia de una víctima chilena confirmada en Black October, y no la vamos a inventar. Pero el ángulo regional es real por tres vías:

El punto estructural, más allá de Chile, es el que CSA subraya: una llave de proveedor de IA guardada como variable de entorno en una PaaS comparte el destino de seguridad del plano de control, el sistema de build y el gestor de secretos de esa plataforma. Eso convierte a cada PaaS de terceros en parte de la superficie de ataque de cualquier organización que la use, sin importar su tamaño o ubicación.

Anatomía del ataque

Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.

Qué hacer, fase por fase

Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.

GV GobernarQuien decide, que se reporta y a quien

El problema de fondo es de gobierno de identidades no humanas: llaves de API de larga duración, guardadas por un tercero, sin dueño claro ni monitoreo propio. Antes de octubre, varias de estas plataformas ni siquiera tenían auditoría habilitada en todos los planes. Quien gobierna el gasto en IA de la organización (TI, FinOps, el equipo de plataforma) necesita saber hoy, con nombre y apellido, en qué PaaS vive cada llave de proveedor de IA y quién puede rotarla sin pedir permiso.

  • Designar un dueño único por cada llave de proveedor de IA en uso, con autoridad para rotarla sin escalamiento.
  • Agregar a la revisión de proveedores (vendor risk) una pregunta explícita: ¿el proveedor PaaS ofrece auditoría en todos los planes y un proceso de rotación masiva ante incidente?
  • Si la organización es un OIV o entidad regida por la Ley 21.663, documentar la revisión de exposición a las nueve plataformas nombradas por Wiz, aunque no derive en un reporte formal a ANCI.
ID IdentificarSi esto me toca, por donde me toca

Antes de poder proteger algo hay que saber dónde está. El inventario relevante no es 'qué llaves de IA tenemos', sino 'en qué plataforma de terceros vive cada una, y qué puede hacer esa plataforma con ella sin que nosotros lo veamos'.

  • Levantar inventario de toda llave de proveedor de IA (OpenAI, Anthropic, Amazon Bedrock, Google Vertex, etc.) guardada como variable de entorno en Northflank, Railway, Zeabur, Fireworks AI, Lightning AI, Warp, OpenCode o CommandCode.
  • Revisar si alguna de esas instancias ejecuta n8u otro orquestador de flujos que a su vez guarde credenciales de terceros — el hallazgo de Zeabur sobre n8n se replica en cualquier plataforma de automatización desplegada sobre una PaaS comprometida.
  • Confirmar el nivel de plan contratado en cada PaaS y si incluye auditoría/logging; si no lo incluye, tratarlo como punto ciego hasta que se habilite o se compense con monitoreo externo.
PR ProtegerComo evito que ocurra

La protección efectiva no es una sola medida sino reducir cuánto daño puede hacer una sola llave robada, en cada capa: cuánto alcanza, cuánto puede gastar, y cuánto dura viva.

Controles priorizados

P1: esta semana · P2: este mes · P3: este trimestre

PrioControlEsfuerzoMapeo
P1 Rotar y revocar de inmediato toda llave de proveedor de IA guardada en Northflank, Railway, Zeabur o cualquier plataforma listada por Wiz; revocar primero donde el abuso esté confirmado. bajo MITRE ATT&CK M1026 CIS Controls v8 6.2 ISO 27001 A.5.17
P1 Emitir llaves separadas y de mínimo privilegio por servicio y entorno, para que la exposición de una plataforma no comprometa llaves usadas en otras. medio MITRE ATT&CK M1026 CIS Controls v8 6.8 ISO 27001 A.8.2
P1 Aplicar límites duros de gasto (no solo alertas) en cada cuenta de proveedor de IA, y restringir las llaves a perfiles de inferencia regionales en vez de globales donde el proveedor lo permita. bajo MITRE ATT&CK M1047 CIS Controls v8 8.2 ISO 27001 A.8.16
P2 Habilitar auditoría/logging en el nivel de plan contratado de cada PaaS en uso; si el proveedor no lo ofrece en el plan actual, evaluar upgrade o compensar con monitoreo externo del tráfico saliente hacia APIs de IA. bajo MITRE ATT&CK M1047 CIS Controls v8 8.5 ISO 27001 A.8.16
P2 Migrar de llaves estáticas en variables de entorno a credenciales de corta duración o federación de identidad de carga de trabajo, o a un gateway de IA bajo control propio que exponga solo tokens de gateway acotados a la PaaS. alto MITRE ATT&CK M1026 CIS Controls v8 5.4 ISO 27001 A.8.5

El mapeo a CIS Controls v8 e ISO 27001 Anexo A (edición 2022) es orientativo para justificar presupuesto ante gerencia; no reemplaza una evaluación de aplicabilidad hecha por el equipo de cumplimiento de cada organización.

DE DetectarComo me doy cuenta de que ya ocurrio

El patrón que importa detectar no es la intrusión a la PaaS —eso lo controla el proveedor—, sino el abuso posterior de la llave una vez que sale de ahí. Wiz documentó una secuencia repetible: validación en minutos, goteo de verificación, enumeración de cuota y catálogo, y recién después la ráfaga de monetización. La enumeración de cuotas es la señal más temprana y específica disponible.

  • Instrumentar alertas sobre llamadas a GetServiceQuota, ListServiceQuotas, ListFoundationModels y ListInferenceProfiles hechas por un principal o IP no vistos antes.
  • Alertar sobre spend de modelos de IA que se desvíe de una línea base móvil, no solo sobre presupuestos de solo-alerta.
  • Cruzar logs de invocación contra las direcciones IP publicadas por Wiz, entendiendo que confirman abuso de una llave ya robada, no el vector de intrusión original.

Qué necesitas tener logueado

  • AWS CloudTrail, especialmente eventos con eventSource bedrock.amazonaws.com y servicequotas.amazonaws.com
  • Logs de auditoría de la plataforma PaaS (Northflank, Railway, Zeabur u otra), cuando el plan contratado los incluya
  • Logs de proxy/CASB corporativo hacia endpoints de API de proveedores de IA, para detectar egress desde rangos no autorizados

Indicadores de compromiso

OjoLos indicadores están defanged (hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.
TipoIndicadorConfianzaNota
ip 23[.]106[.]46[.]239 media Wiz Research, vía CSA Labs
ip 38[.]246[.]114[.]118 media Wiz Research, vía CSA Labs
ip 104[.]243[.]32[.]50 baja Wiz Research, vía CSA Labs
ip 31[.]57[.]201[.]201 baja Wiz Research, vía CSA Labs
blocklistIndicadores en crudo
23.106.46.239
38.246.114.118
104.243.32.50
31.57.201.201

Reglas y consultas de detección

sigmaEnumeración de cuotas y catálogo de modelos Bedrock previa a abuso de llave robada
title: Enumeración de cuotas y catálogo de modelos AWS Bedrock por principal no habitual
id: a1f3c9e2-5b47-4ac1-9d6e-8f2b17a4c930
status: experimental
description: Detecta llamadas de reconocimiento (catálogo de modelos, perfiles de inferencia, cuotas de servicio) que, según Wiz Research, preceden al abuso masivo de llaves de Amazon Bedrock robadas en incidentes de plataforma PaaS.
references:
  - https://labs.cloudsecurityalliance.org/research/csa-research-note-northflank-ai-key-resale-pipeline-20261102/
logsource:
  product: aws
  service: cloudtrail
detection:
  selection_bedrock:
    eventSource: 'bedrock.amazonaws.com'
    eventName:
      - 'GetModelInvocationLoggingConfiguration'
      - 'ListFoundationModels'
      - 'ListInferenceProfiles'
  selection_quotas:
    eventSource: 'servicequotas.amazonaws.com'
    eventName:
      - 'GetServiceQuota'
      - 'ListServiceQuotas'
  condition: selection_bedrock or selection_quotas
fields:
  - userIdentity.arn
  - sourceIPAddress
  - eventName
falsepositives:
  - Personal de ingeniería o FinOps revisando cuotas de forma legítima antes de un despliegue nuevo
  - Scripts de infraestructura como código que listan modelos disponibles al aprovisionar un entorno
level: medium
tags:
  - attack.discovery
  - attack.t1526
Requiere: Tabla/índice de AWS CloudTrail con eventos de control plane habilitados para bedrock.amazonaws.com y servicequotas.amazonaws.com
splunkReconocimiento de cuotas Bedrock + ráfaga de invocación (SPL)
index=aws_cloudtrail sourcetype="aws:cloudtrail" (eventSource="bedrock.amazonaws.com" OR eventSource="servicequotas.amazonaws.com")
eventName IN ("GetModelInvocationLoggingConfiguration","ListFoundationModels","ListInferenceProfiles","GetServiceQuota","ListServiceQuotas")
| stats count earliest(_time) as primera_vez by userIdentity.arn, sourceIPAddress, eventName

``` segunda búsqueda: ráfaga de invocación posterior ```
index=aws_cloudtrail sourcetype="aws:cloudtrail" eventSource="bedrock.amazonaws.com" eventName IN ("InvokeModel","Converse")
| bin _time span=1h
| stats count as invocaciones by userIdentity.arn, _time
| where invocaciones > 500
Requiere: Índice con eventos de AWS CloudTrail ingeridos vía Splunk Add-on for AWS (sourcetype aws:cloudtrail)
sentinel-kqlEnumeración de cuotas Bedrock y spike de invocaciones (KQL)
// Enumeración de cuotas y catálogo de modelos
AWSCloudTrail
| where EventSource in ("bedrock.amazonaws.com","servicequotas.amazonaws.com")
| where EventName in ("GetModelInvocationLoggingConfiguration","ListFoundationModels","ListInferenceProfiles","GetServiceQuota","ListServiceQuotas")
| summarize ConteoLlamadas=count() by UserIdentityArn, SourceIpAddress, EventName, bin(TimeGenerated, 1h)

// Spike de invocaciones posterior (umbral referencial, ajustar a línea base propia)
AWSCloudTrail
| where EventSource == "bedrock.amazonaws.com" and EventName in ("InvokeModel","Converse")
| summarize Invocaciones=count() by UserIdentityArn, bin(TimeGenerated, 1h)
| where Invocaciones > 500
Requiere: Tabla AWSCloudTrail disponible vía el conector de AWS de Microsoft Sentinel (ingesta desde S3/CloudTrail)
Falsos positivos esperables

Equipos de FinOps o ingeniería que revisan cuotas y catálogo de modelos antes de un despliegue legítimo generan el mismo patrón de enumeración que un atacante en etapa de reconocimiento. Lanzamientos de producto o campañas de marketing pueden producir picos de invocación legítimos similares a los de monetización fraudulenta. Ambas reglas deben calibrarse contra una línea base propia de uso antes de pasar a modo de bloqueo o alerta de alta prioridad; se entregan en estado experimental.

RS ResponderContencion y erradicacion

Si tu organización tuvo cargas de trabajo en alguna de las nueve plataformas durante octubre de 2026, el punto de partida es tratar cada secreto en esa plataforma como potencialmente expuesto, empezando por las llaves de IA y de nube.

  • Rotar toda llave de proveedor de IA y credencial de nube guardada en la plataforma afectada; para llaves con abuso confirmado, revocar primero y recién después emitir el reemplazo. Para las no confirmadas, emitir, desplegar y revocar en secuencia rápida para evitar interrupciones.
  • Deshabilitar el acceso de red público a add-ons de bases de datos gestionadas donde esté habilitado por defecto.
  • Revisar uso y facturación desde el 1 de octubre de 2026 para cada llave afectada; en AWS, revisar CloudTrail para InvokeModel, Converse, actividad de Service Quotas y PutAccountDataRetention de principales o direcciones inesperadas.
  • Reportar todo abuso confirmado tanto a la plataforma como al proveedor de IA — algunos proveedores han ajustado cargos ante abuso demostrado por robo de credenciales.
RC RecuperarVolver a operar y no repetirlo

La vuelta a operación normal no debería devolver a la organización al mismo diseño que permitió el problema: llaves estáticas y de larga duración guardadas en texto descifrable por un tercero.

  • Reconciliar la facturación de IA de los 90 días posteriores al incidente contra el uso esperado, como mecanismo de detección incluso si los logs quedaron incompletos.
  • Evaluar migrar de llaves estáticas a credenciales de corta duración o federación de identidad de carga de trabajo donde la plataforma lo soporte.
  • Actualizar el playbook de respuesta para permitir revocación el mismo día sin aprobación de cambio, dado que la ventana entre validación y abuso masivo fue de días, no de semanas.

Llévatelo

Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.

La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.

Fuentes

¿Esto te aplica y no sabes por dónde partir?

Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.

Agendar diagnóstico

Relacionado