Brevo et Trezor : 347 000 e-mails de phishing authentiques

Ce qui s’est passé

Le message prétendait qu’une vulnérabilité du microcontrôleur STM32 des portefeuilles exposait les phrases de récupération, sur un ton d’urgence, avec un lien vers une application qui demandait justement ce secret, le seul dont le vol est irréversible.

Le point technique décisif : le phishing n’a pas eu besoin d’usurper l’expéditeur. Les e-mails sont partis du compte Brevo réel de Trezor, avec l’adresse de support réelle et une authentification de domaine valide. Tous les signaux que les filtres et les utilisateurs considèrent comme des preuves d’authenticité étaient au vert. Un DMARC en rejet, que nous recommandons dans notre guide SPF, DKIM et DMARC, protège contre l’usurpation ; il ne peut rien contre un envoi depuis un compte légitime compromis.

La réponse de Trezor a limité les dégâts : domaine coupé en 20 minutes, compte Brevo suspendu, communication publique rapide. Cette rapidité tient à la préparation, et elle se répète avant d’en avoir besoin.

Un schéma récurrent chez les tiers

C’est le troisième incident touchant Trezor par un prestataire en moins de trois ans : portail de support compromis en janvier 2024 (66 000 utilisateurs), puis son logisticien ShipMonk piraté en août 2026 via une injection SQL zero-day sur Metabase (81 000 clients, avec extorsion par ShinyHunters). Aucun système interne de Trezor n’a été compromis dans ces affaires, et pourtant les données et la marque de ses clients ont été exploitées à chaque fois.

La faille : le compte d’envoi est une clé de votre domaine

Une plateforme d’envoi (Brevo, SendGrid, Mailchimp, Postmark, Resend) détient trois choses : le droit de signer avec votre DKIM, vos listes de contacts, et la confiance que vos destinataires accordent à votre adresse. Les points faibles habituels :

• comptes utilisateurs sans MFA ou partagés entre plusieurs personnes ;
• clés d’API à pleins droits, sans restriction d’adresse IP, copiées dans plusieurs applications ou dans un dépôt ;
• audiences mélangées : newsletter, alertes de sécurité et e-mails de compte dans le même compte ;
• aucune alerte sur une campagne inhabituelle, un nouvel expéditeur ou un export de liste ;
• anciens prestataires (agence, freelance) toujours membres du compte.

La même logique s’applique aux bibliothèques d’envoi elles-mêmes, comme l’a montré le ver npm qui visait un paquet d’e-mailing.

Comment le tester

1. Inventaire. Listez toutes les plateformes autorisées à envoyer pour vos domaines : lisez votre enregistrement SPF et les sélecteurs DKIM publiés, puis retrouvez le compte correspondant à chacun.
2. Membres et MFA. Dans chaque compte, exportez la liste des utilisateurs, leur rôle et l’état du MFA ou du SSO. Repérez les anciens salariés et prestataires.
3. Clés d’API. Listez les clés, leurs droits (envoi seul ou accès complet), leurs restrictions d’IP et leur date de création. Cherchez-les dans vos dépôts et votre CI (voir les secrets dans l’historique Git).
4. Cloisonnement. Vérifiez si une clé utilisée par le site marketing peut envoyer des e-mails transactionnels ou exporter la liste des clients.
5. Alertes. Créez une campagne de test vers une petite liste interne depuis un compte secondaire et vérifiez si quelqu’un est prévenu.
6. Réponse. Chronométrez un exercice : désactiver un compte d’envoi, révoquer ses clés et prévenir les utilisateurs. Trezor l’a fait en 20 minutes.

Comment corriger

• SSO ou MFA obligatoire sur chaque plateforme d’envoi, comptes nominatifs uniquement.
• Clés à droits minimaux (envoi seul), restreintes par IP quand la plateforme le permet, stockées dans un coffre, renouvelées.
• Comptes et sous-domaines séparés pour le marketing et le transactionnel.
• Alertes sur les nouvelles campagnes, les nouveaux expéditeurs et les exports.
• Clauses contractuelles de notification d’incident avec délai.
• Message constant aux utilisateurs : aucune alerte légitime ne demande une phrase de récupération, un mot de passe ou un code MFA.

Quel impact pour un agent IA avec l'affaire Brevo et Trezor ?

Un agent IA doté d’un outil d’envoi d’e-mails est une plateforme d’envoi de plus, avec la même faille et un vecteur supplémentaire : il n’a pas besoin d’être piraté, il suffit de le convaincre. Une instruction cachée dans un ticket ou un document peut lui faire envoyer, depuis votre adresse légitime, un message rédigé par l’attaquant. Dans l’autre sens, un agent qui lit vos e-mails entrants traitera un message comme celui de Trezor comme authentique, puisque tous les contrôles passent.

Les envois d’un agent vers l’extérieur devraient être limités à des modèles validés ou soumis à confirmation humaine. Le Red Team Agent Express teste en cinq jours si votre agent peut être utilisé pour envoyer du phishing en votre nom.