Preámbulo

Te damos la bienvenida a otra entrega de la ingeniería de detección de AWS con Elastic. Puedes leer la entrega anterior en STS AssumeRoot aquí.

En este artículo, vamos a analizar cómo los actores de amenazas usan el cifrado del lado del servidor de Amazon S3 con claves proporcionadas por el cliente (SSE-C) para operaciones de rescate/extorsión. Esta táctica de abuso contemporánea demuestra las formas creativas en las que los adversarios pueden explotar los servicios nativos del cloud para alcanzar sus objetivos monetarios.

Como lector, obtendrás información sobre el funcionamiento interno de S3, los flujos de trabajo de SSE-C y las configuraciones de las cubetas. También repasaremos los pasos de esta técnica, analizaremos las mejores prácticas para proteger las cubetas de S3 y ofreceremos una guía práctica para desarrollar una lógica de detección que identifique el abuso de SSE-C en tu entorno.

Esta investigación se basa en una publicación reciente del equipo de Halcyon Research, que documentó el primer caso conocido públicamente de abuso en entornos reales (ItW) de SSE-C para comportamiento de ransomware. Acompáñanos mientras nos sumergimos en esta amenaza emergente y mostramos cómo hacer para mantenerse por delante de los adversarios.

Hemos publicado un gist con el código de Terraform y el script de emulación al que se hace referencia en este blog. Este contenido se proporciona solo para fines educativos y de investigación. Úsalo de manera responsable y conforme a las leyes y pautas aplicables. Elastic no asume ninguna responsabilidad por consecuencias no deseadas o mal uso.

¡Disfrútalo!

Comprender AWS S3: conceptos y características clave de seguridad

Antes de que nos sumerjamos directamente en la emulación y estas tácticas, técnicas y procedimientos (TTP), revisemos brevemente lo que incluye AWS S3.

S3 es el servicio de almacenamiento común de AWS que te permite almacenar cualquier dato estructurado o no estructurado en “cubetas”. Estas cubetas son similares a las carpetas que uno encontraría localmente en el sistema informático. Los datos almacenados en estas cubetas se denominan objetos, y cada objeto se identifica de forma única mediante una clave de objeto, que funciona como un nombre de archivo. S3 admite muchos formatos de datos, desde JSON hasta archivos multimedia y mucho más, lo que lo hace ideal para una variedad de casos de uso organizacionales.

Las cubetas se pueden configurar para que almacenen objetos de diversos servicios de AWS S3, pero también se pueden completar de forma manual o programática en función del caso de uso. Además, las cubetas pueden utilizar el versionado para mantener múltiples versiones de objetos, lo que ofrece resistencia frente a eliminaciones o sobrescrituras accidentales. Sin embargo, el versionado no siempre está habilitado por defecto, lo que deja los datos vulnerables a ciertos tipos de ataques, como los que involucran ransomware o eliminaciones masivas. Las cubetas se pueden configurar para que almacenen objetos de diversos servicios de AWS S3, pero también se pueden completar de forma manual o programática en función del caso de uso. Además, las cubetas pueden utilizar el versionado para mantener múltiples versiones de objetos, lo que ofrece resistencia frente a eliminaciones o sobrescrituras accidentales. Sin embargo, el versionado no siempre está habilitado por defecto, lo que deja los datos vulnerables a ciertos tipos de ataques, como los que involucran ransomware o eliminaciones masivas.

El acceso a estas cubetas depende en gran medida de sus políticas de acceso que, por lo general, se definen durante su creación. Estas políticas incluyen configuraciones como desactivar el acceso público para prevenir la exposición no intencionada del contenido de las cubetas. Sin embargo, la configuración no termina ahí; las cubetas también tienen su propio y único nombre de recurso de Amazon (ARN), lo que permite definir políticas de acceso más detalladas a través de roles o políticas de gestión de acceso a identidades (IAM). Por ejemplo, si el usuario “Alice” necesita acceso a una cubeta y sus objetos, se deben asignar permisos específicos como s3:GetObject a su rol de IAM. Ese rol puede aplicarse directamente a Alice como política de permisos o a un grupo asociado al que pertenezca.

