L’ingénierie sociale et en particulier le phishing sous toutes ses formes (email, SMS, appels téléphoniques, QR codes, etc.) demeure l’un des principaux vecteurs d’attaque.
En effet, dans de nombreux scénarios d’attaque, l’ingénierie sociale constitue un levier privilégié pour obtenir un accès initial : passer d’une posture d’attaquant externe à celle d’un attaquant disposant d’un premier point d’appui au sein du SI d’une organisation.
De fait, lors d’un exercice de Red Teaming, le recours à l’ingénierie sociale et au phishing s’impose naturellement.
Dans cet article, nous explorons les liens entre ingénierie sociale et Red Teaming. Après avoir clarifié les objectifs respectifs d’un audit d’ingénierie sociale et d’un exercice de Red Team, nous dressons un panorama des principales menaces ciblant le facteur humain. Ces enjeux sont ensuite illustrés par des scénarios réalistes, avant d’aborder les leviers permettant de s’en prémunir.
Guide complet sur l’ingénierie sociale et le Red Teaming
- Audit d’ingénierie sociale et Red Teaming : objectifs, différences et complémentarités
- Ingénierie sociale et Threat Intelligence : panorama des menaces ciblant le facteur humain
- Accès initial : phishing et identifiants déjà compromis
- Phishing AiTM : contourner la double authentification
- Ciblage des plateformes SaaS et des fournisseurs d’identité
- LOTS : détourner des services légitimes
- Contournement des protections et nouvelles techniques d’attaque
- Vishing et attaques hybrides
- Synthèse des tendances actuelles
- Phishing et Red Teaming : illustration d’un scénario d'attaque réaliste
- Comment prévenir les risques liés à l’ingénierie sociale ?
Audit d’ingénierie sociale et Red Teaming : objectifs, différences et complémentarités
Si l’ingénierie sociale est fréquemment utilisée lors d’un exercice de Red Teaming, l’approche adoptée dans le cadre d’un audit d’ingénierie sociale est différente.
Un exercice de Red Teaming vise à évaluer le niveau de sécurité global d’une organisation en simulant des attaques réalistes et sophistiquées, basées sur les TTP (Tactiques, Techniques et Procédures) d’attaquants réels. L’ingénierie sociale y constitue alors un levier parmi d’autres.
À l’inverse, un audit d’ingénierie sociale a pour objectif principal de sensibiliser les collaborateurs aux menaces ciblant le facteur humain. Il repose généralement sur des simulations de phishing, destinées à mesurer la capacité des utilisateurs à détecter et à réagir face à des tentatives de manipulation.
Dans un contexte Red Team, l’ingénierie sociale peut être exploitée à toutes les étapes de la chaîne d’attaque. Elle ne se limite pas à l’obtention d’un accès initial, mais peut également faciliter des mouvements latéraux ou une escalade de privilèges. Par exemple, une campagne de phishing menée depuis un compte de messagerie déjà compromis peut accroître significativement les chances de succès.
En comparaison, dans le cadre d’un audit d’ingénierie sociale, l’obtention d’un accès initial constitue bien souvent une finalité. Une capture d’écran anonymisée d’un compte compromis lors d’une simulation de phishing représente en effet un support efficace pour illustrer les risques et renforcer la sensibilisation. Dans la pratique, la majorité des audits s’arrêtent donc à ce stade.
Cela étant dit, qu’il s’agisse d’un audit dédié ou d’un exercice de Red Teaming, toute simulation d’ingénierie sociale doit être réaliste et contextualisée. Si la Threat Intelligence est essentielle pour une Red Team, l’adaptation des scénarios aux menaces actuelles l’est tout autant pour mener des campagnes de sensibilisation efficaces. Par ailleurs, ces dernières ne peuvent se limiter au phishing par email et doivent intégrer l’ensemble des techniques émergentes.
Ingénierie sociale et Threat Intelligence : panorama des menaces ciblant le facteur humain
Accès initial : phishing et identifiants déjà compromis
Comme évoqué en introduction, l’ingénierie sociale et en particulier le phishing demeure l’un des principaux vecteurs d’accès initial. Un autre levier tout aussi redoutable repose sur l’utilisation d’identifiants de connexion déjà compromis.
Dans l’écosystème cybercriminel, certains groupes se sont spécialisés dans la vente d’accès initiaux, communément appelés Initial Access Brokers. Ces acteurs monétisent des accès à des systèmes d’information compromis, facilitant le travail d’autres groupes malveillants.
Plus largement, le modèle du Cybercrime-as-a-Service, incluant notamment le Ransomware-as-a-Service (RaaS) et le Phishing-as-a-Service (PhaaS), contribue à la démocratisation des cyberattaques. Désormais, même des attaquants peu expérimentés peuvent mener des attaques sophistiquées et contourner des protections techniques avancées.
Phishing AiTM : contourner la double authentification
Certains kits de phishing, disponibles sur le dark web ou via des plateformes comme Telegram, permettent de contourner la majorité des mécanismes de double authentification. Ils reposent sur la technique du phishing AiTM (Adversary-in-the-Middle), également connue sous les appellations phishing MiTM ou reverse proxy phishing.
Dans ce scénario, l’attaquant se positionne comme intermédiaire entre la victime et un service légitime afin de capturer le trafic d’authentification.
Cette technique permet notamment de voler les jetons de session, ce qui est souvent plus efficace que la simple compromission d’identifiants.
Le phishing AiTM permet ainsi de compromettre des comptes utilisateurs même en présence de 2FA. À noter toutefois que certaines méthodes d’authentification forte, comme les passkeys, restent résistantes à ce type d’attaque.
Ciblage des plateformes SaaS et des fournisseurs d’identité
Depuis 2023, de nombreuses attaques utilisant le phishing AiTM ont été attribuées à des groupes comme Scattered Spider, ciblant notamment des plateformes SaaS et des fournisseurs d’identité tels qu’Okta.
Les applications SaaS constituent des cibles privilégiées, car elles hébergent des informations potentiellement critiques (données sensibles, secrets, mots de passe). La compromission d’une application de messagerie instantanée, comme Slack par exemple, permet également de lancer des campagnes de phishing internes particulièrement crédibles à partir de comptes légitimes.
Les solutions d’authentification centralisée (SSO) représentent également des cibles de choix. Compromettre un seul compte SSO peut en effet permettre l’accès à l’ensemble des applications associées.
LOTS : détourner des services légitimes
Une autre tendance marquante concerne l’abus de fonctionnalités offertes par des plateformes légitimes pour héberger ou diffuser du contenu malveillant, une approche connue sous le nom de LOTS (Living Off Trusted Sites).
Les attaquants exploitent par exemple des services comme Google Docs pour envoyer des notifications ou partager des fichiers contenant des liens de phishing. Ce mode opératoire améliore fortement la délivrabilité des emails, puisqu’un message provenant d’un service de confiance a davantage de chances d’atteindre la boîte de réception qu’un email émis depuis un domaine récemment enregistré ou à la réputation douteuse.
En effet, si l’attaquant enregistre et utilise un nom de domaine proche de google.com, certaines protections techniques détecteront probablement une activité suspecte en provenance du domaine en question, par exemple :
![Analyse VirusTotal du domaine de phishing docs-google[.]com](https://www.vaadata.com/blog/wp-content/uploads/2026/01/virustotal-analysis-of-a-phishing-domain--1024x587.png)
Contournement des protections et nouvelles techniques d’attaque
Les attaquants ont également recours à des services tiers légitimes pour héberger ou protéger leurs sites de phishing. L’intégration de mécanismes comme des CAPTCHA permet notamment de contourner les outils d’analyse automatique.
Des attaques comme ClickFix, très répandues récemment, exploitent ce sentiment de confiance en proposant de faux CAPTCHA incitant la victime à exécuter des commandes malveillantes sur sa propre machine.
Vishing et attaques hybrides
Face à l’amélioration des protections anti-phishing par email, les attaquants se tournent de plus en plus vers d’autres canaux de communication. Les attaques de vishing (voice phishing) ont ainsi fortement augmenté ces dernières années.
Un scénario courant consiste à se faire passer pour un membre du support informatique afin d’obtenir des identifiants ou des codes d’authentification. À l’inverse, certains attaquants contactent directement le help desk pour demander une réinitialisation de mot de passe.
Des scénarios hybrides combinant plusieurs canaux se développent également, comme le callback phishing, où la victime est incitée à appeler un numéro de téléphone figurant dans un email.
L’utilisation de QR codes pour masquer des liens malveillants fait aussi partie de l’arsenal des attaquants modernes.
Synthèse des tendances actuelles
Les principales tendances observées en matière d’ingénierie sociale incluent :
- le trafic d’identifiants compromis pour obtenir des accès initiaux ;
- l’usage du phishing AiTM pour contourner la double authentification ;
- le ciblage accru des plateformes SaaS et des fournisseurs d’identité ;
- l’abus de services légitimes pour diffuser des attaques (LOTS) ;
- l’augmentation du vishing et des attaques multi-canaux.
De manière générale, les outils et techniques d’attaque se démocratisent, permettant à des attaquants peu expérimentés de mener des attaques sophistiquées. Les progrès de l’intelligence artificielle accentuent encore cette tendance, notamment dans les scénarios de Business Email Compromise (BEC), où des conversations crédibles peuvent être générées rapidement, dans n’importe quelle langue.
Phishing et Red Teaming : illustration d’un scénario d’attaque réaliste
Un exercice de Red Team, comme tout audit de sécurité, débute par une phase de reconnaissance de la cible, avant toute tentative d’intrusion. Croisées avec les informations issues de la Threat Intelligence, les données collectées durant cette phase permettent de concevoir des scénarios d’attaque pertinents, reproduisant fidèlement les TTP d’attaquants réels.
L’analyse de la surface d’attaque technique constitue une étape clé de cette reconnaissance. L’étude des enregistrements DNS des domaines appartenant à l’organisation fournit notamment des informations précieuses. Les enregistrements MX permettent d’identifier le fournisseur de messagerie utilisé, tandis que certains enregistrements TXT, notamment ceux servant à la vérification de propriété de domaine, peuvent révéler les plateformes SaaS utilisées par les collaborateurs.
Supposons par exemple que notre cible fictive, KooGivi, utilise Gmail comme service de messagerie, ainsi que Slack et Atlassian.
Supposons également que l’authentification à ces services soit centralisée via un SSO Okta.
Dans ce contexte, un scénario de phishing pertinent consisterait à partager un fichier contenant un lien de phishing vers un faux portail de connexion Slack, depuis un compte Google usurpant l’identité du CEO de KooGivi. L’objectif serait alors de compromettre des identifiants Slack et, in fine, l’environnement SSO de l’entreprise.
Déroulé du scénario d’attaque
La vidéo de démonstration suivante illustre cette attaque :
Voyons cela de plus près :
- L’attaquant crée un faux compte Google usurpant l’identité de Zaïa Jefferson, CEO de KooGivi (informations accessibles via LinkedIn). Il partage ensuite un Google Forms prétextant une mise à jour urgente liée à l’authentification SSO sur Slack. La notification de partage est reçue directement dans la boîte de réception de la victime, et non dans les spams, car elle est envoyée depuis l’infrastructure légitime de Google. À ce stade, plusieurs indices permettent toutefois de détecter l’attaque :
- l’adresse email de l’expéditeur apparaît clairement dans la notification ;
- Google indique que l’expéditeur ne fait pas partie de la même organisation Google Workspace.
- Ignorant ces signaux, la victime ouvre le formulaire et clique sur le lien menant à un faux portail de connexion Slack, hébergé sur le domaine goodphish[.]com. Le site de phishing repose sur une technique de phishing AiTM, permettant de proxifier le trafic vers les services légitimes. La page d’authentification est visuellement identique au portail Slack officiel, à l’exception du nom de domaine dans l’URL.
- NB : Lors de la tentative de connexion au SSO Okta, un indice important aurait pu alerter la victime : l’absence de suggestion d’identifiants par son gestionnaire de mots de passe.
- Une fois l’authentification terminée, la victime accède normalement à son compte Slack, mais cette connexion transite toujours par le reverse proxy de l’attaquant. À ce stade, l’attaque est considérée comme réussie : les jetons de session Slack et Okta ont été capturés.
- L’attaquant importe ensuite les sessions capturées afin d’accéder directement aux comptes Slack et Okta de la victime, sans avoir à se réauthentifier.
- Une fois connecté à Okta, l’attaquant peut accéder aux autres applications intégrées au SSO, comme Confluence, faisant partie de la suite Atlassian identifiée lors de la phase de reconnaissance.
Pourquoi ce scénario est réaliste
Ce type d’attaque illustre parfaitement la manière dont des techniques d’ingénierie sociale, combinées à une bonne connaissance de la surface d’attaque et à des outils avancés comme le phishing AiTM, permettent de contourner des protections techniques pourtant robustes.
Il met également en évidence l’importance du facteur humain, tant comme vecteur d’attaque que comme première ligne de détection.
Comment prévenir les risques liés à l’ingénierie sociale ?
Réduire le risque lié aux attaques d’ingénierie sociale, et en particulier aux campagnes de phishing, repose sur une combinaison de mesures techniques et de bonnes pratiques côté utilisateurs.
L’idée clé à retenir est que des contrôles techniques existent et doivent être mis en œuvre afin de :
- Limiter l’exposition des collaborateurs aux attaques d’ingénierie sociale, par exemple en bloquant le plus tôt possible les emails de phishing grâce à des politiques anti-spam robustes ;
- Faciliter la détection précoce des tentatives d’ingénierie sociale qui n’auraient pas été stoppées en amont en partant du principe qu’aucune protection technique n’est infaillible. Cela passe à la fois par des actions de sensibilisation théoriques et par des exercices pratiques, tels que des simulations d’attaque, permettant de tester le niveau de vigilance des collaborateurs avant que des attaquants réels ne s’en chargent ;
- Permettre aux équipes techniques, et notamment aux administrateurs systèmes et réseau, d’identifier rapidement toute activité suspecte, par exemple une connexion depuis une localisation inhabituelle, là encore en considérant qu’aucun utilisateur n’est infaillible.
Cela étant dit, la sensibilisation des collaborateurs demeure un élément central : elle constitue bien souvent le premier, voire le principal rempart face aux attaques d’ingénierie sociale.
Sensibiliser les collaborateurs aux risques d’ingénierie sociale
Face aux attaques d’ingénierie sociale, un certain niveau de vigilance est indispensable. La confiance n’exclut pas le contrôle, à condition de rester dans une approche pragmatique et mesurée.
Identifier les demandes sensibles, urgentes ou non sollicitées
Toute demande sensible, qu’elle soit formulée par email, SMS, téléphone ou même en personne (par exemple un prétendu technicien venu inspecter les locaux), doit faire l’objet d’une vérification attentive. Une telle demande n’est pas nécessairement malveillante, mais la prudence reste de mise.
Dans la majorité des attaques d’ingénierie sociale, l’attaquant cherche à amener sa cible à effectuer une action sensible (télécharger un fichier piégé, cliquer sur un lien malveillant ou donner accès à des zones restreintes) le plus rapidement possible. L’urgence est volontairement mise en avant afin de court-circuiter les mécanismes de réflexion et de vérification. À l’inverse, il est essentiel de prendre du recul, même si cela peut s’avérer difficile dans certains contextes, et de s’appuyer sur des procédures de vérification définies à l’avance.
Les demandes non sollicitées doivent également constituer un signal d’alerte. À titre d’exemple, lors d’une attaque de type “fatigue MFA”, un attaquant ayant récupéré le mot de passe d’un utilisateur envoie de multiples notifications de validation jusqu’à ce que l’une d’entre elles soit acceptée, lui donnant ainsi accès au compte. De la même manière, les pop-ups affichées dans un navigateur ne doivent jamais être validées automatiquement, car elles peuvent elles aussi constituer un vecteur d’attaque.
Reconnaître les tentatives d’usurpation d’identité
Usurpation d’identité : un levier central de l’ingénierie sociale
Dans la majorité des attaques d’ingénierie sociale, les attaquants usurpent l’identité de tiers de confiance, qu’il s’agisse de personnes ou de marques, afin de convaincre leurs victimes de réaliser des actions sensibles mettant en péril la sécurité de leur organisation.
Un exemple emblématique est celui des attaques de type Business Email Compromise (BEC), telles que la fraude au président. Dans ce scénario, l’attaquant se fait passer pour un dirigeant et demande, sous couvert d’urgence, l’exécution d’un virement. Sur le plan psychologique, cette urgence renforce le biais d’autorité, poussant la victime à obéir à la demande du seul fait qu’elle semble émaner d’un supérieur hiérarchique.
Imitation de domaine vs usurpation de domaine
Ces tentatives d’usurpation d’identité s’appuient fréquemment sur l’utilisation de noms de domaine proches de domaines légitimes, sans pour autant être identiques. En raison de contraintes techniques liées à l’authentification des emails (SPF, DKIM, DMARC), les attaquants privilégient généralement l’imitation de domaine plutôt que l’usurpation directe.
Par exemple, le domaine de phishing docs-google[.]com imite le domaine légitime google.com, et plus précisément le sous-domaine docs.google.com. La différence peut sembler subtile, mais elle est significative : docs-google[.]com est un domaine distinct, alors que docs.google.com est un sous-domaine officiel de Google.
À l’inverse, un email envoyé depuis une adresse @google.com par un attaquant relèverait d’une usurpation de domaine. Techniquement, cet email ne serait pas authentifié et serait très probablement bloqué ou classé comme malveillant par les protections de messagerie.
Limites des indices classiques de détection
Le nom de domaine de chaque adresse email, lien ou URL doit être vérifié attentivement, que ce soit dans un message ou dans la barre d’adresse du navigateur. Toutefois, comme évoqué précédemment, les attaquants exploitent de plus en plus des fonctionnalités légitimes de services de confiance pour distribuer du contenu malveillant.
L’avantage en termes de délivrabilité est considérable : utiliser une infrastructure d’envoi réputée maximise les chances qu’un message atteigne la boîte de réception plutôt que le dossier spam. En conséquence, certains indices classiques de phishing, comme une imitation grossière du domaine expéditeur, peuvent être absents ou beaucoup plus difficiles à identifier.
Par ailleurs, l’imitation de marque n’est pas systématique. Les attaquants peuvent également utiliser des domaines génériques mais crédibles, tels que loginprotect[.]net, cohérents avec le prétexte employé (« activité suspecte détectée », « action requise », etc.). De même, l’utilisation d’une adresse personnelle (par exemple en @gmail.com) dans un contexte professionnel doit constituer un signal d’alerte.
Bonnes pratiques de vérification et coordination interne
Face à ce type de menace, un réflexe essentiel consiste à vérifier toute demande sensible via un canal de communication secondaire : appel téléphonique, message instantané ou échange en personne. À défaut, il est recommandé d’impliquer un tiers de confiance compétent, comme le service informatique ou la direction, en s’appuyant sur des canaux de communication définis à l’avance.
En cas de suspicion ou d’attaque avérée, la communication et la coordination internes sont cruciales. Une réaction rapide et collective peut souvent permettre de limiter significativement l’impact d’une attaque d’ingénierie sociale.
Cas particulier du vishing : vérifier l’identité de l’appelant
Dans le cadre des attaques de vishing, il est indispensable de disposer de procédures robustes de vérification de l’identité des appelants. Ces vérifications ne doivent pas reposer uniquement sur des informations personnelles telles que le nom, la date de naissance, le numéro de téléphone ou l’adresse email, des données souvent facilement accessibles aux attaquants.
Même des informations plus sensibles, comme un numéro d’employé ou de sécurité sociale, peuvent être obtenues par un attaquant déterminé, par exemple en usurpant le support informatique. C’est pourquoi l’utilisation de canaux de communication de confiance préétablis prend tout son sens : rappel sur un numéro connu, confirmation via une messagerie interne (Slack, Teams), ou validation par un tiers autorisé.
Détecter, alerter et réagir en cas d’attaque ou d’incident
L’ingénierie sociale repose sur l’exploitation de mécanismes psychologiques visant à pousser un interlocuteur à réaliser une action risquée. Chaque collaborateur réagissant différemment face à ce type de manipulation, il est statistiquement probable que seules certaines personnes détectent qu’une tentative est en cours, notamment lorsqu’une attaque cible plusieurs individus.
Dans ce contexte, l’un des réflexes les plus efficaces consiste à alerter rapidement ses collègues en cas de doute. Cela peut passer par un canal de communication dédié (Slack par exemple) afin de centraliser l’information et d’éviter qu’elle ne se perde. Il est également essentiel que l’ensemble des collaborateurs restent attentifs à ces signalements, en particulier les personnes plus exposées, comme les nouveaux arrivants, les collaborateurs de retour de congés ou les prestataires externes, souvent plus isolés.
Le signalement direct des emails suspects depuis la messagerie doit par ailleurs être encouragé et rendu aussi simple et efficace que possible du point de vue de l’utilisateur.
Enfin, savoir détecter une attaque est essentiel, mais il est tout aussi important de réagir de manière appropriée en cas de compromission, sans paniquer. Si un collaborateur a, par exemple, saisi ses identifiants sur une page de phishing, il est crucial d’alerter immédiatement le service informatique et de modifier ses identifiants afin d’empêcher toute escalade de l’attaque. Lorsque cela est possible, l’ensemble des sessions actives de l’utilisateur doit être révoqué. Les jetons applicatifs (clés API, jetons OAuth, etc.) doivent également être contrôlés et, le cas échéant, révoqués, car ils peuvent être exploités par les attaquants comme mécanisme de persistance.
Limiter les risques liés à la réutilisation des mots de passe
Il est fréquent d’avoir déjà réutilisé le même mot de passe sur plusieurs services. Cette pratique expose toutefois à un risque majeur : les attaques de credential stuffing. Lorsqu’un attaquant obtient les identifiants d’un compte, il peut tenter de les réutiliser automatiquement sur d’autres plateformes. En l’absence de double authentification, cette technique lui permet d’accéder instantanément à plusieurs comptes.
La bonne pratique consiste à utiliser un mot de passe unique pour chaque service. Si cette recommandation peut sembler contraignante, notamment en termes de mémorisation, elle devient réaliste grâce à l’utilisation d’un gestionnaire de mots de passe. Celui-ci permet de générer et de stocker des mots de passe robustes (longs, aléatoires et uniques) sans avoir à les retenir.
Au-delà de la gestion des mots de passe, ces outils offrent également un levier de détection face aux tentatives de phishing. Les identifiants enregistrés ne sont en effet suggérés que lorsque l’utilisateur se trouve sur le site légitime, ce qui peut constituer un signal d’alerte en cas d’imitation de nom de domaine.
Enfin, l’usage d’un gestionnaire de mots de passe doit être encadré au niveau de l’entreprise. Laisser chaque collaborateur choisir son propre outil peut entraîner des problématiques de visibilité et de contrôle pour les équipes IT, favorisant le shadow IT et, par conséquent, augmentant le niveau de risque global.
Implémenter des mesures techniques pour prévenir les attaques d’ingénierie sociale et améliorer leur détection
D’un point de vue technique, les entreprises disposent de plusieurs leviers pour réduire l’impact des attaques d’ingénierie sociale. Ces mesures visent notamment à :
- Filtrer les attaques le plus en amont possible, afin de limiter l’exposition des collaborateurs ;
- Faciliter la détection des tentatives qui parviendraient à contourner ces protections, en aidant les utilisateurs à les identifier.
Authentification forte
Même si la double authentification classique ne permet pas de se prémunir totalement contre certaines techniques de phishing avancées, elle demeure une mesure de défense essentielle contre le trafic d’identifiants de connexion. Qu’ils aient été compromis à la suite d’une attaque de phishing, d’une fuite de données chez un tiers ou de l’action d’un malware d’exfiltration (infostealer), les identifiants ne suffisent plus, à eux seuls, à accéder à un compte lorsque la double authentification est en place.
Dans ce contexte, l’attaquant est contraint de recourir à des techniques supplémentaires pour contourner la protection, telles que la fatigue MFA, le phishing AiTM ou encore le vishing, ce qui augmente significativement la complexité et le coût de l’attaque.
Cela étant dit, certaines méthodes d’authentification plus récentes, comme les passkeys, offrent une résistance accrue face au phishing, y compris dans ses formes les plus avancées. Ces mécanismes, qui tendent à remplacer progressivement les mots de passe, sont désormais pris en charge par un nombre croissant de plateformes, notamment Google et Microsoft. Il est donc recommandé d’envisager leur déploiement pour les applications et comptes sensibles, en complément voire en remplacement de la double authentification classique.
Sécurisation des emails : SPF, DKIM et DMARC
SPF, DKIM et DMARC sont trois standards d’authentification des emails qui doivent être mis en œuvre afin de protéger un nom de domaine contre les tentatives d’usurpation. Ils permettent d’empêcher qu’un attaquant envoie des emails de phishing en utilisant une adresse appartenant à votre domaine, sans y être autorisé, c’est-à-dire sans disposer du contrôle légitime de cette adresse.
SPF
SPF (Sender Policy Framework) permet de définir quels serveurs de messagerie sont autorisés à envoyer des emails pour le compte d’un domaine donné. Concrètement, si un attaquant tente d’envoyer un message en utilisant l’adresse support[@]koogivi.com depuis un serveur non déclaré dans la politique SPF du domaine koogivi.com, l’email échouera l’authentification SPF.
Ce mécanisme réduit significativement les chances que ce message atteigne la boîte de réception du destinataire.
La politique SPF est mise en œuvre via un enregistrement DNS, par exemple :
DKIM
DKIM (DomainKeys Identified Mail) est un mécanisme d’authentification des emails reposant sur une signature cryptographique, basée sur la cryptographie asymétrique. Il permet de vérifier que le message a bien été envoyé par un serveur autorisé et qu’il n’a pas été modifié en transit.
Concrètement, si un attaquant tente d’envoyer un email en utilisant l’adresse support[@]koogivi.com, la signature DKIM du message lorsqu’elle est présente ne pourra pas être validée, l’attaquant ne disposant pas de la clé privée associée au domaine koogivi.com.
À l’instar de SPF, un échec de l’authentification DKIM réduit significativement les chances que l’email atteigne la boîte de réception du destinataire.
La clé publique DKIM est quant à elle publiée dans un enregistrement DNS TXT, par exemple :
DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) permet de définir une politique explicite à appliquer lorsque les contrôles SPF et DKIM échouent. En complément de ces mécanismes, DMARC introduit la notion d’alignement des domaines, un élément essentiel pour se protéger efficacement contre les tentatives d’usurpation d’identité par email.
Sans entrer dans tous les détails techniques, trois domaines distincts interviennent dans l’authentification d’un email :
- le domaine d’envoi, correspondant au domaine de l’adresse de l’expéditeur, visible par le destinataire ;
- le domaine d’enveloppe, utilisé pour la vérification SPF et associé à l’adresse de retour ;
- et le domaine de signature, utilisé lors de la signature DKIM du message.
Sans vérification de l’alignement entre ces domaines, un attaquant pourrait usurper visuellement une adresse légitime (par exemple support[@]koogivi.com) tout en utilisant des domaines d’enveloppe et de signature différents, sous son contrôle. Il pourrait ainsi valider les contrôles SPF et DKIM en s’appuyant sur sa propre infrastructure, sans pour autant être autorisé à utiliser le domaine usurpé.
DMARC empêche ce scénario en vérifiant que les domaines utilisés pour SPF et DKIM sont correctement alignés avec le domaine d’envoi.
La politique DMARC est définie via un enregistrement DNS TXT, permettant notamment de spécifier le comportement à adopter en cas d’échec (quarantaine ou rejet).
Dans l’exemple d’un email utilisant goodphish.com comme domaine d’enveloppe et de signature, mais koogivi.com comme domaine d’envoi afin d’usurper un collaborateur de KooGivi, l’email ne passerait pas les vérifications d’alignement imposées par DMARC. Avec une politique stricte (aspf=s et adkim=s) et un mode p=reject, le message serait en théorie bloqué avant même sa délivrance.
Renforcement de la sécurité des messageries
Des protections techniques peuvent être mises en place au niveau des boîtes de messagerie des collaborateurs afin de filtrer les attaques de phishing par email, notamment via des politiques anti-spam et anti-phishing. Les fonctionnalités disponibles, ainsi que leur niveau de granularité, dépendent toutefois fortement du fournisseur de messagerie utilisé.
À titre d’exemple, Gmail et Outlook, les deux services que nous rencontrons le plus fréquemment lors de nos audits, proposent des mécanismes de protection avancés, incluant la détection des tentatives d’usurpation ou d’imitation d’identité, ainsi que l’analyse automatique des liens et des pièces jointes.
Afin de protéger efficacement les collaborateurs face aux tentatives de phishing, il est donc recommandé de bien connaître et configurer les mécanismes de sécurité proposés par son fournisseur de messagerie.
À ce titre, les ressources suivantes constituent de bons points de départ :
- pour Gmail : documentation sur les protections anti-phishing et anti-spam
- pour Outlook : présentation des fonctionnalités de protection d’Exchange Online Protection et Microsoft Defender.
Monitoring, alertes de sécurité et authentification basée sur le risque
À l’instar des mécanismes de sécurité mis en place au niveau des messageries, de nombreuses plateformes, en particulier les fournisseurs d’identité, offrent des fonctionnalités de monitoring et d’alertes administrateur en cas d’activité suspecte, par exemple lors d’une connexion depuis une localisation inhabituelle.
Des solutions comme Okta proposent ainsi des mécanismes avancés permettant de définir des politiques d’accès conditionnel basées sur différents facteurs contextuels associés à une tentative de connexion, tels que le terminal utilisé, l’adresse IP ou la localisation géographique. Chaque connexion se voit attribuer un niveau de risque, sur la base duquel des mesures de sécurité adaptées peuvent être appliquées, comme l’exigence d’un facteur d’authentification supplémentaire pour finaliser l’accès.
Des fonctionnalités équivalentes existent également pour la protection des comptes Microsoft 365, via les politiques d’accès conditionnel, et pour Google Workspace, avec des mécanismes de contrôle et d’alerte similaires.
Il est donc fortement recommandé de se familiariser avec les capacités de monitoring, d’alerte et de contrôle d’accès conditionnel des applications utilisées, en particulier celles jugées sensibles.
À titre d’exemple, les ressources suivantes constituent de bons points de départ :
- documentation sur la sécurité et les alertes dans Google Workspace
- présentation des politiques d’accès conditionnel pour Microsoft Entra / Office 365
- documentation sur le risk scoring et les politiques adaptatives d’Okta.
Auteur : Benjamin BOUILHAC – Pentester @Vaadata