Chapitre 2 : Menaces, logiciels malveillants et ingénierie sociale

Accéder au laboratoire pratique et aux trois nouveaux exercices corrigés

Objectifs du chapitre

• Reconnaître les principaux mécanismes d’attaque.
• Analyser un message sans ouvrir ses liens.
• Choisir une réaction adaptée à un doute ou à un clic.

1. L’attaque exploite aussi la confiance

L’ingénierie sociale cherche à obtenir une action d’une personne : communiquer un secret, installer un logiciel, modifier un paiement ou ouvrir un accès. Le message peut imiter une direction, une banque ou un support informatique. L’attaquant exploite l’urgence, l’autorité, la curiosité ou la peur de perdre un service. Une orthographe correcte et une présentation professionnelle ne suffisent donc pas à établir la confiance.

Le phishing, ou hameçonnage, utilise des messages trompeurs pour attirer une victime vers une action dangereuse. Il peut arriver par courriel, SMS, messagerie ou QR code. Une demande personnalisée visant une personne précise est souvent appelée spear phishing. Le téléphone peut également servir à persuader une personne de révéler un code ou de valider une connexion.

Chez GeniusCampus, un faux prestataire demande de remplacer son numéro de compte bancaire « avant 17 heures ». Le bon réflexe est une confirmation par un canal déjà connu, par exemple le numéro figurant dans le contrat. Répondre au message suspect ou appeler le numéro qu’il fournit maintient le contact avec son auteur.

2. Lire un message avec méthode

Exemple fictif : https://campus.example.connexion-aide.test/validation. Le texte commence par « campus.example », mais l’hôte complet est campus.example.connexion-aide.test. Dans cet exemple, le suffixe contrôlé est connexion-aide.test, pas campus.example. La terminaison .test sert ici à un exemple réservé. Dans le monde réel, les suffixes publics sont plus variés : il faut connaître le domaine officiel attendu, pas simplement compter les points.

Le HTTPS peut aussi être présent sur un faux site : il protège le transport vers le domaine visité, pas l’honnêteté de son propriétaire. Sur un téléphone, où l’adresse est tronquée, ouvrez le service par son application ou un favori enregistré. N’ouvrez pas un lien uniquement pour « voir si le site est faux ».

3. Les logiciels malveillants

Un logiciel malveillant est conçu pour réaliser une action nuisible. Un rançongiciel peut rendre les fichiers indisponibles et s’accompagner d’un vol de données. Un cheval de Troie se présente comme un programme utile. Un logiciel espion collecte des informations. Ces catégories décrivent des comportements qui peuvent se combiner ; elles ne désignent pas toujours des programmes séparés.

Une infection peut partir d’un exécutable téléchargé, d’un document piégé, d’une vulnérabilité ou d’une mise à jour compromise. Un antivirus peut arrêter certaines menaces, mais la limitation des droits, les mises à jour, les restrictions d’installation et les sauvegardes restent nécessaires. Un poste compromis peut parfois être utilisé sans signe visible : absence de fenêtre inquiétante ne signifie pas absence de problème.

Les attaques contre les comptes n’exigent pas forcément un malware. Le bourrage d’identifiants réutilise des couples adresse–mot de passe issus d’autres fuites. Les tentatives par force brute essaient des secrets ; les mesures de limitation et de détection aident à les contenir. Un mot de passe unique évite qu’une fuite externe ouvre automatiquement plusieurs services.

4. Interrompre la chaîne

Dans notre cas fictif, le message attire vers une page de connexion, la victime saisit son mot de passe, puis l’auteur du message utilise le compte pour consulter les dossiers. On peut agir à plusieurs étapes : sensibilisation avant le clic, filtre de messagerie, authentification résistante au phishing, accès restreint aux dossiers et alerte sur un export inhabituel. Aucune de ces couches ne dispense des autres.

Si vous avez seulement reçu un message suspect, utilisez le mécanisme de signalement prévu et évitez de le transférer à toute l’équipe avec ses pièces jointes. Si vous avez saisi un secret, avertissez rapidement le support par le canal officiel. Depuis un appareil de confiance, faites modifier le secret exposé, révoquer les sessions concernées et vérifier les modifications du compte. Le chapitre 8 détaille l’organisation de cette réponse.

Si un programme a été exécuté, décrivez précisément ce qui s’est passé. Ne multipliez pas les essais sur le poste : ils peuvent modifier les traces. La réaction dépend du contexte et de la procédure interne. Signaler vite sans culpabiliser les personnes permet souvent de limiter l’impact.

5. Atelier de tri sans cliquer