Aunque estos mecanismos parecen infalibles, las configuraciones incorrectas en los controles de acceso (p. ej., políticas de cubetas o listas de control de acceso demasiado permisivas) son una causa común de incidentes de seguridad. Por ejemplo, al momento de escribir esto, aproximadamente 325 800 cubetas están disponibles públicamente según buckets.grayhatwarfare.com. Elastic Security Labs también observó que el 30 % de las verificaciones de postura de AWS fallidas estaban relacionadas con S3 en el Reporte de amenazas globales de Elastic 2024.

Cifrado del lado del servidor en S3
S3 ofrece múltiples opciones de cifrado para proteger los datos en reposo. Esto incluye lo siguiente:

• SSE-S3: AWS gestiona completamente las claves de cifrado.
• SSE-KMS: las claves se administran a través del servicio de gestión de claves (KMS) de AWS, lo que posibilita políticas de claves y control de acceso con mayor personalización. Mira cómo se implementan en Elastic.
• SSE-C: los clientes proporcionan sus propias claves de cifrado para tener más control. Esta opción se utiliza con frecuencia para cumplir con los requisitos de cumplimiento o de seguridad específicos, pero incorpora una sobrecarga adicional, como la gestión y el almacenamiento seguro de claves. Es importante destacar que AWS no almacena claves SSE-C; en su lugar, se registra el HMAC (código de autenticación de mensajes basado en hash) de una clave con fines de verificación.

En el caso de SSE-C, la mala gestión de las claves de cifrado o el abuso intencionado (p. ej., ransomware) puede hacer que los datos estén permanentemente inaccesibles.

Políticas de ciclo de vida

Las cubetas de S3 también pueden utilizar políticas de ciclo de vida, que automatizan acciones como la transición de objetos a clases de almacenamiento más económicas (por ejemplo, Glacier) o la eliminación de objetos después de un tiempo determinado. Aunque estas políticas se usan generalmente para optimizar costos, los atacantes pueden explotarlas para programar la eliminación de datos críticos, lo que aumenta la presión durante un incidente de ransomware.

Clases de almacenamiento

Amazon S3 ofrece múltiples clases de almacenamiento, cada una diseñada para diferentes patrones de acceso y necesidades de frecuencia. Aunque las clases de almacenamiento suelen elegirse para optimizar costos, es fundamental comprenderlas al considerar cómo interactúan el cifrado y la seguridad con el almacenamiento de datos.

Por ejemplo, S3 Standard e Intelligent-Tiering garantizan un acceso frecuente con mínima latencia, lo que los hace ideales para aplicaciones en tiempo real. Por otro lado, las clases de archivo como Glacier Flexible Retrieval y Deep Archive introducen demoras antes de que se pueda acceder a los datos, lo que puede complicar la respuesta a incidentes en escenarios de seguridad.

Esto se vuelve particularmente relevante cuando se incorpora el cifrado. El cifrado del lado del servidor (SSE) funciona en todas las clases de almacenamiento, pero SSE-C (claves proporcionadas por el cliente) traslada la responsabilidad de la gestión de claves al usuario o adversario. A diferencia del cifrado gestionado por AWS (SSE-S3, SSE-KMS), SSE-C requiere que cada operación de recuperación proporcione la clave de cifrado original; si dicha clave se pierde o un adversario no la proporciona, los datos no se podrán recuperar de forma permanente.

Con esta comprensión, surge una pregunta crítica sobre las consecuencias del abuso de SSE-C observado en un entorno real: ¿qué sucede cuando un atacante obtiene acceso a cubetas de S3 expuestas públicamente o mal configuradas y tiene control sobre la política de almacenamiento y las claves de cifrado?

Así comienza: el abuso de SSE-C para las operaciones de rescate

En la siguiente sección, compartiremos un enfoque práctico para emular este comportamiento en nuestro entorno de pruebas de AWS al completar lo siguiente:

1. Despliega infraestructura vulnerable mediante el proveedor de Infraestructura como Código (IaC) Terraform
2. Explora cómo crear solicitudes SSE-C en Python
3. Ejecuta un script personalizado para emular el comportamiento de ransomware descrito en el blog de Halcyon

Requisitos previos

En este artículo, se habla sobre la recreación de un escenario específico para la ingeniería de detección. Si este es tu objetivo, primero se debe establecer lo siguiente.

