L’appel arrive en fin de journée, pendant les vacances de notre CTO. « Bonne nouvelle, Cédric. Le client va peut-être prendre ta prestation de recherche d’identifiants compromis. »

La bonne nouvelle, c’est que le parc vient d’être chiffré.

Personne ne relève sur le moment — à cette heure-là, des gens passent leurs nuits à remonter des serveurs. Mais la phrase dit à peu près tout de l’économie de la prévention en France : une prestation devient vendable au moment exact où elle devient inutile.

Un an plus tôt, le même client avait dit non. Ce n’était pourtant pas un dossier ouvert à froid : il y avait déjà eu une intrusion l’année précédente. Un accès, une présence, des traces qu’on n’aime pas voir dans des journaux. Mais pas de chiffrement, pas de rançon, pas d’arrêt d’activité. Donc, dans la logique du décideur : pas de dommage. Et sans dommage, pas la peine d’aller chercher des identifiants qui traîneraient dans des fuites.

Le raisonnement est comptablement rationnel. Il est simplement faux du point de vue de l’attaquant.

Ce que ces chiffres disent vraiment

1. Une intrusion sans rançongiciel n’est pas un échec. C’est la première moitié du travail.

L’accès a été obtenu, les identifiants ont été récoltés, et l’accès a été revendu ou mis de côté. Le silence qui suit n’est pas une victoire : c’est un délai.

Les identifiants collectés à cette occasion gardent leur valeur des mois, parfois des années, et se revendent indépendamment de l’accès initial. Il n’y a pas de prescription sur un mot de passe qu’on n’a jamais changé.

2. La démonstration à grande échelle a eu lieu cet été.

En juin 2026, un serveur laissé ouvert a exposé un volume considérable d’identifiants FortiGate valides — adresses et mots de passe en clair. Les estimations varient selon les analystes : de l’ordre de 74 000 URL concernées dans 194 pays selon Recorded Future, 86 644 équipements confirmés selon Bitdefender, 30 000 à 75 000 identifiants administrateurs vérifiés selon Arctic Wolf.

Ces trois mesures ne disent pas la même chose et ne se recouvrent pas exactement — nous les donnons telles quelles plutôt que d’en choisir une. Elles convergent en revanche sur un même ordre de grandeur : environ la moitié des FortiGate exposés sur Internet.

Le mécanisme détruit l’excuse habituelle. Pas de faille inédite : de l’extraction de configurations sur des équipements exposés, du cassage hors ligne, et surtout de la réutilisation d’identifiants issus d’incidents antérieurs. Fortinet l’a écrit dans son propre billet du 19 juin 2026. Il n’y a rien à corriger — aucun correctif ne ferme cette exposition. Il faut faire tourner les mots de passe, imposer le MFA, et sortir les interfaces d’administration d’Internet.

Traduction : une bonne partie des organisations touchées avaient déjà été compromises une première fois et n’avaient jamais changé leurs identifiants. Exactement le scénario du client de cette histoire.

3. Le point d’entrée n’est pas celui que vous surveillez.

Selon Coalition, 87 % des réclamations liées à un rançongiciel ont pour point d’entrée un service d’accès distant, et le VPN seul représente 73 % des intrusions dont le vecteur a pu être identifié — contre 38 % en 2023. At-Bay mesure jusqu’à 6,8 fois plus de risque pour une organisation exploitant un VPN sur site que pour une organisation qui n’en a pas.

Aucun de ces chiffres ne parle d’intelligence artificielle. Ils décrivent un boîtier posé il y a cinq ans, exposé sur Internet par conception, dont personne n’a touché la configuration depuis.

Pourquoi votre dispositif actuel ne voit pas ça

Parce qu’il n’y a rien à détecter. L’attaquant se connecte avec des identifiants valides, par le canal prévu pour ça, depuis une adresse qui ne déclenche rien. Ce n’est pas une intrusion au sens de vos outils : c’est une session.

