El 25 de junio de 2026, el equipo de inteligencia de amenazas de Microsoft publicó los detalles de una campaña de phishing que lleva activa desde abril contra hoteles de toda Europa y Asia. El cebo es sencillo: un archivo ZIP llamado photo-<números>.zip, que se presenta como la queja de un huésped por una infestación de chinches o una reseña de estancia, enviado a las bandejas de entrada de recepción. Lo que hace que esta campaña merezca la atención de cualquier dominio protegido con DMARC no es el cebo. Es el mecanismo de entrega, al que Microsoft llama “blanqueo de autenticación”.
Cada mensaje de esta campaña superó SPF, DKIM y DMARC. No porque el atacante falsificara nada, sino porque el atacante nunca necesitó hacerlo.
La Cadena: De Calendly a Google, a Cloudflare, hasta tu Recepción
Los correos no procedían de un dominio suplantado ni de uno parecido. Procedían de una cuenta de Calendly genuinamente comprometida, enviados a través de la propia infraestructura de notificaciones de Calendly, respaldada por SendGrid, bajo el subdominio em1618.calendly.com. Como Calendly es el remitente autorizado real de su propio dominio de notificaciones, SPF superó la comprobación. Como Calendly firma su correo saliente con DKIM, eso también se superó. Como la alineación del dominio From coincidía con la política DMARC del propio Calendly, DMARC pasó sin ningún problema.
El mensaje se mostraba como “Booking Manager (via Calendly)” – un nombre elegido específicamente porque el personal de hostelería está acostumbrado a esperar notificaciones de reservas de remitentes exactamente así. El enlace del interior redirigía a través de share.google, el propio sistema de redirección de enlaces de Google, antes de llegar a un dominio de phishing alojado tras Cloudflare. Cada salto de esa cadena es, por sí solo, una pieza legítima y confiable de infraestructura de internet.
Al hacer clic se descargaba un ZIP que contenía un archivo con nombre diseñado para parecer una foto – IMG-<aleatorio>.png.lnk en la primera oleada, PHOTO-<aleatorio>.png.lnk en una segunda oleada que comenzó a finales de mayo. Al abrirlo se activaba un script de PowerShell que usaba un decodificador de siete fases basado en BigInt para obtener la siguiente carga útil. La segunda oleada añadió un paso en el que el malware compilaba localmente una pequeña DLL en .NET usando csc.exe, antes de descargar finalmente una copia completa y legítima del entorno Node.js desde nodejs.org y utilizarlo para ejecutar un implante en JavaScript que Microsoft rastrea como TonRAT. La persistencia se establecía mediante las claves de registro HKCU\Run y HKCU\RunOnce, de modo que eliminar una ruta dejaba la otra intacta. El implante después se comunicaba con infraestructura de mando y control a través de puertos no estándar, ejecutaba automatización de navegador en modo headless y consultaba servicios de geolocalización por IP para perfilar la máquina comprometida.
Por Qué “Blanqueo de Autenticación” es el Nombre Correcto
DMARC, SPF y DKIM responden a una sola pregunta: ¿procede este mensaje de una infraestructura que el propietario del dominio ha autorizado a enviar en su nombre? No dicen nada sobre si el contenido de ese mensaje es seguro, ni sobre lo que ocurre después de que un destinatario haga clic en un enlace incluido por el remitente autorizado.
El planteamiento de Microsoft es preciso: cuando el dominio remitente es en sí mismo un servicio legítimo, y un atacante ha comprometido una cuenta de ese servicio o está abusando de alguna de sus funciones, las comprobaciones de autenticación confirman que el remitente es quien dice ser, sin decir nada sobre su intención. La confianza que Calendly, SendGrid y Google han tardado años en ganarse ante los proveedores de correo se convierte en la cobertura del atacante. Eso es blanqueo en el sentido literal: hacer pasar algo ilegítimo por un sistema legítimo hasta que sale limpio.
Se trata de un modo de fallo distinto de la suplantación de dominio y de las configuraciones híbridas incorrectas de Exchange que han dominado los titulares sobre elusión de DMARC este año. Nadie falsificó una cabecera. Nadie explotó un fallo de análisis. El atacante alquiló, phisheó o consiguió acceso de algún otro modo a una única cuenta real en una única plataforma SaaS real, y cada mecanismo de autenticación posterior hizo exactamente lo que estaba diseñado para hacer.
Qué Significa Esto si Administras un Dominio Protegido con DMARC
Si tu dominio aplica DMARC en p=reject, esta campaña no te suplanta. La postura de autenticación de tu propio dominio es irrelevante para que tu personal reciba este correo exacto, porque el mensaje no finge ser de tu dominio – es un mensaje real del dominio de Calendly, reenviado a través del dominio de Google, sobre algo que ocurre en tu negocio.
Precisamente ese es el punto. La aplicación de DMARC protege la identidad de tu dominio. No protege, ni puede proteger, a tu organización de ser atacada a través de la infraestructura autenticada de otra empresa. Son dos problemas relacionados pero distintos, y confundirlos es la forma en que las organizaciones terminan confiando en una seguridad del correo electrónico que en realidad no tienen.
De esa distinción se derivan tres conclusiones prácticas:
Aplica DMARC en tu propio dominio de todos modos. Sigue siendo necesario. Simplemente no es suficiente en este caso, y ningún cambio en tus propios registros DNS habría detenido esta campaña específica.
Trata a cada remitente externo autorizado como parte de tu superficie de ataque. Las herramientas de programación de citas, los sistemas de notificación de CRM, las plataformas de firma electrónica y los servicios de automatización de marketing que has autorizado en tu registro SPF, o en los que tu personal confía por costumbre, son exactamente los canales que esta técnica está diseñada para explotar. Un compromiso de cuenta en cualquiera de ellos llega a tu bandeja de entrada con un resultado de autenticación limpio.
Vigila tus propios informes agregados DMARC en busca de anomalías en los servicios de envío en los que confías, no solo en busca de suplantación de tu propio dominio. Si el volumen de envío, la huella de IP o los patrones de destino de un proveedor cambian bruscamente en el correo dirigido a tu organización, es una señal que merece investigarse incluso cuando SPF, DKIM y DMARC informan de un resultado positivo.
Para los equipos de seguridad que evalúan archivos ZIP con temática de fotos, actividad inesperada de csc.exe generando DLL pequeñas, o procesos de Node.js iniciados desde AppData\Local\Nodejs con un nombre de archivo aleatorio y un argumento de dominio, merece la pena revisar directamente la lista completa de indicadores de Microsoft. Para todos los demás, la lección es más sencilla: un resultado positivo en DMARC te dice quién envió un mensaje. Nunca te ha dicho, ni fue diseñado para decirte, si ese mensaje es seguro para actuar sobre él.
La visibilidad continua de tus informes agregados DMARC es lo que te permite detectar anomalías en los patrones de envío de los servicios externos que has autorizado, antes de que una campaña de blanqueo de autenticación como esta llegue a tu equipo. Regístrate gratis en Excello Mail y obtén visibilidad clara y continua sobre cada fuente que envía correo en tu nombre.