Exercices corrigés Wazuh type E7 et E6 SISR

1. Le récit.

Le point de départ est le poste de l'accueil, d'où sont partis les essais : il est lui-même compromis, ou quelqu'un l'a utilisé physiquement.

Pour l'alerte de 2 h 20, ne te laisse pas guider par la fin de la description : la règle 92657 ajoute « Possible RDP connection » dès que le nom du poste client est renseigné. C'est le type de session 3 qui compte : un accès réseau (un partage), pas une session de bureau à distance (type 10).

2. Qualification. Seule, l'alerte de 1 h 52 aurait pu être bénigne : un utilisateur qui se trompe plusieurs fois de mot de passe. Mais le compte ext-maintenance n'a rien à faire sur le poste de l'accueil, la nuit, hors des créneaux du prestataire. L'ensemble, lui, est sans ambiguïté un vrai positif : réussite après une rafale, script masqué, service installé dans un dossier public, rebond, tentative de sortie, effacement du journal. C'est un incident de sécurité.

3. Les mesures, dans l'ordre.

1. Confiner : isoler srv-gestion du réseau sans l'éteindre (déconnecter son interface virtuelle dans Proxmox), pour garder la mémoire et les traces ; isoler PC-ACCUEIL-02 de la même façon ; désactiver le compte ext-maintenance dans l'annuaire.
2. Préserver les preuves : instantané de srv-gestion avec sa mémoire, export des alertes Wazuh de la nuit (elles sont intactes malgré l'effacement local du journal), journaux du pare-feu.
3. Mesurer l'étendue : chercher dans Wazuh toute activité de ext-maintenance, de 192.168.10.93, de 192.168.10.179 et de l'adresse 203.0.113.66 sur les 30 derniers jours, sur toutes les machines ; examiner srv-fichiers.
4. Prévenir : le responsable (Antoine Mercier), le prestataire (par téléphone, son compte est compromis), et ouvrir la main courante de l'incident.
5. Ensuite : éradiquer (supprimer le service et le programme, ou mieux, restaurer srv-gestion depuis une sauvegarde antérieure à l'intrusion), changer les mots de passe concernés, revenir à la normale sous surveillance renforcée, puis faire le retour d'expérience.

4. Pourquoi personne n'a réagi. Les alertes sont bien parties, mais vers un canal Teams que personne ne lit la nuit : la détection a fonctionné, la réaction n'existait pas. Propositions : une astreinte pour les alertes de niveau 12 et plus, avec une notification qui réveille (appel, SMS) ; ou la surveillance confiée à un prestataire de type MDR ou SOC externalisé, disponible jour et nuit ; et, pour gagner du temps sur les cas évidents, une réponse automatique limitée (par exemple la désactivation d'un compte de prestataire utilisé hors de ses créneaux, décidée à l'avance, documentée et réversible). Et des mesures de prévention : le compte ext-maintenance ne devrait être activé que pendant les interventions planifiées, avec une authentification multifacteur, et seulement depuis le VPN du prestataire, pas depuis un poste interne.

5. La paie. Non. On sait seulement que ext-maintenance a ouvert une session réseau sur srv-fichiers à 2 h 20. Le contrôle d'intégrité des fichiers ne voit que les modifications, pas les lectures, et l'événement de lecture (4663) n'est pas collecté par défaut. Pour le savoir, il faut l'audit des accès aux objets sur le dossier de la paie (sous-catégorie Système de fichiers, plus une liste de contrôle d'accès système sur le dossier) et l'événement 4663 autorisé dans la collecte de srv-fichiers. À défaut, l'enquête doit partir de l'hypothèse que les fichiers ont pu être lus. La tentative de connexion vers Internet bloquée à 2 h 31 suggère une volonté de sortir quelque chose ; le blocage par le pare-feu est un élément rassurant, à confirmer dans ses journaux (aucun flux sortant autorisé depuis srv-gestion cette nuit-là).

6. Les obligations. Les fichiers de la paie contiennent des données personnelles des salariés (identité, salaire, coordonnées bancaires). Si une violation de données personnelles est constatée ou ne peut être écartée, le responsable de traitement doit la notifier à la CNIL dans les 72 heures après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes, et informer les salariés si le risque est élevé ; dans tous les cas, la violation est inscrite au registre des violations. Une plainte peut être déposée (accès frauduleux, article 323-1 du Code pénal). Le prestataire, dont le compte a servi, doit être associé. Voir notifier un incident et le chapitre Violation de données du cours Droit et RGPD.

1. Le niveau 5 correspond à une « erreur d'utilisateur ». Sur un serveur exposé, où seuls deux administrateurs ont des droits, un compte de déploiement qui tente d'obtenir les droits de root n'est pas une maladresse ordinaire : c'est le geste typique d'un attaquant qui vient de prendre ce compte et cherche à monter en privilèges. De plus, le niveau 5 ne déclenche ni courriel ni carte Teams.

2.

<group name="sorbier,sudo,">
  <rule id="100400" level="10">
    <if_sid>5405</if_sid>
    <description>Sorbier : un compte non autorisé a tenté d'utiliser sudo</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

  <rule id="100401" level="12">
    <if_sid>100400</if_sid>
    <match>COMMAND=/bin/bash|COMMAND=/usr/bin/bash|COMMAND=/bin/sh|COMMAND=/usr/bin/su|COMMAND=/bin/su</match>
    <description>Sorbier : un compte non autorisé a tenté d'obtenir un interpréteur root par sudo</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>
</group>

La première s'accroche à 5405 et relève le niveau ; la seconde s'accroche à la première et ne retient que les commandes qui donnent un interpréteur root. T1548.003 est la sous-technique Abuse Elevation Control Mechanism: Sudo and Sudo Caching. La ligne de l'énoncé déclenche la règle 100401, niveau 12.

3. Avec wazuh-logtest sur le serveur : coller la ligne de l'énoncé, vérifier en phase 2 le décodeur sudo et le champ srcuser, en phase 3 la règle 100401 et le niveau 12. Puis, sur le laboratoire, un essai réel : avec le compte de test deploy, taper sudo -i ; l'alerte doit apparaître dans le tableau de bord après le redémarrage de wazuh-manager.

Écarté pour l'instant : l'archivage de tous les événements, les requêtes DNS, Sysmon sur tous les postes. Points à ne pas oublier : ouvrir TCP 1514 (et 1515 le temps de l'inscription) de 10.30.1.161 et .162 vers 192.168.10.180 sur les équipements entre les sites (matrice des flux) ; l'agent garde un tampon si le lien est coupé quelques minutes ; synchroniser l'heure des machines de Marseille sur la même source que Lyon.

1. allowed-ips trop large. 192.168.10.0/24 contient tous les VLAN du siège, y compris le Wi-Fi des visiteurs (192.168.10.0/26) : n'importe quel invité pourrait envoyer de faux messages syslog, que Wazuh analyserait comme s'ils venaient du pare-feu (fausses alertes, ou bruit pour masquer une vraie attaque). Correction : <allowed-ips>192.168.10.190</allowed-ips> pour le pare-feu, plus le réseau de gestion des switchs (192.168.10.208/28) si besoin.
2. Réponse active dangereuse. Un blocage sur tous les agents, sans délai (timeout absent, donc permanent), déclenché par le syslog du pare-feu, une source dont l'adresse se falsifie facilement : un attaquant peut faire bloquer définitivement le contrôleur de domaine sur toutes les machines. Correction : supprimer ce bloc ; un balayage se traite par une notification et, si besoin, une règle posée sur pfSense par un administrateur.
3. Courriel impossible. Wazuh ne gère pas l'authentification SMTP, que Microsoft 365 exige : aucun courriel ne partira. Correction : relais Postfix local (<smtp_server>localhost</smtp_server>) qui transmet au service de messagerie avec la méthode qu'il accepte (authentifié pour un serveur interne, connecteur par adresse IP pour Microsoft 365), et une adresse <email_from>.
4. Seuils absurdes. log_alert_level à 1 enregistre des alertes sans intérêt de sécurité (et multiplie le stockage) ; email_alert_level à 5 envoie un courriel pour chaque mot de passe mal tapé : des centaines par jour, que plus personne ne lira, y compris le jour de la vraie attaque. Correction : revenir à 3 et à 12, et utiliser des blocs <email_alerts> ciblés pour les quelques règles qui doivent prévenir quelqu'un en particulier.

1. La surveillance. Dans /var/ossec/etc/shared/windows-serveurs/agent.conf, ajouter une section qui ne vise que srv-fichiers :

<agent_config name="^srv-fichiers$">
  <syscheck>
    <directories whodata="yes">D:\Partages\Compta</directories>
  </syscheck>
</agent_config>

Vérifier avec sudo /var/ossec/bin/verify-agent-conf -f /var/ossec/etc/shared/windows-serveurs/agent.conf. L'agent reçoit la configuration en quelques minutes ; on le constate dans le tableau de bord (inventaire des fichiers surveillés de l'agent, dans File Integrity Monitoring).

2. La règle. Dans /var/ossec/etc/rules/local_rules.xml :

<group name="sorbier,syscheck,">
  <rule id="100210" level="12" frequency="30" timeframe="60">
    <if_matched_group>syscheck_entry_modified</if_matched_group>
    <same_location />
    <description>Sorbier : 30 fichiers ou plus modifiés en une minute sur une même machine (rançongiciel ?)</description>
    <mitre>
      <id>T1486</id>
    </mitre>
  </rule>
</group>

Puis sudo systemctl restart wazuh-manager et contrôle de ossec.log.

3. La démonstration, sur des fichiers de test et jamais sur de vraies données. Sur srv-fichiers, dans PowerShell :

New-Item -ItemType Directory -Path "D:\Partages\Compta\test-fim" | Out-Null
1..40 | ForEach-Object { Set-Content -Path "D:\Partages\Compta\test-fim\fichier-$_.txt" -Value "test $_" }
Start-Sleep -Seconds 30
1..40 | ForEach-Object { Add-Content -Path "D:\Partages\Compta\test-fim\fichier-$_.txt" -Value "modification" }

La première boucle crée 40 fichiers : 40 alertes 554 (fichier ajouté), avec le compte qui les a créés. La seconde les modifie en quelques secondes : 40 alertes 550 (fichier modifié), et la règle 100210 se déclenche au niveau 12, avec la carte Teams si l'intégration est en place. On montre au jury l'alerte 550 d'un fichier (chemin, syscheck.mode à whodata, syscheck.audit.user.name), puis l'alerte 100210 et sa technique T1486. On termine en supprimant le dossier de test (Remove-Item -Recurse "D:\Partages\Compta\test-fim"), ce qui produit 40 alertes 553 : le nettoyage est lui aussi tracé.

Dans la fiche de la réalisation, noter le seuil choisi et sa justification (l'activité normale du dossier), et la limite : le FIM signale, il ne protège pas ; ce sont les sauvegardes hors ligne qui permettent de récupérer les fichiers.