Comptes de service : risques et mitigations Active Directory 2025

Les comptes de service (service accounts) dans Active Directory sont la cible n°1 des pentesters AD depuis 2014 et la popularisation du Kerberoasting par Tim Medin. Selon les retours PASSI français 2024 (Synacktiv, Almond, Wavestone Cyber), 60 à 80 % des pentests internes AD démontrent une chaîne d'escalade Kerberoasting exploitable en 1-3 jours — et cette chaîne passe presque systématiquement par un compte de service avec SPN configuré et mot de passe faible. Cinq classes de risques structurels se cumulent : SPN accessible à tout user authentifié (par design Kerberos, fonctionnalité standard), mots de passe persistants faibles (créés il y a 10-15 ans, jamais rotationnés, 8-14 caractères non-aléatoires), privilèges excessifs (15-30 % sont DA ou Local Admin multi-serveurs selon audits 2024), absence de rotation (< 30 % des organisations rotent leurs service accounts annuellement), absence de MFA et Conditional Access (contraintes techniques et applicatives). Les attaques dominantes sont Kerberoasting (T1558.003 MITRE), Silver Ticket (T1558.002, forge de TGS après compromission), Shadow Credentials (CVE-2021-33757, attaque msDS-KeyCredentialLink), ACL abuse via comptes service sur-délégués. La mitigation prioritaire 2025 est la migration vers gMSA (Group Managed Service Account) — introduits Windows Server 2012, qui offrent rotation automatique 30 jours d'un mot de passe 240 octets aléatoires, incrackable par conception. Tous les services ne supportent pas gMSA (SQL Server 2012+, IIS, Exchange certains rôles oui ; applications métier legacy souvent non) — un inventaire exhaustif de compatibilité est la première étape, avec remplacement progressif sur 6-18 mois selon périmètre. Pour les comptes incompatibles gMSA, les alternatives sont gestion PAM (CyberArk, Delinea, BeyondTrust avec rotation automatique + vault + session recording) ou migration vers identités cloud-native (AWS IRSA, Azure Workload Identity, GCP Workload Identity Federation) pour les workloads modernisés. Cet article détaille les 4 types de comptes de service Windows, les 5 classes de risques, les attaques dominantes avec commandes concrètes, la migration gMSA pas-à-pas, le cas cloud NHI, et la détection via Microsoft Defender for Identity + règles SIEM custom. Pour le contexte Kerberos sous-jacent, voir Kerberos expliqué. Pour le panorama AD comme cible, Pourquoi Active Directory est une cible majeure.

1. Qu'est-ce qu'un compte de service

1.1 Définition

Un compte de service est un compte Active Directory dédié à l'exécution d'un service, application ou script, sans interaction humaine directe. Il sert à :

• Authentifier un service Windows (SQL Server, Exchange, IIS, SharePoint).
• Exécuter des tâches planifiées (backup, ETL, orchestration).
• Connecter des applications à des ressources AD (LDAP, Kerberos, SMB).
• Faire fonctionner des agents (monitoring, antivirus, backup, EDR).

1.2 Caractéristiques typiques

1.3 Pourquoi les comptes de service sont structurellement à risque

Les 4 traits qui convergent vers la vulnérabilité
──────────────────────────────────────────────────
 
1. Créé « pour que ça marche » il y a 10-15 ans
2. Password facile à mémoriser / partager (Service123!, Password2014, etc.)
3. Jamais rotationné (peur de casser le service)
4. Permissions accordées par sur-précaution (« on verra plus tard »)
 
Résultat : compte Kerberoastable, crackable, sur-privilégié, persistant.
C'est EXACTEMENT le profil que les frameworks d'attaque AD ciblent.

2. Les 4 types de comptes de service Windows

2.1 User account comme compte de service — le pire des mondes

Créer un compte utilisateur AD classique et l'assigner à un service est la pratique historique la plus répandue (60-80 % des comptes de service existants en 2025 selon audits terrain). Caractéristiques :