Préparez trois messages fictifs : une facture attendue, une demande de paiement inhabituelle et une alerte de connexion. Pour chaque message, notez ce qui est demandé, pourquoi la demande est plausible, les éléments vérifiables et le canal utilisé pour confirmer. Une alerte réelle doit aussi être vérifiée par l’accès habituel au compte. L’objectif est une démarche répétable, pas une collection de détails visuels à mémoriser.

Exercices et corrigés

Essayez de répondre avant de déplier les corrigés. Les situations et données sont fictives.

Sources officielles et approfondissements

Repères consultés le 14 octobre 2026. Les cas GeniusCampus et les schémas sont des exemples pédagogiques originaux.

• CISA : Repères de sensibilisation
• OWASP : Authentification

Laboratoire 2 : Construire un modèle de menaces et examiner un message suspect

Objectif : Relier un actif, une frontière de confiance, une menace et un contrôle à une preuve concrète. Durée indicative : 40 minutes.

Le portail pédagogique NKILItech reçoit des demandes, stocke des pièces fictives et permet à un agent de consulter les dossiers qui lui sont attribués. Une frontière sépare le navigateur, contrôlé par l’utilisateur, de l’API. Une autre sépare les permissions de l’API de celles de la base. Une donnée ne devient pas fiable simplement parce qu’elle provient d’un formulaire du site.

Le modèle de menaces donne un support de discussion : ce que l’on protège, ce qui peut arriver, les mesures prévues et la façon de les vérifier. Il doit distinguer une menace possible d’un incident constaté. Une liste de noms de vulnérabilités sans scénario ne décrit pas encore le risque du portail.

Manipulations guidées

1. Lister quatre actifs : dossiers, comptes, sauvegardes et journaux. Décrire pour chacun un propriétaire, un usage et l’impact d’une perte de confidentialité, d’intégrité ou de disponibilité.
2. Tracer les flux navigateur → API → base et API → journaux. Placer les contrôles d’identité et d’autorisation côté API. Les journaux ne doivent pas devenir une copie des secrets transmis.
3. Étudier le message fictif : « Service NKILItech, urgence : vérifiez votre compte à https://nkilitech-support.example/verification ». Le domaine .example est un domaine de démonstration : ne rien ouvrir ni envoyer.
4. Identifier l’urgence imposée, la demande inhabituelle et l’adresse distincte du canal approuvé. Le nom affiché seul ne prouve pas l’identité de l’expéditeur ; inversement, une faute de langue n’est pas une preuve suffisante de fraude.
5. Rédiger une réponse opérationnelle : interrompre l’action, vérifier via un contact déjà connu et signaler le message selon la procédure du cours. Ne pas répondre au lien ou au numéro fourni par le message suspect.

Résultats attendus et preuves à conserver

Un tableau de quatre lignes : actif, scénario, contrôle, test. Exemple : dossier d’Amina ; Boris change un identifiant ; contrôle de propriétaire côté API ; requête de Boris refusée sur le dossier d’Amina.

Limites de la démonstration

Un modèle de menaces dépend d’hypothèses ; le faire évoluer lorsque les flux ou les droits changent. Cet atelier analyse un message fictif et n’envoie aucune simulation de phishing.

Télécharger les ateliers Python complets, le journal fictif et le modèle de rapport · Mode d’emploi et code complet

Trois exercices d’application corrigés

1. Positionner le contrôle

Le navigateur masque le bouton Exporter pour Boris. Est-ce une protection suffisante ?

Voir le corrigé 1

Non : l’interface est modifiable par son utilisateur. L’API doit vérifier l’autorisation au moment de la demande d’export. Le masquage reste une aide ergonomique, pas une preuve de sécurité.

2. Qualifier une preuve

Trois indices rendent le message suspect. Peut-on conclure à une compromission du compte ?

Voir le corrigé 2

Non. Les indices justifient une vérification ou un signalement. Une compromission exige des éléments supplémentaires, par exemple une utilisation non autorisée confirmée ; suspicion et incident prouvé doivent rester distincts.

3. Définir un test utile

Proposer un test de confidentialité pour deux comptes fictifs Amina et Boris.

Voir le corrigé 3

Amina lit son propre dossier ; Boris lit le sien ; chacun reçoit un refus pour le dossier de l’autre ; une session absente reçoit également un refus. Les essais portent sur les réponses du serveur, pas seulement sur les boutons visibles.

Références du laboratoire

• Modélisation des menaces OWASP

Complément original PandaCodeur, cas NKILItech fictif. Les interfaces de WebGoat peuvent évoluer : relever la version et le titre de la leçon suivie.