Cloud-Ransomware nativo - Cómo los ataques a la disponibilidad aprovechan los servicios de cloud

Cómo afecta el ransomware a los datos empresariales cloud

El ransomware es un delito de motivación económica cuyo objetivo es inhibir los sistemas empresariales y obtener el pago de un rescate. Históricamente, el rescate de datos que residen en las cargas de trabajo tradicionales de las empresas locales y en los sistemas gubernamentales ha dado lugar a amplios beneficios económicos para los agresores que utilizan ataques de ransomware. Con la creciente huella cloud de los sistemas digitales modernos, las organizaciones tratan ahora de determinar si el ransomware puede afectar en el mismo grado a las cargas de trabajo cloud, y se preguntan además "¿existirá una presión evolutiva sobre los atacantes que les obligue a evolucionar en sus tácticas?".

Con las recientes observaciones de las tendencias en la adopción de cloud y la migración de datos, mi conclusión es tal: No veo cómo el ransomware PODRÍA NO convertirse en un problema mayor para las empresas globales.

Mi tesis sobre este tema puede resumirse simplemente así: Dondequiera que vivan los datos críticos, irá el ransomware. Cuando los datos empresariales residen en la Cloud, en lugar de, por ejemplo, en una base de datos local, tiene sentido desde el punto de vista financiero que los atacantes evolucionen sus tácticas para atacar los sistemas cloud con los mismos objetivos que los sistemas locales.

Este documento sirve para esbozar los caminos que podría seguir un actor malicioso en la cloud para afectar a la disponibilidad de los datos mediante el uso de las herramientas proporcionadas por el proveedor de servicios Cloud (CSP). Además de los comportamientos de los atacantes, he esbozado medidas proactivas para proteger las API de cloud que proporcionan servicios criptográficos, patrones arquitectónicos para facilitar la protección de estos sistemas y métodos para detectar el ransomware cloud.

Atacar la disponibilidad en Cloud

Los más de 10 primeros años de transformaciones de cloud han visto una aceleración de las migraciones a cloud y el depósito de conjuntos de datos cada vez más grandes en la cloud. Aun siendo testigos de este cambio, a menudo seguimos pensando en el ransomware únicamente en el contexto de los entornos locales, extendiendo ingenuamente esos conceptos a la cloud.

En la cloud, las herramientas disponibles que los desarrolladores y clientes necesitan para realizar tareas cotidianas están integradas y son ofrecidas como funciones por los proveedores de servicios cloud . Con el acceso, las mismas herramientas y capacidades son utilizadas a menudo por los malos actores para superar los controles de seguridad, evitar la detección y lograr objetivos específicos. El uso malintencionado de estas funciones suele denominarse abuso de funciones.

La apertura de los servicios cloud a través de API facilita a los atacantes el abuso, o mejor dicho, el uso indebido de herramientas para los mismos.

Las API, creadas por cada CSP, son altamente descubribles, y pueden ser rápidamente comprendidas y aprovechadas de maneras no intencionadas. El abuso de características presenta un riesgo adicional a las vulnerabilidades de código. A diferencia de la explotación de una vulnerabilidad, no existe un fallo de código que manipular que pueda detectarse mediante la comparación de patrones o protegerse mediante parches. En su lugar, los actores de la amenaza están aprovechando las herramientas proporcionadas por el CSP utilizadas para desplegar o mantener el software de producción y la infraestructura para llevar a cabo tareas nefastas.

Sea cual sea el entorno en el que se encuentren, los actores de las amenazas aprovecharán las herramientas que tengan a su disposición para llevar a cabo sus nefastas tareas. En cierto sentido, al abusar de las API públicas, el ransomware en la cloud continuará la tendencia de "vivir de la tierra", donde los "binarios LOL" de la Cloud son sus API, ricas en funciones y públicas. A diferencia de los ejecutables de Windows, que pueden desinstalarse como software superfluo, las API de cloud de AWS están siempre activas. La exposición, el acceso y la disponibilidad siguen proporcionando la apertura que requieren los servicios y dan paso a los medios para los devastadores ataques de ransomware.

¿Dónde se alojan sus datos Cloud ?

Para entender las técnicas de abuso que pueden utilizar los operadores de ransomware, primero hay que conocer los sistemas en los que se almacenan los datos. Es probable que los datos locales se almacenen en diversas tecnologías, desde bases de datos Oracle hasta servidores Microsoft SQL. Lo que estos sistemas tienen en común es que son hosts físicos, totalmente bajo su control.