Parce que le calendrier joue contre vous. Le Verizon Data Breach Investigations Report mesure le passage de l’exploitation d’équipements de bordure de 3 % à 22 % des compromissions par exploitation de faille en un an. Délai médian de remédiation de ces équipements : 32 jours. Délai médian entre divulgation et exploitation de masse : zéro. Aucun outil ne résout un écart pareil. Il se résout par une décision d’organisation sur qui a le droit de redémarrer un équipement en production un dimanche.

Parce que ça arrive quand il n’y a personne. Le rapport Semperis 2025, mené auprès de 1 500 responsables sécurité et informatique dans dix pays dont la France, mesure que 52 % des organisations ciblées l’ont été un week-end ou un jour férié, que 78 % réduisent les effectifs de leur centre opérationnel de sécurité de moitié ou plus pendant ces périodes, et que 29 % de celles qui le font invoquent la conviction qu’elles ne seront pas attaquées. Plus de 70 % des chiffrements observés en 2024 sont survenus avant 8 heures ou après 18 heures. Les attaquants ont lu la même étude que vous.

Ce que ça change pour vous

Regardez votre accès distant. Il a probablement été posé par un prestataire il y a quatre ou cinq ans, il fonctionne, et personne n’y a touché depuis. C’est exactement le profil que décrivent 73 % des sinistres.

Trois questions concrètes à poser cette semaine, à votre DSI ou à votre prestataire :

• Le MFA est-il actif sur tous les accès distants, sans exception pour les comptes techniques et les comptes de service ?
• Quand les mots de passe administrateurs de l’équipement ont-ils été changés pour la dernière fois ?
• Avons-nous déjà eu un incident classé « sans conséquence » ? Si oui, les identifiants ont-ils tourné à ce moment-là ?

Si la réponse à la troisième est « on avait regardé, il ne s’était rien passé », vous êtes dans le scénario de cette édition. Une intrusion sans rançongiciel n’est pas un incident clos. C’est un incident dont vous n’avez pas encore vu la deuxième moitié.

L’action

Quatre choses, dans cet ordre — celui que dictent les données de sinistres, pas le catalogue d’un éditeur.

1. Traiter l’exposition du VPN comme une urgence. MFA sur tous les accès distants, rotation complète des identifiants administrateurs et VPN, firmware à jour, interface d’administration sortie d’Internet.
2. Partir du principe que vos anciens identifiants circulent. Si un équipement a été exposé une fois, même il y a trois ans, et que les mots de passe n’ont pas tourné depuis, considérez-les comme publics.
3. Traiter une intrusion sans rançongiciel comme une intrusion. Rotation, chasse, recherche de persistance.
4. Décider maintenant qui décroche en août. Pas au moment où le téléphone sonne.

Les trois premières supposent toutes de savoir quels identifiants de votre organisation circulent déjà. C’est précisément ce que nous mesurons, en continu.

Sans compte. Résultats en 15 minutes.

La version longue, avec la méthode et l’ensemble des sources, est sur la newsletter de notre CTO Cédric Bertrand : « « Ça scintille comme une guirlande de Noël ». Et on est en août. », Un mot de passe pourri, 25/08/2026.

Sources : Coalition, Cyber Claims Report — At-Bay, InsurSec Report 2026 — Verizon, Data Breach Investigations Report — Semperis, 2025 Ransomware Holiday Risk Report — Recorded Future / Insikt Group, Bitdefender et Arctic Wolf, publications de juin 2026 — billet Fortinet du 19/06/2026.

Traitement des données fondé sur l’intérêt légitime au sens du RGPD (sécurisation des accès contre l’usage frauduleux d’identifiants compromis).

L'article Il a dit non il y a un an : pourquoi une intrusion sans rançongiciel n’est pas un incident clos a été publié en premier sur CYBERESIST .

Le fait

Ce que la victime ne voit pas : à la seconde où elle valide, ses données partent vers un canal Telegram. L’opérateur les reçoit en clair, avec son adresse IP et l’horodatage, dans un format d’une régularité clinique. Entre deux messages, les escrocs discutent et commentent leurs chiffres de la journée.

