Cas type E7 corrigé : un incident de bout en bout

Incident de sécurité confirmé : le compte de Thomas Giraud a été utilisé par un tiers. Éléments :

• document 2, ligne 5 : connexion VPN avec le compte t.giraud le samedi 31 octobre à 23:47:12 depuis 203.0.113.201, une adresse située dans un pays où l'entreprise n'a aucune activité, alors que ses connexions habituelles viennent de sa box (192.0.2.40, lignes 1 à 3) ; le SIEM l'a signalée (document 4, règle 100210) ;
• document 3 : ouverture de session à distance (4624, type 10) sur SRV-FIC depuis 10.8.0.14, l'adresse VPN attribuée à cette connexion (document 2, ligne 6), puis lecture de 2 870 fichiers du partage Commercial et lancement de rc.exe depuis un dossier temporaire avec une commande de copie vers une destination externe ;
• document 6 : 6 658 192 345 octets (environ 6,7 Go, soit 6,2 Gio) envoyés de SRV-FIC vers 198.51.100.88 entre 00:22 et 02:47, heure de Paris (le journal est en UTC ; le 1er novembre, Paris est à UTC+1) ;
• document 5 : export de la liste des 1 842 clients à 01:10:33 avec le compte t.giraud depuis 10.8.0.14 ;
• contexte : Thomas Giraud a saisi ses identifiants sur une page piégée le vendredi, et des courriels frauduleux sont partis de sa boîte lundi à 7 h 55.

Aucun de ces éléments n'est compatible avec une activité légitime : le samedi à minuit, Thomas Giraud n'était pas connecté depuis l'étranger.