Los servidores de almacenes de datos locales suelen ser hosts físicos implementados en un entorno de pila completa que proporcionan objetivos fáciles para el malware debido a la amplia superficie de ataque. Sin embargo, los entornos full-stack se benefician de estar protegidos por sólidas estrategias de protección de datos, empleando controles de seguridad que han evolucionado a lo largo de los últimos 20 años de modelado de amenazas basadas en la red. Como tales, las bases de datos locales tradicionales se esconden tras capas de controles de red, se acorralan en los recovecos más profundos de las redes corporativas y se supervisan intensamente con detección de amenazas basada en agentes.

El enfoque local para proteger los almacenes de datos tradicionales no se traslada a la cloud, ni debería. Los datos migrados a la cloud residen en sistemas en los que todos los usuarios finales, incluidos los agentes maliciosos, tienen un acceso limitado y restringido al sistema subyacente. Esto significa que los almacenes de datos cloud nube tienen superficies de ataque radicalmente diferentes.

Cada uno de los principales proveedores de servicios cloud (por ejemplo, AWS, AZURE, GCP) tiene una versión única de un almacén de datos distribuido, altamente disponible y polivalente: AWS S3, Azure Blob Storage y GCP Storage Buckets. Cada uno de ellos es un repositorio central para datos no estructurados y es un servicio ubicuo, estable y altamente disponible que se integra con muchos otros servicios en sus respectivas plataformas, satisfaciendo casi todas las necesidades de almacenamiento de datos de los clientes. Los proveedores de Cloud utilizan los servicios de almacenamiento para construir pipelines, y sirven como almacén de datos de respaldo para plataformas de big data o como repositorios públicos para contenidos web.

Si eres cliente de AWS, es difícil NO usar S3. Lo que lo convierte en un objetivo probable para los autores de ransomware cloud.

Estrategia tradicional de cifrado de ransomware

El ransomware dirigido a sistemas locales utiliza un esquema de cifrado híbrido, aprovechando lo mejor del cifrado simétrico y asimétrico, para sortear las limitaciones de cada ^uno1.

Siendo las limitaciones:

• Mientras que las operaciones de cifrado asimétrico son lentas, el cifrado de datos con una clave simétrica es rápido.
• El cifrado simétrico utiliza la misma clave para el cifrado y el descifrado. Una estrategia puramente simétrica suele dejar la clave de descifrado en el sistema, lo que facilita su recuperación por parte de los equipos forenses.

Las estrategias empleadas por los autores de ransomware para sortear estas limitaciones son las mismas técnicas que utilizan los equipos criptográficos internos. Ya sea con fines benévolos o malévolos, las jerarquías de claves pueden utilizarse para derivar un conjunto de claves de otro y luego cifrar las claves de datos simétricas.

Combinando el cifrado simétrico y el asimétrico, los autores de ransomware pueden lograr una serie de objetivos más complejos.

• Mayor velocidad al realizar tareas de cifrado
  > Al dirigirse a datos con claves simétricas, el ransomware a menudo puede completar la explotación antes de que las capacidades defensivas tengan la oportunidad de responder.
• La ofuscación del material de la clave simétrica dificulta la recuperación durante el análisis posterior a la explotación.
  > Al cifrar la clave simétrica de los datos con una clave asimétrica, la recuperación del material de la clave resulta difícil, si no imposible, para los profesionales forenses.

La creación de malware para realizar complejas técnicas de cifrado es necesaria para los cifradores locales. Sin embargo, es probable que esta estrategia de cifrado resulte engorrosa y completamente innecesaria cuando se ataca a datos en la cloud. En este documento se describen métodos que podría utilizar un atacante para aprovechar las herramientas que ofrecen los proveedores de servicios cloud nube y dejar obsoletas las técnicas tradicionales de ransomware.

Cifrado de objetos S3 con claves KMS controladas por el atacante

Los proveedores de servicios Cloud han hecho el trabajo pesado de mantener raíces de confianza seguras para sus clientes que utilizan sus servicios criptográficos. Los atacantes pueden aprovechar estas ventajas para afectar a la disponibilidad de los datos cloud.

AWS Key Management Service (AWS KMS), permite a sus clientes generar claves, controlar el acceso a dichas claves y utilizarlas para realizar operaciones criptográficas como firmar, verificar y administrar el proceso de cifrado de sobres necesario para S3 Server-Side Encryption (SSE).

