Lo que necesita saber sobre el ransomware en AWS

Por más grave que sea el problema del ransomware dentro de los centros de datos, yo era un poco escéptico de que fuera un problema importante en el cloud. Personalmente, no me había topado con ningún incidente y empecé a pensar que era más teórico que otra cosa. Resulta que estaba algo equivocado. Bueno, totalmente equivocado. No solo es un problema mayor de lo que pensaba, sino que el patrón de ataque era distinto del que esperaba dentro de Amazon Web Services (AWS).

En la conferencia AWS re:Inforce asistí a una sesión excelente dirigida por Kyle Dickinson, Megan O'Neil y Karthik Ram. Estaba completamente llena y el encargado de la sala tuvo que rechazar a decenas de personas. Esta publicación es en parte un resumen de la sesión, combinado con mis propias experiencias y recomendaciones sobre el ransomware en AWS. Cualquier error u omisión es mío, no de ellos.

Puntos clave:

• Los actores de ransomware apuntan cada vez más a los entornos de Amazon Web Services (AWS), y suelen explotar brechas en el acceso de identidades, las configuraciones de almacenamiento y la visibilidad entre servicios.
• Los buckets de Amazon S3 son un punto de entrada habitual: los atacantes cifran o eliminan datos críticos debido a políticas débiles o a la falta de ejecución del cifrado.
• Una defensa eficaz contra el ransomware en el cloud requiere una estrategia por capas que incluya control de acceso, monitoreo en tiempo real y flujos de trabajo de respuesta rápida.
• FireMon mejora la postura de seguridad de los datos al monitorear continuamente las configuraciones incorrectas, aplicar políticas a escala y brindar la visibilidad que ayuda a los equipos a responder más rápido a las amenazas de ransomware basadas en el cloud.

¿Es el ransomware en Amazon AWS un problema?

Sí. Resulta que el ransomware en AWS es más problemático de lo que pensaba en un principio. Hay clientes reales afectados; no es algo meramente teórico.

¿Cómo funciona un ataque de ransomware en Amazon?

Cubriré el vector de explotación inicial en la siguiente pregunta, pero existen cuatro posibles técnicas de ataque de ransomware en Amazon:

• Los atacantes comprometen una instancia (a menudo mediante phishing a un usuario o administrador, no siempre por compromiso directo) y luego instalan su malware para cifrar los datos y propagarse a otras instancias alcanzables. Esto en realidad no se diferencia del ransomware en un centro de datos, ya que no involucra nada específico del cloud.
• El atacante copia los datos de un bucket de S3 y luego elimina los datos originales. Este es el ransomware nativo del cloud en Amazon que se observa con mayor frecuencia.
• Un actor malicioso cifra los datos de S3 usando una clave de KMS bajo su control. Esto es más teórico que real, por múltiples factores. Es mucho más fácil eliminar un objeto o bucket que cifrarlo de forma retroactiva.
• Un atacante hace algo con los datos en otro servicio de almacenamiento para bloquearlos o eliminarlos. Soy impreciso porque esto no se observa, y la mayoría de esos servicios tienen limitaciones internas y resiliencia integrada que dificultan la ejecución del ransomware.

El ransomware apunta con mayor frecuencia a los buckets de AWS S3, y los atacantes copian y luego eliminan los datos. Las instancias y servidores también pueden ser blanco del mismo malware que se usa para atacar centros de datos. Hay algunos ataques teóricos que en realidad no se ven en el mundo real.

Sin embargo, un nuevo ataque de ransomware en Amazon está ganando terreno: las bandas de ransomware han comenzado a cifrar los datos en su lugar utilizando el cifrado del lado del servidor de AWS con claves proporcionadas por el cliente (SSE-C). Esta técnica permite a los atacantes cifrar archivos directamente en sus buckets de S3 sin eliminarlos ni activar las alertas estándar, y la recuperación es imposible sin la clave de cifrado personalizada del atacante.

¿Cómo obtienen acceso los actores de amenazas para realizar ataques de ransomware en Amazon Web Services?

Credenciales expuestas. Casi siempre claves de acceso estáticas, pero posiblemente claves obtenidas de una instancia comprometida (a través del servicio de metadatos). Ya sabe, prácticamente así funcionan casi todos los ataques de seguridad basada en el cloud.

¿Cuál es la secuencia de un ataque de ransomware a S3?

Me centraré en el escenario de ransomware en buckets de S3, ya que es el nativo del cloud en el que queremos enfocarnos.

• El atacante obtiene credenciales.
• El atacante usa las credenciales para hacer reconocimiento y determinar qué llamadas a la API están permitidas e identificar los recursos a los que puede acceder.
• El atacante descubre que tiene permisos de escritura en S3 y acceso de lista/lectura para identificar buckets. Tenga en cuenta que el atacante puede no tener privilegios de List, pero puede obtener los nombres de los buckets de otras fuentes, como DNS, GitHub u otras ubicaciones. Esto es mucho menos probable.
• El atacante copia o mueve los datos a otra ubicación, que no necesariamente está en AWS.
• El atacante elimina los objetos o archivos de origen.
• El atacante sube una nota de rescate (o la envía por correo electrónico).