Notre CTO Cédric Bertrand a construit une chaîne de collecte pour observer ces canaux de façon systématique. Trois jours de collecte : 533 sites de phishing actifs, 1 399 canaux d’exfiltration, 732 opérateurs distincts. L’un d’eux a encaissé 459 victimes en quatre jours avec un seul bot. Une personne toutes les douze minutes, pendant quatre jours, pour une seule équipe parmi 732.

Une réserve d’emblée, parce qu’elle compte : ce qui est mesuré ici, c’est l’infrastructure joignable depuis un navigateur. Les kits qui relaient côté serveur n’apparaissent pas. Le chiffre réel est plus élevé, et personne ne sait de combien.

Ce que ces chiffres disent vraiment

1. Ce n’est pas une série d’incidents. C’est un flux industriel.

Après déduplication, le site médian collecté pèse 0,9 octet. La moitié de ce qui apparaît chaque matin est une copie exacte d’un kit déjà vu, repeint et déposé sur un nouveau nom de domaine. Conséquence directe pour vous : bloquer un domaine de phishing ne produit presque rien. Le même kit ressort le lendemain, ailleurs, sous un autre nom.

2. Un identifiant volé ne circule jamais chez un seul acteur.

1 399 canaux d’exfiltration pour 533 sites : beaucoup de kits envoient les données vers deux ou trois destinations en même temps. L’explication est connue du milieu — celui qui revend le kit y laisse son propre canal. L’escroc du bas de la chaîne travaille, et son fournisseur lui vole sa récolte au passage.

Traduit en risque : quand un identifiant de votre organisation est capté, il arrive simultanément chez plusieurs acteurs qui ne se connaissent pas et n’en feront pas le même usage. Le démantèlement de l’un n’éteint pas le risque.

3. La valeur d’un signalement a une date de péremption.

Des chercheurs ont mesuré l’effet à l’échelle (DarkGram, USENIX Security 2025). Sur 339 canaux Telegram cybercriminels historiques signalés à la plateforme, 19 % ont été supprimés. Sur 196 canaux récents signalés selon la même procédure, 100 % ont été supprimés, en quatre jours de délai médian.

La seule variable qui change entre les deux lots, c’est l’âge : 237 jours de médiane contre 27. Un canal jeune tombe. Un canal installé résiste. Et lorsqu’un canal tombe malgré tout, la moitié de ses abonnés le retrouve ailleurs dans la semaine.

C’est la conclusion la plus importante de l’étude, et elle vaut bien au-delà de Telegram : en matière d’identités compromises, la fraîcheur bat l’exhaustivité. Un identifiant repéré trois jours après le vol, c’est un compte qu’on sécurise avant usage. Le même identifiant six mois plus tard, c’est une ligne dans un rapport.

Pourquoi votre dispositif actuel ne voit pas ça

Ce n’est pas une intrusion. Aucune vulnérabilité exploitée, aucun code malveillant, aucun EDR déclenché. L’utilisateur a saisi ses identifiants de sa propre main, sur son téléphone personnel, un dimanche soir. De votre côté du réseau, il ne s’est rien passé.

Ce n’est pas votre périmètre. La page est hébergée chez un tiers, le canal de collecte est chez Telegram. Aucun scan de votre surface d’attaque ne remontera cette activité — et c’est normal, elle n’a pas lieu chez vous.

Ce n’est pas lisible dans le code. Point contre-intuitif issu des travaux de Cédric : sur 300 kits restés muets à l’analyse, une désobfuscation poussée au maximum en a débloqué zéro. Pas trois, pas dix. Aucun. L’adresse d’exfiltration n’est pas cachée dans la page — elle n’y est pas du tout. Elle se construit à l’exécution, ou elle vit côté serveur. Les outils qui se contentent de lire le code passent structurellement à côté.

Le délai joue contre vous. Entre le vol de l’identifiant et son apparition dans une base de fuites publique, il s’écoule des semaines. L’attaquant, lui, teste le couple e-mail / mot de passe sur vos services dans les heures qui suivent.

Ce que ça change pour vous