Cuando no se utiliza KMS, los objetos cifrados en S3 se cifran con una clave de AmazonMaster. Cuando una parte autorizada solicita acceso a un objeto de este bucket, AWS descifra los datos de forma transparente en segundo plano. En lugar de permitir que AWS genere y administre las claves de respaldo SSE, los clientes pueden utilizar una clave KMS y aprovechar la política basada en recursos adjunta a la clave como otra capa de control de acceso en torno a los datos cifrados. La capacidad de aplicar políticas y restringir el acceso a una clave deja una abertura para que los atacantes afecten a la disponibilidad de los datos cifrados con la clave.

Para demostrar el papel de KMS en SSE, observe el escenario uno a continuación, donde un operador de ransomware obtiene un acceso significativo a S3 y KMS en una cuenta de AWS. El actor malicioso puede leer, copiar y eliminar objetos de S3, además de obtener los permisos para crear una nueva clave KMS. El escenario describe además cómo un actor de amenazas podría utilizar el acceso para afectar a la disponibilidad de los datos y exigir un rescate por su restauración.

Escenario: Demostración de ransomware Cloud en S3

En el escenario planteado, un actor de amenazas tiene como objetivo los datos del llamado "bucket víctima". En este bucket, el cifrado del lado del servidor (SSE) está habilitado, especificando que los objetos se cifran de forma transparente con una clave maestra gestionada por Amazon (SSE-S3). Un usuario final al que sólo se le conceda acceso para recuperar objetos (acción s3:GetObject) de este bucket tendría permisos suficientes para descargar el texto claro de los objetos almacenados. No se requieren permisos adicionales para descifrar los objetos cuando se cifran con una clave maestra administrada por Amazon.

En este escenario, consideramos que un actor malicioso ha comprometido a un usuario final con la intención de pedir un rescate por sus datos. El actor malicioso ha creado un nuevo bucket de S3 que llamaremos "staging-bucket", que utilizará como zona de aterrizaje para los datos de S3 objetivo. El "staging-bucket" recién creado también requiere que los objetos subidos estén cifrados, pero con una clave KMS. Generamos la clave KMS en AWS y la almacenamos en un HSM de AWS; a continuación, confiamos en la política administrada por el cliente para aplicar el control de acceso a la clave.

Al migrar los datos del "contenedor víctima" al "contenedor de almacenamiento", los objetos se vuelven a cifrar con la nueva clave KMS creada. Los permisos asociados a los objetos S3 y a la clave KMS determinan el acceso a los objetos. Espere respuestas de acceso denegado cuando las solicitudes procedan de personas que carezcan de permisos explícitos para acceder tanto a los objetos S3 como a la clave KMS. Si un usuario final tiene un permiso explícito de "denegación" en el objeto S3 o en la clave KMS, es de esperar que también se denieguen las solicitudes de acceso.

En este punto, nuestro actor de amenazas ficticio ha preparado el escenario para un ataque de ransomware migrando los objetos S3 a un nuevo almacén de datos y volviendo a cifrar los objetos con claves bajo su control. El siguiente paso en esta narrativa implica afectar al acceso a la clave para operaciones criptográficas, como el descifrado.

Bloqueo de políticas clave - "DENEGAR, excepto cuando; PERMITIR, sólo cuando"

La técnica de bloquear a un cliente de AWS una clave KMS alojada en su propia cuenta fue descrita por primera vez por Spencer Geitzen en la Cloud Village de DEFCON en ²⁰²⁰².

Veamos cómo podría ser una actualización maliciosa de la política de claves.

• DENY - todas las acciones sobre la clave KMS - excepto cuando la clave de condición "aws:sourceIp" es igual a la IP controlada por el atacante.
• PERMITIR - todas las acciones en la clave KMS - sólo cuando la persona que llama es de la cuenta controlada por el atacante.

Este estilo de jerga política basada en recursos puede denominarse:"DENEGAR, excepto cuando; PERMITIR, sólo cuando".

Puedes imaginar otras condiciones que podrían ser aprovechadas por un operador de ransomware que quiera emplear este patrón. Requerir que la persona que llama se origine desde una IP de origen específica es, en efecto, un mecanismo para restringir toda la actividad en una clave, sin embargo, igual de eficaz podría ser el uso de las siguientes condiciones de clave global de AWS:

• aws:DirectorArn
• aws:CuentaPrincipal
• aws:fuenteVPC
• aws:FuenteVPCe