Vecteur d'accès initial : l'hameçonnage. L'attaquant a obtenu le mot de passe de Thomas Giraud par une fausse page de connexion Microsoft 365, puis l'a utilisé sur le VPN (le même compte de l'annuaire sert pour la messagerie et le VPN). C'est l'utilisation d'un compte valide (MITRE T1078).

Faiblesses (trois parmi) :

• pas de double authentification pour les comptes non administrateurs, ni sur le VPN ni sur Microsoft 365 (document 7) : le mot de passe seul suffisait ;
• les clients VPN accèdent à tout le VLAN des serveurs, sur tous les ports (document 1) : un commercial n'a aucun besoin d'ouvrir une session RDP sur le serveur de fichiers ;
• les serveurs joignent Internet sans restriction (document 1) : rien n'empêchait SRV-FIC d'envoyer 6,7 Go vers une destination inconnue ;
• les alertes ne sont lues que les jours ouvrés (document 4) : l'alerte de niveau 12 de 00:44 est restée sans réponse pendant près de 32 heures, et les alertes de niveau inférieur ne sont pas notifiées du tout ;
• le TMS n'applique pas sa matrice d'habilitations : un commercial a pu exporter toute la liste des clients (documents 5 et 9).

• Confidentialité : atteinte, c'est l'impact principal. Les fichiers du partage Commercial (contrats, tarifs, contacts) ont été copiés vers l'extérieur et la liste des clients exportée.
• Intégrité : atteinte au sens de l'authenticité des échanges : des courriels frauduleux ont été envoyés au nom de Thomas Giraud depuis sa vraie boîte, ce qui trompe les clients. Aucune modification des fichiers n'est constatée à ce stade.
• Disponibilité : non atteinte : aucun service n'a été interrompu.
• Preuve : préservée grâce à la journalisation centralisée : chaque étape est tracée, avec le compte, l'adresse et l'heure. Mais l'imputabilité montre ses limites : les actions sont attribuées au compte de Thomas Giraud alors qu'il n'en est pas l'auteur, ce que seule l'analyse de l'adresse source et du contexte permet d'établir.

Quatre parmi :

1. Désactiver le compte t.giraud dans l'annuaire, réinitialiser son mot de passe et révoquer ses sessions ouvertes dans Microsoft 365 : l'attaquant utilise encore la boîte (courriels de 7 h 55). Vérifier et supprimer les règles de transfert ou de suppression qu'il a pu créer dans la boîte pour cacher les réponses des clients.
2. Bloquer sur le pare-feu les adresses 203.0.113.201 (connexion VPN) et 198.51.100.88 (destination de l'exfiltration), et fermer toute connexion VPN en cours de ce compte.
3. Prévenir les clients destinataires des courriels frauduleux de ne pas cliquer ni payer, et retirer ces messages des boîtes internes s'ils y ont été envoyés : la fraude est en cours.
4. Restreindre en urgence l'accès VPN au VLAN des serveurs (plus de RDP depuis le réseau des nomades vers les serveurs, sauf comptes d'administration) et bloquer les flux sortants de SRV-FIC vers Internet.
5. Rechercher les mêmes indicateurs de compromission (adresses, nom rc.exe, connexions VPN depuis des pays inhabituels) pour les autres comptes et serveurs, afin de vérifier que l'attaque ne s'est pas étendue.

Avis : non. La réinstallation détruirait les traces de l'attaque sur le serveur (fichier rc.exe, sa configuration, qui contient peut-être les identifiants du dépôt de l'attaquant, l'historique de la session, la mémoire), utiles à l'enquête, à la plainte et à l'assureur. Elle n'est d'ailleurs pas justifiée à ce stade : l'attaquant a utilisé un compte sans privilège d'administration, et rien n'indique une compromission du système lui-même. On vérifie d'abord l'absence de persistance (tâches planifiées, services, comptes créés) avant de décider.

Préserver :

• prendre un instantané de la machine virtuelle SRV-FIC avec sa mémoire, ou une capture de la mémoire puis une image du disque ;
• exporter depuis le SIEM les journaux du pare-feu, de SRV-FIC et du TMS sur la période, et copier rc.exe et son fichier de configuration ;
• calculer l'empreinte SHA-256 de chaque élément au moment de la collecte et la noter ;
• tenir la chaîne de possession (qui a collecté quoi, quand, avec quel outil, où c'est stocké, à qui c'est remis) ;
• tout consigner dans la main courante ;
• conserver aussi les journaux de Microsoft 365 (connexions, règles de boîte, messages envoyés), dont la durée de conservation est limitée.

Y a-t-il une violation de données personnelles ? Oui. Le fichier des contacts clients (document 8) contient les noms, prénoms, fonctions, courriels et téléphones des interlocuteurs de 1 842 entreprises : ce sont des données personnelles, même dans un contexte professionnel. Elles ont été copiées et exportées par un tiers : violation de confidentialité (article 4 du RGPD).

Obligations :

• inscrire la violation au registre des violations (article 33, paragraphe 5), comme toute violation ;
• notifier la CNIL dans les 72 heures après la prise de connaissance (article 33) : le risque pour les personnes n'est pas improbable, il est déjà réalisé, puisque des courriels frauduleux visent ces contacts ;
• informer les personnes concernées dans les meilleurs délais (article 34) : le risque est élevé (hameçonnage et fraude au paiement en cours, avec des messages crédibles envoyés depuis la vraie boîte d'un commercial). Aucune exception ne s'applique (données non chiffrées). L'information individuelle est réaliste (les adresses sont connues).

Autres démarches : porter plainte (accès frauduleux à un système, articles 323-1 et suivants du Code pénal), au plus tard 72 heures après la connaissance de l'atteinte si l'entreprise veut être indemnisée par son assureur (article L12-10-1 du Code des assurances) ; déclarer le sinistre à l'assureur ; s'informer et se faire aider via 17Cyber ou le CSIRT régional. Le dossier n'indique pas que Transports Lagarde soit OIV ou OSE : à défaut, pas d'obligation de déclaration à l'ANSSI à ce jour. Au 1er novembre 2026, la loi qui transpose NIS 2 n'est pas adoptée ; une fois qu'elle sera en vigueur, il faudra vérifier si l'entreprise entre dans son champ (secteur d'activité et taille), auquel cas elle devra signaler ses incidents importants sous 24 heures, puis 72 heures.

Si l'on retient comme point de départ la prise de connaissance par la RSSI, le lundi 2 novembre 2026 à 8 h 40, l'échéance est le jeudi 5 novembre 2026 à 8 h 40.

Discussion : le SIEM a signalé l'exfiltration dès le dimanche à 0 h 44 (alerte de niveau 12, document 4), mais personne ne l'a lue. Le délai court à partir du moment où l'organisation a pris connaissance de la violation avec un degré raisonnable de certitude : une alerte non lue n'est pas une prise de connaissance, mais un contrôle pourrait reprocher à l'entreprise de ne pas s'être organisée pour traiter ses alertes. La prudence commande de notifier sans attendre, dès le lundi ou le mardi, quitte à compléter ensuite, et d'expliquer le délai de détection dans la notification.

Proposition :

« Dans la nuit du 31 octobre au 1er novembre, un attaquant a utilisé le mot de passe de Thomas Giraud, volé vendredi par un faux courriel Microsoft 365, pour se connecter au VPN depuis l'étranger. Il a copié près de 7 Go de documents commerciaux (contrats, tarifs) et la liste des contacts de nos 1 842 clients, puis a envoyé lundi matin de fausses factures à des clients depuis la boîte de M. Giraud. Le compte est bloqué, les adresses de l'attaquant aussi, les clients sont prévenus. Il s'agit d'une violation de données personnelles : nous notifions la CNIL avant jeudi 8 h 40 et déposons plainte aujourd'hui. Causes : pas de double authentification sur le VPN et la messagerie, accès trop large du VPN aux serveurs, alertes non surveillées le week-end. Décisions attendues : généraliser la double authentification et organiser le traitement des alertes hors des heures ouvrées. »

Règle : une connexion VPN réussie depuis un pays inhabituel ou depuis une adresse jamais vue pour ce compte, suivie dans les 30 minutes d'une ouverture de session à distance (4624 de type 10) sur un serveur avec le même compte, déclenche une alerte critique (niveau 12 ou plus). La gravité monte encore si elle est suivie d'un volume sortant anormal depuis ce serveur.

Prise isolément, chaque étape n'est qu'un signal faible (niveaux 6 et 8 dans le document 4) ; c'est leur enchaînement, avec le même compte et l'adresse VPN qui fait le lien, qui caractérise l'attaque.

Traitement : les alertes critiques ne doivent pas arriver seulement dans une boîte aux lettres lue les jours ouvrés. Il faut une astreinte (notification par SMS ou appel) ou un SOC externalisé qui surveille en continu, avec une procédure écrite : qui qualifie, qui peut désactiver un compte ou couper un accès VPN la nuit, qui prévenir.

a) Priorité = catégorie × 8 + gravité = 19 × 8 + 5 = 157.

b) auth.warning : sans le signe =, le sélecteur prend la gravité warning et toutes les plus graves (err, crit, alert, emerg).

c) En UDP, syslog n'a ni accusé de réception, ni chiffrement, ni authentification : des événements peuvent être perdus (perte de disponibilité de la trace), lus sur le réseau (les noms des comptes et les adresses circulent en clair) ou falsifiés par un tiers qui envoie de faux messages (perte d'intégrité, preuves contestables). Syslog sur TLS (port 6514) garantit la livraison grâce à TCP, chiffre les échanges et authentifie l'émetteur et le collecteur par certificats.