Vos collaborateurs utilisent leur adresse professionnelle sur des dizaines de services tiers, et souvent le même mot de passe que sur votre messagerie. Il suffit qu’un seul d’entre eux tombe sur un faux SMS de colis un dimanche soir.

Le scénario qui coûte cher n’est pas le ransomware spectaculaire. C’est le compte de messagerie d’un dirigeant ou d’un comptable, détourné discrètement pendant trois semaines, le temps d’observer vos échanges, d’apprendre vos tournures de phrases et vos circuits de validation — puis d’envoyer une demande de changement de RIB au bon moment, au bon interlocuteur, dans le bon fil de discussion.

Aucun antivirus ne bloque ça : l’attaquant est connecté avec des identifiants valides, les vôtres.

La question à poser à votre DSI ou à votre prestataire cette semaine : combien d’identifiants de notre domaine sont actuellement en circulation, et depuis quand ? Si la réponse est « on ne sait pas », vous venez d’identifier votre angle mort le moins cher à combler.

L’action

Une seule, faisable cette semaine : listez vos domaines de messagerie, y compris ceux que vous n’utilisez plus — anciennes marques, filiales absorbées, domaines de campagne. Ce sont eux qui traînent le plus longtemps dans les bases, parce que plus personne ne les surveille.

Ensuite, la vraie question n’est plus « avons-nous subi une fuite ? », mais « depuis combien de temps un identifiant valide de notre organisation circule-t-il, et chez combien d’acteurs ? ».

Sans compte. Résultats en 15 minutes.

Pour consulter la version technique complète de cet article — méthode de collecte, pièges rencontrés, code — rendez-vous sur la newsletter de Cédric BERTRAND : « J’ai regardé des inconnus se faire voler, en direct », Un mot de passe pourri.

Sources : Un mot de passe pourri, 15/09/2026 — « DarkGram: A Large-Scale Analysis of Cybercriminal Activity Channels on Telegram », Saha Roy et al., 34th USENIX Security Symposium, 2025 — StalkPhish-OSS, Thomas Damonneville, AGPLv3.

L'article 459 victimes en quatre jours : ce que trois jours de collecte sur les kits de phishing nous ont appris a été publié en premier sur CYBERESIST .

Présentation

Ces moteurs de recherche permettent aux chercheurs en sécurité (et aux cybercriminels) de trouver des appareils connectés à Internet, tels que des serveurs, des routeurs, des caméras de sécurité, des imprimantes et d’autres appareils. Toutes les données sont indexées et permettent d’avoir des informations sur les ports ouverts, les versions de logiciels, les noms d’utilisateurs et les mots de passe par défaut.

Ces informations peuvent être utilisées pour trouver des vulnérabilités potentielles sur les appareils connectés à Internet. Dès qu’une nouvelle vulnérabilité est diffusée, il est ainsi possible de trouver quasi-instantanément des équipements vulnérables.

En 2019, des chercheurs en sécurité ont découvert que des appareils de stockage en réseau de la société Western Digital étaient exposés sur Internet en raison d’une mauvaise configuration. Les attaquants ont ensuite utilisé cette information pour effacer les données sur les appareils de stockage en réseau et exiger une rançon pour les restaurer.

En 2020, des chercheurs en sécurité ont découvert que des milliers de caméras de sécurité étaient exposées sur Internet en raison d’une mauvaise configuration. Les chercheurs ont pu trouver ces caméras en utilisant Shodan. Les attaquants ont ensuite utilisé cette information pour accéder aux caméras et surveiller les personnes à leur insu.

Les risques associés aux moteurs de recherche orientés sécurité sont nombreux. Les attaquants peuvent utiliser ces moteurs de recherche pour trouver des appareils connectés à Internet qui sont mal configurés ou qui ont des vulnérabilités connues. Les attaquants peuvent utiliser ces informations pour compromettre les appareils connectés à Internet et accéder aux réseaux d’entreprise.

Retour d’expérience