• Terraform debe estar instalado localmente.
• Python 3.9 (o superior) también debe estar instalado localmente para usarse en el entorno virtual y ejecutar un script de emulación.
• El perfil de AWS CLI debe configurarse con privilegios administrativos para que Terraform lo use durante el despliegue de la infraestructura.

Despliegue de una infraestructura vulnerable

Para nuestra emulación de caja blanca, es crucial replicar una configuración de S3 que una organización podría tener en un escenario real. A continuación se muestra un resumen de la infraestructura desplegada:

• Región: us-east-1 (región de despliegue predeterminada)
• Cubeta de S3: una cubeta de datos de nómina con nombre único que contiene datos confidenciales y permite el cifrado controlado por adversarios.
• Controles de propiedad de la cubeta: aplica “BucketOwnerEnforced” para prevenir permisos basados en ACL.
• Restricciones de acceso público: el acceso público está completamente bloqueado para prevenir la exposición accidental
• Usuario de IAM: un usuario IAM en riesgo y controlado por un adversario con permisos S3 excesivos; no se le asigna un perfil de inicio de sesión, ya que las credenciales de clave de acceso se utilizan programáticamente en otro lugar para tareas automatizadas.
• Política de IAM: tanto a nivel de cubeta como de objeto, los adversarios tienen autorización para lo siguiente:
  • s3:GetObject
  • s3:PutObject
  • s3:DeleteObject
  • s3:PutLifecycleConfiguration
  • s3:ListObjects
  • s3:ListBucket
• Se aplica tanto a nivel de cubetas como de objetos.
• Claves de acceso de IAM: se generan claves de acceso para el usuario adversario, lo que permite el acceso programático.
• Datos ficticios: los datos confidenciales simulados (customer_data.csv) se cargan en la cubeta.

Comprender la infraestructura es vital para evaluar cómo se desarrolla este tipo de ataque. En el blog de Halcyon, se describe la metodología de ataque, pero se ofrecen pocos detalles sobre la configuración específica de AWS de las organizaciones afectadas. Estos detalles son fundamentales para evaluar la viabilidad de un ataque de este tipo y los pasos necesarios para llevarlo a cabo con éxito.

Accesibilidad y exposición de las cubetas

Para que ocurra un ataque de esta naturaleza, un adversario debe obtener acceso a una cubeta de S3 mediante uno de los dos métodos principales:

Cubetas de acceso público: si una cubeta está mal configurada con una política de acceso público, un adversario puede interactuar directamente con esta, siempre que la política de permisos de la cubeta habilite acciones como s3:PutObject, s3:DeleteObject o s3:PutLifecycleConfiguration. Estos permisos a menudo se asignan erróneamente utilizando una entidad principal comodín (*), lo que significa que cualquiera puede ejecutar estas operaciones.

Credenciales en riesgo: si un atacante obtiene credenciales de AWS (a través de fugas de credenciales, phishing o malware), puede autenticarse como un usuario legítimo de IAM e interactuar con S3 como si fuera el propietario legítimo de la cuenta.

En nuestra emulación, asumimos que la cubeta no es pública, lo que significa que el ataque depende de las credenciales en riesgo. Esto requiere que el adversario haya obtenido claves de acceso válidas de AWS y que haya realizado el descubrimiento de la infraestructura del cloud para identificar las cubetas de S3 accesibles. Esto se hace comúnmente mediante llamadas a la API de AWS, como s3:ListAllMyBuckets, s3:ListBuckets o s3:ListObjects, que revelan cubetas y su contenido en regiones específicas.

Permisos de IAM necesarios para la ejecución de ataques: para cifrar archivos mediante SSE-C y aplicar una política de eliminación con éxito, el adversario debe tener los permisos de IAM adecuados. En nuestra emulación, configuramos permisos explícitos para el usuario de IAM en riesgo, pero en un escenario real, varios modelos de permisos podrían permitir este ataque:

• Políticas personalizadas excesivamente permisivas: las organizaciones pueden, sin darse cuenta, otorgar permisos amplios de S3 sin restricciones estrictas.
• Políticas administradas por AWS: es posible que el adversario haya obtenido credenciales asociadas con un usuario o rol que posee AmazonS3FullAccess o AdministratorAccess.
• Permisos parciales a nivel de objeto: si el usuario de IAM tuviera AllObjectActions, esto solo permitiría acciones a nivel de objeto, pero no otorgaría modificaciones de la política de ciclo de vida ni la enumeración de cubetas, que son necesarias para recuperar objetos y luego iterarlos para cifrarlos y sobrescribirlos.