Cualquier condición que requiera un valor único y controlado por el atacante puede aprovecharse para bloquear los recursos de un cliente de AWS.

Al actualizar una política basada en recursos adjunta a la clave KMS al patrón "DENEGAR, excepto cuando; PERMITIR, solo cuando", la cuenta de la víctima queda efectivamente bloqueada de sus datos recién cifrados. Ni siquiera el usuario root puede acceder a los datos S3 cifrados.

Solo las personas que llamen desde la cuenta de AWS controlada por el atacante desde la IP controlada por el atacante podrían acceder a la clave KMS y descifrar los datos de S3.

La limpieza final de un ataque de ransomware cloud nube incluiría borrar el "cubo víctima" original y subir una nota de rescate a un nuevo cubo sin cifrar.

Claves KMS existentes

Bloquear a una víctima de una clave KMS no es la única forma de afectar a la disponibilidad de S3. Sin embargo, es uno de los mecanismos más interesantes de modelar para un investigador de seguridad.

Esta técnica no se limita a las nuevas claves KMS. Para afectar a la disponibilidad mediante el impacto de una clave KMS existente se requerirían permisos aún más escasos por parte del actor de la amenaza. Actualizar una política de claves KMS existente para restringir el acceso a ella para operaciones criptográficas tendría el mismo efecto debilitador sobre la disponibilidad de los datos que volver a cifrar los datos S3 con una nueva clave creada por el atacante.

En los dos escenarios anteriores, el acceso a la clave simétrica utilizada en el cifrado del lado del servidor (SSE-KMS) es tomado como rehén por actores maliciosos mediante la manipulación de la política de claves.

Cuando la víctima paga

No podemos presumir de saber cómo sería para una banda de ransomware cloud nube ceder el control de la clave de descifrado de datos basada en un ransomware tradicional local. En la cloud, el proceso de "entregar las claves" de los datos cifrados será diferente, aunque siga siendo un componente necesario del ciclo de vida del ransomware. Al fin y al cabo, el producto que el ransomware ofrece a su consumidor es un mecanismo para recuperar los datos cifrados. Como cualquier otro negocio, los operadores de ransomware necesitan un medio fiable y de confianza para entregar productos a sus "clientes".

En el escenario uno, sólo las personas que llaman desde la cuenta del atacante pueden acceder a la clave KMS que se necesita para descifrar los datos críticos para el negocio, pero la actualización de la política de claves es una acción que un atacante no puede realizar entre cuentas. Por lo tanto, un mecanismo fiable y en tiempo real para devolver el control a la víctima no puede implicar una actualización de la política de claves. En su lugar, una banda de ransomware puede recurrir a la concesión de claves, un mecanismo alternativo de control de acceso a las claves KMS utilizado para delegar permisos para operaciones criptográficas.

Una concesión de clave ^KMS3 es una delegación de permisos a un beneficiario que devuelve un token utilizado para realizar operaciones criptográficas sobre esa clave. Al crear una concesión de clave y permitir que la cuenta de la víctima utilice la clave secuestrada para el descifrado, la banda de ransomware puede devolver efectivamente la disponibilidad a sus "clientes" de pago, eludiendo las restricciones impuestas por la política de clave restringida. Una concesión de clave KMS permitiría a la víctima acceder a la clave KSM y comenzar el proceso de recuperación de sus datos cifrados.

¿Podría AWS salvarte de un ataque de ransomware Cloud?

Teniendo en cuenta las ideas anteriores, cuando nos enfrentamos a un ataque de ransomware en un entorno nativo de la nube, es razonable preguntarse dónde entra en juego el "modelo de responsabilidad compartida". A continuación se presentan algunas consideraciones que vale la pena examinar.

El primer escenario para una intervención de AWS plantea la hipótesis de que AWS podría acceder al material de claves KMS desde un HSM de AWS. Esta conjetura es tan inverosímil que parece completamente fuera del ámbito de lo posible. Es impensable que AWS pudiera recuperar una clave KMS de uno de sus HSM alojados en sus centros de datos. AWS ha hecho todo lo posible para asegurarse de que nadie pueda recuperar el material de la clave y ha hecho declaraciones públicas en ese sentido.

Los dos escenarios restantes en cualquier intervención de AWS son mucho más una cuestión abierta. La primera vía de ayuda implicaría que AWS cambiara el entorno de la víctima. No hay pruebas de que AWS pueda revertir una política de claves maliciosamente aplicada en una cuenta víctima, restaurando el acceso a una clave KMS. No hay indicios de que tengan ninguna capacidad de "mano de Dios" sobre las políticas basadas en recursos. Tampoco hay mucho incentivo para admitir públicamente la capacidad si la tuvieran.

