Dos equipos de investigación independientes han mapeado ahora el mismo esquema de ataque desde ángulos distintos. El grupo Securelist de Kaspersky documentó un fuerte aumento de campañas de phishing y compromiso de correo empresarial que abusan de Amazon Simple Email Service a comienzos de 2026, mientras que la firma de seguridad en la nube Wiz rastreó por su cuenta la mecánica técnica: cómo una clave de acceso de AWS filtrada se convierte en una plataforma de phishing funcional en cuestión de minutos. Ninguno de los dos equipos encontró una falla en SPF, DKIM o DMARC. Encontraron algo más incómodo: atacantes enviando correo a través de infraestructura que pasa legítimamente los tres controles, porque es la infraestructura propia de Amazon, alquilada con credenciales robadas de otra persona.
De una Clave Filtrada a una Cuota de Envío en Producción
El esquema comienza con un reconocimiento que no tiene nada que ver con el correo electrónico. Bots automatizados, a menudo construidos sobre herramientas de escaneo de secretos de código abierto, rastrean repositorios públicos de GitHub, archivos .env expuestos, imágenes de Docker y buckets de S3 mal configurados buscando claves de acceso IAM de AWS que los desarrolladores dejaron atrás. Una vez que aparece una clave, los atacantes verifican qué puede hacer con una simple llamada GetCallerIdentity. Un nombre de clave que contiene “ses” suele bastar para indicar que fue creada para el servicio de correo de Amazon.
El siguiente paso es el que convirtió esto de una molestia en un arma a escala. Amazon limita las cuentas nuevas de SES en un modo sandbox con topes de envío estrictos hasta que un humano solicita acceso a producción. Los investigadores observaron a los atacantes automatizando esa solicitud, disparando llamadas PutAccountDetails en todas las regiones de AWS con segundos de diferencia entre ellas, llevando la cuenta a modo de producción región por región y desbloqueando una cuota predeterminada de decenas de miles de correos por día, multiplicada por la cantidad de regiones que activen a la vez.
Dos Señuelos, un Solo Sobre de Confianza
Con el acceso de envío asegurado, Kaspersky documentó dos tipos de campaña distintos montados sobre la misma infraestructura. La primera suplanta servicios de firma electrónica, más comúnmente Docusign, pidiendo al destinatario que haga clic para revisar un documento. El enlace resuelve a amazonaws.com, infraestructura que la mayoría de los usuarios y muchos filtros de seguridad tratan como inherentemente segura, antes de redirigir a una página de robo de credenciales. La segunda es una jugada de compromiso de correo empresarial más paciente: un hilo fabricado para parecer una conversación en curso entre un empleado y un proveedor sobre una factura pendiente, enviado al equipo de finanzas del objetivo con una solicitud urgente de liberar un pago.
Por Qué la Autenticación Pasa sin Problemas
Esta es la parte que vale la pena detenerse a analizar. SPF, DKIM y DMARC existen para responder una pregunta: ¿autorizó el propietario del dominio esta infraestructura para enviar en su nombre? Nunca fueron diseñados para hacer una segunda pregunta que aquí importa igual de mucho: ¿sigue la parte que hoy tiene las claves de esa infraestructura siendo la parte en la que confía el propietario del dominio? Amazon SES es infraestructura autorizada. Una clave IAM robada no cambia ese hecho desde el punto de vista del protocolo, así que el correo enviado a través de una cuenta de SES secuestrada se autentica con la misma limpieza que el correo enviado por el dueño legítimo de la cuenta.
La investigación de Wiz añade un detalle más agudo. Los atacantes verificaron identidades nuevas en la cuenta comprometida para dominios que controlaban por completo, lo cual es esperable. Pero también encontraron atacantes reutilizando identidades de dominio que ya estaban verificadas en la cuenta antes de que fuera robada, específicamente dominios con políticas DMARC débiles o sin aplicar, lo que les permitió suplantar una marca real y previamente confiable a través de infraestructura que el propio equipo de esa marca había configurado. Bloquear los rangos de IP de envío de Amazon tampoco es una defensa viable, ya que eso derribaría enormes volúmenes de tráfico legítimo de SES usado por empresas comunes en todo el mundo.
Cerrando la Brecha en Ambos Extremos
Trate las credenciales de envío en la nube como un problema de identidad, no de correo. Limite las políticas IAM al privilegio mínimo, migre de claves estáticas de larga duración a roles de corta duración donde la automatización de SES lo permita, aplique MFA en las cuentas que administran esas credenciales, y escanee sus propios repositorios y copias de seguridad de configuración en busca de claves expuestas antes de que el bot de un atacante las encuentre primero.
Aplique DMARC con cobertura total en cada identidad de dominio que alguna vez haya verificado en un servicio de envío en la nube, no solo en su dominio principal. El hallazgo de Wiz fue específico: fueron las identidades con DMARC débil las que se reutilizaron para la suplantación. Un subdominio olvidado o una identidad heredada sin política es exactamente el tipo de cabo suelto que esta campaña está diseñada para encontrar.
Vigile la cuenta, no solo la bandeja de entrada. Una ráfaga de llamadas a la API que abarca varias regiones, una solicitud repentina de acceso a producción, o una nueva verificación de identidad que nadie del equipo inició son señales visibles mucho antes de que salga el primer correo de phishing. Esa telemetría pertenece al mismo canal de monitoreo que sus informes agregados de DMARC.
Del lado receptor, recuerde qué certifica realmente la alineación de DMARC. Confirma que la infraestructura de envío fue autorizada por un propietario de dominio en algún momento, no que el mensaje de hoy provenga de las mismas manos que fueron autorizadas originalmente. Los mensajes que superan la autenticación todavía necesitan una capa adicional de inspección de contenido y comportamiento, especialmente los que le piden a finanzas que mueva dinero.
La Conclusión
Que infraestructura confiable en la nube se convierta en una plataforma de phishing no es una idea nueva, pero la escala aquí es un recordatorio de cuánta defensa se juega ahora antes de llegar a la bandeja de entrada, en la higiene de credenciales y la cobertura de DMARC que la mayoría de los equipos nunca piensa en revisar. Un dominio con una política DMARC fuerte y prácticas IAM limpias no le deja al atacante nada con qué trabajar, incluso después de que encuentre una clave funcional.
Una cobertura completa de DMARC en cada dominio y subdominio que posee cierra exactamente el tipo de identidad reutilizada y débilmente protegida en la que se apoya esta campaña. Regístrese gratis en Excello Mail para obtener la visibilidad y las herramientas de aplicación necesarias para encontrar esas brechas antes que alguien más lo haga.