Compte de service compromis : contenir sans détruire la preuve
Une PME de 45 salariés (agroalimentaire, 8 M€ de chiffre d'affaires) exploite un pare-feu FortiGate 60F, un accès VPN SSL ouvert à 8 télétravailleurs et un NAS de sauvegarde piloté par le compte de service backup_svc. Le MFA est imposé à tous les comptes nominatifs, mais a été volontairement exclu sur les comptes de service lors de la migration de 2023. Le 12 mars, la supervision relève 214 échecs d'authentification VPN entre 02 h 11 et 02 h 17, depuis 5 adresses IP réparties dans 3 pays, puis une authentification acceptée à 02 h 19 sur backup_svc. À 03 h 40, 38 Go sont lus sur le partage « compta », sans aucune écriture. La sauvegarde nocturne sur bande existe, mais aucune restauration n'a été testée depuis 14 mois. Le directeur veut couper le VPN et le NAS immédiatement ; l'exploitant propose d'attendre l'analyse des journaux.
1. Qualifiez l'événement et fixez l'ordre des actions des 30 premières minutes. Faut-il couper immédiatement le VPN et le NAS comme le demande le directeur ?
Read the worked answer
Qualification. On a une attaque par force brute (214 échecs en 6 minutes, 5 IP, 3 pays) qui aboutit : c'est une compromission authentifiée, pas un simple scan. L'accès en lecture seule de 38 Go sur « compta » oriente vers une exfiltration ou une reconnaissance ; aucune écriture ni chiffrement n'est observé, donc pas d'indice de rançongiciel à ce stade. L'atteinte porte sur la confidentialité.
Ordre des actions.
- Geler la scène avant toute coupure : exporter les journaux FortiGate, NAS et contrôleur de domaine, vérifier la synchronisation NTP (des horodatages décalés ruinent la chronologie).
- Contenir de façon ciblée : désactiver backup_svc, révoquer ses sessions VPN actives, bloquer les 5 IP en périphérie, placer le NAS dans une ACL restrictive.
- Réinitialiser le secret du compte partout où il est utilisé (NAS, tâches de sauvegarde, hyperviseur, scripts).
- Chercher la persistance : comptes locaux créés, tâches planifiées, clés SSH autorisées, règles de pare-feu ajoutées.
- Mesurer le volume sortant pour confirmer ou infirmer l'exfiltration.
Décision. Couper le VPN pour tous les télétravailleurs serait disproportionné et coûteux ; éteindre le NAS détruirait la mémoire vive et les sessions, donc la preuve. On isole le NAS du réseau sans l'éteindre. Si la violation de données personnelles est confirmée, la notification CNIL s'impose sous 72 h.
2. Le compte backup_svc ne peut pas recevoir un MFA interactif. Proposez trois mesures de sécurisation compatibles avec des sauvegardes nocturnes et précisez le risque résiduel de chacune.
Read the worked answer
1. Coffre de secrets avec rotation automatique. Le mot de passe est stocké dans un coffre (type Vault, Keeper, Bitwarden Secrets Manager) et injecté au job au moment de l'exécution, avec rotation tous les 30 jours. Risque résiduel : si l'hôte qui exécute le job est compromis, le secret est lisible en mémoire pendant la fenêtre de sauvegarde. Il faut donc durcir cet hôte et journaliser chaque lecture de secret.
2. Authentification par certificat ou compte de service managé (gMSA). Le compte n'a plus de mot de passe utilisable : un certificat client à durée courte, ou un gMSA dont Windows gère la rotation, authentifie le serveur de sauvegarde. Risque résiduel : le vol du certificat ou de la clé de l'hôte permet l'usurpation jusqu'à expiration ; prévoir une révocation et une durée de vie de quelques jours.
3. Restriction par source et moindre privilège. Le compte n'est autorisé que depuis l'adresse du serveur de sauvegarde (règle VPN/pare-feu), et ses droits sur le partage « compta » sont limités au strict nécessaire - idéalement un compte distinct par périmètre. Risque résiduel : une usurpation depuis l'hôte légitime reste possible ; la détection repose sur l'analyse comportementale (heure, volume, chemin).
À combiner avec une alerte sur toute authentification hors fenêtre de sauvegarde : c'est cette alerte qui aurait fait échouer l'attaque à 02 h 19.
3. Le directeur refuse tout budget supplémentaire et demande de « fermer le VPN, ça suffit ». Expliquez en quoi cette mesure est insuffisante et proposez un plan à coût quasi nul pour les 30 jours suivants.
Read the worked answer
Pourquoi c'est insuffisant. Le VPN n'est que le point d'entrée observé. Rien ne prouve que l'attaquant n'a pas déposé un accès alternatif (compte local, tâche planifiée, clé SSH, règle de redirection de port). Fermer le VPN coupe aussi la production des 8 télétravailleurs et donne un faux sentiment de sécurité : si la persistance existe, l'attaquant revient par un autre chemin. Enfin, fermer sans collecter les journaux revient à détruire les seules preuves disponibles.
Plan à coût quasi nul.
- Activer l'authentification à deux facteurs sur le portail VPN administrateur et sur les comptes à privilèges (fonction native du FortiGate).
- Créer une règle de blocage géographique ou une liste d'IP autorisées pour le VPN.
- Activer la journalisation centralisée gratuite (syslog vers un poste dédié) et une alerte courriel sur échec répété.
- Revoir les droits du compte de sauvegarde sur le partage « compta » : la lecture intégrale n'est pas nécessaire à une sauvegarde si un instantané est utilisé.
- Tester une restauration sur un disque externe : coût matériel nul, et cela valide enfin la stratégie de sauvegarde.
- Recenser les comptes de service et supprimer ceux qui sont inutilisés.
Ces actions ne coûtent que du temps ; elles réduisent fortement la surface d'attaque sans bloquer l'activité.