La última opción de remediación asistida a considerar sería que AWS requisara la cuenta en la que operan los actores maliciosos. El equipo de confianza y seguridad de AWS pondrá en cuarentena y cerrará las cuentas maliciosas que infrinjan las condiciones de servicio, como las utilizadas en campañas de botnets. Sin embargo, poner en cuarentena y cerrar cuentas es muy diferente de hacerse con el control de los recursos, que sería necesario para recuperar el control sobre una clave KMS secuestrada. Aunque no está claro si AWS dispone de un proceso para hacerse con el control de las cuentas, hay indicios que sugieren que sí lo tiene.

En AWS existe un mecanismo para cambiar la dirección de correo electrónico raíz de una cuenta. Vería esto en acción si alguna vez olvidara la contraseña de su usuario raíz y perdiera el acceso al correo electrónico asociado al usuario raíz. AWS Support le pedirá que proporcione un certificado notarial de la titularidad de su cuenta antes de aceptar un cambio en la cuenta de correo electrónico raíz subyacente. Este proceso interno sugiere que AWS tiene el poder de hacerse con el control de las cuentas, no simplemente cerrarlas, sino acceder a los recursos alojados en ellas con capacidades administrativas.

Al igual que la teoríade la"mano de Dios", AWS tiene pocos incentivos para hacer pública su capacidad de confiscar cuentas. Desde el punto de vista de los defensores, sin un proceso claramente documentado para la recuperación asistida de AWS con acuerdos de nivel de servicio garantizados, la asistencia de remediación teórica de AWS no es útil. La planificación de la respuesta y recuperación ante un evento de ransomware no debe centrarse en la ayuda de AWS y no debe esperarse.

Prevención, detección y respuesta al ransomware Cloud

Partiendo de la base de que es poco probable que AWS pueda ayudar durante un ataque de ransomware, nos centramos en la base de todos los programas de seguridad, los controles preventivos y las capacidades de detección y respuesta.

SCP Restricción de claves KMS

Las mitigaciones mediante políticas de control de servicios (SCP) requieren un cierto grado de madurez en su programa de seguridad cloud , pero eso no significa que su uso no deba ser un objetivo operativo. Crear una política a medida para las claves KMS requiere comprender qué claves deben autorizarse para realizar operaciones criptográficas en sus datos y quién debe tener acceso a ellas.

Una Política de Control de Servicios (SCP) que nombre las claves KMS específicas permitidas para cifrar objetos podría ser un buen comienzo para prevenir un ataque de ransomware cloud del tipo descrito en este documento. Restringir las operaciones criptográficas a claves específicas impediría a un atacante cifrar maliciosamente objetos S3 con una clave recién creada o con una clave externa bajo su control, pero no secuestrar la política de una clave existente y aprobada.

A menudo, este tipo de SCP se combina con un patrón arquitectónico que acorrala todas las claves KMS en una única cuenta. Debería ser el patrón de diseño preferido, no solo por la resistencia al ransomware, sino también por todas las ventajas que aporta la centralización, como la auditabilidad y la rotación simplificada de claves.

El uso de este enfoque centralizado de "Fort Knox" para la gestión de claves crea el diseño de "todos los huevos en la misma cesta". También permite el enfoque de "todos los controles de seguridad en la misma cesta". Una cuenta central de gestión de claves permite a una organización de seguridad aplicar el principio del mínimo privilegio en el sentido más estricto, establecer una línea de base para los patrones normales de uso de claves y supervisar las transacciones anómalas.

Configuraciones de cubos S3

No todos los buckets de S3 pueden configurarse para ser fortalezas, pero merece la pena destacar los controles disponibles en S3 que pueden añadirse a la estrategia general de resistencia al ransomware.

• Bloqueo de objetos: Configuración aplicada a un bucket de S3 que impide el borrado de un objeto o de su versión.
• Versionado de objetos: Esta configuración forzará la creación de nuevos objetos, en lugar de sobrescribir los objetos cargados previamente. Cuando se combina con "Bloqueo de objetos", esta configuración puede evitar que los objetos se sobrescriban con versiones maliciosamente codificadas. Siempre que se active el versionado, asegúrese de establecer políticas para gestionar el ciclo de vida de sus objetos versionados.
• Borrado MFA: Garantiza que el bit MFA se establece en el token de sesión de la persona que llama cuando se intenta eliminar un objeto de S3. Una vez más, es probable que estos controles sean incompatibles con los datos altamente transaccionales, pero podrían ser factibles cuando se trata de proteger sus copias de seguridad sensibles. Saber qué datos tienes y dónde viven es un requisito previo para aplicar cualquiera de estas mitigaciones a nivel de Bucket.

