Abuso legítimo de la infraestructura: la técnica de phishing que elude la autenticación del correo electrónico

Imagínate lo siguiente: un correo electrónico de phishing llega directamente a la bandeja de entrada de una empresa. La pasarela de seguridad lo analiza y le da el visto bueno. Sender Policy Framework (SPF): aprobado. DomainKeys Identified Mail (DKIM): aprobado. Domain-based Message Authentication, Reporting, and Conformance (DMARC): aprobado. El correo electrónico es extremadamente malicioso, pero ha superado sin problemas todas y cada una de las capas de defensa. ¿Por qué? Porque se envió a través de una infraestructura en la nube de buena reputación en la que tus herramientas de seguridad del correo electrónico ya confían ciegamente.

Esta estrategia se conoce como «abuso de infraestructuras» o, en el caso del phishing por correo electrónico, como «living off the land». En lugar de crear dominios sospechosos y efímeros, los atacantes canalizan sus campañas a través de plataformas de envío de correo electrónico en la nube ya consolidadas y de gran reputación.

Se trata de una tendencia muy extendida. El Informe sobre amenazas de Cloudflare para 2026 destaca que las plataformas de correo electrónico en la nube son vectores muy explotados para el phishing sofisticado y la distribución de malware, y señala que los actores estatales están incorporando activamente esta técnica a sus estrategias. Los investigadores de seguridad de Kaspersky también han detectado un aumento sostenido y significativo de los ataques de phishing enviados a través de las principales infraestructuras en la nube a partir de enero de 2026.

¿Qué se entiende por «uso indebido de la infraestructura legítima»?

El abuso de infraestructura legítima es la práctica de canalizar campañas de phishing a través de plataformas de envío de correo electrónico en la nube consolidadas y de buena reputación, en lugar de utilizar infraestructura creada específicamente por los atacantes. En el ámbito de la seguridad de los terminales, la expresión «living off the land» se refiere a que los hackers utilizan herramientas nativas y de confianza del sistema, como PowerShell, para ejecutar ataques, en lugar de instalar malware evidente. Esto dificulta enormemente la detección, ya que la propia herramienta forma parte del sistema. El abuso de infraestructura legítima aplica exactamente esa misma lógica al envío de correo electrónico.

En lugar de comprar un dominio con errores tipográficos o poner en marcha un servidor de correo malicioso dedicado, los estafadores se apropian indebidamente o alquilan espacio en plataformas de correo electrónico transaccional en la nube ya consolidadas. Plataformas como Amazon SES, SendGrid y Mailjet son blanco frecuente de estos ataques, no porque su seguridad interna sea débil, sino porque su impecable reputación como remitentes es el activo más valioso para un atacante.

Los autores de amenazas suelen obtener acceso mediante dos métodos principales:

• Robo de credenciales y claves API: Los atacantes roban o compran claves API válidas y credenciales de cuentas de correo electrónico en la nube ya existentes. Según Abnormal AI, estas se comercializan habitualmente en foros de ciberdelincuencia por tan solo 15 dólares.
• Dominios de envío comprometidos: los atacantes se apropian de un dominio empresarial ya existente que cuenta con un proveedor de servicios de correo electrónico en la nube (ESP) configurado como remitente autorizado, lo que le permite heredar directamente la reputación de remitente acumulada a lo largo de los años.

Por qué la autenticación del correo electrónico no lo impide

La brecha de autenticación

Protocolos como SPF, DKIM y DMARC se crearon para responder a una pregunta fundamental: ¿procede este correo electrónico de un remitente autorizado para este dominio? Cuando un atacante secuestra una cuenta legítima en la nube o se aprovecha de la configuración del proveedor de servicios de correo electrónico (ESP) autorizado de un dominio, la respuesta técnica es un rotundo sí.

El correo electrónico supera la verificación SPF porque la dirección IP del proveedor de servicios en la nube figura explícitamente en el registro SPF del dominio. Supera la verificación DKIM porque la plataforma firma el mensaje con la clave criptográfica adecuada del dominio. Por último, supera la verificación DMARC porque ambos protocolos coinciden perfectamente.

