Caso real: así intentaron colarnos un ‘Stripe Compliance’ por correo (y qué aprender de ello)

En octubre de 2025 recibimos un correo con asunto “Review Required: Compliance Update — Support Case #3989843”.

Aparentaba venir de Stripe, con botón para acceder al dashboard. La URL, sin embargo, no se correspondía con la del dashboard legítimo de Stripe.

Lo interesante: el mensaje se mostraba “a través de eevidence.com” en Gmail, lo que a ojos de un usuario distraído aumenta la confianza. ¿Cómo es posible?

Resumen rápido del ataque (para no técnicos)

• El remitente, que no fue Stripe, mandó el correo con Mailchimp (cabeceras X-Mailer: Mailchimp, mail73.sea31.mcsv.net).
• Pasó SPF, DKIM y DMARC… con el dominio del atacante.
• El correo entró en una lista de distribución gestionada por Google (gpdr@eevidence.com), sin que Google identificara el phishing.
• Al reenviarlo a los miembros, Google Groups añadió la firma DKIM de nuestra organización (d=eevidence.com; s=corp). Resultado: el mensaje parecía “nuestro”.

Qué pasó técnicamente (paso a paso)

1. Origen y plataforma

   From: Stripe <FAKE>
Received: from mail73.sea31.mcsv.net …
X-Mailer: Mailchimp Mailer

   → Campaña enviada desde Mailchimp utilizando el dominio FAKE.

   Nota. “FAKE” se refiere a la dirección de correo o dominio del atacante. No mostramos el dominio real por seguridad.

2. Autenticación del remitente original (del atacante)

   spf=pass … mail73.sea31.mcsv.net
dkim=pass header.i=@FAKE
dmarc=pass header.from=FAKE

   → El atacante configuró bien SPF/DKIM/DMARC para su dominio y Mailchimp usó dicha configuración para añadir la firma DKIM correspondiente. Por eso el primer salto es legítimo.

3. Entrada por un Google Group interno

   To: <privacidad@eevidence.com>
List-ID: <gpdr.eevidence.com>
X-Google-Group-Id: 32262899634

4. Reenvío a los miembros de la lista por parte de Google Groups incluyendo el firmado DKIM con nuestro dominio

   DKIM-Signature: … d=eevidence.com; s=corp
ARC-Authentication-Results: … dkim=pass header.i=@eevidence.com

   → Al reenviar, Google Groups añade una nueva firma DKIM basada en el dominio de la lista. A ojos del receptor final: parece un correo interno/legítimo, pese a que el header.from original era externo.

Clave: la comprobación DMARC no invalida el correo porque las firmas DKIM son válidas, tanto la que añade Google al reenviar el correo de la lista a sus miembros como la que añadió Mailchimp basada en el dominio del remitente.

Señales que delatan el fraude (visibles para cualquier usuario)

• Dirección del remitente no es de Stripe.
• Dominio del enlace mal escrito.
• La urgencia y el caso “Compliance” genérico son habituales en campañas de phishing para forzar el clic.

Lecciones y medidas de mitigación

1) Endurece tus Google Groups

• Modera a externos: activa “Moderate messages from non-members” o “Outside the organization”.

2) Políticas y formación

• Forma a los usuarios para que comprueben siempre la correspondencia entre el contenido del correo y su emisor. ¿Qué sentido tiene que Stripe envíe una notificación demandando una acción desde una cuenta con un dominio distinto de stripe.com?
• Política de “clic cero”: en lugar de usar los enlaces del correo, escribe la URL oficial en el navegador y accede allí al contenido.
• Doble canal: valida cualquier urgencia por un canal alternativo (teléfono, portal oficial).

3) Sobre SPF/DKIM/DMARC

• Mantén DMARC en p=quarantine o p=reject cuando sea posible, y revisa periódicamente tus ajustes de SPF. Usa DKIM en todas las plataformas de envío, ya sean propias o de terceros.

Preguntas Frecuentes (FAQs)

¿Por qué Gmail lo mostró “a través de eevidence.com”?

Porque el mensaje fue reenviado por un Google Group de nuestra organización. Al reenviar, Google lo firmó con DKIM de nuestro dominio, dando apariencia de “correo interno”.

¿Bloquear externos en todos los Groups no romperá cosas?

Puedes permitir externos pero bajo moderación y solo en los Groups que lo necesitan. El resto, solo miembros.

¿DMARC reject nos habría salvado?

DMARC protege tu dominio de correo frente a ciberdelincuentes que lo quieran usar como remitente. Si en este caso el dominio usado como remitente hubiera sido stripe.com, Google hubiera rechazado el correo entrante por DMARC. Este correo no se rechazó porque Google comprobo DMARC del dominio FAKE del atacante.

Conclusión

Este caso demuestra que la seguridad no es solo tecnología de autenticación, también arquitectura y gobierno del correo. Un Group abierto puede convertir un mensaje externo en algo que parece interno.

Cierra lo que no uses, modera lo necesario, entrena a tu equipo y desconfía siempre de los enlaces de urgencia.