Trois parmi :

• Double authentification sur le VPN et sur Microsoft 365 pour tous les comptes (étape : accès initial). Le mot de passe volé n'aurait pas suffi. Pour la messagerie, des méthodes résistantes à l'hameçonnage (clés de sécurité, passkeys) évitent aussi le vol des codes à usage unique par une page piégée.
• Filtrage entre le réseau VPN et les serveurs (étape : mouvement vers le serveur de fichiers). Les commerciaux n'ont besoin que du TMS et de quelques partages, en SMB ; le RDP vers les serveurs doit être réservé aux comptes d'administration, depuis le VLAN d'administration. Application du principe du moindre privilège au réseau.
• Filtrage des flux sortants des serveurs (étape : exfiltration). Un serveur de fichiers n'a pas à joindre n'importe quelle adresse en HTTPS ; ses mises à jour passent par un proxy ou un serveur de mises à jour interne. Les 6,7 Go n'auraient pas pu sortir.
• Restriction géographique ou par adresse des connexions VPN, et accès conditionnel sur Microsoft 365 (étape : accès initial) : refuser les connexions depuis les pays où l'entreprise n'opère pas, ou exiger une vérification supplémentaire.
• Blocage de l'exécution depuis les dossiers temporaires des profils sur les serveurs (étape : installation de l'outil de copie), par une stratégie de contrôle des applications.