• Mot de passe saisi manuellement à la création, rarement rotationné.
• Visible dans AD Users & Computers comme tout autre user.
• Peut être Domain Admin, Enterprise Admin, membre de n'importe quel groupe.
• SPN configurable → Kerberoasting possible.

Anti-pattern absolu mais omniprésent.

2.2 MSA — amélioration partielle

Introduit en 2008 R2, MSA offre rotation auto 30j, mais limitation critique : un MSA ne peut être utilisé que par une seule machine à la fois. Incompatible avec les services clusterisés, load-balanced ou multi-instances. Rarement déployé en pratique.

2.3 gMSA — la solution 2025

Group Managed Service Account introduit en 2012 résout la limitation MSA : un gMSA peut être utilisé par plusieurs machines désignées. Il utilise un mécanisme de password generation basé sur KDS Root Key (Kerberos Group Key Distribution Service) — le DC calcule dynamiquement le password pour chaque request autorisée.

Propriétés :

• Password 240 octets aléatoires — incrackable offline.
• Rotation transparente tous les 30 jours (configurable).
• Admins ne connaissent jamais le password — récupéré par machines autorisées via NetLogon.
• Multi-machines via PrincipalsAllowedToRetrieveManagedPassword.
• SPN géré automatiquement.
• Kerberoasting inefficace : même si TGS obtenu et hashé, le password incrackable.

3. Les 5 classes de risques des comptes de service

3.1 Risque n°1 : Kerberoasting via SPN

Mécanisme : Kerberos autorise par design tout user authentifié à demander un TGS (Ticket Granting Service) pour n'importe quel SPN du domaine. Le TGS contient une signature avec la clé dérivée du password du compte de service. Un attaquant extrait ce hash et le crack offline.

# Énumération SPNs + extraction TGS hashes
# Depuis n'importe quel user authentifié
GetUserSPNs.py -request \
    -dc-ip 10.0.0.1 \
    CORP.LOCAL/alice:Password123 \
    -outputfile kerberoast_hashes.txt
 
# Exemple de sortie (format hashcat mode 13100) :
# $krb5tgs$23$*svc_sql@CORP.LOCAL$CORP.LOCAL$MSSQLSvc/sql01.corp.local:1433*$...
 
# Cracking offline avec hashcat
hashcat -m 13100 -a 0 kerberoast_hashes.txt \
    /usr/share/wordlists/rockyou.txt \
    --rules-file /usr/share/hashcat/rules/best64.rule
 
# Durée typique password 10-12 chars : heures
# Password gMSA 240 octets : impraticable

3.2 Risque n°2 : crédentials persistants et dette historique

Un password service créé en 2014 SQLService2014! vit potentiellement 10+ ans sans rotation. Pendant ce temps :

• Diffusé à plusieurs équipes (admins successifs).
• Stocké dans des runbooks, fichiers config, wikis internes, chats Slack/Teams.
• Déployé sur plusieurs serveurs qui ont pu être compromis indépendamment.
• Utilisé dans des scripts commit en Git accidentellement.

Blast radius maximal : un leak passé compromet encore le compte 10 ans après.

3.3 Risque n°3 : over-privileged

Observation récurrente en audits terrain 2024-2025 :

La raison historique : un admin pressé ajoute le service à DA « temporairement » pour débloquer une installation, oublie de scoper après. L'ACL Audit BloodHound révèle typiquement 20-40 % des comptes de service avec privilèges excessifs.

3.4 Risque n°4 : absence de rotation

Selon Varonis 2024 Data Risk Report, 40 % des comptes de service AD ont un password non changé depuis 3+ ans. Et 12 % depuis 10+ ans. La raison : peur de casser le service si le password change, absence d'automatisation, perte de connaissance de l'usage.

3.5 Risque n°5 : absence de MFA et Conditional Access

Les comptes de service sont non-interactifs donc incompatibles avec MFA classique (OTP, push notification, FIDO). Le Conditional Access par risk signals est difficile à appliquer car :