En campañas recientes, los atacantes también han comenzado a usar políticas de S3 Object Lifecycle Management para marcar los archivos cifrados para su eliminación en un plazo de siete días, lo que aumenta la urgencia de pagar el rescate. Con frecuencia dejan un archivo warning.txt en el directorio afectado con una dirección de billetera de Bitcoin y un identificador único de la víctima.

Dado que todo esto está automatizado, el proceso puede comenzar en menos de un minuto tras la exposición de una credencial.

¿Cómo puedo detectar el ransomware en Amazon S3?

Bueno, si no puede saltar directamente a la prevención del ransomware en S3…

El atacante suele dejar una nota con información de contacto para que usted le envíe Bitcoin, lo cual es muy conveniente. Pero lo más probable es que la mayoría de ustedes quiera identificar el problema antes de eso. Repasemos la secuencia del ataque de ransomware a Amazon S3 para ver dónde podemos detectarlo.

Primero, conviene habilitar un monitoreo más profundo de sus buckets sensibles. Como esta publicación ya se está extendiendo más de lo que quisiera, omitiré todos los detalles sobre cómo identificar y administrar esos buckets y, en su lugar, me centraré en algunas fuentes clave a considerar. Por razones de costos, no espere activarlas para todo:

• CloudTrail, por supuesto.
• CloudTrail Data Events para cualquier bucket que le importe. Esto tiene un costo adicional.
• GuardDuty.
• Opcional: Security Hub. Es la mejor manera de agregar GuardDuty y otros servicios de seguridad de AWS en todas sus cuentas.
• Tal vez: S3 Server Access Logs. Si tiene CloudTrail Data Events, obtiene la mayor parte de lo que querría. Pero los registros de S3 son gratuitos de crear (solo paga el almacenamiento) y sí capturan algunos eventos que CloudTrail podría pasar por alto (por ejemplo, autenticaciones fallidas). También tardan horas en aparecer, por lo que no resultan útiles durante un incidente en curso. Lea más en esta guía del usuario.

Ahora que cubrimos el monitoreo, veamos los siete pasos del proceso de detección:

1. Detección de credenciales expuestas y actividad de reconocimiento

El proceso de detección comienza con la identificación propia o de terceros de claves de AWS divulgadas públicamente o comprometidas, así como de cualquier actividad sospechosa. Normalmente mediante el escaneo de un repositorio común, como GitHub. Amazon Web Services encontró una de las mías una vez y me envió un correo electrónico. Ups.

Aquí funcionarán sus detecciones de reconocimiento de credenciales de cuenta. Algunas opciones incluyen:

• Hallazgos de GuardDuty, como la exfiltración de credenciales. Sin embargo, esto tiene un retraso de unos 20 minutos y existen técnicas de evasión
• La llamada a la API GetCallerIdentity no siempre es maliciosa, pero no es una llamada que deba ver con frecuencia en cuentas de producción
• GetAccountAuthorizationDetails debería activar una alarma siempre
• Múltiples llamadas a la API fallidas desde una sola entidad de IAM

2. Vigilancia de la enumeración de S3

Ahora empezamos a centrarnos en las detecciones de ransomware en AWS que indican que el atacante está enfocándose en S3. Probablemente note que la detección temprana en estas fases puede ser difícil debido al ruido, pero tenga en cuenta que resultarán más viables en situaciones como cuentas de producción administradas mediante CI/CD con acceso humano limitado. De hecho, esto podría motivarlo a usar más patrones nativos del cloud.

Los hallazgos de S3 de GuardDuty para eventos de Discovery, que deben habilitarse además de simplemente activar GuardDuty, según cómo estén configuradas su cuenta y su organización. Filtre por eventos fallidos de Read y List Management y Data Events en el servicio S3. Podría sorprender al atacante mientras husmea. Podría hacerlo en su SIEM, pero también es fácil crear CloudWatch Metrics Filters para esto.

3. Monitoreo de lecturas y copias de objetos

Aquí, usted está monitorear continuamente para ver si el atacante está leyendo los objetos y haciendo copias. Si los lee (copia) y luego elimina cada objeto, esto puede entrelazarse con la siguiente fase.

4. Detección de eliminaciones masivas y colocación de notas de rescate

Esta es la etapa del “uh oh”. El atacante ya no solo está explorando, está ejecutando el ataque y eliminando los datos copiados. Los hallazgos de exfiltración/impacto de S3 de GuardDuty se activarán. Recuerde que tardan al menos 20 minutos en activarse y, según la cantidad de objetos, este podría ser un indicador tardío. CloudTrail Insights, si los utiliza, alertará sobre la gran cantidad de eventos de escritura usados para mover los datos.