No se trata de un error ni de un fallo de DMARC. Los protocolos están haciendo exactamente lo que se diseñaron para hacer. El problema es que verificar si un remitente está autorizado es algo completamente distinto a verificar si la cuenta sigue bajo el control del propietario real del dominio.

Por qué falla el bloqueo basado en la reputación de IP

Las herramientas de seguridad tradicionales se basan en gran medida en las puntuaciones de reputación de las direcciones IP. Si una dirección IP envía spam, se bloquea. Sin embargo, frente al uso indebido de la infraestructura, este enfoque falla por completo.

Las direcciones IP de origen pertenecen a grandes proveedores de servicios en la nube que gestionan miles de millones de correos electrónicos corporativos legítimos cada día. Si una pasarela de correo electrónico segura (SEG) bloqueara esos rangos de IP para detener una campaña de phishing, provocaría unas tasas catastróficas de falsos positivos y bloquearía correos electrónicos empresariales importantes de miles de empresas que no tienen nada que ver con el asunto. El atacante se oculta entre una multitud enorme y de confianza.

Por qué las pasarelas de correo electrónico seguras no dan la talla

La mayoría de los sistemas de filtrado de correo electrónico (SEG) evalúan el correo entrante basándose en la antigüedad del dominio, los enlaces maliciosos conocidos y las firmas de los archivos adjuntos. En estos ataques, el dominio remitente está limpio, su reputación es impecable y la puntuación de autenticación es del 100 % perfecto.

Además, los atacantes neutralizan los escáneres de enlaces aprovechando las técnicas de phishing de redireccionamiento abierto integradas en los propios proveedores de servicios de correo electrónico (ESP). Utilizan las URL de seguimiento de clics nativas de la plataforma, que las pasarelas de correo electrónico incluyen de forma generalizada en sus listas de permitidos. La pasarela analiza el enlace de seguimiento, que goza de gran confianza, y deja pasar el mensaje; el destino malicioso solo se activa mediante un redireccionamiento en el momento exacto en que el usuario hace clic en el enlace.

En otras variantes, los estafadores eluden por completo el análisis de URL enviando mensajes de suplantación de identidad empresarial (BEC) sin enlaces. Adjuntan archivos PDF «limpios» que contienen datos de pago sin formato o insertan hilos de correo electrónico falsificados sobre modificaciones en las facturas, y se valen de técnicas de ingeniería social ocultas en un correo electrónico autenticado.

Cómo se manifiesta en la práctica el abuso legítimo de la infraestructura

En la práctica, estas campañas se basan en señuelos que transmiten una gran urgencia y generan mucha confianza. Entre los argumentos más habituales se encuentran las notificaciones falsas de firmas electrónicas que suplantan plataformas como DocuSign, las alertas urgentes sobre la seguridad de las cuentas y el fraude en las facturas dirigido a los departamentos de contabilidad.

El motivo de estos ataques radica directamente en una mala gestión de las credenciales. Los hackers recopilan habitualmente claves API a partir de configuraciones expuestas de AWS Identity and Access Management (IAM) en repositorios públicos de GitHub o en archivos .env que se han subido por error.

Cuando todo encaja, los resultados son sorprendentes. Un incidente real documentado por IRONSCALES en abril de 2026 puso de manifiesto un correo electrónico de phishing que obtuvo una puntuación perfecta de 100 sobre 100 en la autenticación compuesta de Microsoft. El correo se hacía pasar por una herramienta de gestión de proyectos muy utilizada y superó sin problemas las verificaciones de SPF, DKIM y DMARC, ya que se envió a través de la configuración legítima de un proveedor de servicios de correo electrónico (ESP) en la nube de un dominio comprometido.

Mensaje recibido: Resultados de la autenticación

Conclusión principal: Autenticado, pero no legítimo. (Basado en un incidente documentado por IRONSCALES, abril de 2026).

Lo que realmente ayuda: una defensa realista

Para ser totalmente sinceros: no existe ninguna herramienta que por sí sola pueda detener por completo este tipo de ataques. Cualquiera que afirme que DMARC por sí solo puede bloquear automáticamente el uso indebido de la infraestructura está exagerando. Sin embargo, un enfoque realista y de múltiples capas reduce el riesgo de forma significativa.

1. Supervisión de DMARC: tu sistema de alerta temprana