Aunque el blog de Halcyon no detalla los permisos que se explotaron, nuestra emulación de caja blanca garantiza que se configuran los permisos mínimos requeridos para que el ataque se ejecute según lo descrito.

El rol del usuario de IAM comprometido
Otro factor crítico es el tipo de usuario de IAM cuyas credenciales se vieron comprometidas. En AWS, un adversario no necesariamente necesita credenciales para un usuario que tenga un perfil de inicio de sesión interactivo. Muchos usuarios de IAM se crean exclusivamente para el acceso programático y no requieren una contraseña de la consola de administración de AWS ni autenticación multifactor (MFA), ambas podrían actuar como bloqueadores de seguridad adicionales.

Esto significa que si las credenciales robadas de un usuario de IAM se utilizan para automatización o integración de servicios, el atacante tendría más facilidad para ejecutar solicitudes de API sin desafíos de autenticación adicionales.

Aunque en el blog de Halcyon, se documenta eficazmente la técnica que se utiliza en este ataque, no incluye detalles sobre la configuración subyacente de AWS de la víctima. Comprender la infraestructura detrás de los ataques, como el acceso a las cubetas, los permisos de IAM y los roles de usuario, es esencial para evaluar cómo se desarrollan estas operaciones de ransomware en la práctica. Dado que no se proporcionan estos detalles, debemos hacer suposiciones informadas para entender mejor las condiciones que permitieron que el ataque tuviera éxito.

Nuestra emulación está diseñada para replicar las condiciones mínimas necesarias para este tipo de ataque, lo que asegura una evaluación realista de las estrategias defensivas y las capacidades de detección de amenazas. Al explorar los aspectos técnicos de la infraestructura, podemos proporcionar información más profunda sobre las posibles mitigaciones y cómo las organizaciones pueden defenderse de manera proactiva contra amenazas parecidas.

Configuración de la infraestructura

Para el despliegue de nuestra infraestructura, utilizamos Terraform como nuestro marco de trabajo de IaC. Para mantener esta publicación simplificada, hemos almacenado tanto la configuración de Terraform como el script de emulación atómica en un gist que se puede descargar para fácil acceso. A continuación, se muestra la estructura esperada de los archivos locales una vez que se descargan.

Después de configurar los archivos necesarios localmente, puedes crear un entorno virtual de Python para este escenario e instalar las dependencias necesarias. Una vez que el entorno esté configurado, el siguiente comando inicializará Terraform y desplegará la infraestructura:

Comando: python3 s3\_sse\_c\_ransom.py deploy

Una vez que se complete el despliegue, la infraestructura necesaria de AWS estará lista para proceder con la emulación y ejecución del ataque. Es importante tener en cuenta que el acceso público está bloqueado y que la política de IAM solo se aplica al usuario de IAM que se generó dinámicamente por razones de seguridad. Sin embargo, recomendamos desarmar la infraestructura una vez que se completen las pruebas o después de registrar los datos necesarios.

Si inicias sesión en tu consola de AWS o usas la CLI, puedes verificar que la cubeta en la región us-east-1 existe y contiene customer_data.csv,, que, al descargarse, estará en texto sin formato. También notarás que no existe ningún “ransom.note”.

Explora cómo crear solicitudes de S3 SSE-C en Python

Antes de ejecutar la emulación atómica, es importante explorar las técnicas subyacentes que permiten a un adversario llevar a cabo este ataque en el mundo real con éxito.

Para quienes están familiarizados con AWS, las operaciones de S3, como acceder a cubetas, enumerar objetos o cifrar datos, suelen ser directas al usar los SDK de AWS o la CLI de AWS. Estas herramientas abstraen gran parte de la complejidad, lo que permite a los usuarios ejecutar operaciones sin necesidad de comprender profundamente la mecánica subyacente de la API. Esto también reduce la barrera de conocimiento para un adversario que intente abusar de estas funcionalidades.

Sin embargo, en el blog de Halcyon se destaca un detalle técnico crucial sobre la ejecución del ataque:

“El atacante comienza el cifrado invocando el encabezado x-amz-server-side-encryption-customer-algorithm, usando una clave de cifrado AES-256 que crean y guardan en su sistema local”.

La distinción clave aquí es el uso del encabezado x-amz-server-side-encryption-customer-algorithm, que se requiere para las operaciones de cifrado en este ataque. Según la documentación de AWS, este encabezado SSE-C generalmente se especifica al crear URL prefirmadas y al utilizar SSE-C en S3. Esto significa que el atacante no solo cifra los datos de la víctima, sino que lo hace de tal manera que AWS no almacena la clave de cifrado, lo que hace que la recuperación sea imposible sin la cooperación del atacante.

URL prefirmadas y su papel en el abuso de SSE-C

¿Qué son las URL prefirmadas?
Las URL prefirmadas son solicitudes de API firmadas que permiten a los usuarios realizar operaciones específicas de S3 durante un tiempo limitado. Estas URL se utilizan comúnmente para compartir objetos de manera segura sin exponer las credenciales de AWS. Una URL prefirmada otorga acceso temporal a un objeto de S3 y se puede acceder a través de un navegador o usarse programáticamente en solicitudes de API.

En un entorno típico de AWS, los usuarios utilizan los SDK o los envoltorios CLI para las URL prefirmadas. Sin embargo, al usar SSE-C, AWS requiere encabezados adicionales para cifrar o descifrar.

SSE-C y encabezados HTTP requeridos
Al hacer solicitudes SSE-C, ya sea mediante el SDK de AWS o llamadas directas a la API REST de S3, debes incluir los siguientes encabezados:

• x-amz-server-side​-encryption​-customer-algorithm: especifica el algoritmo de cifrado, pero debe ser AES256 (anotado en el reporte de Halcyon).
• x-amz-server-side​-encryption​-customer-key: proporciona una clave de cifrado de 256 bits codificada en base64 para que S3 la use para cifrar o descifrar tus datos.
• x-amz-server-side​-encryption​-customer-key-MD5: proporciona un resumen MD5 de 128 bits codificado en base64 de la clave de cifrado; S3 utiliza este encabezado para verificar la integridad del mensaje y garantizar que la clave de cifrado se haya transmitido sin errores ni alteraciones.

Cuando buscas oportunidades de detección, estos detalles son cruciales.

AWS Signature versión 4 (SigV4) y su rol

Las solicitudes a S3 son autenticadas o anónimas. Dado que el cifrado SSE-C con URL prefirmadas requiere autenticación, todas las solicitudes deben estar firmadas criptográficamente para probar su legitimidad. Aquí es donde entra en juego AWS Signature versión 4 (SigV4).

AWS SigV4 es un mecanismo de autenticación que asegura que las solicitudes de API a los servicios de AWS se firmen y se verifiquen. Esto es particularmente importante para las operaciones de SSE-C, ya que modificar objetos en S3 requiere llamadas API autenticadas.

Para este ataque, cada solicitud de cifrado debe estar firmada por:

1. Generar una firma criptográfica usando AWS SigV4
2. Incluir la firma en los encabezados de la solicitud
3. Adjuntar los encabezados necesarios de cifrado SSE-C
4. Enviar la solicitud a S3 para sobrescribir el objeto con la versión cifrada

Sin una firma adecuada de SigV4, AWS rechazaría estas solicitudes. Los ataques como el descrito por Halcyon se basan en credenciales en riesgo, y lo sabemos porque las solicitudes no fueron rechazadas en nuestras pruebas. También sugiere que los adversarios saben que pueden explotar las configuraciones incorrectas de AWS S3, como los requisitos de firma inadecuados, y comprenden las complejidades de las cubetas y sus controles de acceso a objetos. Esto refuerza la suposición de que el ataque se basó en credenciales de AWS en riesgo en lugar de en una cubeta de S3 expuesta y de acceso público, y que los adversarios eran lo suficientemente hábiles como para entender los matices no solo de las cubetas y los objetos de S3, sino también de la autenticación y el cifrado en AWS.

Detonar nuestra emulación atómica

