10 fallos de los filtros email: las señales sutiles que tu pasarela pasa por alto
Por CaptainDNS
Publicado el 28 de marzo de 2026
- Las pasarelas email bloquean el spam obvio pero pasan por alto los ataques sofisticados que explotan fallos sutiles en las cabeceras
- 10 indicadores precisos en las cabeceras delatan los emails maliciosos: desfase de sobre, DKIM de terceros, Reply-To divergente, cadena Received anormal y otras seis señales técnicas
- Cada indicador se deconstruye desde la perspectiva del atacante (como lo explota) y del defensor (como detectarlo)
- El análisis de cabeceras despues de la pasarela es la última linea de defensa para el 1% de emails que superan todos los filtros
Tu pasarela email muestra una tasa de bloqueo del 99,5%. El informe mensual es tranquilizador, los paneles estan en verde y tu equipo de seguridad pasa al siguiente tema. El problema se esconde en el 0,5% restante. Sobre un volumen de 200 000 emails mensuales, eso representa 1 000 mensajes no filtrados. Entre ellos, basta un solo email de spear-phishing dirigido al empleado adecuado para comprometer una cuenta privilegiada, exfiltrar datos o desencadenar un ransomware. El coste medio de una brecha iniciada por phishing alcanza los 4,8 millones de dolares (IBM, Cost of a Data Breach 2025), y el tiempo medio para detectar un compromiso por phishing es de 207 dias (IBM, 2025). Segun el informe Verizon DBIR 2025, el tiempo mediano entre la recepción de un email de phishing y el primer clic es de 21 segundos. Tus usuarios no reflexionan: reaccionan.
Las pasarelas de seguridad email (Secure Email Gateways, SEG) como Proofpoint, Mimecast, Barracuda o Microsoft Defender for Office 365 analizan el contenido, la reputación IP, las firmas conocidas y las heurísticas comportamentales. Pero comparten un angulo muerto común: las señales sutiles en las cabeceras SMTP y MIME que los atacantes sofisticados manipulan para superar los filtros sin activar ninguna alerta. Las cifras son claras: las pasarelas fallan en el 30 al 50% de las amenazas avanzadas, y el volumen de emails maliciosos que eluden los SEG ha aumentado un 105% en un año, es decir, un email malicioso cada 19 segundos que supera los filtros (Cofense, Annual State of Email Security 2026). Sin sorpresa, el 91% de los responsables de seguridad se declaran frustrados con el rendimiento de su SEG (Egress, Email Security Risk Report 2024). No es un problema teorico. En 2025, el grupo Tycoon2FA exploto fallos de enrutamiento MX y autenticación email para generar 13 millones de emails maliciosos en un solo mes, eludiendo las pasarelas de miles de organizaciones. En total, el 78% de las organizaciones han sufrido al menos una brecha email en los últimos 12 meses (Barracuda, 2025).
Este articulo disecciona 10 indicadores precisos en las cabeceras email que la mayoria de las pasarelas ignoran o subestiman. Para cada indicador, se detalla la perspectiva del atacante (como lo explota) y la del defensor (como detectarlo), con ejemplos concretos de cabeceras. Si eres ingeniero de seguridad, analista SOC, administrador email o CISO, estas 10 señales deberian formar parte de tu cuadricula de análisis post-pasarela.
Analiza tus cabeceras email
Por que los filtros email no son suficientes
Lo que las pasarelas verifican (y lo que ignoran)
Las pasarelas email modernas se basan en varias capas de filtrado. La reputación IP verifica si la dirección del servidor emisor figura en listas negras (Spamhaus, Barracuda, SpamCop). El análisis de contenido busca palabras clave sospechosas, URLs maliciosas y archivos adjuntos peligrosos. Las firmas anti-malware comparan los archivos con bases de definiciones conocidas. Las heurísticas comportamentales detectan patrones de envio masivo y anomalias estadísticas.
Esta arquitectura funciona contra el spam masivo y las campañas de phishing genéricas. Un servidor con una IP en lista negra, un email con "Haz clic aqui para recuperar tu premio" y un archivo adjunto .exe se bloquean antes de llegar a la bandeja de entrada. La tasa de bloqueo del 99% es real para este tipo de amenazas.
Pero los atacantes que apuntan a tu organización no hacen nada de eso. Envian desde IPs limpias (alquiladas en ESP legítimos), redactan mensajes creibles y manipulan las cabeceras SMTP para que el mensaje parezca un email legítimo. Dato notable: el 82,6% de los emails de phishing analizados usan ahora alguna forma de IA para la redacción (KnowBe4, Phishing Threat Trends 2025), y la tasa de clic en estos emails generados por IA alcanza el 54%, frente al 12% de los emails redactados manualmente (Brightside AI, 2025). Además, el 76,4% de los ataques de phishing contienen al menos un rasgo polimorfico, es decir, cada email enviado es ligeramente diferente para evadir las firmas estaticas (KnowBe4, 2025). La pasarela ve un email que "pasa" todos sus criterios estandar y lo deja entrar.
Lo que las pasarelas ignoran en gran medida son las señales de coherencia en las cabeceras. Un email legítimo presenta coherencia interna: el dominio del From coincide con el dominio del Return-Path y del Message-ID, la firma DKIM cubre el dominio correcto, la cadena Received es lógica y las cabeceras propietarias de la plataforma de alojamiento estan presentes. Cuando un atacante falsifica un email, reproduce las cabeceras visibles (From, Subject, Date) pero deja incoherencias en las cabeceras técnicas que solo un examen profundo revela. Las pasarelas no realizan ese examen.
La paradoja de la adaptación
Cuanto más estricto es un filtro, más se adapta el atacante. Los grupos de amenazas avanzadas (APT, operaciones de spear-phishing dirigido) prueban sistemáticamente sus emails contra las pasarelas del mercado antes de lanzar una campaña. Servicios clandestinos ofrecen "SEG testing": el atacante envia su email y recibe un informe indicando que pasarelas lo bloquean y cuales lo dejan pasar. Es un proceso iterativo. El atacante ajusta las cabeceras, el contenido y la infraestructura de envio hasta obtener una tasa de paso satisfactoria.
El resultado: los emails que llegan a la bandeja de entrada tras la pasarela no son intentos fallidos. Son los intentos más logrados, los que han sido optimizados para eludir tus defensas específicas. Es un sesgo cognitivo frecuente en los equipos de seguridad: considerar que lo que supera la pasarela es "probablemente legítimo". En realidad, es exactamente lo contrario. Lo que supera la pasarela tras un filtrado estricto es potencialmente más peligroso que el spam promedio, porque ha sido diseñado para pasar.
Este fenomeno explica por que los usuarios formados para reconocer los signos visuales del phishing siguen cayendo. Los emails que superan la pasarela ya no contienen errores ortograficos, maquetaciones aproximadas o URLs evidentes. Se parecen a emails legítimos porque han sido optimizados para ello. La única diferencia reside en las cabeceras técnicas, invisibles para el usuario final.
La última linea de defensa: el análisis post-pasarela
Por eso el análisis de cabeceras despues del filtrado es critico. Los 10 indicadores detallados en este articulo no sustituyen la pasarela: complementan la detección examinando señales que los filtros automatizados no verifican o verifican mal. Este análisis puede ser manual (para incidentes individuales), semiautomatizado (reglas de transporte Exchange/Gmail) o integrado en un SIEM para la detección a gran escala.
Los 10 indicadores que tu pasarela pasa por alto
1. Desfase Return-Path / From (desfase de sobre)
Como lo explota el atacante. El protocolo SMTP separa dos identidades distintas: el remitente de sobre (MAIL FROM, visible en la cabecera Return-Path) y el remitente mostrado (cabecera From). El atacante configura su servidor para enviar con un Return-Path que controla (bounce@atacante-infra.net) mientras muestra un From creible (direction@captaindns.com). La mayoria de los clientes email solo muestran el From. El destinatario ve un email que parece provenir de la dirección, sin sospechar que el sobre apunta a otro sitio.
Por que los filtros lo pasan por alto. Las pasarelas verifican SPF sobre el Return-Path y DKIM sobre el From, pero pocas comparan activamente ambos y alertan sobre un desfase. Un SPF pass sobre el Return-Path y un DKIM pass sobre un dominio de terceros suelen ser suficientes para dejar pasar el mensaje.
Lo que el defensor debe verificar. Comparar el dominio en Return-Path con el dominio en From. Si difieren sin razon legítima (lista de correo, ESP configurado), es una señal fuerte.
Ejemplo de cabecera:
Return-Path: <bounce-7842@atacante-infra.net>
From: "Dirección General" <direction@captaindns.com>
El desfase es visible inmediatamente: el sobre viene de atacante-infra.net, el From muestra captaindns.com. Un email legítimo enviado a traves de un ESP tendria un Return-Path conteniendo el dominio del ESP configurado en el SPF del dominio remitente, no un dominio de terceros desconocido.
Cuando el desfase es legítimo. Es normal que el Return-Path difiera del From en ciertos casos: los ESP (SendGrid, Mailgun, Amazon SES) usan su propio dominio para el Return-Path con el fin de gestionar los rebotes. Las listas de difusion reescriben el Return-Path. La clave es verificar si el dominio del Return-Path es el de un servicio conocido y configurado en el SPF del dominio del From. Un Return-Path hacia un dominio desconocido (atacante-infra.net) asociado a un From empresarial (captaindns.com) sin vinculo SPF es una señal fuerte.
2. DKIM firmado por un dominio de terceros (firma delegada)
Como lo explota el atacante. El atacante crea una cuenta en un ESP legítimo (SendGrid, Mailgun, Amazon SES) y configura DKIM para su propio dominio. Luego envia un email con un From suplantado (compta@captaindns.com). El mensaje lleva una firma DKIM válida, pero firmada por el dominio del atacante (d=atacante-marketing.com), no por captaindns.com. La pasarela ve "dkim=pass" y considera el mensaje como autenticado.
Por que los filtros lo pasan por alto. Las pasarelas verifican que la firma DKIM es tecnicamente válida (la clave pública coincide, el hash del cuerpo es correcto). Pero la mayoria no verifica si el dominio firmante (d=) corresponde al dominio del From. Eso es el papel del alineamiento DMARC, y muchas organizaciones aun no han desplegado DMARC en modo estricto.
Lo que el defensor debe verificar. En la cabecera DKIM-Signature, comparar el campo d= con el dominio del From. Si no corresponden, el email está firmado por un tercero que no tiene autoridad sobre el dominio mostrado.
Ejemplo de cabecera:
DKIM-Signature: v=1; a=rsa-sha256; d=atacante-marketing.com;
s=sel2026; c=relaxed/relaxed;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Servicio Contabilidad" <compta@captaindns.com>
El d=atacante-marketing.com no corresponde al From captaindns.com. La firma es tecnicamente válida pero el alineamiento está roto.
3. SPF pass pero alineamiento DMARC fallido
Como lo explota el atacante. El atacante envia desde un servidor cuya IP está autorizada por el SPF de un dominio que controla (su propio dominio o un dominio de ESP). El MAIL FROM (sobre) usa ese dominio autorizado, lo que da un SPF pass. Pero el From (cabecera) muestra el dominio del objetivo (rh@captaindns.com). SPF pasa, DKIM está ausente o firmado por otro dominio, y DMARC falla en alineamiento. Si el dominio objetivo tiene una politica DMARC p=none, no se toma ninguna acción. Y está falla es masiva: el 84,2% de los ataques de phishing analizados pasan los controles DMARC (Egress, Email Security Risk Report 2024), en gran parte porque el 47% de los dominios email no tienen configuración DMARC (Barracuda, 2025), el 63% de los implementadores permanecen en p=none (Mailgun/Email on Acid, 2025) y solo el 4% de los dominios aplican p=reject (Valimail, 2025).
Por que los filtros lo pasan por alto. La pasarela ve spf=pass en los resultados de autenticación y atribuye una puntuación positiva. El hecho de que el alineamiento DMARC falle a menudo está infraponderado si la politica es p=none. El resultado neto: el mensaje pasa el filtrado con una "puntuación de autenticación aceptable".
Lo que el defensor debe verificar. En la cabecera Authentication-Results, buscar la combinación spf=pass con dmarc=fail. Esta combinación indica que el SPF paso sobre un dominio diferente del From, señal clásica de suplantación.
Ejemplo de cabecera:
Authentication-Results: mx.captaindns.com;
spf=pass (sender IP is 198.51.100.42)
smtp.mailfrom=bounces.atacante-esp.com;
dkim=none;
dmarc=fail (p=none dis=none) header.from=captaindns.com
El spf=pass corresponde a atacante-esp.com (sobre), no a captaindns.com (From). DMARC falla porque ningun mecanismo (SPF o DKIM) está alineado con el dominio del From. La politica p=none deja pasar.
4. Reply-To hacia un dominio diferente del From
Como lo explota el atacante. El atacante falsifica un From creible (support@captaindns.com) pero inserta un Reply-To hacia una dirección que controla (support-captaindns@protonmail.com o support@captaindns-helpdesk.com). Cuando el destinatario responde, su respuesta va hacia el atacante. Es una técnica terriblemente eficaz para el BEC (Business Email Compromise), que ha causado 55 500 millones de dolares de perdidas acumuladas en diez años (FBI IC3, 2024). El primer email no contiene ni enlace ni archivo adjunto, lo que evita toda detección por análisis de contenido.
Por que los filtros lo pasan por alto. El Reply-To es una cabecera informativa, no un mecanismo de autenticación. Las pasarelas generalmente no comparan el dominio del Reply-To con el del From. Un email sin URL sospechosa ni archivo adjunto, con un SPF pass y un contenido textual limpio, supera los filtros sin dificultad.
Lo que el defensor debe verificar. Comparar el dominio de la cabecera Reply-To con el del From. Un desfase hacia un dominio gratuito (Gmail, ProtonMail, Outlook.com) o un dominio similar (typosquatting) es una señal fuerte de BEC.
Ejemplo de cabecera:
From: "Jean Dupont - DAF" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Transferencia urgente - factura proveedor
El From muestra una dirección interna creible. El Reply-To redirige hacia una cuenta ProtonMail que el atacante controla. Si el destinatario responde sin verificar, la conversación continua con el atacante.
Variantes avanzadas. Los atacantes más sofisticados no usan un dominio gratuito evidente. Registran un dominio de typosquatting cercano al dominio objetivo: captaindns-support.com, captaindns.net, captaindnss.com. Estos dominios son más difíciles de detectar en una lectura rapida del Reply-To. Otra variante consiste en usar un subdominio engañoso: captaindns.service-desk.com (el dominio real es service-desk.com, no captaindns). Para la detección automatizada, manten una lista blanca de dominios Reply-To autorizados y marca todo lo que no figure en ella.
5. Cadena Received anormalmente corta o larga
Como lo explota el atacante. Cada servidor que procesa un email añade una cabecera Received en la parte superior de la pila. Un email legítimo atraviesa generalmente de 3 a 5 saltos (servidor del remitente, pasarela saliente, MX del destinatario, pasarela entrante, servidor de buzones). El atacante puede manipular está cadena de dos formas. Primera opción: enviar directamente desde un script hacia el MX del destinatario, produciendo una cadena con solo 1 o 2 saltos, señal de un envio no estandar. Segunda opción: inyectar cabeceras Received falsas para simular un transito por servidores legítimos, alargando artificialmente la cadena.
Por que los filtros lo pasan por alto. Las pasarelas no cuentan sistemáticamente el número de saltos ni verifican la coherencia temporal entre los Received. Un email con 8 saltos de los cuales 3 son falsificados pasa los controles estandar si las cabeceras forjadas estan bien formateadas.
Lo que el defensor debe verificar. Contar las cabeceras Received y verificar dos cosas. Primero, la coherencia temporal: las marcas de tiempo deben progresar de abajo (primer salto) hacia arriba (último salto). Un salto en el tiempo (un salto fechado antes del anterior) indica una cabecera forjada. Segundo, el número de saltos: menos de 2 o más de 7 es anormal para un email profesional estandar.
Ejemplo de cabecera (cadena sospechosa, demasiado corta):
Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.atacante.net) (45.77.200.18)
by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100
Solo 2 saltos. Sin servidor saliente, sin pasarela del remitente. El mensaje fue enviado directamente desde un nodo de envio hacia el MX de captaindns.com, señal de un envio por script, no de un servidor de mensajeria empresarial.
La técnica de las cabeceras Received forjadas. Un atacante más sofisticado inserta cabeceras Received falsas para simular un transito por servidores legítimos. Añade por ejemplo un salto Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com al fondo de la pila. La trampa: los servidores de recepción añaden las cabeceras Received en la parte superior de la pila, no en la inferior. Las cabeceras del fondo son las más antiguas y las primeras en haber sido añadidas. Una cabecera Received que afirma provenir de un servidor interno pero que se encuentra al fondo de la pila (antes del primer salto legítimo) es una cabecera forjada por el emisor. Verifica siempre la coherencia de la cadena comenzando por el fondo.
6. Ausencia de TLS en el primer salto (STARTTLS ausente)
Como lo explota el atacante. El atacante usa un servidor configurado sin soporte TLS o desactiva voluntariamente STARTTLS. El objetivo no es el cifrado en si, sino lo que revela su ausencia. Un servidor de mensajeria legítimo en 2026 soporta STARTTLS. Un servidor que envia en texto plano es probablemente un script, una herramienta de ataque o un servidor comprometido. La ausencia de TLS también puede indicar un ataque de degradación SMTP, donde un atacante intercepta la negociación TLS para forzar la transmision en texto plano.
Por que los filtros lo pasan por alto. Las pasarelas no bloquean los emails recibidos sin TLS. El protocolo SMTP está diseñado para funcionar en texto plano con TLS como extension opcional. Muchas pasarelas aceptan conexiones sin cifrar para no perder correo legítimo proveniente de servidores antiguos. El hecho de que el primer salto sea en texto plano no es un criterio de filtrado estandar.
Lo que el defensor debe verificar. En la primera cabecera Received (la más baja en la pila), buscar la mención with ESMTPS (conexion TLS) frente a with SMTP o with ESMTP (conexion en texto plano). Un email profesional en 2026 deberia siempre transitar con TLS activado en el primer salto.
Ejemplo de cabecera:
Received: from send-node.atacante.net (45.77.200.18)
by mail-gw.captaindns.com with SMTP;
Thu, 27 Mar 2026 09:15:20 +0100
La mención with SMTP (sin la S de ESMTPS) indica una conexion en texto plano. Un servidor de mensajeria empresarial legítimo tendria with ESMTPS o with TLS. Esta ausencia de cifrado es una señal debil pero significativa cuando se combina con otros indicadores.
7. X-Mailer o User-Agent sospechoso
Como lo explota el atacante. Los clientes de correo y los servidores insertan una cabecera X-Mailer o User-Agent que identifica el software utilizado. Los atacantes usan scripts Python (biblioteca smtplib o aiosmtplib), herramientas de envio masivo (GoPhish, King Phisher, Social Engineering Toolkit) o frameworks propios. Algunos atacantes omiten está cabecera (lo que ya es una señal), otros la falsifican para imitar un cliente legítimo (Outlook, Thunderbird). Las falsificaciones suelen ser imperfectas: una version inexistente, un formato de cadena incoherente o un X-Mailer que no coincide con las demas cabeceras presentes.
Por que los filtros lo pasan por alto. El X-Mailer no es una cabecera estandarizada por las RFC. Las pasarelas no lo consideran un criterio de seguridad y no mantienen una base de firmas de clientes maliciosos. Un email enviado desde GoPhish con un X-Mailer falsificado Microsoft Outlook 16.0 pasa los filtros si el contenido y la reputación IP son limpios.
Lo que el defensor debe verificar. Buscar la cabecera X-Mailer o User-Agent. Un User-Agent Python (Python/3.11 aiosmtplib/2.0) es una señal fuerte. La ausencia total de X-Mailer en un email supuestamente procedente de Outlook es sospechosa. Una version de Outlook que no existe (por ejemplo Microsoft Outlook 17.5 cuando la última version es 16.x) delata una falsificación.
Ejemplo de cabecera:
X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "Servicio IT" <it-support@captaindns.com>
Subject: Actualización obligatoria de tu contraseña
Un email de "actualización de contraseña" enviado desde un script Python. Ningun servicio IT legítimo envia emails criticos a traves de un script Python con aiosmtplib. Esta cabecera delata una herramienta de ataque o un test de phishing interno.
8. Message-ID con dominio incoherente
Como lo explota el atacante. La cabecera Message-ID es un identificador único generado por el servidor de envio. Contiene tipicamente un hash o un identificador aleatorio seguido del dominio del servidor que lo genero. El atacante que suplanta el From @captaindns.com pero envia desde su propio servidor genera un Message-ID con su propio dominio o un identificador genérico. Este desfase entre el dominio del From y el dominio en el Message-ID revela la infraestructura real del atacante.
Por que los filtros lo pasan por alto. El Message-ID se usa para el seguimiento de hilos de conversación y la deduplicación, no para la seguridad. Las pasarelas no comparan el dominio del Message-ID con el dominio del From. Es una cabecera técnica que pocos sistemas de filtrado analizan desde el angulo de la coherencia.
Lo que el defensor debe verificar. Extraer el dominio despues del @ en el Message-ID y compararlo con el dominio del From. Un desfase indica que el mensaje fue generado por un servidor que no pertenece al dominio mostrado.
Ejemplo de cabecera:
Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.atacante.net>
From: "Recursos Humanos" <rh@captaindns.com>
El Message-ID revela el servidor real: vps-node-14.atacante.net. Un email legítimo de captaindns.com tendria un Message-ID conteniendo captaindns.com o el dominio del ESP utilizado (por ejemplo amazonses.com si la organización usa Amazon SES).
9. Cabeceras X-MS-Exchange o X-Google ausentes
Como lo explota el atacante. Las grandes plataformas de mensajeria insertan cabeceras propietarias específicas. Microsoft 365 añade X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator y otras. Gmail añade X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source. Cuando un email afirma venir de un dominio alojado en Microsoft 365 pero no contiene ninguna de estas cabeceras, no ha transitado por la plataforma Microsoft. El atacante que falsifica el From @captaindns.com (dominio alojado en M365) pero envia desde su propio servidor no puede reproducir estas cabeceras propietarias de manera creible.
Por que los filtros lo pasan por alto. Las pasarelas de terceros (no Microsoft, no Google) no conocen la lista de cabeceras propietarias esperadas para cada plataforma. Incluso las pasarelas integradas (Defender, Gmail) no verifican sistemáticamente la coherencia entre el dominio From y la presencia de las cabeceras esperadas de la plataforma de alojamiento.
Lo que el defensor debe verificar. Identificar la plataforma de alojamiento del dominio del From (M365, Google Workspace, otra). Verificar que las cabeceras propietarias correspondientes estan presentes. Un email @captaindns.com (alojado en M365) sin ninguna cabecera X-MS-Exchange-* no ha transitado por Microsoft 365.
Ejemplo de cabecera (email sospechoso, From M365 pero sin cabeceras Exchange):
From: "Dirección Financiera" <daf@captaindns.com>
To: contabilidad@captaindns.com
Subject: Validación urgente - transferencia internacional
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.atacante.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Ninguna cabecera X-MS-Exchange-*, ningun X-MS-Has-Attach, ningun X-OriginatorOrg. Si captaindns.com está alojado en Microsoft 365, este email no ha transitado por la plataforma. Es una falsificación enviada desde un servidor externo.
10. Content-Type multipart con archivo adjunto .html encapsulado
Como lo explota el atacante. El atacante encapsula una pagina HTML de robo de credenciales (credential harvesting) en el cuerpo MIME del mensaje. A diferencia de un archivo adjunto clásico (.exe, .zip) que activa las alertas, un archivo .html a menudo se considera inofensivo por las pasarelas. Cuando el usuario abre el archivo adjunto HTML, su navegador carga una pagina de inicio de sesión falsa que imita Microsoft 365, Google Workspace u otro servicio. Las credenciales introducidas se envian al servidor del atacante. La pagina HTML puede funcionar completamente offline (sin descarga de recursos externos), lo que dificulta la detección por los sandboxes.
Por que los filtros lo pasan por alto. Los archivos HTML no son ejecutables y no contienen código malicioso en el sentido tradicional (sin shellcode, sin macro). Las pasarelas que analizan archivos adjuntos se concentran en formatos de riesgo (.exe, .docm, .xlsm, .js, .vbs). Un archivo HTML es contenido web estatico, y muchos filtros lo dejan pasar. Algunas pasarelas analizan las URLs en el HTML, pero si la pagina funciona offline con JavaScript embebido, no hay URL que bloquear en el momento de la entrega.
Lo que el defensor debe verificar. En las cabeceras MIME, buscar una parte con Content-Type: text/html y Content-Disposition: attachment. La combinación HTML + attachment es una señal fuerte. Analizar el contenido del archivo HTML: la presencia de etiquetas <form>, <input type="password"> o de JavaScript ofuscado en un archivo adjunto HTML es casi con certeza maliciosa.
Ejemplo de cabecera:
Content-Type: multipart/mixed;
boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"
------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hola, por favor consulta el documento de seguridad adjunto.
------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...
El boundary MIME contiene un archivo adjunto security-update-captaindns.html. El cuerpo en base64 decodifica hacia una pagina HTML con un formulario de inicio de sesión. Un email legítimo de CaptainDNS nunca enviaria un archivo HTML como adjunto para una "actualización de seguridad".
Tecnicas de evasion en el HTML embebido. Los atacantes usan varias técnicas para evadir los sandboxes que analizan archivos adjuntos HTML. El JavaScript puede estar ofuscado (codificación base64, concatenación de cadenas, ejecución dinámica de código). La pagina puede verificar si se ejecuta en un navegador real (detección de resolución de pantalla, de movimiento de raton, de plugins) y solo activar el formulario de phishing si se cumplen las condiciones. Algunas paginas HTML usan el protocolo data: o Blob URLs para construir dinamicamente el formulario, haciendo ineficaz el análisis estatico. En 2025 y 2026, los archivos adjuntos .svg con JavaScript embebido se han convertido en una variante cada vez más común de está técnica, ya que los SVG son aun menos vigilados que los archivos HTML.
Combinar los indicadores: el poder del scoring multi-señal
Tomados individualmente, cada indicador puede tener una explicación legítima. Un Return-Path diferente del From es normal cuando un ESP envia en nombre de una organización. Un DKIM firmado por un dominio de terceros es estandar con SendGrid o Amazon SES. Una cadena Received corta puede provenir de un servidor on-premise que envia directamente.
El poder de estos 10 indicadores aparece cuando se combinan. Un email que presenta un solo indicador merece una verificación. Un email que presenta tres indicadores o más es casi con certeza malicioso. El principio es el scoring multi-señal: atribuir una puntuación a cada indicador detectado y escalar cuando la puntuación acumulada supera un umbral.
Ejemplo de scoring para un email sospechoso:
| Indicador detectado | Puntuación |
|---|---|
| Return-Path ≠ From (dominio desconocido) | +2 |
| DKIM firmado por dominio de terceros no ESP | +2 |
| SPF pass + DMARC fail | +3 |
| Reply-To hacia dominio gratuito | +3 |
| Cadena Received < 3 saltos | +1 |
| Ausencia de TLS en primer salto | +1 |
| X-Mailer Python/script | +2 |
| Message-ID dominio ≠ From | +2 |
| Ausencia cabeceras X-MS-Exchange (dominio M365) | +3 |
| Archivo adjunto HTML | +2 |
Un umbral de 5 puntos activa una señalización para revision SOC. Un umbral de 8 puntos activa una cuarentena automática. Este scoring puede implementarse en las reglas de transporte Exchange/Gmail o en un SIEM.
En la práctica, los emails de spear-phishing sofisticados combinan generalmente de 3 a 5 indicadores. Los indicadores 1 (desfase Return-Path), 3 (SPF pass + DMARC fail) y 8 (Message-ID incoherente) aparecen juntos en la mayoria de los casos de suplantación de dominio. Los indicadores 4 (Reply-To divergente) y 9 (ausencia de cabeceras propietarias) caracterizan los ataques BEC (Business Email Compromise). La combinación 5 (cadena Received corta) + 6 (ausencia TLS) + 7 (X-Mailer script) delata un envio desde una herramienta de ataque.
La lección es clara: nunca juzgues un email por un solo indicador. Construye un scoring multi-señal adaptado a tu entorno y calibra los umbrales analizando tus emails legítimos y tus incidentes pasados.
Como detectar estas señales despues de la pasarela
Análisis manual con una herramienta de inspección
Para los incidentes individuales (un usuario reporta un email sospechoso), el análisis manual de cabeceras sigue siendo el método más rápido. El usuario exporta las cabeceras brutas desde su cliente email (en Outlook: Archivo > Propiedades > Encabezados de Internet; en Gmail: los tres puntos > Mostrar original). El analista SOC pega las cabeceras en una herramienta de análisis que descompone cada cabecera y resalta las anomalias.
Los puntos a verificar en prioridad durante el análisis manual:
- Return-Path vs From: dominios identicos o justificación legítima del desfase?
- DKIM d= vs From: la firma cubre el dominio correcto?
- Authentication-Results: combinación
spf=pass+dmarc=fail? - Reply-To: dominio coherente con el From?
- Cadena Received: número de saltos, coherencia temporal, presencia de TLS?
- Message-ID: dominio coherente con el From?
- Cabeceras propietarias: presentes si el dominio está alojado en M365/Gmail?
- Partes MIME: archivo adjunto HTML sospechoso?
Reglas de transporte Exchange/Gmail para el marcado automático
Para una detección sistemática, las reglas de transporte (mail flow rules) en Exchange Online o las reglas de enrutamiento en Google Workspace permiten marcar automaticamente los mensajes que presentan ciertos indicadores.
Ejemplo de regla Exchange Online para detectar el desfase Reply-To:
Condición: la cabecera Reply-To contiene un dominio diferente del dominio del From, Y el dominio del Reply-To no está en una lista blanca (dominios internos, ESP autorizados). Acción: añadir un banner de advertencia al mensaje ("Este mensaje tiene un Reply-To diferente del remitente mostrado") y marcarlo para revision SOC.
Ejemplo de regla para detectar la ausencia de cabeceras M365:
Condición: el dominio del From es un dominio interno alojado en M365, Y la cabecera X-MS-Exchange-Organization-AuthSource está ausente. Acción: poner en cuarentena para revision manual.
Estas reglas no sustituyen la pasarela pero añaden una capa de detección post-filtrado dirigida a las señales que la pasarela ignora.
Integración SIEM para la detección a gran escala
Para las organizaciones con un volumen significativo de emails, la integración con un SIEM (Microsoft Sentinel, Splunk, Elastic Security) permite automatizar la detección y la correlación. Los logs de transporte Exchange o Gmail contienen los resultados de autenticación, las cabeceras clave y los metadatos de enrutamiento. Reglas de detección personalizadas buscan los siguientes patrones:
- Volumen anormal de emails con
dmarc=fail action=nonepara un dominio interno - Emails entrantes con Reply-To hacia dominios gratuitos cuando el From es un dominio interno
- Mensajes sin cabeceras
X-MS-Exchange-*cuando el dominio From está alojado en M365 - Archivos adjuntos HTML en emails entrantes con un
Frominterno
La correlación SIEM también permite cruzar un email sospechoso con las conexiones de red: si un usuario abre un archivo adjunto HTML a las 09:15 y una conexion sospechosa a M365 desde una IP extranjera aparece a las 09:18, el incidente se detecta en casi tiempo real.
El vinculo con la entregabilidad y el spam
Los 10 indicadores descritos en este articulo no conciernen unicamente a la seguridad. También afectan la entregabilidad de tus propios emails. Si tu dominio presenta las mismas señales que un email de phishing (Return-Path incoherente, DKIM no alineado, DMARC en p=none), las pasarelas de los destinatarios van a tratar tus mensajes con sospecha. Tus emails legítimos terminan en spam porque tu configuración DNS y tus cabeceras activan las mismas señales que los atacantes explotan.
Corregir tus propias cabeceras (alinear SPF y DKIM, pasar DMARC a p=reject, configurar Message-ID coherentes) tiene un doble beneficio: reforzar la seguridad de tu dominio contra la suplantación Y mejorar la entregabilidad de tus emails legítimos. Es la misma cuadricula de lectura aplicada a dos objetivos complementarios.
Plan de acción
- Auditar tus 50 últimos emails sospechosos: recupera las cabeceras de los emails reportados por tus usuarios en el último mes y analiza cada uno con los 10 indicadores. Esta auditoria revela los tipos de ataques que superan tu pasarela.
- Crear reglas de transporte para los indicadores 1, 4 y 5: el desfase Return-Path/From, el Reply-To divergente y la cadena Received anormal son las tres señales más fáciles de detectar automaticamente mediante reglas Exchange o Gmail.
- Reforzar DMARC hacia p=quarantine o p=reject: mientras tu politica DMARC sea
p=none, los indicadores 1, 2 y 3 siguen siendo explotables sin consecuencia para el atacante. Recordemos que solo el 4% de los dominios aplicanp=reject(Valimail, 2025): cada dominio que migra reduce la superficie de ataque para todo el ecosistema. Usa nuestra herramienta de verificación DMARC (enlace en el banner de arriba) para auditar tu politica actual. - Formar a los equipos SOC en las señales de alerta de cabeceras: los empleados formados reportan cuatro veces más amenazas que los no formados, un 21% frente a un 5% (Verizon DBIR, 2025). Los 10 indicadores de este articulo deberian formar parte del procedimiento estandar de análisis de incidentes email. Crea una lista de control imprimible que los analistas consulten durante cada investigación.
- Integrar el análisis de cabeceras en el proceso de respuesta a incidentes: las organizaciones que integran IA en su pipeline de seguridad reducen el ciclo de brecha en 80 dias y ahorran en promedio 1,9 millones de dolares por incidente (IBM, Cost of a Data Breach 2025). Cada email sospechoso reportado debe pasar por un análisis post-pasarela sistematico antes de ser clasificado como falso positivo.
- Re-testear mensualmente con emails de prueba: enviate emails que reproduzcan cada uno de los 10 indicadores. Si tu pasarela los deja pasar y tus reglas de transporte no los señalan, tus defensas tienen un angulo muerto.
FAQ
Por que mi pasarela email no detecta estas señales?
Las pasarelas estan optimizadas para el filtrado masivo: reputación IP, contenido sospechoso, firmas malware. Los 10 indicadores descritos aqui corresponden a la coherencia de las cabeceras, un ambito que las pasarelas no analizan en profundidad. El desfase Return-Path/From o la ausencia de cabeceras propietarias no son criterios de filtrado estandar en la mayoria de los SEG del mercado.
Que filtros email son los más vulnerables a estos eludimientos?
Las pasarelas que se concentran exclusivamente en la reputación IP y el análisis de contenido son las más vulnerables. Las soluciones que integran análisis comportamental y verificación de alineamiento DMARC estan mejor posicionadas, pero ninguna pasarela del mercado verifica los 10 indicadores de manera exhaustiva. Por eso el análisis post-pasarela sigue siendo necesario.
Como crear una regla de transporte Exchange para detectar el desfase Reply-To?
En el Exchange Admin Center, crea una regla de flujo de correo con la condición "Un encabezado de mensaje incluye" sobre el encabezado Reply-To. Combina con la condición "El dominio del remitente es" para apuntar a los dominios internos. La acción recomendada es añadir una advertencia visible al destinatario y marcar el mensaje para revision SOC. Prueba en modo auditoria durante dos semanas antes de activar el bloqueo.
El análisis de cabeceras puede automatizarse?
Si. Los resultados de autenticación y las cabeceras clave son accesibles en los logs de transporte Exchange Online y Gmail. Un SIEM (Sentinel, Splunk, Elastic) puede ingerir estos logs y aplicar reglas de detección sobre los 10 indicadores. Para las organizaciones sin SIEM, las reglas de transporte Exchange/Gmail ofrecen un primer nivel de automatización accesible.
Estas técnicas de eludimiento funcionan contra Gmail y Outlook nativos?
Gmail y Outlook disponen de sus propias capas de filtrado (Gmail usa modelos ML avanzados, Outlook integra Defender). Estos filtros son mejores que la media en el alineamiento DMARC y la detección de Reply-To sospechoso. Pero no son infalibles: los indicadores 5 (cadena Received anormal), 7 (X-Mailer sospechoso), 8 (Message-ID incoherente) y 10 (archivo adjunto HTML) siguen siendo angulos muertos incluso para estas plataformas.
Como formar a mi equipo SOC en el análisis de cabeceras?
Comienza con un taller práctico de 2 horas con emails reales (anonimizados) que presenten cada uno de los 10 indicadores. Crea una lista de control imprimible que los analistas consulten durante cada investigación. Integra el análisis de cabeceras en los ejercicios de simulación de mesa y las simulaciones de phishing internas. El objetivo es que cada analista SOC pueda identificar los 10 indicadores en menos de 5 minutos por email.
Hay que reemplazar mi pasarela email para protegerse?
No. Los 10 indicadores son complementos a la pasarela, no sustitutos. La pasarela sigue siendo indispensable para bloquear el spam masivo, los malwares conocidos y las campañas de phishing genéricas. El objetivo es añadir una capa de detección post-pasarela (reglas de transporte, análisis SOC, SIEM) dirigida a los ataques sofisticados que el filtrado estandar no capta.
Como probar si mi pasarela pasa por alto estas señales?
Enviate emails de prueba reproduciendo cada uno de los 10 indicadores desde un servidor externo. Para el desfase Return-Path: configura un MAIL FROM diferente del From. Para el DKIM de terceros: firma con un dominio diferente. Para el Reply-To: inserta un Reply-To hacia un dominio externo. Documenta que emails superan la pasarela y cuales son bloqueados. Esta prueba revela los angulos muertos específicos de tu configuración.
Glosario
- Return-Path: cabecera insertada por el servidor de recepción que contiene la dirección del sobre SMTP (MAIL FROM). Usada para las notificaciones de no entrega (rebotes). Verificada por SPF.
- DKIM-Signature: cabecera que contiene la firma criptográfica de un mensaje. El campo
d=identifica el dominio firmante,s=el selector de la clave pública. - Alineamiento DMARC: verificación de que el dominio del From corresponde al dominio verificado por SPF (alineamiento SPF) o al dominio firmante DKIM (alineamiento DKIM). El alineamiento puede ser estricto (correspondencia exacta) o relajado (correspondencia sobre el dominio organizacional).
- Reply-To: cabecera opcional que indica la dirección hacia la cual deben dirigirse las respuestas. Puede diferir del From.
- Cadena Received: serie de cabeceras añadidas por cada servidor (salto) que ha procesado el mensaje. Leidas de arriba a abajo, trazan el recorrido del mensaje desde el último salto (arriba) al primero (abajo).
- STARTTLS: extension SMTP que permite iniciar una conexion cifrada TLS sobre una conexion SMTP existente. Visible en las cabeceras Received por la mención
with ESMTPS. - X-Mailer: cabecera opcional que identifica el software cliente usado para enviar el mensaje. No estandarizada por las RFC, pero ampliamente usada por los clientes de correo.
- Message-ID: identificador único asignado a cada mensaje por el servidor de envio. Formato:
<identificador@dominio>. Usado para el encadenamiento de conversaciones y la deduplicación. - MIME (Multipurpose Internet Mail Extensions): estandar de codificación de emails que permite los archivos adjuntos, el contenido HTML y los caracteres no ASCII. Definido por la cabecera
Content-Type. - Content-Disposition: cabecera MIME que indica si una parte del mensaje debe mostrarse en linea (
inline) o proponerse para descarga (attachment). - Remitente de sobre (envelope sender): dirección SMTP usada durante el comando MAIL FROM en la sesión SMTP. Distinta de la dirección en la cabecera From visible por el destinatario.
Tus cabeceras esconden señales sospechosas? Pega tus cabeceras brutas en nuestro analizador de cabeceras email para un diagnostico automático que cubre la autenticación, el enrutamiento y las anomalias descritas en este articulo.