Aunque un correo electrónico de phishing autenticado superará la validación, los informes agregados de DMARC (RUA) ofrecen una visibilidad total de tu ecosistema de salida. Si un atacante roba tus claves API y empieza a enviar spam a través de una plataforma en la nube utilizando tu dominio, ese aumento masivo del volumen aparecerá al instante en tus informes.

La revisión periódica de los informes DMARC (RUA) te permite detectar a tiempo cualquier uso no autorizado de la infraestructura, antes de que se produzca un daño generalizado a la reputación. Para los equipos que desean una detección automatizada, el DMARC Analyzer de PowerDMARC ofrece una supervisión continua y alertas de anomalías en tiempo real para señalar las fuentes de envío inesperadas en el momento en que aparecen.

2. Aplicación de DMARC: protege el tráfico saliente de tu dominio

Configurar tu política DMARC con el valor «p=reject» garantiza que, si un atacante intenta suplantar tu dominio a través de canales no autorizados ajenos a tu infraestructura en la nube aprobada, los mensajes se bloqueen de inmediato. Además, una aplicación estricta de la política convierte tu dominio en un objetivo mucho más difícil de atacar. Los estafadores que buscan vectores fáciles para abusar de la infraestructura prefieren objetivos más vulnerables que utilicen una política débil del tipo «p=none».

3. Seguridad de las credenciales ESP: Cerrar el punto de entrada

La estrategia más directa para prevenir el phishing de credenciales consiste en proteger las claves de tu infraestructura de envío.

• Aplicar la autenticación multifactorial (MFA) en todas las cuentas de administrador del ESP.
• Utiliza claves API con un ámbito de aplicación muy limitado, restringidas a los permisos mínimos necesarios.
• Renueva periódicamente las claves API de producción.
• Implementa el análisis automático de código para garantizar que los datos confidenciales nunca se suban a repositorios públicos.
• Revisa semanalmente los paneles de control de uso de tu ESP para detectar picos de volumen inusuales o configuraciones de remitentes desconocidos.

4. Seguridad del correo electrónico basada en el comportamiento

Dado que las puertas de enlace tradicionales no son eficaces frente a una infraestructura de confianza, necesitas una capa integrada de seguridad del correo electrónico en la nube (ICES). Las herramientas de seguridad basadas en el comportamiento y en la inteligencia artificial analizan el contexto, en lugar de limitarse únicamente a la reputación. Tienen en cuenta el historial de comunicaciones, los volúmenes habituales de envío y los patrones lingüísticos. Si una cuenta totalmente autenticada envía de repente una solicitud de factura anómala a un destinatario inusual, las herramientas de seguridad basadas en el comportamiento pueden detectarla y ponerla en cuarentena.

5. Formación específica para sensibilizar a los usuarios

Si un correo electrónico de phishing supera todas las comprobaciones técnicas, todo depende de la defensa humana. Hay que formar a los empleados para que reconozcan que un correo electrónico con una imagen de marca impecable, una dirección de remitente correcta y sin ninguna advertencia técnica puede seguir siendo una trampa si la cuenta subyacente ha sido pirateada.

Enseña a tu equipo a verificar de forma independiente cualquier orden de pago repentina o cambio en las cuentas a través de un canal de comunicación secundario y fuera de la vía habitual (como una llamada telefónica rápida). También deben revisar minuciosamente las páginas de destino finales del navegador antes de introducir sus credenciales, independientemente de lo seguro que pareciera el enlace del correo electrónico inicial.

Por último, pero no por ello menos importante, los empleados pueden utilizar simplemente un verificador de correos electrónicos de phishing para obtener un análisis instantáneo de las amenazas. Lo único que tienen que hacer es pegar el texto completo del correo electrónico, incluidas las cabeceras, para comprobar los registros de autenticación, las señales del remitente, los enlaces sospechosos, los patrones de urgencia y mucho más.

Palabras finales

El modelo de amenazas corporativas ha cambiado radicalmente. El phishing avanzado actual ya no se basa en correos electrónicos mal redactados enviados desde dominios aleatorios y sospechosos. Mediante el uso indebido de infraestructuras legítimas, los atacantes se aprovechan activamente de los servicios en la nube que utilizamos y en los que confiamos a diario, explotando la brecha existente entre la autorización del remitente y el control de la identidad real.