Nuestra emulación atómica utilizará las credenciales “en riesgo” del usuario de IAM sin perfil de inicio de sesión que tiene una política de permisos adjunta que permite varias acciones de S3 en nuestra cubeta de destino. Como recordatorio, la infraestructura y el entorno en el que estamos llevando a cabo esto se desplegó a partir de la sección “Configuración de la infraestructura” que hace referencia a nuestro gist compartido.

A continuación, se presenta un flujo de trabajo paso a paso de la emulación.

1. Carga credenciales robadas de AWS (recuperadas de variables de entorno).
2. Establece un cliente S3 con credenciales en riesgo.
3. Genera la URL del endpoint de S3 (crea la URL de la cubeta).
4. Enumera objetos de S3 → s3:ListObjectsV2 (obtener lista de objetos).
5. Genera una clave de cifrado AES-256 (generada localmente)
6. Inicia bucle (para cada objeto en la cubeta).
   1. Genera una solicitud GET y firma con AWS SigV4 (autentica la solicitud).
   2. Recuperar objeto de S3 → s3:GetObject (obtener datos sin cifrar).
   3. Genera una solicitud PUT y firma con AWS SigV4 (adjunta los encabezados SSE-C).
   4. Cifra y sobreescribe el objeto en S3 → s3:PutObject (cifra con SSE-C).
7. Fin del bucle
8. Aplica la política de eliminación de 7 días → s3:PutLifecycleConfiguration (destrucción de datos con restricción de tiempo).
9. Sube la nota de rescate a S3 → s3:PutObject (mensaje de extorsión dejado para la víctima).

A continuación, se presenta una representación visual de este flujo de trabajo de emulación:

En nuestro script de Python, agregamos intencionalmente avisos que requieren tu interacción para confirmar que estás de acuerdo en no abusar de este script. Se genera otra petición durante la detonación que pausa la ejecución, lo que otorga tiempo para que AWS investigue, si fuera necesario, antes de borrar los objetos S3 Dado que se usa SSE-C, los objetos se cifran con una clave a la que Terraform no tiene acceso y, por lo tanto, fallaría.

Comando: python s3\_sse\_c\_ransom.py detonate

Después de la detonación, los objetos en nuestra cubeta de S3 se cifrarán con SSE-C, se habrá subido una nota de rescate y se habrá agregado un ciclo de vida de expiración.

Si intentas acceder al objeto customer_data.csv, AWS rechazará la solicitud porque se almacenó con cifrado desde el servidor. Para recuperar el objeto, necesitas una solicitud firmada que incluya la clave de cifrado AES-256 correcta.

Limpieza

La limpieza de esta emulación es bastante sencilla. Si decides conservar los objetos S3, comienza con el paso 1; de lo contrario, ve directamente al paso 5.

1. Ve a la región us-east-1
2. navega a S3
3. localiza el s3-sse-c-ransomware-payroll-XX bucket
4. Elimina todos los objetos.
5. Comando: python s3\_sse\_c\_ransom.py cleanup

Una vez que se complete, se eliminará todo lo desplegado inicialmente.

Estrategias de detección y búsqueda

Después de nuestra emulación atómica, es crucial compartir cómo podemos detectar eficazmente este comportamiento de ransomware basándonos en los logs de API proporcionados por CloudTrail de AWS. Ten en cuenta que utilizaremos Elastic Stack para la ingesta de datos y el desarrollo inicial de consultas; sin embargo, la lógica y el contexto de las consultas deben ser traducibles a tu SIEM de elección. Además, es importante tener en cuenta que los eventos de datos para S3 en tu configuración de CloudTrail deben estar configurados en “Registrar todos los eventos”.

Cifrado inusual de objetos de AWS S3 con SSE-C

El objetivo de esta estrategia de detección es identificar las solicitudes PutObject que utilizan SSE-C, ya que las claves de cifrado proporcionadas por el cliente pueden ser un fuerte indicador de actividad anómala, en especial si una organización utiliza principalmente el cifrado gestionado por AWS a través de KMS (SSE-KMS) o el cifrado nativo de S3 (SSE-S3).

En nuestra emulación, las solicitudes PutObject se configuraron con el encabezado x-amz-server-side-encryption-customer-algorithm establecido en AES256, lo que le señala a AWS que se usaron claves proporcionadas por el cliente para el cifrado (SSE-C).

