Le domaine, c’est l’adresse. Pas tout le bâtiment.
La réponse courte : par un logiciel accessible depuis internet, un compte récupéré, une personne qu’on a réussi à convaincre ou l’accès d’un partenaire compromis. Et pas forcément par ton site. Ça peut commencer dans les mails, une application cloud ou un accès à distance pendant que la page d’accueil tourne tranquillement.
Ce ne sont pas juste des scénarios de formation. Dans M-Trends 2026, Mandiant attribue 32 % des intrusions de ses enquêtes de 2025 à l’exploitation de vulnérabilités comme point d’entrée. Ça décrit leurs dossiers, pas ta probabilité personnelle de te faire pirater. Le DBIR de Verizon apporte un autre ensemble de cas : aucun des deux ne donne un classement identique pour toutes les boîtes.
Par un service qui a une faille
Un plugin du site, une passerelle VPN, un outil de transfert de fichiers, une vieille application… Quelque chose est accessible et contient une faiblesse exploitable. Selon la faille, l’attaquant peut récupérer des données ou prendre la main sans connaître le moindre mot de passe. Certaines campagnes cherchent les systèmes concernés à grande échelle, pas ta boîte en particulier.
Imagine : le site principal est propre, mais un ancien portail client tourne toujours ailleurs. C’est lui qui sert d’entrée. La suite dépend de ses droits et de ce à quoi il peut accéder. Attention au raccourci quand même : vieux ou public ne veut pas automatiquement dire exploitable. Il faut regarder la faille précise et la configuration.
Avec un vrai compte. Juste plus seulement le tien.
Parfois, la personne se connecte, tout simplement. Un mot de passe réutilisé a fuité ailleurs, des identifiants ont été volés sur une machine, ou un accès a été acheté à un autre groupe. Un infostealer, c’est un logiciel malveillant qui récupère notamment des identifiants enregistrés et des éléments de session. Le départ peut donc être un portable compromis, pas un serveur.
Une session volée peut parfois être réutilisée sans nouvelle demande de connexion, selon les protections du service. Donc « on a la MFA », c’est important, mais ce n’est pas la fin de l’histoire. Si le compte contrôle les mails, l’hébergement ou l’enregistrement du domaine, ses droits peuvent permettre d’usurper ton identité, de modifier le site ou de rediriger des services.
En faisant ouvrir la porte à quelqu’un
Un soi-disant document partagé te demande de te reconnecter. Un faux support appelle pour une action urgente. Une fausse mise à jour se fait installer. Le principe, c’est de faire passer la demande de l’attaquant pour du travail normal. La personne donne un mot de passe, autorise un accès ou lance quelque chose de malveillant sans voir ce qui se joue derrière.
Ce n’est pas réservé au mail bourré de fautes. Ça peut passer par téléphone, SMS ou messagerie, avec un contexte crédible. Et « quelqu’un a été bête » n’explique pas grand-chose. Ce qui compte, c’est de comprendre comment une histoire convaincante a pu devenir un vrai accès.
Par quelqu’un à qui tu fais déjà confiance
Une agence gère le site. Un prestataire informatique a un accès distant. Une application connectée peut lire les fichiers de la boîte. Si ce partenaire ou cette intégration est compromis, ses accès légitimes peuvent devenir le passage vers chez toi. Personne dans ton équipe n’a forcément besoin de cliquer sur quoi que ce soit.
Par exemple, le compte compromis d’une agence qui peut publier ton site ne pose pas le même problème qu’un fournisseur qui reçoit seulement tes factures. « Un tiers », ce n’est pas un niveau de risque. Ce sont les droits qu’on lui a donnés qui changent l’histoire.
Par ce qui est déjà ouvert, ou ce qui traîne
Un stockage rendu public, une interface d’administration sans vraie authentification, une API qui ne vérifie pas qui a le droit de lire une fiche, une clé encore valide publiée dans du code… Là, pas forcément besoin de casser une porte. Le système autorise déjà quelque chose qu’il devrait refuser.
Une clé d’API exposée peut servir d’identifiant, mais seulement avec les droits associés. Un fichier lisible publiquement peut être une fuite sans donner le contrôle du serveur. Ce n’est pas la même conséquence. « On a trouvé un truc » doit encore devenir « voilà ce qu’on peut réellement faire avec ».
Et une petite entrée peut mener plus loin
Exemple de chaîne possible : une session mail volée donne accès aux messages de récupération ; une procédure de récupération d’hébergement mal protégée permet ensuite de remplacer une page. Autre cas : un serveur exploité contient un compte de service trop puissant, et le problème dépasse cette seule machine. Ce n’est pas automatique : les limites de droits et les vérifications indépendantes peuvent couper la chaîne.
Un ransomware, c’est une conséquence possible, pas la réponse à « par où ils sont entrés ? ». Et un domaine qui imite le tien pour une arnaque ne prouve pas que le vrai a été piraté. Un scan extérieur aide à repérer les services exposés ; il ne voit pas toutes les sessions volées ni tous les droits internes détournés. La bonne question devient donc : chez nous, quelle entrée peut mener à quoi ?