Detección de ransomware Cloud

En este documento se describen dos posibilidades que un actor de amenazas podría utilizar para afectar a la disponibilidad de los datos alojados en S3. Nuestro actor de amenazas ficticio utilizó un método de bloqueo de política de claves para afectar a la disponibilidad de una nueva clave KMS. También se reconoce la posibilidad de utilizar el mismo modus operandi en una clave existente. O cifrar maliciosamente datos de S3 con una clave KMS externa, alojada en la cuenta controlada por el atacante. Veamos cada uno de los escenarios para discutir qué eventos en su CloudTrail podrían justificar una investigación por parte de sus respondedores.

Bloqueo con llave nueva

Si un actor de amenazas emplea esta técnica, hay dos puntos críticos sobre los que se podría alertar y responder durante la fase de explotación, al observar el uso de una nueva clave KMS e ingerir los eventos que rodean la actualización de la política de claves. Si su organización tiene una visión clara de qué claves deben utilizarse para el cifrado, el uso de claves KMS no aprobadas debería hacer saltar las alarmas. Además, la actualización de la política de claves para incluir una de las claves de condición global mencionadas en este documento también debería justificar un seguimiento.

Bloqueo con llave existente

Un actor de amenazas puede optar por centrar sus esfuerzos en afectar a una clave KMS existente. Esto limita las posibilidades de detección durante la fase de explotación. Aun así, se pueden crear alertas personalizadas para notificar cuando la política de claves se actualiza para incluir una de las claves de condición global mencionadas en este documento, lo que podría significar que se ha producido un ataque de ransomware cloud.

Cifrado con clave KMS externa

Aunque este escenario no se detalla en este documento, sigue siendo un mecanismo viable para el cifrado malicioso de datos. Los equipos de operaciones de seguridad querrían ser notificados cuando se realicen operaciones de cifrado con claves KMS que no estén alojadas en una cuenta bajo su control.

En conclusión

Los proveedores de servicios Cloud nube ponen a disposición herramientas criptográficas que, si no están debidamente protegidas, pueden ser aprovechadas por las bandas de ransomware para afectar a la disponibilidad de los datos en la cloud. Una campaña exitosa de ransomware en la cloud utiliza servicios cloud de cloud nube para cifrar datos con rapidez y mecanismos de control de acceso incorporados para bloquear a la víctima de datos empresariales críticos.

La elaboración de patrones arquitectónicos centralizados para la gestión de claves es el primer paso para prevenir el ransomware cloud. La gestión centralizada de claves permite tanto una prevención más eficaz del ransomware como una imagen más coherente de cómo es un patrón criptográfico normal en su entorno de cloud .

Aunque lo ideal es una postura preventiva, es poco probable que la mayoría de las organizaciones dispongan de estos controles arquitectónicos desde el primer día. Además, corresponde a todas las organizaciones, incluso a las que tienen entornos muy restrictivos, planificar el día en que fallen sus barandillas. Por lo tanto, detectar si los datos cloud se ven afectados por el ransomware debería ser la prioridad principal. Estas estrategias de detección variarán sutilmente en función de la técnica utilizada por el agente de la amenaza, pero se basan en el concepto de saber qué significa externo para su entorno de cloud , ya sea en la supervisión de la concesión de acceso externo, el uso de claves externas o las declaraciones condicionales en la política.

---

Referencias:

¹ Técnicas de cifrado de ransomware: https://medium.com/@tarcisioma/ransomware-encryption-techniques696531d07bb9

² Rescate en Cloud - Spencer Gietzen (DEF CON Cloud Village): https://www.youtube.com/watch?v=8QdZ2- sAQFs&list=PL5944c_fOMYn2cQQuQe23gtqZfHWzyrPn&index=3

³ Subvenciones en AWS KMS: https://docs.aws.amazon.com/kms/latest/developerguide/grants.html S3 Ransomware Parte 1: Vector de ataque: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/ S3 Ransomware Parte 2: Prevención y defensa: https://rhinosecuritylabs.com/aws/s3-ransomware-part-2- prevention-and-defense/