Afortunadamente, AWS CloudTrail registra estos detalles de cifrado dentro de los parámetros de solicitud, permitiendo a los equipos de seguridad detectar un uso inusual de SSE-C. Los atributos clave de CloudTrail que debes monitorizar incluyen lo siguiente:

• SignatureVersion: SigV4 → Indica que esta solicitud fue firmada
• SSEApplied: SSE_C → Indica que se usó el cifrado de la clave del cliente del lado del servidor
• bucketName: s3-sse-c-ransomware-payroll-96 → Indica en qué cubeta ocurrió esto
• x-amz-server-side-encryption-customer-algorithm: AES256 → Indica qué algoritmo se utilizó para la clave de cifrado del cliente
• key: customer_data.csv → Indica el nombre del objeto al que se le aplicó

Con estos detalles, ya podemos crear una consulta de detección de amenazas que coincida con estos eventos y, finalmente, con la amenaza reportada en el blog original de Halcyon.

Si bien esta detección es amplia, las organizaciones deben adaptarla a su entorno preguntando:

• ¿Esperamos URL prefirmadas con SigV4 para operaciones de cubetas u objetos de S3?
• ¿Esperamos que SSE-C se use para operaciones PutObject en S3 o en esta cubeta específico?

Reducción de falsos positivos con nuevos tipos de reglas de términos
Para minimizar los falsos positivos (FP), podemos aprovechar el tipo de regla New Terms de Elastic, que ayuda a detectar ocurrencias por primera vez de actividad sospechosa. En lugar de emitir una alerta en cada coincidencia, rastreamos combinaciones únicas de usuarios de IAM y cubetas de S3 afectadas, lo que genera solo una alerta cuando este comportamiento se observa por primera vez dentro de un período establecido. Algunas de las combinaciones únicas que vigilamos son las siguientes:

• Usuarios únicos de IAM (ARN) que realizan el cifrado SSE-C en S3.
• Cubetas específicas donde se aplica SSE-C.

Estas alertas solo se activan si esta actividad se ha observado por primera vez en los últimos 14 días.

Este enfoque adaptativo asegura que los casos de uso legítimos se aprendan con el tiempo, lo que evita que se repitan alertas en operaciones esperadas. Al mismo tiempo, marca las primeras ocurrencias anómalas de SSE-C en S3, lo que facilita la detección temprana de amenazas. Según sea necesario, se pueden agregar excepciones de regla para ARN de identidad de usuario específicos, cubetas, objetos o incluso IP de origen para refinar la lógica de detección. Al incorporar el contexto histórico y las líneas de base de comportamiento, este método mejora la fidelidad de la señal, lo que incrementa tanto la efectividad de las detecciones como la capacidad de respuesta de las alertas.

Referencias de reglas

Cifrado inusual de objetos de AWS S3 con SSE-C
Cifrado excesivo de objetos de AWS S3 con SSE-C

Conclusión

Te agradecemos que te hayas tomado el tiempo de leer esta publicación y, si lo hiciste, por probar la emulación tú mismo. Las pruebas de caja blanca desempeñan un rol crucial en la seguridad del cloud, lo que nos permite replicar amenazas del mundo real, analizar sus patrones de comportamiento y desarrollar estrategias de detección efectivas. Dado que los ataques basados en cloud se vuelven cada vez más frecuentes, es esencial comprender las herramientas detrás de las tácticas de los adversarios y compartir los resultados de las investigaciones con la comunidad de seguridad en general.

Si estás interesado en explorar nuestro conjunto de reglas de detección de AWS, puedes encontrarlo aquí: Reglas de detección de Elastic AWS. También agradecemos las contribuciones para mejorar nuestro conjunto de reglas: tus esfuerzos ayudan a fortalecer las defensas colectivas, ¡y lo apreciamos mucho!

¡Animamos a cualquiera que esté interesado a revisar la publicación de Halcyon y les agradecemos de antemano por compartir su investigación!

Hasta la próxima.

Referencias importantes:

Blog de investigación de Halcyon sobre SSE-C ItW
Código de emulación de Elastic para SSE-C en AWS
Conjunto de reglas de detección de amenazas de AWS predefinidas de Elastic
Repositorio de reglas de detección predefinidas de Elastic
Regla: cifrado inusual de objetos de AWS S3 con SSE-C
Regla: cifrado excesivo de objetos de AWS S3 con SSE-C