Le script vérifie seulement qu'un utilisateur est connecté (session.php renvoie 401 sinon), mais jamais son rôle. Or la matrice des habilitations réserve l'export au rôle direction. N'importe quel compte authentifié, ici un commercial dont le mot de passe a été volé, peut donc appeler api/clients_export.php et récupérer toute la liste. C'est un contrôle d'accès défaillant : authentification n'est pas autorisation.

Catégorie OWASP : A01, contrôle d'accès défaillant (Broken Access Control), en tête du Top 10 de l'OWASP (sécurité des applications).

Le journal fonctionne (document 5 : il a permis de voir l'export, avec le compte, le rôle et l'adresse), mais rien ne réagit : un export complet par un rôle non autorisé aurait dû être refusé et déclencher une alerte.

À insérer juste après les trois require, avant la requête SQL :

// Contrôle d'accès : seul le rôle direction peut exporter la liste des clients
if (($_SESSION['role'] ?? '') !== 'direction') {
    journaliser('CLIENT_EXPORT_DENIED', ['reason' => 'role']);   // ajoute user, role et ip
    http_response_code(403);
    exit('Accès refusé');
}

Points attendus :

• la vérification se fait côté serveur, à chaque appel, avant toute lecture de données ;
• le refus renvoie le code 403 (interdit), et non 401 : l'utilisateur est authentifié mais pas autorisé ;
• le refus est journalisé avec un événement distinct (CLIENT_EXPORT_DENIED), sur lequel le SIEM peut poser une alerte : plusieurs refus d'affilée sont un signal d'attaque ;
• le rôle est lu dans la session, jamais dans un paramètre envoyé par le client ($_GET['role'] serait trivial à falsifier).

Amélioration possible : une ré-authentification avant un export complet et une limite du nombre d'exports par jour.

a)

SELECT login, role, COUNT(*) AS nb_exports, SUM(nb_lignes) AS total_lignes
FROM journal_appli
WHERE evenement = 'CLIENT_EXPORT'
  AND role <> 'direction'
  AND date_heure >= NOW() - INTERVAL 7 DAY
GROUP BY login, role;

b)

SELECT login, COUNT(*) AS nb_connexions
FROM journal_appli
WHERE evenement = 'LOGIN_OK'
  AND ip LIKE '10.8.0.%'
  AND (HOUR(date_heure) >= 22 OR HOUR(date_heure) < 6)
  AND date_heure >= DATE_FORMAT(CURDATE(), '%Y-%m-01')
GROUP BY login;

Dans b), la plage de nuit chevauche minuit : il faut un OR (après 22 h ou avant 6 h), un BETWEEN 22 AND 6 ne renverrait rien. DATE_FORMAT(CURDATE(), '%Y-%m-01') donne le premier jour du mois en cours. Le filtre LIKE '10.8.0.%' correspond exactement au réseau 10.8.0.0/24 puisque les adresses y vont de 10.8.0.0 à 10.8.0.255.