Investigadores de seguridad han descubierto una nueva campaña masiva denominada TruffleNet que explota credenciales robadas de Amazon Web Services (AWS) para abusar del servicio Amazon SES (Simple Email Service). El objetivo es ejecutar operaciones de correo electrónico malicioso, en particular fraudes de tipo Business Email Compromise (BEC), utilizando una infraestructura masiva que involucra más de 800 hosts.
TruffleNet: BEC con Apoyo de Infraestructura AWS
Esta campaña representa una evolución del BEC, ya que los atacantes aprovechan servicios cloud legítimos y tokens robados para lograr una alta tasa de entrega y credibilidad del fraude.
Mecanismo de Abuso de SES
- Robo y Validación de Claves: Los atacantes obtienen claves de AWS (clave de acceso/secreto) mediante filtraciones o escaneo de repositorios (utilizando herramientas legítimas como TruffleHog ). Luego validan el poder de la clave usando las API GetCallerIdentityy GetSendQuotade SES para determinar su capacidad de envío.
- Falsificación con DKIM: Una vez autorizados, crean nuevas identidades de correo en SES, utilizando claves DKIM obtenidas de sitios web comprometidos (ej., WordPress). Esto les permite enviar correos altamente creíbles desde dominios que parecen legítimos con altísima tasa de entrega.
- Escala y Automatización: La infraestructura comprometida (más de 800 servidores) está configurada con herramientas como Portainer (orquestador de contenedores) para automatizar y escalar el envío de los correos de fraude.
- Ataque BEC Observado: Una campaña se dirigió al sector de petróleo y gas, enviando una factura falsa solicitando un pago de $50,000 USD, usando un dominio typosquatted ( zoominfopay[.]com) que imitaba un proveedor legítimo.
Por Qué es Crítico (IaaS Malicioso)
- Baja Huella Maliciosa: Los atacantes utilizan servicios cloud legítimos (AWS SES) y hosts con pocos rastros de reputación negativa, lo que evade muchos filtros tradicionales que buscan botnets reconocidas.
- Modelo IaaS: El uso de Portainer y contenedores sugiere que el adversario adoptó un modelo de “infraestructura como servicio malicioso” (IaaS) para sus campañas de fraude, similar a operaciones legítimas de DevOps.
- Falla de Monitoreo: El vector de riesgo ya no es solo el endpoint o el correo, sino el compromiso de servicios en la nube utilizada como plataforma de fraude.
Recomendaciones
Refuerzo de AWS IAM y SES
- Rotación y Auditoría: Rotar las claves de acceso de AWS periódicamente. Habilitar registros de uso de API relacionados con SES y alertas sobre llamadas a GetCallerIdentityy GetSendQuota.
- Menor Privilegio: Aplicar el principio de mínimo privilegio en IAM: reducir permisos para enviar correos y limitar quién puede crear identidades de SES.
- Monitoreo de Creación de Identidades: Monitorizar el uso de SES y alertar cuando se creen nuevas identidades de envío, se agrega DKIM de dominios externos o se cambian metadatos de cuentas.
- Escaneo de Secretos: Usar escáneres (como TruffleHog) para detectar credenciales de AWS publicadas o fugas dentro de repositorios internos, almacenamiento de objetos o registros.
Detección de BEC y Concientización
- No Asumir Confianza: No asumir que un correo enviado desde un proveedor conocido (AWS SES) es seguro. Implementar una verificación estricta de dominios y validar el remitente.
- DMARC/DKIM/SPF: Asegurar la implementación y el monitoreo estricto de políticas DMARC/DKIM/SPF.
- Formación BEC Avanzada: Implementar formación de phishing enfocada en BEC avanzada: los empleados deben sospechar de facturas inesperadas, cambios de canal de pago y dominios typosquatted (levemente distintos).
- Correlación Cloud-Email: Correlacionar alertas de seguridad en la nube (ej., volúmenes de envío inusuales de SES) con actividad de correo interno, ya que un movimiento lateral en AWS seguido de envío masivo puede indicar un compromiso de IAM.