Tu estrategia de defensa debe adaptarse a esta realidad. Aunque los protocolos de autenticación por sí solos no resuelven el problema, vigilar de cerca tu entorno cambia por completo las reglas del juego.

Protege tu ecosistema de correo electrónico hoy mismo: ¿Quieres saber exactamente quién envía correos en nombre de tu marca? Toma el control de tu perímetro y recibe alertas en tiempo real sobre comportamientos de envío inesperados con el DMARC Analyzer de PowerDMARC.

Preguntas frecuentes

Si un correo electrónico supera las verificaciones de SPF, DKIM y DMARC, ¿por qué mi puerta de enlace de seguridad sigue dejándolo pasar?

Porque las pasarelas de seguridad están programadas para confiar precisamente en esos protocolos. Cuando un correo electrónico cumple a la perfección los tres requisitos, la pasarela considera que se trata de una comunicación legítima y autorizada por parte del propietario del dominio. Las pasarelas comprueban si la infraestructura está autorizada a enviar el correo, no quién está detrás del teclado escribiéndolo.

¿Significa esto que DMARC no funciona o que es inútil?

En absoluto. DMARC está haciendo exactamente lo que diseñamos para que hiciera: impedir que cualquier malhechor suplantara tu nombre de dominio de la nada. No puede saber si un atacante ha comprado una clave API robada o si ha secuestrado tu cuenta real en la nube. Piensa en DMARC como un cerrojo de alta tecnología: funciona a la perfección, a menos que el ladrón te robe las llaves reales de tu casa.

¿Por qué no podemos simplemente bloquear las direcciones IP desde las que se envían estos correos electrónicos de phishing?

Porque esas direcciones IP pertenecen a servicios legítimos a gran escala, como Amazon SES o SendGrid. Cada día circulan por esas mismas direcciones IP millones de correos electrónicos comerciales habituales y seguros (como recibos, confirmaciones de vuelos y restablecimientos de contraseñas). Si bloqueas ese rango de IP, bloqueas tanto el tráfico legítimo como el malicioso.

¿Cómo consiguen los hackers las credenciales de estas plataformas de correo electrónico en la nube?

Por lo general, todo se reduce a simples errores humanos. A veces, los desarrolladores dejan accidentalmente claves de API expuestas en repositorios públicos de GitHub o suben archivos como .env que contienen datos de acceso sin cifrar. Otras veces, los ciberdelincuentes simplemente compran credenciales válidas que se han filtrado en foros de ciberdelincuencia por cuatro duros, a menudo por tan solo 15 dólares.

¿Puede la formación en sensibilización de los usuarios resultar realmente útil si fallan los filtros técnicos?

Sí, pero hay que cambiar la forma de formar al personal. La formación tradicional enseña a los usuarios a buscar «señales de alerta», como direcciones de correo electrónico que parecen falsas o métricas de autenticación erróneas. En el caso del abuso de la infraestructura, esas señales de alerta no están presentes. La formación debe centrarse en puntos de control de comportamiento, como llamar por teléfono para verificar cualquier solicitud repentina y fuera de lo habitual de dinero o actualizaciones sensibles de la cuenta, por muy legítimo que parezca el correo electrónico.

• Acerca de
• Últimas publicaciones

Milena Baghdasaryan

Especialista en contenidos de PowerDMARC

Milena es una hábil escritora y creadora de contenidos con más de 7 años de experiencia en la elaboración de contenidos atractivos sobre TI, ciberseguridad, eventos virtuales y mucho más. Tiene un historial probado de entrega de trabajos de alta calidad para revistas internacionales y se ha graduado en prestigiosas instituciones como la New York University Abu Dhabi, UWC China y el College of Europe.

Últimos mensajes de Milena Baghdasaryan (ver todos)

• Seguridad del correo electrónico en Latinoamérica: Situación actual de DMARC y la autenticación del correo electrónico en Latinoamérica en 2026 - 30 de junio de 2026
• Abuso de infraestructuras legítimas: la técnica de phishing que elude la autenticación del correo electrónico - 30 de junio de 2026
• Cómo vender servicios de seguridad del correo electrónico: una guía para los MSP - 24 de junio de 2026