Varonis Threat Labs ha desarrollado NotC2, un marco de mando y control (C2) de prueba de concepto que opera totalmente sobre servicios nativos de AWS. Esta herramienta utiliza Amazon Bedrock para convertir lenguaje sencillo en inglés en comandos de nube. No se trata de un fallo de Bedrock, sino de un abuso de sus servicios, y solo es efectivo si el atacante ya posee credenciales de AWS.

Varonis Threat Labs ha creado NotC2, un marco de trabajo de comando y control (C2) de prueba de concepto. Funciona enteramente sobre servicios nativos de AWS y utiliza Amazon Bedrock para convertir inglés sencillo en comandos de nube.

Se trata de un abuso del servicio, no de un fallo en Bedrock, y solo funciona una vez que un atacante ya posee credenciales de AWS.

NotC2: marco de trabajo C2 impulsado por IA

El C2 clásico depende de servidores y protocolos personalizados que las herramientas de seguridad pueden detectar y bloquear. Los atacantes hace tiempo que se alejaron de ese modelo utilizando plataformas confiables como Telegram, Discord, Slack, Pastebin, GitHub Gists y Google Sheets. Pocas empresas pueden bloquear estos dominios sin perjudicar el trabajo diario.

El almacenamiento en la nube sigue la misma idea. Amazon S3, Google Drive, OneDrive y Azure Blob Storage pueden transportar comandos y datos robados. Recientemente se informó que los atacantes están ocultando el tráfico C2 a través de AWS, Google Cloud, Cloudflare, Microsoft y GitHub.

Gran parte de ese tráfico viaja a través del puerto 443, por lo que el bloqueo basado en la reputación pierde su valor.

NotC2 no surgió de la nada. El investigador Dhiraj Mishra creó XRayC2, que oculta comandos en anotaciones de traza de AWS X-Ray mientras los hosts infectados consultan la misma API de monitoreo que ya utiliza la aplicación. Informamos anteriormente sobre cómo los hackers convierten AWS X-Ray en un canal de comandos encubierto.

Rhino Security Labs también mostró balizas de Cobalt Strike que utilizan objetos S3 como canal. La baliza consulta un bucket en busca de objetos de tarea y escribe los resultados nuevamente como objetos de respuesta. Rhino señaló dos puntos débiles en ese diseño: la baliza necesita claves API y la consulta constante añade retraso.

Cada uno de estos métodos utilizaba un solo servicio de AWS. Varonis se preguntó qué pasaría si todo el bucle C2 se ejecutara dentro de AWS, incluida la habilidad que normalmente aporta un operador humano.

Según la investigación técnica publicada por Varonis Threat Labs, el nombre proviene de "notification" (notificación), por el servicio que envía los resultados de vuelta, más "C2". El bucle utiliza cuatro servicios de AWS, y cada uno tiene una tarea clara.

Amazon SQS es la entrada de comandos. El servidor externo del atacante deposita mensajes en una cola, y no hay una conexión constante que detectar. AWS Lambda es el motor.

Un mapeo de fuente de eventos ejecuta la función para cada mensaje nuevo, utilizando el rol de ejecución de la función. Cada ejecución dura como máximo 15 minutos y no deja un proceso permanente, aunque puede aparecer en los registros de la nube.

Amazon SNS transporta los resultados hacia fuera. La función publica la salida en un tema, y SNS la entrega al punto final HTTPS del atacante una vez que se confirma la suscripción. La función Lambda nunca contacta al atacante directamente.

Amazon Bedrock es el intérprete de IA. Lee una solicitud como "listar todas las instancias EC2 en ejecución con sus IPs" y construye la llamada a la API de AWS correspondiente.

Normalmente, un operador debe conocer la sintaxis exacta de la CLI, como un comando largo de aws ec2 describe-instances con filtros y consultas. Con NotC2, el atacante escribe un prompt corto que comienza con "ai:" y el modelo hace el resto.

Una única herramienta genérica, llamada execute_aws_operation, acepta un servicio, una operación y sus parámetros.

El modelo también puede adaptarse. Si una llamada a la API devuelve un error, el bucle lo retroalimenta y el modelo puede corregir la solicitud o sugerir un siguiente paso. El reconocimiento se convierte en un chat, con preguntas como "muéstrame a qué tengo acceso".

El modelo no puede otorgar nuevos permisos, pero hace que el acceso existente sea mucho más fácil de usar. Varonis demostró el listado de instancias EC2, tablas de DynamoDB, bases de datos y funciones Lambda. Con suficientes permisos, un atacante también podría eliminar buckets de S3 o instancias EC2.

Toda la cadena depende de los permisos de las credenciales robadas. Para desplegarlo, una identidad necesita sqs:CreateQueue, lambda:CreateFunction, lambda:CreateEventSourceMapping e iam:PassRole para un rol de Lambda existente. Si no existe un rol adecuado, el atacante también necesita derechos de rol y política de IAM.

En tiempo de ejecución, el rol de Lambda necesita derechos para leer y eliminar mensajes de la cola, gestionar y publicar en el tema de SNS, suscribir el punto final externo y llamar a bedrock:InvokeModel. También necesita derechos sobre los propios servicios objetivo. Los atacantes suelen buscar estas rutas con herramientas de código abierto como Pacu, un marco de pruebas de AWS de Rhino Security Labs.

Atacantes reales ya se están moviendo en esta dirección. Un caso reciente de LLMjacking mostró el uso de claves de nube robadas para generar facturas enormes de modelos. Otro informe mostró atacantes apuntando a puertas de enlace de IA vinculadas a Amazon Bedrock.

Las señales de red desaparecen en su mayoría. No hay dominios extraños, IPs desconocidas ni protocolos personalizados. Las pistas están en los propios registros de la nube de la víctima, incluyendo CloudTrail, registros de Lambda, registros de entrega de SNS y registros de invocación de Bedrock.

CloudTrail registra eventos de gestión por defecto, pero los eventos de datos requieren una configuración adicional. CloudTrail también oculta el contenido de los mensajes de SQS y SNS, y el detalle de Bedrock a nivel de prompt requiere el registro de invocación del modelo.

Como defensor, deberías vigilar tres señales:

• Una suscripción de SNS creada por un rol de Lambda que apunta a una dirección HTTP o HTTPS externa.
• Un aumento repentino en las llamadas a Converse o InvokeModel de un rol que nunca utilizó Bedrock.
• Una secuencia rápida de un mensaje de SQS, una ejecución de Lambda, llamadas a Bedrock y una publicación de SNS a un suscriptor externo.

El privilegio mínimo es el control más fuerte. Limita quién puede crear colas y funciones, configurar mapeos de fuente de eventos, pasar roles potentes a Lambda, llamar a Bedrock y crear suscripciones externas de SNS. Bloquear el acceso de Lambda a internet ayuda, pero no detendrá a NotC2 por sí solo, ya que SNS se encarga de la entrega exterior.

Tú y tu equipo también deberíais restringir las suscripciones de SNS a destinos aprobados.

NotC2 demuestra que la seguridad centrada en el perímetro falla en configuraciones serverless. Sin un servidor C2 que bloquear, debes centrarte en las identidades de las cargas de trabajo, los vínculos de servicio y el comportamiento inusual. Bloquea cualquier paso requerido y la cadena fallará.