Puede crear sus propias detecciones para una gran cantidad de llamadas de eliminación. Según su entorno y sus patrones normales de actividad, esta cifra podría ser baja y activarse más rápido que GuardDuty. Su SIEM y los filtros de métricas de CloudWatch son buenas opciones.

5. Identificación del abuso de SSE-C (cifrado silencioso)

Monitoree la aplicación repentina de encabezados SSE-C en llamadas a la API como PutObject: una señal de que los datos podrían estar cifrados con la clave del atacante. Dado que AWS solo registra un hash HMAC de las operaciones, la recuperación forense estándar es imposible sin un monitoreo proactivo.

6. Uso de buckets canario y detección de KMS

Las organizaciones maduras pueden sembrar cuentas con buckets/objetos canario y generar alertas ante cualquier operación que toque esos buckets. Aunque es un patrón de ataque menos común, puede alertar a las personas sobre el uso de una clave de KMS desde fuera de su cuenta.

7. Escalamiento y respuesta a incidentes

Si detecta el ataque en esta etapa, ya está comprometido. Es momento de responder. Llame a las autoridades y contacte al equipo de respuesta a incidentes de clientes de AWS.

Protección contra ransomware en AWS: ¿cómo puedo mantener segura a mi empresa?

Para llevar a cabo un ataque exitoso de ransomware en AWS, el actor malicioso necesita tres condiciones:

• Acceso a credenciales
• Permisos de lectura y escritura en S3
• La capacidad de eliminar objetos que no se pueden recuperar

La primera capa para prevenir el ransomware es restringir IAM y luego usar las herramientas integradas de AWS para lograr resiliencia. Es fácil decirlo y difícil hacerlo, pero aquí hay una lista de verificación enfocada en S3, y trataré de omitir la mayor parte de la higiene y los controles habituales:

• No permita en absoluto usuarios de IAM que vengan con claves de acceso estáticas. Si eso no es posible, sin duda utilice sus herramientas para identificar a cualquier usuario con permisos de eliminación en S3.
• Exija MFA para los usuarios de SSO/federados. Siempre y para siempre.
• Haga que los administradores escalen a un rol de IAM distinto cuando necesiten realizar operaciones de eliminación. Incluso puede separar por completo los permisos de lectura y de eliminación en roles distintos.
• Si una instancia necesita acceso a S3, asegúrese de acotar los permisos lo más estrictamente posible a las llamadas a la API mínimas necesarias sobre los recursos mínimos.
• Deshabilite SSE-C a menos que sea absolutamente necesario. Esto ayuda a prevenir ataques de cifrado silencioso que pueden dejarlo sin acceso a sus datos sin ninguna vía de recuperación.
• Use un endpoint de VPC para acceder al bucket y agregue una política de recursos que solo permita eliminar desde la VPC de origen. Así el atacante no podrá usar las credenciales fuera de esa VPC.
• Active el versionado, AWS Backup y/o la replicación de buckets. Todo esto garantizará que no pueda perder el acceso a sus datos. Bueno, a menos que arruine DE VERDAD sus políticas de IAM y le deje el camino libre al atacante. Algunas de estas opciones deben habilitarse al crear el bucket, por lo que quizá necesite una operación de migración para lograrlo.

Notará que estoy omitiendo Block Public Access. Es una excelente función, pero muchas organizaciones tienen dificultades para implementarla a escala, ya que necesitan algunos buckets públicos y no ayuda con ataques que usan credenciales expuestas.

Todo esto requiere esfuerzo y agrega costos, así que realmente recomiendo enfocarse al principio en los buckets que de verdad importan. Existen estrategias más avanzadas, especialmente si opera entornos más grandes, que no caben en una publicación, pero escríbame si desea hablar sobre ellas.

¿Qué cosas nuevas sobre el ransomware en S3 aprendió en la sesión de Re:Inforce?

No sabía que el ransomware en S3 fuera tan común. Tampoco sabía que copiar y luego eliminar fuera la técnica de ataque preferida. Pensaba que se usaba el cifrado con KMS y tiene todo el sentido que eso sea más teórico e infrecuente. Conocía los detectores y las defensas, pero los ponentes de AWS hicieron un trabajo excelente al articularlos de una manera muy clara y utilizable. La charla superó por completo mis expectativas.

¿Cómo puede FireMon ayudar a mi empresa con la protección contra el ransomware en S3?

Tenemos un nuevo producto de IAM en Beta para privilegios Just in Time que debería estar disponible pronto. También ofrecemos verificaciones de postura y detectores de amenazas en DisruptOps para identificar buckets riesgosos y alertar sobre actividad maliciosa, como los ataques de ransomware. Escríbame si desea hablar sobre ellos, o incluso si solo quiere algún consejo general sobre las opciones de AWS que mencioné en la publicación.

Agende un demo hoy y vea cómo FireMon puede ayudarle a proteger su empresa del ransomware en AWS.