Lors d’une veille réalisée via le moteur de recherche Shodan pour détecter d’éventuels serveurs vulnérables (et ainsi notifier ainsi les structures médicales concernées), un serveur avec un logiciel de synchronisation a été découvert.

Découverte d’un serveur utilisant un protocole de synchronisation de fichiers (~sauvegarde)

L’accès à ce logiciel de synchronisation n’était pas protégé, et celui-ci contenait de nombreuses données dont des sites web, la messagerie de l’entreprise ainsi que des sauvegardes.

Analyse du protocole de synchronisation avec le logiciel nmap. Recherche des répertoires de sauvegardes (synchronisation)

Parmi les sauvegardes, la comptabilité de l’entreprise ainsi que les sites web de tous ses clients (il s’agissait d’un infogérant). Beaucoup de données étaient disponibles (dont des identifiants, des bases de données clients, etc.).

Récupération de l’ensemble des fichiers synchronisés

Malheureusement ce type de vulnérabilité est très courante et fait les choux gras des attaquants.

Il est malheureusement quasi-impossible de bloquer tous les scans issus des moteurs de recherche (adresses ip non connues, nouveaux services qui apparaissent régulièrement, etc.). Les recommandations contre ce type de moteurs de recherche sont donc les mêmes visant à sécuriser son réseau :

• Auditer son réseau régulièrement ;
• Faire des scans de vulnérabilités ;
• Utiliser un outil tel que portsentry afin de bloquer les scans de ports (première étape de la cartographie d’un réseau) ;
• Masquer les bannières logicielles (permettant d’éviter certaines attaques massives basées sur une version spécifique) ;
• Changer les identifiants et les mots de passe par défaut ;
• Appliquer des mises à jour de sécurité ;
• Utiliser des pare-feux ;
• Surveiller régulièrement les dispositifs connectés à Internet : Utiliser des outils de surveillance pour détecter les dispositifs connectés à Internet vulnérables et prenez rapidement des mesures pour les sécuriser ;
• Sensibiliser les utilisateurs.

L'article Compromission d’un SI en quelques minutes ou le danger des moteurs de recherche (1/2) a été publié en premier sur CYBERESIST .

Le point de départ est souvent le même : à partir du nom de domaine associé à l’entreprise, il y a tout d’abord une phase passive pour l’audit qui consiste à réaliser une cartographie de toutes les ressources disponibles. Celles-ci sont multiples :

• Liste des domaines
• Applications et serveurs disponibles
• Fuite de données (mots de passe, codes-source, etc.)
• Attaques de phishing en cours
• Shadow-it (équipements cachés / sites oubliés, etc.)

Plus d’infos sur notre audit d’exposition sont disponibles ici.

Parfois les informations découvertes lors de cette phase permettent d’obtenir un accès à des informations confidentielles ou de compromettre un des serveurs de l’organisation auditée. Dans le cas présent, nous allons exploiter une attaque de type credential-stuffing pour accéder à un compte de messagerie de l’entreprise.

Pour rappel les attaques par credential stuffing consiste à récupérer des identifiants volés (compromissions de sites web) qui ont été diffusés et à tenter de les ré-utiliser. Il existe de nombreux services/sites mettant à disposition ce type d’informations. Ce type d’attaque est particulièrement dangereux car il peut permettre d’accéder à des ressources protégées de l’entreprise (messagerie, serveurs, etc.)

Cinétique de l’attaque

Détails de l’attaque
Phase n°1 : Récupération de comptes piratés associés à un domaine.

Une fois ces comptes récupérés, il va s’agir de les tester.

Phase n°2 : Vérification si présence d’Office365

La seconde phase consiste à tester si l’entreprise / domaine possède bien une messagerie sur Office365.

Une fois la présence d’un webmail confirmé, reste à tester liste des logins / mdp récupérée.

Phase n°3 : Tests des comptes

Un compte valide a bien été trouvé. Reste maintenant à l’utiliser pour se connecter au webmail365.

Il s’agit d’un compte générique (certainement partagé vu le mot de passe faible).

Phase n°4 : Connexion avec le compte valide détecté