• Pattern de login attendu : 24/7 depuis le serveur dédié.
• Géolocation : toujours au même datacenter.
• Device : souvent serveur non-MDM compliant.

Mitigation : Silverfort (MFA sur Kerberos/NTLM via RPC interception) est la seule solution commerciale 2025 pour ajouter MFA à un compte service Kerberos.

4. Attaques dominantes 2024-2025

4.1 Kerberoasting (T1558.003) — la base

Couverte en 3.1. Vecteur d'attaque n°1 AD en 2024-2025.

4.2 Silver Ticket (T1558.002)

Après avoir cracké le password d'un compte de service (ou extrait son NT hash via DCSync), un attaquant peut forger des TGS directement pour ce service, sans passer par le DC. Il accède au service en se faisant passer pour n'importe quel utilisateur.

# Forge Silver Ticket pour service MSSQLSvc
# via Rubeus (GhostPack)
Rubeus.exe silver /service:MSSQLSvc/sql01.corp.local:1433 \
    /rc4:e19ccf75ee54e06b06a5907af13cef42 \
    /user:administrator \
    /domain:CORP.LOCAL \
    /sid:S-1-5-21-1234567890-1234567890-1234567890 \
    /ptt
 
# Maintenant la session Windows a un TGS valide
# pour accéder au SQL Server en tant qu'administrator
sqlcmd -S sql01.corp.local -E

4.3 Shadow Credentials (Whisker, 2021)

Elad Shamir et Charlie Clark ont documenté fin 2021 une attaque exploitant l'attribut msDS-KeyCredentialLink (ajouté Windows Server 2016 pour Windows Hello for Business). Un attaquant avec ACL WriteProperty sur ce champ peut ajouter une clé publique attacker-controlled et s'authentifier via PKINIT en tant que la victime.

# Outil Whisker ou pyWhisker
python pywhisker.py -d CORP.LOCAL \
    -u alice -p Password123 \
    --target "svc_sql" \
    --action add
 
# Utilise Rubeus asktgt avec la clé pour obtenir TGT
# En tant que svc_sql → accès à tout ce que ce compte accède

4.4 ACL abuse via comptes service

Un compte de service avec des ACLs étendues (WriteOwner, WriteDACL, GenericAll) sur des OUs sensibles permet à un attaquant qui le compromet de modifier des permissions ailleurs. Chaîne typique BloodHound :

User-Alice → HasSession → Server-DB01
Server-DB01 → RunsAs → svc_sql@CORP.LOCAL
svc_sql → WriteDACL → OU-Finance
OU-Finance → Contains → User-CFO

Un attaquant Alice avec session sur DB01 dump svc_sql token, puis écrit un ACL sur l'OU Finance, ajoute droits sur CFO, etc. Chaîne indirecte mais fréquente.

4.5 Pass-the-Hash avec NT hash service account

Voir NTLM expliqué. Après obtention du NT hash via LSASS ou DCSync, le compte service sert de pivot pour accéder à toutes les machines où il est configuré en local admin.

5. Mitigation prioritaire 2025 : migration gMSA

5.1 Prérequis gMSA

• Domain Functional Level Windows Server 2012+.
• KDS Root Key créée (une fois par domaine, via Add-KdsRootKey).
• Clients Windows Server 2012+ ou Windows 8+ pour récupérer le password.
• Service compatible gMSA.

5.2 Création d'un gMSA

# Sur DC ou machine avec RSAT AD tools
# Prérequis : KDS Root Key créée (une fois par domaine)
# En prod, différer de 10h pour propagation inter-sites
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
 
