Huntress publicó una investigación el 7 de julio de 2026 que detalla una campaña de phishing que operó sin interrupciones durante aproximadamente ocho meses al explotar algo que ningún protocolo de autenticación fue diseñado para detectar: una función real, funcionando exactamente como fue diseñada, activada por un atacante en lugar de una empresa legítima. Los correos llegaban desde [email protected]. Realmente provenían de los propios servidores de Meta. Superaban SPF, DKIM y DMARC porque no había nada que fallara. El engaño comenzaba únicamente después de que el destinatario hacía clic.
Una Función, No una Falsificación
Meta Business Manager permite que una empresa envíe una “solicitud de socio” invitando a otra cuenta a colaborar en cuentas publicitarias o Páginas, un flujo de trabajo rutinario usado constantemente por agencias y equipos de marketing. Huntress descubrió que los actores de amenaza, activos desde al menos noviembre de 2025, habían aprendido a configurar el nombre visible y el nombre de la empresa en su propia cuenta controlada por el atacante para que pareciera una iniciativa oficial de Meta, algo similar a una invitación al Programa de Socios de Agencias de Meta o a una oferta de verificación. La plataforma de Meta entonces hacía exactamente lo que fue diseñada para hacer: generaba un correo de notificación real desde su propia infraestructura y lo entregaba, dirigido como si viniera del propio Meta, porque, en lo que respecta al sistema de correo, así era.
De Google Sites a un Chatbot Falso
La campaña evolucionó con el tiempo. Una versión anterior, activa en mayo de 2026, dirigía los clics a una página falsa del Programa de Socios de Agencias de Meta alojada en Google Sites. Para junio, los operadores habían añadido un chatbot fraudulento de Facebook Messenger a la cadena, presentando a las víctimas opciones como “Obtener Insignia de Verificación” o “Activar Monetización” antes de redirigirlas a páginas de phishing alojadas en Netlify. Los dominios registrados por el atacante detrás de estas páginas estaban diseñados para mezclarse con las propias convenciones de nomenclatura de Meta: agency-ad-hub.com, agency-partner-register.com, marketing-partner-join.com. Nada de esa infraestructura necesitaba tocar el correo en sí. El correo ya había hecho su trabajo al ser real.
Lo Que el Kit Realmente Robaba
Las páginas de phishing recolectaban credenciales de cuentas de Meta, códigos MFA, números de teléfono personales y de la empresa, direcciones de correo electrónico, y una fotografía del documento de identidad o pasaporte de la víctima, suficiente para tomar el control de una cuenta y a la vez burlar la reverificación de identidad. Huntress rastreó la exfiltración hasta un bot de Telegram, encontró cadenas de texto en idioma vietnamita en el código del lado del cliente, e identificó el nombre de usuario del operador del bot, apuntando a una infraestructura probablemente vinculada a Vietnam detrás de una campaña que alcanzó a empresas en múltiples regiones antes de que Meta implementara medidas de seguridad en junio de 2026 que, según los investigadores, la han detenido desde entonces.
Por Qué el DMARC No Tenía Nada Que Señalar
El DMARC existe para confirmar que el dominio en el encabezado “From” de un mensaje está autorizado a enviar en su propio nombre. En esta campaña, business.facebook.com envió el correo, lo firmó y lo alineó, todo correctamente, todo de forma genuina. No había un dominio parecido, ni un encabezado suplantado, ni ninguna brecha de autenticación que el DMARC pudiera detectar, porque la plataforma que enviaba la notificación y el dominio que la notificación decía representar eran, por una vez, exactamente lo mismo. El atacante nunca necesitó suplantar a Meta. Solo necesitaba lograr que Meta enviara un mensaje en su nombre, usando un campo de nomenclatura de cuenta sobre el cual el DMARC no tiene ninguna visibilidad ni autoridad.
Lo Que las Empresas Deben Hacer Ahora
Verificar cualquier notificación de “socio”, “verificación” o “agencia” directamente dentro de Meta Business Suite, nunca a través del enlace del propio correo. Navega a la plataforma por tu cuenta y revisa ahí las solicitudes de socios pendientes.
Auditar quién puede enviar solicitudes de socio a tu empresa, y revisar ese acceso de forma periódica. La configuración de socios y accesos de Business Manager controla esto directamente; los permisos permanentes sin revisar son exactamente de lo que dependía esta campaña.
Nunca enviar una foto de un documento de identidad, pasaporte o un código MFA en respuesta a un enlace dentro de un correo, sin importar cuán legítima parezca la dirección remitente. La verificación de identidad legítima ocurre dentro de una sesión autenticada que tú mismo iniciaste.
Mantén de todos modos la aplicación de DMARC en tu propio dominio. No detendrá que el sistema de notificaciones de tu proveedor se use en tu contra, pero sigue cerrando la vía mucho más común en la que un atacante falsifica tu nombre directamente, dejando libre la atención de tu equipo para puntos ciegos como este.
La Conclusión
Esta campaña nunca necesitó vencer al DMARC, porque nunca tuvo que enfrentarlo. La propia infraestructura de Meta envió un mensaje que la propia infraestructura de Meta tenía todo el derecho de enviar, en nombre de una cuenta que la propia infraestructura de Meta había verificado como real. Lo único falso era la intención detrás de ello, un campo que el DMARC nunca fue diseñado para leer. La autenticación te dice quién envió un mensaje. Nunca ha afirmado decirte por qué.
Excello Mail mantiene cada dominio que administras totalmente autenticado y aplicado, cerrando la puerta a la suplantación directa para que la atención de tu equipo se dirija a los puntos ciegos que viven una capa más adentro, en las funciones de plataforma y la lógica de negocio que el DMARC nunca fue creado para vigilar. Regístrate gratis en Excello Mail y descubre hoy mismo la postura real de autenticación de tu dominio.