
Índex de continguts
L’octubre de 2025 vam rebre un correu amb assumpte “Review Required: Compliance Update — Support Case #3989843”.
Aparentava venir de Stripe, amb botó per accedir al dashboard. La URL, tanmateix, no es corresponia amb la del dashboard legítim de Stripe.
L’interessant: el missatge es mostrava “a través d’eevidence.com” a Gmail, el que als ulls d’un usuari distret augmenta la confiança. Com és possible?

Resum Ràpid de l’Atac (per a no Tècnics)
- El remitent, que no va ser Stripe, va enviar el correu amb Mailchimp (capçaleres
X-Mailer: Mailchimp,mail73.sea31.mcsv.net). - Va passar SPF, DKIM i DMARC… amb el domini de l’atacant.
- El correu va entrar en una llista de distribució gestionada per Google (
gpdr@eevidence.com), sense que Google identifiqués el phishing. - En reenviar-lo als membres, Google Groups va afegir la signatura DKIM de la nostra organització (
d=eevidence.com; s=corp). Resultat: el missatge semblava “nostre”.
Què Va Passar Tècnicament (Pas a Pas)
Origen i plataforma
From: Stripe <FAKE>Received: from mail73.sea31.mcsv.net …X-Mailer: Mailchimp Mailer→ Campanya enviada des de Mailchimp utilitzant el domini FAKE.
Nota. “FAKE” es refereix a l’adreça de correu o domini de l’atacant. No mostrem el domini real per seguretat.
Autenticació del remitent original (de l’atacant)
spf=pass … mail73.sea31.mcsv.netdkim=pass header.i=@FAKEdmarc=pass header.from=FAKE→ L’atacant va configurar bé SPF/DKIM/DMARC per al seu domini i Mailchimp va usar aquesta configuració per afegir la signatura DKIM corresponent. Per això el primer salt és legítim.
Entrada per un Google Group intern
To: <privacidad@eevidence.com>List-ID: <gpdr.eevidence.com>X-Google-Group-Id: 32262899634Reenviament als membres de la llista per part de Google Groups incloent el signat DKIM amb el nostre domini
DKIM-Signature: … d=eevidence.com; s=corpARC-Authentication-Results: … dkim=pass header.i=@eevidence.com→ En reenviar, Google Groups afegeix una nova signatura DKIM basada en el domini de la llista. Als ulls del receptor final: sembla un correu intern/legítim, malgrat que el
header.fromoriginal era extern.
Clau: la comprovació DMARC no invalida el correu perquè les signatures DKIM són vàlides, tant la que afegeix Google en reenviar el correu de la llista als seus membres com la que va afegir Mailchimp basada en el domini del remitent.
Senyals que Delaten el Frau (Visibles per a Qualsevol Usuari)
- Adreça del remitent no és de Stripe.
- Domini de l’enllaç mal escrit.
- La urgència i el cas “Compliance” genèric són habituals en campanyes de phishing per forçar el clic.
Lliçons i Mesures de Mitigació
1) Endureix els Teus Google Groups
- Modera a externs: activa “Moderate messages from non-members” o “Outside the organization”.
2) Polítiques i Formació
- Forma els usuaris perquè comprovin sempre la correspondència entre el contingut del correu i el seu emissor. Quin sentit té que Stripe enviï una notificació demanant una acció des d’un compte amb un domini diferent de stripe.com?
- Política de “clic zero”: en lloc d’usar els enllaços del correu, escriu la URL oficial al navegador i accedeix allà al contingut.
- Doble canal: valida qualsevol urgència per un canal alternatiu (telèfon, portal oficial).
3) Sobre SPF/DKIM/DMARC
- Mantén DMARC en
p=quarantineop=rejectquan sigui possible, i revisa periòdicament els teus ajustos de SPF. Utilitza DKIM en totes les plataformes d’enviament, siguin pròpies o de tercers.
Preguntes Freqüents (FAQs)
Per què Gmail el va mostrar “a través d’eevidence.com”?
Perquè el missatge va ser reenviat per un Google Group de la nostra organització. En reenviar, Google el va signar amb DKIM del nostre domini, donant aparença de “correu intern”.
Blocar externs en tots els Groups no trencarà coses?
Pots permetre externs però sota moderació i només als Groups que ho necessiten. La resta, només membres.
DMARC reject ens hauria salvat?
DMARC protegeix el teu domini de correu davant ciberdelinqüents que el vulguin usar com a remitent. Si en aquest cas el domini usat com a remitent hagués estat stripe.com, Google hauria rebutjat el correu entrant per DMARC. Aquest correu no es va rebutjar perquè Google va comprovar DMARC del domini FAKE de l’atacant.
Conclusió
Aquest cas demostra que la seguretat no és només tecnologia d’autenticació, també arquitectura i govern del correu.
Un Group obert pot convertir un missatge extern en alguna cosa que sembla intern.
Tanca el que no usis, modera el necessari, entrena el teu equip i desconfia sempre dels enllaços d’urgència.
A punt per començar?
Contacta'ns per compartir el teu projecte de negoci o registra't ara per començar a provar els nostres serveis avui
