Los equipos de seguridad en la nube que investigan accesos robados a modelos deben determinar quién podía habilitar nuevos servicios de IA y crear identidades adicionales, y después rastrear qué hicieron esas identidades. Rotar la primera clave expuesta puede dejar sin resolver otras rutas de acceso y servicios activados recientemente.
Esa es la lección operativa que Maetra extrae del informe sobre LLMJacking de Mandiant y Google Threat Intelligence Group del 2 de noviembre. Mandiant describe incidentes en los que atacantes secuestraron recursos empresariales de modelos. Informa de cargos fraudulentos por recursos superiores a 100.000 dólares en un solo día en incidentes individuales y de cargos acumulados que alcanzaron 1 millón de dólares en algunas organizaciones. Se trata de observaciones atribuidas procedentes de casos investigados, no de una pérdida media, una tasa de todo el sector ni resultados financieros auditados de forma independiente.
Investigue la capacidad de activar servicios
El informe afirma que los tokens de identidad en la nube expuestos o robados fueron la vía de acceso inicial dominante en múltiples investigaciones. También describe casos en los que los servicios de LLM no estaban habilitados cuando comenzó el compromiso. Los atacantes usaron su acceso para habilitar servicios y consumir recursos. La implicación práctica es que un inventario de los modelos usados en este momento no describe todos los servicios de modelos que una identidad podría activar.
Comience la investigación con el proyecto, la suscripción o la cuenta en la nube afectados y con los permisos que tenía la identidad en el momento relevante. Compare los servicios que estaban habilitados antes de la presunta intrusión con los cambios posteriores. Identifique el actor, la marca temporal y la configuración de cada activación que no tenga explicación.
Esta revisión también debe incluir las identidades habituales de automatización. Una cuenta de servicio de despliegue puede necesitar aprovisionar infraestructura aprobada y, al mismo tiempo, no tener ninguna razón operativa para habilitar un proveedor adicional de modelos. Determine si esos poderes pueden separarse en el entorno real. No dé por hecho que un nombre de credencial familiar vuelve legítimo su uso.
Construya un linaje de acceso, no solo una lista de claves
Maetra recomienda registrar la relación entre la identidad inicial y cualquier acceso creado durante el incidente. Reúna nuevas cuentas, credenciales, concesiones, sesiones y servicios, junto con sus propietarios y su estado actual. Cuando los registros estén incompletos, marque la relación como incierta en lugar de unir eventos únicamente porque sus marcas temporales estén próximas.
Un registro de investigación útil responde a cuatro preguntas:
- ¿Qué identidad obtuvo primero el acceso y qué evidencia respalda esa conclusión?
- ¿Qué nueva autoridad o credencial creó u obtuvo?
- ¿A qué recurso llegó esa autoridad y qué solicitudes fueron aceptadas?
- ¿Qué evidencia demuestra que la ruta de acceso ha sido cerrada?
La última pregunta cambia la remediación. Revocar una credencial principal puede tener efectos distintos sobre sesiones derivadas o cuentas creadas de forma independiente. Haga que el propietario de la identidad correspondiente verifique esos efectos. Preserve la evidencia necesaria para la investigación antes de eliminar artefactos maliciosos confirmados, siguiendo los procedimientos del equipo de incidentes.
Correlacione sondeos pequeños con cambios de configuración
Los grandes picos de uso son señales útiles, pero esperar a una factura elevada hace que el impacto financiero forme parte de la detección. El informe describe tanto la validación de bajo volumen de claves robadas como abusos de alto volumen. Eso respalda la revisión de patrones de acceso junto con cambios de configuración y eventos de identidad.
Para una revisión acotada, seleccione un servicio de modelos y compare un período de actividad normal con la ventana de exposición sospechada. Busque el primer uso por parte de una identidad inesperada, una activación de servicio inusual, una credencial nueva o un cambio en el registro. Investigue combinaciones de señales en contexto; una sola solicitud desconocida no prueba por sí sola un compromiso.
Asigne a un responsable de seguridad en la nube y a un responsable de costos a la misma línea temporal. La telemetría de seguridad puede establecer qué solicitudes tuvieron éxito, mientras que los registros de facturación describen el consumo atribuido en un intervalo de reporte distinto. Mantenga visibles esas diferencias al estimar el impacto. Evite presentar una estimación preliminar de uso como si fuera una factura cerrada o una pérdida confirmada.
Verifique la contención con el propietario del recurso
El informe ofrece orientación específica por proveedor para detección y remediación. El equipo de respuesta debe aplicar los controles pertinentes del proveedor y verificar su comportamiento en su propio entorno. Las notificaciones de presupuesto, las cuotas de uso, las restricciones de credenciales y los permisos para habilitar servicios tienen finalidades distintas y semánticas de aplicación diferentes.
Por ejemplo, una notificación de presupuesto puede informar a un propietario mientras las solicitudes continúan. Una cuota configurada puede limitar un recurso sin abarcar todas las regiones, todos los modelos o todas las identidades. Determine el alcance real antes de tratar cualquiera de esas medidas como un límite de contención. Estas son preguntas de revisión, no afirmaciones de que todos los proveedores se comporten del mismo modo.
Después de la remediación, verifique el estado previsto: las identidades no autorizadas están deshabilitadas, las concesiones sin explicación se han eliminado, los servicios innecesarios están restringidos y los registros requeridos siguen disponibles. Pruebe también el acceso de las aplicaciones aprobadas, para que la recuperación no rompa en silencio el flujo de trabajo legítimo.
Mantenga precisas las afirmaciones de las fuentes y el papel del producto
The Register cubrió el informe de forma independiente, incluida una declaración de la dirección de inteligencia de amenazas de Google. Eso corrobora la divulgación y la atribución. No reproduce de forma independiente las investigaciones de incidentes ni verifica el costo de cada víctima.
Un inventario de agentes respaldado por evidencias ofrece un punto de partida útil para identificar las aplicaciones implicadas y sus responsables. Incluya también en la investigación las identidades y los servicios ajenos a ese inventario.
Maetra Secure analiza prompts, mensajes, llamadas a herramientas y salidas en busca de amenazas en tiempo de ejecución, incluida la exposición de datos. Esa inspección puede aportar evidencia sobre la actividad de la aplicación cubierta. La gestión de identidades y accesos en la nube, la revocación de credenciales, las restricciones de servicios y los controles financieros siguen requiriendo aplicación por parte de sus respectivos sistemas. Este artículo no afirma que Maetra haya prevenido o detectado los incidentes descritos.
Use la documentación de Maetra para identificar los eventos de aplicación relevantes para la línea temporal de un incidente y, después, conecte esos registros con la evidencia de identidad en la nube y de recursos. La revisión solo está completa cuando los propietarios responsables pueden explicar tanto el flujo de trabajo legítimo como la incertidumbre restante.