Le Facteur Humain
Dernier chapitre de la partie exploitation : comprendre pourquoi l'humain reste souvent le vecteur d'accès le plus simple, et le cadre éthique strict qui encadre ce type de test.
1. Introduction
Exploiter le facteur humain plutôt qu'une faille technique.
2. Pretexting
Construire un scénario crédible pour justifier une demande inhabituelle.
3. Phishing avec GoPhish
La plateforme de référence pour des campagnes de sensibilisation autorisées.
Un Vecteur d'Accès à Part
- Contrairement à tous les chapitres précédents, l'ingénierie sociale ne cible ni un service ni une machine, mais directement une personne et son comportement.
- C'est souvent le vecteur d'accès le plus simple : il est généralement plus facile de convaincre une personne d'agir que de contourner un contrôle technique bien configuré.
- Rappel du chapitre 6 : ce type de test est soumis à des limites éthiques strictes, toujours validées par écrit avant le moindre envoi, sans exception.
Concepts
- Le pretexting consiste à construire un scénario ou une histoire crédible pour justifier une demande qui, sans ce contexte, paraîtrait suspecte.
- Il existe des ressources publiques (dépôts GitHub) recensant des exemples de prétextes utilisés en test d'intrusion autorisé, utiles pour s'entraîner à les reconnaître plutôt qu'à les improviser.
- Un bon prétexte s'appuie souvent sur des informations collectées lors de la phase de renseignement (OSINT, chapitre 2) — d'où l'importance de traiter ces phases comme un tout cohérent, pas des étapes isolées.
Concepts
- GoPhish est une plateforme open source dédiée à la simulation de campagnes de phishing dans un cadre autorisé (test de sensibilisation, jamais une attaque réelle).
- Permet de mesurer objectivement le taux de clic/ouverture d'une organisation face à un e-mail piégé simulé, pour orienter la formation des utilisateurs.
Fonctionnalités Principales
- Création et gestion de campagnes.
- Éditeur de modèles d'e-mail.
- Gestion des cibles (listes de destinataires).
- Création de pages d'atterrissage (landing pages).
- Suivi et reporting des résultats.
- Planification et automatisation des envois.
Ce qui ne se Négocie Pas
- Autorisation écrite préalable, avec un périmètre et des scénarios validés à l'avance — jamais improvisés en cours de mission.
- L'objectif est la sensibilisation et l'amélioration de la posture de sécurité, jamais de piéger ou d'humilier un employé individuellement.
- Aucune information personnelle collectée hors périmètre ne doit être utilisée, même si elle est facilement accessible.
- Les résultats d'une campagne restent confidentiels et sont présentés de façon agrégée, pas nominative, dans le rapport final.
Une campagne de social engineering ne consiste pas simplement à « envoyer un faux e-mail ». Il faut comprendre le contexte, définir ce que l’on veut mesurer, choisir un scénario proportionné et déterminer à l’avance ce qui constitue un résultat exploitable.
Comprendre
Identifier les mécanismes humains et organisationnels qui rendent une demande crédible.
Tester
Mesurer une réaction définie : ouverture, clic, signalement ou autre comportement autorisé.
Améliorer
Transformer les observations en mesures de réduction du risque : formation, procédures et contrôles techniques.
Principe : le résultat recherché est une information sur la posture de sécurité, pas l’obtention d’un avantage personnel sur une personne testée.
La « surface d’attaque humaine » correspond aux interactions où une personne peut recevoir, interpréter ou transmettre une information influençant la sécurité : e-mail, téléphone, messagerie, support informatique, accès physique ou réseaux sociaux.
E-mail
Pièces jointes, liens, demandes urgentes, changement de coordonnées bancaires.
Voix
Demande d'assistance, vérification d'identité, pression temporelle ou autorité apparente.
Physique
Badge, visiteur, accès à une zone ou observation d'informations exposées.
À retenir : un scénario crédible exploite généralement plusieurs signaux de contexte plutôt qu'un seul élément technique.
Signaux courants
- Autorité : la demande semble provenir d'une personne légitime.
- Urgence : le destinataire est incité à agir avant de vérifier.
- Contexte : la demande paraît cohérente avec une activité réelle.
- Familiarité : le message reprend des éléments connus de l'organisation.
Pourquoi cela compte
Un contrôle technique peut être correctement configuré tout en étant contourné par une interaction humaine. L'objectif d'un test est donc d'identifier où le processus organisationnel permet une action qui devrait normalement être vérifiée.
1. RenseignementInformations publiques et contexte autorisé.
→
2. HypothèseIdentifier une situation réaliste à tester.
→
3. ScénarioConstruire une interaction cohérente.
→
4. MesureObserver uniquement le comportement prévu.
Point méthodologique : l'OSINT ne sert pas à collecter « tout ce qui est trouvable », mais à fournir le minimum d'informations nécessaires à l'hypothèse de test.
Structure d'un prétexte
- Qui ? identité ou rôle utilisé dans le scénario.
- Pourquoi ? raison de l'interaction.
- Pourquoi maintenant ? événement qui rend la demande plausible.
- Quelle action ? comportement exact que le test cherche à observer.
Exemple de logique
Contexte réel
↓
Situation plausible
↓
Demande limitée
↓
Action observable
↓
Résultat / signalement
| Élément | Ce qu'un analyste examine |
|---|
| Expéditeur | Domaine, adresse réelle, nom affiché et cohérence avec le contexte. |
| Objet | Urgence, promesse, demande inhabituelle ou formulation atypique. |
| Corps | Contexte, ton, cohérence, fautes, demande d'action. |
| Lien | Destination réelle, domaine, chemin et présence éventuelle de redirections. |
| Pièce jointe | Type, origine, extension réelle et comportement attendu. |
Perspective défense : ces mêmes indicateurs constituent une base utile pour entraîner les utilisateurs et améliorer les mécanismes de détection.
PréparerPérimètre, objectifs, population et scénario.
→
ConfigurerCampagne et mécanismes de mesure.
→
ExécuterEnvoi dans la fenêtre autorisée.
→
MesurerOuverture, clic, signalement selon le périmètre.
→
RestituerRésultats agrégés et actions correctives.
Delivery
Part des messages effectivement remis aux destinataires.
Interaction
Ouverture ou clic selon les mécanismes de mesure autorisés.
Signalement
Capacité des utilisateurs à identifier et signaler le scénario.
Attention aux métriques : un taux de clic seul ne décrit pas toute la posture de sécurité. Il faut également considérer le signalement, le contexte et les limites de la mesure.
Objectif pédagogique
Une page d'atterrissage peut permettre de mesurer si une personne suit le scénario jusqu'à une étape définie, sans nécessairement collecter une information réelle.
clic
navigation
signalement
Limites
Éviter la collecte de mots de passe réels, de données personnelles non nécessaires ou d'informations qui dépassent le périmètre convenu. La simulation doit être conçue pour mesurer, pas pour conserver des secrets.
Questions à se poser
- Est-ce que la demande correspond à mon rôle ?
- Le domaine et l'expéditeur sont-ils cohérents ?
- Le message crée-t-il une urgence artificielle ?
- Le lien mène-t-il réellement vers le service attendu ?
- Existe-t-il une procédure interne de vérification ?
Bonne réaction
Ne pas agir sous pression. Vérifier via un canal indépendant et utiliser la procédure de signalement prévue par l'organisation.
Messagerie
SPF, DKIM, DMARC, filtrage des pièces jointes et analyse des URL.
Identité
MFA et politiques d'accès réduisent l'impact d'une compromission de compte.
Endpoint
EDR, navigateur sécurisé et contrôle des téléchargements limitent les conséquences d'une interaction malveillante.
Approche en profondeur : la sensibilisation seule ne doit pas être considérée comme l'unique contrôle contre le phishing.
| Niveau | Caractéristique | Objectif |
|---|
| Faible | Message générique, peu de contexte. | Tester les contrôles et réflexes de base. |
| Moyen | Contexte organisationnel cohérent. | Mesurer la résistance à une demande plausible. |
| Élevé | Scénario plus réaliste et informations contextuelles. | Évaluer une chaîne de contrôles, avec validation stricte du périmètre. |
Règle : augmenter le réalisme uniquement lorsque cela répond à l'objectif du test. Plus un scénario est réaliste, plus son impact potentiel doit être anticipé.
HypothèseQuel comportement voulait-on tester ?
→
ObservationQue s'est-il réellement passé ?
→
RisqueQuelle conséquence aurait une attaque réelle ?
→
RemédiationQuel contrôle réduit ce risque ?
OBJECTIF DU TEST
|
+-- Contrôles techniques ? ----> Messagerie / identité / endpoint
|
+-- Comportement humain ? -----> Simulation autorisée
| |
| +-- E-mail ----> campagne
| +-- Téléphone -> scénario validé
| +-- Physique --> test d'accès autorisé
|
+-- Résultat observé
|
+-- Signalement correct ------> contrôle efficace
|
+-- Interaction ---------------> analyser le processus
|
+-- Dépassement du périmètre -> arrêter / documenter
Avant
- Périmètre écrit
- Population définie
- Scénarios approuvés
- Critères d'arrêt
Pendant
- Respect du scénario
- Collecte minimale
- Journalisation
- Arrêt en cas d'incident
Après
- Nettoyage
- Analyse agrégée
- Recommandations
- Restitution confidentielle
Checklist Pratique — Social Engineering
- 1. Autorisation d'abord : aucun scénario, même simulé, sans validation écrite préalable du périmètre exact.
- 2. Pretexting : s'appuie sur le renseignement collecté en amont (OSINT) — jamais improvisé sur place.
- 3. GoPhish : outil de référence pour mesurer objectivement une posture de sensibilisation, pas pour piéger.
- 4. Confidentialité : résultats toujours restitués de façon agrégée, jamais nominative.
- 5. Cela conclut la partie exploitation (chapitres 6 à 11) — place maintenant à la sécurité des applications web.