Quand le mail des autorités devient une porte d’entrée

Le cas Revolut montre qu’un message peut être techniquement authentifié et contenir une demande non autorisée, faille que les mécanismes classiques de sécurité des e-mails ne suffisent pas, à eux seuls, à combler. Avant de transmettre des données sensibles, les entreprises doivent donc vérifier l’origine du message, mais aussi confirmer de manière indépendante l’identité du demandeur, la réalité du dossier concerné et l’autorisation de transmettre les données. Ces contrôles supplémentaires ne ralentissent pas nécessairement les processus lorsqu’ils sont intégrés aux procédures de validation existantes en fonction des risques.

À lire aussi : MFA résistante au phishing : CISA, FIDO et USDA · Des attaquants lisent des fichiers GitLab sans s’authentifier

Le 12 septembre 2026, on apprenait que la banque numérique Revolut avait communiqué des données personnelles sensibles à un tiers non autorisé, après avoir reçu des demandes de renseignements frauduleuses envoyées depuis une adresse e-mail relevant du domaine légitime d’un organisme gouvernemental. Selon les rapports, environ 680 personnes ont été touchées au total, les informations divulguées comprenant, selon la personne concernée, notamment des copies de passeport, des images de vérification d’identité ainsi que des données de compte et de transaction. Dans le même temps, Revolut déclarait que ses systèmes et les fonds de ses clients n’avaient pas été compromis.

Quelques jours plus tard, le groupe « IAmNotAVillain » a publié une demande de rançon à hauteur de plusieurs millions, payable en Monero, et a menacé, à défaut, de vendre les données. On ne peut pas confirmer à ce jour, de manière indépendante, si toutes les informations publiées proviennent réellement de l’incident Revolut et quelle est l’étendue totale du jeu de données.

Contrairement aux attaques classiques par rançongiciel, le levier de pression n’est pas ici un système chiffré, mais la possession de données sensibles et la menace de leur publication ou d’un usage abusif supplémentaire. Or, des informations telles que des données de passeport, des images de vérification ou des données financières peuvent, longtemps après une attaque, servir à l’usurpation d’identité, au social engineering ou à de nouvelles tentatives de chantage.

Authentifié ne veut pas dire autorisé

L’incident montre ainsi à quel point des contrôles supplémentaires s’imposent avant de remettre des données sensibles. C’est précisément là qu’apparaît la limite des procédés établis d’authentification e-mail : ils peuvent vérifier qu’un message a bien été envoyé techniquement via le domaine et l’infrastructure attendus, mais non que la demande concrète est réellement autorisée. Ces procédés incluent SPF, DKIM et DMARC. SPF vérifie si un serveur est autorisé à envoyer au nom d’un domaine, DKIM contrôle l’intégrité du message au moyen d’une signature cryptographique et DMARC recoupe les domaines utilisés et définit le traitement des authentifications échouées.

Pour les divulgations de données sensibles, les entreprises devraient donc examiner quatre points séparément. Elles doivent établir si le message a réellement été envoyé via le domaine indiqué, si la personne habilitée contrôle le compte utilisé et si la demande se rapporte à un dossier réel et autorisé. Elles devraient en outre vérifier si l’étendue et la nature de la divulgation exigée sont réellement nécessaires. L’authentification technique des e-mails répond avant tout à la question de l’origine du message. Pour le reste, il faut des preuves supplémentaires, aussi indépendantes que possible les unes des autres.

L’utilisation abusive de comptes de messagerie d’autorités jugés fiables pour adresser des demandes de renseignements frauduleuses n’est pas un phénomène isolé. Le FBI alertait déjà en 2024 sur des cas où des comptes e-mail gouvernementaux américains et étrangers compromis servaient à des Emergency Data Requests frauduleuses.

Répartir la confiance sur plusieurs systèmes

Comme un e-mail techniquement authentifié ne suffit pas, à lui seul, à confirmer qu’une demande est autorisée, les entreprises devraient mobiliser des critères de contrôle supplémentaires et indépendants de cette authentification. La demande peut par exemple être confirmée par un canal de contact déjà établi ou déterminé de manière indépendante. Un numéro de téléphone figurant dans l’e-mail reçu ne sert pas à cet effet, pas plus qu’une demande de confirmation envoyée à la même adresse e-mail. En revanche, un interlocuteur déjà enregistré, un annuaire officiel ou un contact connu de l’autorité compétente conviennent.

Le dossier lui-même offre des points d’appui : la référence du dossier, l’autorité émettrice, la base juridique et la compétence peuvent être recoupées via des systèmes distincts ou des contacts connus. Il convient en parallèle de vérifier si la nature et l’étendue des données exigées correspondent au but indiqué. Même une demande légitime ne justifie pas automatiquement la remise de toutes les informations disponibles. Les entreprises ne devraient donc transmettre que les données réellement nécessaires en droit pour le cas concerné.