# Créer un gMSA
New-ADServiceAccount -Name "gmsa_sql01" `
    -DNSHostName "sql01.corp.local" `
    -ServicePrincipalNames "MSSQLSvc/sql01.corp.local:1433","MSSQLSvc/sql01:1433" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers" `
    -ManagedPasswordIntervalInDays 30 `
    -Enabled $true
 
# SQL-Servers est un groupe AD contenant les machines autorisées
# à récupérer le password du gMSA
 
# Sur le serveur SQL (membre du groupe SQL-Servers)
Install-ADServiceAccount -Identity "gmsa_sql01"
 
# Test
Test-ADServiceAccount -Identity "gmsa_sql01"
# Retourne True si la machine peut utiliser le gMSA

5.3 Utilisation dans SQL Server

SQL Server Configuration Manager
  → SQL Server Services
    → Propriétés du service SQL Server
      → Log On tab
        → Account Name: CORP\gmsa_sql01$
        → Password: (vide — géré automatiquement)
        → Confirm Password: (vide)
      → OK
 
Pas de password à saisir — le service récupère via NetLogon.
Rotation 30j transparente.

5.4 Migration massive — approche progressive

Pour un domaine existant avec 50-300 comptes de service, migration en 4 phases :

Plan de migration comptes service → gMSA — ETI 6-18 mois
──────────────────────────────────────────────────────────
 
Phase 1 — INVENTAIRE (4-8 semaines)
  ├─ Extraction tous comptes avec SPN via PowerShell
  │  Get-ADUser -Filter {ServicePrincipalName -ne "$null"}
  │     -Properties ServicePrincipalName, MemberOf, PasswordLastSet
  ├─ Validation compatibilité gMSA par application
  ├─ Priorisation : high-privilege first, legacy last
  └─ Livrable : matrice de migration 50-300 lignes
 
Phase 2 — PILOTE (4-8 semaines)
  ├─ Migration 5-10 comptes pilotes (SQL Server simples)
  ├─ Validation fonctionnelle et rotation
  └─ Retours d'expérience documentés
 
Phase 3 — DÉPLOIEMENT (16-40 semaines)
  ├─ Migration par vague de 10-20 comptes
  ├─ Monitoring intensif 2 cycles de rotation
  └─ Ancienne compte désactivé puis supprimé J+90
 
Phase 4 — RÉSIDUELS (8-16 semaines)
  ├─ Comptes non-migrables : alternative PAM vault
  ├─ Documentation des exceptions
  └─ Audit final + rotation krbtgt 2x

6. Comptes de service incompatibles gMSA — que faire ?

6.1 Options pour l'incompatible

Applications legacy qui ne supportent pas gMSA (stockage password en fichier config, SDK NTLM hardcoded) :

1. PAM avec rotation automatique : CyberArk Conjur, Delinea Secret Server, BeyondTrust Password Safe. Password rotationné automatiquement puis push vers fichier config via API + redémarrage service orchestré. Coût : 50-200 k€/an ETI.

2. HashiCorp Vault + rotation manuelle scripts : pour les environnements cloud-native ou ops-heavy. Moins clean-and-play qu'un PAM dédié mais flexible.

3. Migration vers auth moderne : refactoring applicatif pour OAuth2, OIDC, Kerberos avec SPN computer account. Investissement applicatif mais solution long terme.

4. Migration cloud : remplacer service AD par Managed Identity AWS IRSA, Azure Workload Identity, GCP Workload Identity Federation. Supprime complètement la classe compte de service AD. Voir Secrets management dans le cloud.

6.2 Matrix décisionnelle

7. Cas cloud : Non-Human Identities (NHI)

Les comptes de service AD sont la forme on-prem des NHI (Non-Human Identities) cloud. En 2025, la migration cloud-native remplace progressivement les comptes de service AD par :

Avantage structurel : zéro credential long-terme stocké. Rotation cryptographique à chaque requête via OIDC JWT + STS.

Pour le détail voir Secrets management dans le cloud. Selon GitGuardian NHI Report 2024, 45 % des incidents cloud 2023-2024 impliquent une NHI compromise. Les patterns AWS IRSA / Azure WI / GCP WI sont le remplacement structurel des comptes de service AD pour les workloads modernisés.

8. Détection des usages anormaux

8.1 Détections Microsoft Defender for Identity (MDI)

8.2 Règles Sigma pour SIEM custom

# Détection Kerberoasting via Windows Event Log
# Source : DC Security log, Event ID 4769 (TGS request)
 
title: Potential Kerberoasting Activity
id: a4a3b51c-abcd-1234-5678-901234567890
status: stable
description: Detects multiple TGS requests for different SPNs from same user
references:
  - https://attack.mitre.org/techniques/T1558/003/
author: Zeroday Cyber Academy
logsource:
  category: security
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: "0x17"  # RC4 (weak, Kerberoastable)
  timeframe: 10m
  condition: selection | count(TicketEncryptionType) by TargetUserName > 20
falsepositives:
  - Legitimate SPN enumeration by admin tools
  - BloodHound authorized audit
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

8.3 Audit PowerShell pour inventaire comptes de service

# Script d'audit — exporter tous comptes user avec SPN
Get-ADUser -Filter {ServicePrincipalName -like "*"} `
    -Properties ServicePrincipalName, PasswordLastSet, MemberOf, `
                LastLogonDate, Enabled, AdminCount, Description |
    Select-Object Name, SamAccountName, Enabled, `
                  @{N="SPNs";E={$_.ServicePrincipalName -join ";"}}, `
                  @{N="PasswordAgeDays";E={(New-TimeSpan -Start $_.PasswordLastSet -End (Get-Date)).Days}}, `
                  @{N="GroupMembership";E={$_.MemberOf | Get-ADGroup | Select -ExpandProperty Name | Where {$_ -match "Admin"}}}, `
                  LastLogonDate, AdminCount, Description |
    Sort-Object PasswordAgeDays -Descending |
    Export-Csv -Path "service_accounts_audit.csv" -NoTypeInformation
 
# Interpréter : tri descending sur PasswordAgeDays révèle
# les comptes les plus risqués (rotation longue + SPN +
# privilèges élevés = priorité migration gMSA)

9. Cadre réglementaire et conformité

Comptes de service évoqués explicitement dans :

En 2025, un audit NIS 2 ou DORA exige explicitement un inventaire des comptes de service avec leur justification, rotation et niveau de privilège documentés.

Points clés à retenir

• Cible n°1 des pentesters AD : 60-80 % des pentests internes 2024-2025 exploitent un compte de service via Kerberoasting en 1-3 jours.
• 4 types : user account (pire), computer account, MSA (single-machine), gMSA (multi-machines, solution 2025).
• 5 classes de risques : SPN Kerberoasting, crédentials persistants, over-privileged (15-30 % sont DA/LocalAdmin multi-serveurs), pas de rotation, pas de MFA.
• Attaques : Kerberoasting (T1558.003), Silver Ticket, Shadow Credentials (Whisker 2021), ACL abuse, Pass-the-Hash via NT hash service.
• Mitigation prioritaire gMSA : password 240 octets aléatoires, rotation auto 30j, incrackable. Migration ETI 6-18 mois.
• Incompatible gMSA : PAM vault (CyberArk, Delinea, BeyondTrust, HashiCorp Vault) avec rotation auto + push config.
• Cloud-native : migration vers AWS IRSA, Azure Workload Identity, GCP Workload Identity — élimine structurellement la classe compte service AD.
• Détection : MDI (Microsoft Defender for Identity) + règles Sigma Kerberoasting sur Event 4769 — ~30 % SIEM ont la règle active en 2025 (marge de progression massive).
• Audit : script PowerShell pour inventaire trié par PasswordAge × Privilèges × SPN — priorisation immédiate.
• Conformité : NIS 2, DORA, ANSSI v2 2023 exigent explicitement inventaire + justification comptes service en 2025.

Pour le contexte Kerberos, voir Kerberos expliqué. Pour le protocole voisin NTLM, NTLM expliqué. Pour la méthodologie offensive AD, Qu'est-ce qu'un pentest interne, Privilege escalation AD. Pour la rotation des clés en général, Rotation de clés. Pour l'équivalent cloud NHI, Secrets management dans le cloud.