Entre el 3 y el 5 de agosto de 2026, Microsoft Threat Intelligence rastreó más de un millón de correos llegando a bandejas de entrada empresariales en Estados Unidos, cada uno construido alrededor del mismo argumento: una factura de suscripción anual de ServiceNow, una petición urgente del propio CEO de la empresa, y una transferencia ACH de casi 50,000 dólares esperando aprobación. Los dominios detrás de aproximadamente el 87.7 por ciento de ese volumen enviaban desde Estados Unidos. Nada de esto necesitó un dominio falsificado para llegar. Salió a través de la infraestructura de correo real de empresas reales, autenticándose exactamente como debía.
Un Paquete Convincente, No un Encabezado Roto
El propio correo hizo el trabajo que en otros casos suele hacer un truco de encabezados. Los atacantes suplantaron al CEO, CFO o presidente de cada empresa objetivo en el nombre visible del remitente, en el nombre visible de reply-to y en la firma, y luego pidieron al personal de cuentas por pagar que procesara el pago ACH descrito en una factura adjunta. Esa factura no era una plantilla genérica. Llevaba la marca de ServiceNow, un número de factura específico, una fecha de facturación, y una sección “FACTURADO A” dirigida a la empresa objetivo real. Debajo había un hilo de correo reenviado fabricado, construido para parecer que el CEO suplantado y un representante de ServiceNow ya habían discutido la compra, de modo que el destinatario en cuentas por pagar entraba en una conversación que parecía tener ya un consenso detrás. Microsoft no encontró evidencia de que ServiceNow, ni ninguna de las otras marcas nombradas en los señuelos, estuviera comprometida o involucrada.
Cuentas Reales, Dominios Reales, Autenticación Real
La elección de infraestructura es lo que hace que esta campaña merezca una segunda mirada. En lugar de levantar dominios similares para enviar, los operadores encaminaron el millón y medio de mensajes a través de múltiples cuentas en un servicio legítimo de entrega masiva de correo, con direcciones de envío ligadas a negocios reales y no relacionados: [email protected], [email protected], [email protected], entre otras. El correo enviado a través de esas cuentas se autentica contra los propios registros SPF y DKIM de esos dominios, exactamente como lo haría para cualquier cliente legítimo de esa plataforma, porque, mecánicamente, es exactamente eso. Dos dominios de apoyo, service-nowinc[.]com y domainlify[.]net, ambos registrados el 31 de julio, existían solo para recibir respuestas si una víctima contestaba, no para llevar la identidad autenticada del mensaje. Las comprobaciones de alineación de DMARC verifican el dominio en el encabezado From visible contra el dominio que realmente envió el correo. Aquí ambos hechos coincidían. El engaño vivía por completo en el nombre visible junto a una dirección precisa y alineada, un campo que DMARC nunca fue construido para evaluar.
Las Huellas de la IA, y Por Qué No le Importan a DMARC
Los investigadores de Microsoft señalaron varias señales consistentes con que la IA generativa tuvo un papel en la construcción de las plantillas: comentarios HTML extensos que etiquetaban cada sección de la factura y del hilo, un formato inusualmente uniforme en toda la muestra, uso intensivo de separadores tipo banner, y un uso consistente de rayas largas en todo el texto. Los investigadores tuvieron cuidado de aclarar que estos indicadores establecen la participación de la IA en la construcción de plantillas, no cuánto contenido de un correo individual redactó realmente un modelo. De cualquier forma, la técnica se sitúa una capa por encima de la autenticación. Ya sea que un humano o un modelo escribiera la factura falsa de ServiceNow, el mensaje seguía necesitando un dominio desde el cual enviarse, y usó uno que tenía pleno derecho a enviarlo.
Por Qué DMARC Nunca Fue la Capa Que Vigilaba Esto
Esta campaña no es tanto una nueva especie de evasión de autenticación como un recordatorio de lo que DMARC fue diseñado para comprobar desde el principio: si el dominio en el encabezado From coincide con un dominio autorizado a enviar ese correo. No dice nada sobre si el nombre visible junto a esa dirección coincide con el CEO real de una empresa, si una factura adjunta es genuina, o si un hilo reenviado debajo de ella realmente ocurrió. Una plataforma de envío masivo con miles de cuentas de clientes legítimos va a pasar SPF y DKIM, por diseño, para cada una de ellas, tanto las honestas como las secuestradas. Es un modo de fallo distinto al de la brecha en una plataforma de marketing que dejó a un solo atacante llegar a 138 cuentas de clientes y falsificar avisos a través de varias marcas fintech a la vez, o al truco de encabezados autofalsificados que hacía que el correo de phishing pareciera venir de la propia dirección del destinatario. Aquí, no parece necesario ningún compromiso de las cuentas de envío: un atacante solo necesita una cuenta, un nombre de remitente plausible, y un documento lo bastante convincente para sobrevivir a una lectura apresurada en cuentas por pagar.
Qué Significa Esto Para Tu Programa
Dale a cuentas por pagar un paso de verificación que no dependa de la bandeja de entrada. Cualquier solicitud de ACH o transferencia ligada a una nueva relación con un proveedor, o a un cambio repentino en una ya existente, debería requerir una llamada de confirmación a un número de teléfono obtenido de un sistema interno, no uno encontrado en el propio correo. Que DMARC pase no es evidencia de que la solicitud sea real.
Vigila las discrepancias en el nombre visible, no solo en el dominio. Una regla que marque cuando el nombre visible de un remitente coincide con el de un ejecutivo pero el dominio autenticado no coincide con ningún dominio con el que tu equipo de finanzas haya transaccionado antes, captura exactamente este patrón, incluso cuando SPF y DKIM están limpios.
Trata un hilo reenviado dentro de un correo como no verificado hasta que se demuestre lo contrario. Una captura de pantalla o una conversación citada incrustada en un mensaje es texto, no evidencia. No lleva autenticación propia y nunca debería ser lo que mueve una solicitud de pago de sospechosa a aprobada.
Recuerda que el trabajo de DMARC termina en el dominio, no en el trato. Un dominio puede tener una política DMARC estricta y nunca ver llegar un mensaje falsificado a una bandeja, mientras que un dominio completamente distinto y totalmente autenticado envía el fraude de facturas que vacía una cuenta bancaria. Ambos resultados son consistentes con que DMARC haga exactamente lo que fue construido para hacer.
La Conclusión
Un millón de correos llegaron a bandejas de entrada empresariales en tres días sin que ninguno necesitara fallar SPF, DKIM o DMARC para lograrlo. Los operadores eligieron una infraestructura que se autentica limpiamente por defecto y construyeron un documento lo bastante convincente como para que la comprobación de autenticación nunca fuera el obstáculo en su camino. DMARC verificó el dominio correctamente en cada mensaje. Nunca se le pidió, ni fue construido, para verificar la factura.
DMARC confirma que un dominio está autorizado a enviar. No tiene forma de decirte si ese dominio pertenece a un remitente masivo cuyos otros clientes están siendo suplantados para defraudar a tu equipo de finanzas. Excello Mail te da visibilidad continua y en lenguaje claro sobre tu postura de autenticación real, para que sepas exactamente dónde termina la cobertura de DMARC y dónde debe empezar el resto de tu defensa. Regístrate gratis en Excello Mail y mira hoy tu imagen de autenticación real.