Il va s’agir maintenant de tester la combinaison valide détectée. Il est possible le compte soit protégé par une authentification forte, ce qui nous empêcherait de l’utiliser.

Pas d’authentification forte, un accès obtenu en quelques minutes à la messagerie de l’entreprise.

Le compte est de toute évidence un compte générique poubelle.

Problème même si ce compte est peu ou pas utilisé, il donne de nombreuses informations à un attaquant : l’ensemble des contacts, liste de diffusion de l’entreprise, contacts téléphoniques, etc.

Très simple pour un attaquant ensuite de faire des messages personnalisés et de viser d’autres adresses de contact.

Suite de l’attaque

Une fois ce compte obtenu, plusieurs options s’offrent aux attaquants :

• Accèder à des données sensibles de l’entreprise, telles que les informations financières, les données clients, les données de propriété intellectuelle et autres informations confidentielles.
• Envoyer des emails frauduleux à des clients (demande de paiement, obtention d’informations sensibles)
• Envoyer des emails frauduleux à d’autres employés (divulgation d’informations sensibles, faire effectuer des tâches)

Concernant la dernière possibilité (envoi d’emails frauduleux à d’autres employés de l’entreprise), c’était l’une des techniques utilisées par le gang du malware Emotet (technique du thread hi-jacking).

Recommandations

Ces recommandations sont similaires à celles déjà décrites pour se prémunir des attaques de credential-stuffing. Il va s’agir de :

• S’auditer (notre service d’audit d’exposition teste ce type d’attaque ainsi que de nombreuses autres)
• Sensibiliser les utilisateurs sur l’utilisation de gestionnaire de mots de passe et sur comment réaliser des mots de passe robustes
• Faire une ville sur les fuites de données (haveIbeenPowned)
• Appliquer l’authentification forte sur tous les comptes utilisant le webmail
  • Attention aux comptes génériques et aux comptes partagés qui ne sont souvent pas protégés correctement et représente une porte d’entrée dans le système d’informations)

L'article Compromission de Compte de Messagerie : Une Étude de Cas Révélatrice en Quelques Minutes a été publié en premier sur CYBERESIST .

Menace de plus en plus courante pour les entreprises, les attaques par credential stuffing sont une technique qui consiste à tester de nombreuses combinaisons d’identifiants et de mots de passe volés sur différents sites web, dans l’espoir de trouver une correspondance valide.

Les attaques par « Credential Stuffing » consiste à réaliser, à l’aide de logiciels ou de façon manuelle, des tentatives d’authentification massives sur des sites et services web à partir de couples identifiants/mots de passe

Problématique des identifiants / mots de passe

Les utilisateurs ont souvent de nombreux comptes en ligne : avec la multiplication des services en ligne, il devient courant pour un utilisateur d’avoir des dizaines, voire des centaines de comptes en ligne, chacun nécessitant un mot de passe différent. Il peut être tentant de réutiliser ses mots de passe pour simplifier la gestion des comptes, mais cela augmente le risque de violation de données.

Or non seulement il y a beaucoup de mots de passe à gérer mais avec le nombre de mots de passe différents pour chaque compte, il peut être difficile de tous les retenir. La réutilisation de mots de passe est donc une solution « pratique » pour les utilisateurs qui ne veulent pas avoir à se souvenir de plusieurs mots de passe.

Or en cas d’utilisation d’un même mot de passe pour plusieurs comptes en ligne, en cas de compromission d’un de ces comptes, les pirates ont accès à tous les autres comptes utilisant le même mot de passe.

Fonctionnement

Certains services / forums sur le darknet proposent aux attaquants une liste de login / mot de passe utilisateurs. Ces listes sont issues de fuites de données / piratages / phishing / attaques automatisées.

De nombreuses listes sont partagées sur des sites / services connus des attaquants.

En récupérant ces listes, il va être possible pour les attaquants de tester ces combinaisons de login / mots de passe et voir si une d’elles est valide.

Il existe certains outils qui permettent de tester un login/ mot de passe sur différents services simultanément.

Les conséquences

