Compte de service à privilèges compromis et exfiltration nocturne

Les soixante premières minutes, ordre et justification :

1. Isoler au réseau, pas éteindre. Désactiver le port de switch de WS-COMPTA-07 et de SRV-FS01, ou les basculer en VLAN de quarantaine. Ne pas couper l'alimentation : la mémoire contient les clés de chiffrement, l'historique des commandes et parfois le binaire encore en cours, et un arrêt brutal peut déclencher l'effacement des preuves. L'isolation réseau coupe l'exfiltration et le mouvement latéral sans détruire les données volatiles.

2. Désactiver les comptes compromis et révoquer les tickets. Désactiver svc_backup, réinitialiser son mot de passe, purger les tickets Kerberos (klist purge sur les machines concernées, réinitialisation des sessions côté DC). Tant qu'un TGT valide circule, la désactivation du compte ne suffit pas.

3. Bloquer la destination externe au pare-feu tout en conservant les journaux. La règle doit être journalisée : on veut la preuve du volume et des horaires, pas seulement la coupure.

4. Préserver les preuves avant toute remédiation : export des journaux EDR, copie des journaux de sécurité (4624, 4625, 4672, 4768, 4769, 5140, 5145), journaux du pare-feu et du proxy, capture mémoire et image disque si l'outillage le permet.

5. Qualifier l'étendue avant de décider de la reprise. svc_backup est administrateur du domaine : il faut considérer le domaine comme compromis tant que l'inverse n'est pas prouvé. Cela implique un plan de réinitialisation des comptes à privilèges, voire du double krbtgt, et non la simple remise en route du serveur de fichiers.

6. Communiquer et décider du redémarrage de la facturation : rien n'indique qu'elle soit touchée, mais elle doit être isolée et ses authentifications auditées avant réouverture.

Construire la chronologie et la carte de la compromission :

• Sur DC01, filtrer les événements 4624 (types 3 et 10) pour svc_backup sur toute la période, puis 4768 et 4769 pour suivre les demandes de tickets, et 4672 pour repérer les connexions avec privilèges élevés. Un 4769 avec chiffrement RC4 ou un type de ticket anormal évoque un Kerberoasting.
• Sur SRV-FS01, exploiter 5140 et 5145 pour savoir quels partages ont été lus, et repérer la création d'une archive de plusieurs dizaines de gigaoctets entre 3 h 15 et 3 h 40. Rechercher les tâches planifiées et services créés par svc_backup ces dernières semaines (Get-ScheduledTask, événements 4698 et 7045).
• Sur WS-COMPTA-07, examiner l'arbre de processus EDR : quel binaire a lancé PsExec, depuis quel script, avec quelles options. Chercher une origine distante (RDP, VPN) dans les journaux du pare-feu.
• Expliquer l'angle mort de la sonde réseau. L'EDR voit une connexion sortante de 38 Go que la sonde ne voit pas : soit la sonde n'est pas sur le bon segment ou travaille en NetFlow échantillonné, soit le trafic emprunte un chemin non supervisé. Vérifier l'emplacement du port miroir et comparer avec les journaux du pare-feu et du proxy en sortie. C'est une conclusion en soi : la supervision doit être corrigée pour que le prochain incident soit vu.

Sur les sauvegardes : vérifier si le NAS a été monté ou chiffré, si des clichés ont été supprimés, et si une copie hors ligne existe. Sans copie saine, la reprise peut être impossible.

Mesures structurelles, par ordre d'impact :

1. Sortir le compte de sauvegarde des Admins du domaine. Utiliser un compte de service géré (gMSA) avec mot de passe géré par l'AD, ou un compte dédié limité aux partages et aux API strictement nécessaires. Un compte de sauvegarde n'a jamais besoin d'être administrateur de domaine sur une station de travail.
2. Modèle de tiers. Les comptes d'administration des DC (tier 0) ne se connectent jamais sur un poste utilisateur ; les postes d'administration sont dédiés, à accès restreint et sans messagerie. La connexion interactive de svc_backup sur WS-COMPTA-07 doit devenir impossible par stratégie : refus de connexion locale et RDP pour les comptes de service.
3. Cloisonner. Un pare-feu entre le VLAN des postes et celui des serveurs, avec refus de SMB (445), RPC (135) et WinRM (5985-5986) depuis les postes vers les serveurs sauf flux identifiés. Ici, PsExec n'aurait pas fonctionné.
4. Sauvegardes hors d'atteinte. Copie immuable ou bande hors ligne, avec des identifiants distincts de ceux du domaine et un compte de sauvegarde qui ne peut pas supprimer les sauvegardes. Appliquer la règle 3-2-1-1-0.
5. Détection. Alerter sur l'usage d'un compte de service hors fenêtre de sauvegarde, sur les connexions de type 10 avec un compte de service, sur l'exécution de PsExec et sur toute sortie de plus de 5 Go vers une destination inhabituelle. Aujourd'hui, c'est l'EDR qui a vu, cinq heures trop tard.
6. Hygiène des comptes. Rotation des secrets, inventaire des comptes à privilèges, LAPS pour les administrateurs locaux, MFA sur les accès VPN et d'administration. Un mot de passe inchangé depuis quatre ans sur un compte administrateur du domaine est la cause racine la plus probable.