L’historique des demandes reçues par l’entreprise sollicitée constitue un autre niveau de contrôle. Les systèmes de gestion des dossiers montrent si le même demandeur a déjà pris contact auparavant, quels formats de documents et canaux de transmission sont usuels et quel volume de données est habituellement demandé. Des écarts ne signalent pas nécessairement une attaque, mais peuvent déclencher un contrôle supplémentaire. Le simple historique e-mail est moins fiable à cette fin, car un attaquant ayant accès à une boîte mail peut aussi consulter les correspondances antérieures.

Enfin, une attention particulière devrait porter sur la destination de la transmission des données. Si la demande impose soudain un autre canal pour la transmission des données, cela devrait déclencher un contrôle supplémentaire. C’est le cas par exemple lorsque des informations sensibles doivent être envoyées, non plus via le portail habituel de l’autorité compétente, mais vers une nouvelle adresse e-mail, un espace de stockage en nuage ou un service jusqu’ici inconnu. Dans la mesure du possible, les demandes d’autorités et les demandes juridiques devraient être traitées via des portails sécurisés protégés par une authentification multifacteur résistante au phishing. Le droit de soumettre ou de valider une demande devrait être dissocié des identifiants du compte e-mail.

Aucune de ces mesures n’offre à elle seule une protection complète. L’objectif n’est donc pas de trouver la preuve de légitimité parfaite, mais de fonder la décision de transmettre les données sur plusieurs sources de confiance indépendantes. Plus un attaquant doit contrôler simultanément de systèmes distincts, plus il devient difficile de faire passer une demande frauduleuse par l’ensemble du processus.

Plus de contrôles, sans freiner l’activité

Une telle chaîne de contrôle ne signifie pas que chaque demande de routine doive être entièrement examinée à la main. Des contrôles automatisés peuvent aider à repérer tôt les écarts par rapport au déroulement habituel et à soumettre de manière ciblée à un examen complémentaire les demandes suspectes.

Des étapes de vérification supplémentaires devraient entrer en jeu en cas de risque accru : par exemple face à un nouvel interlocuteur, à un canal de retour modifié, à des demandes portant sur un volume inhabituellement important de données ou à des données particulièrement sensibles comme des copies de pièce d’identité, des données biométriques ou des historiques financiers complets. Plusieurs demandes rapprochées dans le temps, des heures d’envoi suspectes, des écarts nets par rapport au comportement habituel ou la tentative de contourner les étapes de contrôle ordinaires en invoquant une urgence particulière sont également de bons déclencheurs d’une vérification step-up.

Dans de tels cas, une confirmation obtenue auprès d’un interlocuteur dont les coordonnées ont été trouvées de manière indépendante peut être combinée à une seconde validation interne. Il devrait en outre exister, pour les véritables urgences, un processus rapide défini à l’avance. Des contacts vérifiés joignables 24 heures sur 24 et des procédures d’escalade claires permettent d’agir rapidement tout en maintenant les contrôles ; si une remise immédiate s’impose, elle devrait d’abord rester limitée aux informations réellement nécessaires pour faire face à l’urgence.

L’automatisation peut aider à intégrer des contrôles supplémentaires dans le processus sans le ralentir inutilement. Les systèmes de gestion des dossiers peuvent ainsi comparer les demandes à des cas antérieurs, signaler des schémas inhabituels, déclencher des validations additionnelles et empêcher la transmission de données vers des destinations non approuvées. Des journaux centralisés rendent en outre visibles des séries de demandes qui, prises isolément, semblent banales, mais qui, par leur accumulation, s’écartent du schéma habituel.

L’e-mail n’est que le début du contrôle

Le cas Revolut montre quelles conséquences surviennent lorsque l’authentification technique d’un canal de communication est assimilée à l’autorisation d’une action. L’objectif ne devrait toutefois pas être de se méfier par principe des demandes légitimes d’autorités. L’essentiel est plutôt de concevoir des processus de validation qui restent fiables même lorsqu’un canal de communication en soi digne de confiance est détourné.

L’authentification technique des e-mails peut continuer à prendre en charge une partie du contrôle, mais elle ne doit pas constituer, à elle seule, un motif suffisant pour accorder sa confiance. Pour les données sensibles, la divulgation doit donc reposer sur plusieurs contrôles indépendants les uns des autres.

Questions fréquentes

Plus du réseau MBF Media

cloudmagazinLe support Kubernetes prend fin, Amazon encaisse le sextuple

Source de l’image : Acronis

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.