Une attaque réussie de credential stuffing peut avoir des conséquences graves pour les entreprises ou pour un utilisateur. Lorsqu’un attaquant réussit à accéder à un compte utilisateur, il peut

• Réaliser des opérations sur le compte de l’utilisateur ;
• Accès à des données sensibles de l’entreprise, telles que les informations financières, les données clients, les données de propriété intellectuelle et autres informations confidentielles ;
• Envoi d’emails frauduleux à des clients (demande de paiement, obtention d’informations sensibles)
• Envoi d’emails frauduleux à d’autres employés (divulgation d’informations sensibles, faire effectuer des tâches) :
  • C’est d’ailleurs une des techniques préférées utilisée par les groupes de rançonlogiciels pour diffuser des malwares (qui vont permettre plus tard de compromettre le réseau interne).

Attention car les entreprises peuvent également faire face à des poursuites judiciaires pour avoir laissé des données sensibles exposées et pour ne pas avoir empêcher ce type d’attaque[1].

Cas d’actualités

Quelques cas d’actualité récents avec ce type d’attaque.

En février 2023, le service de streaming musical Tidal a été victime d’une attaque de Credential Stuffing qui a entraîné la fuite de données d’utilisateur, notamment les noms d’utilisateur et les mots de passe. Les pirates ont ensuite utilisé ces informations pour se connecter aux comptes compromis et diffuser du contenu illégal.

En mars 2023, un pirate informatique a utilisé des attaques de Credential Stuffing pour prendre le contrôle de plus de 12 000 comptes de messagerie Microsoft Office 365 appartenant à des établissements d’enseignement aux États-Unis. Les comptes compromis ont été utilisés pour envoyer des spams et des messages de phishing.

Plus récemment, de nombreux utilisateurs du service Vinted ont vu leur cagnottes siphonnée[2]. La cagnotte (ou « porte-monnaie ») de Vinted, permet normalement aux membres de récupérer de manière sécurisée le fruit de leurs ventes et de pouvoir acheter avec ce même pactole. S’ils le souhaitent, les utilisateurs peuvent également transférer le montant de leur cagnotte sur leur compte bancaire. Le modus operandi semble être des attaques par réutilisation de mots de passe.

Recommandations

Plusieurs stratégies pour lutter contre ce type d’attaque.

Tout d’abord, il est important de sensibiliser les employés aux risques de ces attaques, et de leur fournir des formations pour apprendre à créer des mots de passe forts et à détecter les tentatives de phishing.

Faire une veille sur des services de fuites de données tels que HaveIbeenpowned est également intéressant.

Surtout, il est surtout nécessaire d’implémenter (quand c’est possible) la vérification en deux étapes (OTP). Ainsi même en cas de découverte d’un compte avec un mot de passe connu, l’attaquant ne sera pas en mesure de se connecter au compte.

Dans les autres mesures techniques, le blocage de compte après un certain nombre de tentatives pourrait paraître être une bonne idée, mais n’est pas efficace. Avec les attaques de ré-utilisation de mots de passe, seuls quelques mots de passe sont testés. De plus, les attaquants utilisent des réseaux de machines infectées pour effectuer leurs tests (et contournent ainsi le blocage associé à une adresse IP par exemple[4]).

Conclusion

il s’agit d’une menace sérieuse pour les entreprises mais il existe des mesures efficaces pour prévenir ces attaques. En sensibilisant les employés et en mettant en place des mesures de sécurité appropriées (en particulier l’authentification forte), les entreprises peuvent limiter ce nombre d’attaques.

Néanmoins, attention aux comptes génériques ou partagés, souvent non protégés. Un exemple de retour d’expérience est disponible ici. Celui-ci est notre retour d’expérience avec notre service « audit d’exposition » et il a démontré comment, en quelques minutes, un attaquant aurait pu compromettre un compte de messagerie pour effectuer des attaques plus évoluées.

Un retour d’expérience sur l’exploitation de cette attaque est disponible ici.

[1]

[2

L'article Introduction aux attaques de Credential Stuffing a été publié en premier sur CYBERESIST .