Cuando Amazon SES se convierte en motor de phishing sofisticado

En las últimas semanas se ha observado un fenómeno particularmente preocupante: actores maliciosos están aprovechando el servicio legítimo de Amazon Simple Email Service (SES) como infraestructura para campañas de phishing de alta calidad. El valor estratégico de SES para los atacantes no es accidental: al usar una plataforma de envío confiable y verificada, los correos maliciosos pueden sortear controles habituales y llegar a las bandejas de entrada con encabezados y firmas que parecen legítimos.

La raíz del problema es la exposición de credenciales en texto plano. Repositorios públicos, archivos .env, imágenes Docker y copias de seguridad mal protegidas siguen filtrando claves de acceso a AWS, y los delincuentes han automatizado su búsqueda con herramientas que escanean grandes volúmenes de datos públicos. Ese mismo proceso, una vez automatizado, permite comprobar permisos, validar límites de envío y utilizar la cuenta comprometida para difundir miles de mensajes en poco tiempo.

El resultado técnico es claro: cuando el remitente es Amazon SES, protocolos como SPF, DKIM o DMARC dejan de ser un obstáculo práctico para el distribuidor de la estafa, y la opción de bloquear direcciones IP se vuelve ineficaz porque implicaría bloquear parte del correo legítimo que pasa por la misma infraestructura en la nube. Además, los atacantes están alojando páginas de phishing en servicios de AWS, lo que añade una capa extra de credibilidad y dificulta la detección por listas negras tradicionales.

Los ataques observados ya han trascendido el phishing genérico: los delincuentes fabrican hilos de correo completos, plantillas HTML que replican flujos de inicio de sesión reales y documentos falsos para engañar a departamentos financieros con facturas fraudulentas. Esta evolución hacia BEC (compromiso de correo empresarial) y páginas de suplantación hospedadas en la nube obliga a repensar la defensa, que no puede depender solo de filtros basados en reputación.

Qué deben hacer los equipos técnicos de inmediato: eliminar claves de acceso de uso prolongado, rotarlas con frecuencia y sustituirlas por roles temporales cuando sea posible; aplicar el principio de menor privilegio para cada identidad; forzar la autenticación multifactor (MFA) en todas las cuentas con permisos administrativos; y restringir el acceso por dirección IP o rangos específicos para operaciones sensibles. En paralelo, activar registros y alertas en CloudTrail y CloudWatch para detectar patrones anómalos de uso de SES, y fijar límites operativos que requieran revisión humana antes de aumentos bruscos en el volumen de envío.

En el plano del ciclo de desarrollo, es imprescindible incorporar escaneo de secretos en los pipelines y prevenir la publicación accidental de claves. Herramientas de detección en el propio repositorio —como la solución pública que inspira muchas de estas campañas— ayudan tanto a evitar fugas como a reaccionar rápido cuando ocurren. Para más contexto sobre esa herramienta de detección puedes revisar su repositorio oficial en https://github.com/trufflesecurity/truffleHog, y para recomendaciones de gestión de identidades en AWS conviene consultar las buenas prácticas de IAM en https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html.

También hay medidas organizativas que reducen el impacto: establecer procesos de verificación secundarios para pagos y órdenes (confirmación por teléfono o canales fuera del correo), formar a equipos financieros y de atención al cliente en la detección de señales de ingeniería social, y desplegar soluciones de seguridad de correo que realicen análisis dinámico de enlaces y contenido al hacer clic (click-time URL scanning) en lugar de confiar únicamente en firmas estáticas.

Responsabilidad compartida y presión sobre los proveedores son dos piezas clave: las empresas deben endurecer sus prácticas internas, pero los proveedores de nube también pueden mitigar el abuso mejorando la detección de anomalías en el uso de servicios como SES y aplicando controles automáticos cuando un conjunto de credenciales muestra comportamientos atípicos. Un informe técnico reciente documenta este patrón de abuso y aporta trazas que ilustran la sofisticación actual; para profundizar en esa investigación puede consultarse el análisis publicado por Kaspersky en https://securelist.com/amazon-ses-phishing-and-bec-attacks/119623/.

En suma, la facilidad con la que un servicio legítimo puede ser reciclado para campañas maliciosas obliga a combinar controles técnicos (rotación de claves, MFA, least privilege, monitoreo), prácticas de desarrollo seguras (escaneo de secretos, revisión de artefactos) y políticas operativas (verificación de pagos, formación). Ignorar cualquiera de estas capas deja a organizaciones y usuarios expuestos a fraudes que hoy se apoyan en la credibilidad de la infraestructura en la nube.