Quand on parle de sécurité sur Windows, les services sont presque toujours impliqués à un moment ou à un autre. Pas parce qu’ils sont intrinsèquement vulnérables, mais parce qu’ils tournent en permanence, souvent avec des privilèges élevés, et qu’ils sont rarement audités en profondeur une fois mis en production.
Sur le terrain, une grande partie des élévations de privilèges locales et des mécanismes de persistance passent par un service Windows mal configuré. L’objectif ici n’est pas de vulgariser, mais de rentrer dans le concret, commandes à l’appui, comme on le ferait lors d’un audit ou d’un durcissement post-installation.
Identifier précisément ce qui tourne sur le système
La première étape consiste toujours à savoir exactement quels services sont présents, et surtout sous quel contexte ils s’exécutent. La console graphique ne suffit pas.
En PowerShell, on commence par extraire une vue exploitable :
Ce qui nous intéresse immédiatement :
StartName→ compte d’exécutionPathName→ chemin du binaireStartMode→ comportement au démarrage
À ce stade, tout service non Microsoft ou non directement lié à l’infrastructure doit attirer l’attention. Un service oublié est souvent un service dangereux.
Détection des chemins de service à risque
Un classique : les chemins avec espaces non protégés. C’est une faille vieille comme Windows, et pourtant toujours présente.
Exemple typique :
Si le chemin n’est pas entouré de guillemets, Windows va tenter :
Pour les identifier :
Si un utilisateur peut écrire dans l’un de ces répertoires intermédiaires, l’élévation de privilèges est immédiate.
Vérifier les permissions NTFS sur les binaires de service
C’est ici que beaucoup de compromissions deviennent triviales.
On récupère le chemin réel du service :
Puis on contrôle les ACL :
Tout droit d’écriture pour :
UsersAuthenticated Usersun groupe métier large
est inacceptable pour un service exécuté avec des privilèges élevés.
Même logique pour le dossier parent :
Dans un audit, un seul binaire modifiable suffit à obtenir SYSTEM.
Comptes d’exécution : là où tout se joue
Beaucoup trop de services tournent encore sous LocalSystem par défaut. Ce n’est pas une vulnérabilité en soi, mais c’est une exposition maximale.
Lister les services sous LocalSystem :
Pour un service applicatif, la bonne pratique reste :
un compte dédié
sans droits interactifs
sans appartenance à des groupes privilégiés
Modification du compte d’exécution :
À noter : l’espace après obj= est obligatoire, sinon la commande échoue silencieusement.
Permissions sur le Service Control Manager (SCM)
Un point souvent oublié : qui peut modifier le service lui-même.
Un utilisateur capable de changer la configuration d’un service peut rediriger son exécutable vers n’importe quel binaire.
Affichage des permissions :
On recherche notamment :
SERVICE_CHANGE_CONFIGSERVICE_ALL_ACCESS
Si un groupe non privilégié dispose de ces droits, le service devient un point d’attaque direct.
Démarrage automatique et persistance
Les services configurés en démarrage automatique sont idéaux pour la persistance.
Lister les services auto :
Un service automatique doit répondre à une nécessité opérationnelle claire. Sinon :
passage en
Manualou désactivation pure
Analyse réseau du service
Un service exposé sur le réseau doit être traité comme une application serveur.
Identifier les ports utilisés :
Puis corréler avec le PID :
Tout service écoutant sans filtrage firewall explicite est un risque inutile. Le pare-feu Windows permet de limiter précisément les IP sources, trop souvent laissé en configuration permissive.
Journalisation et détection d’abus
Un service attaqué se comporte rarement de manière totalement silencieuse.
Les événements à surveiller :
création / modification de service
échecs de démarrage répétés
redémarrages anormaux
Ces événements sont visibles dans les journaux système et doivent être corrélés. Un service qui redémarre sans raison fonctionnelle mérite une analyse immédiate.
Conclusion terrain
Dans la majorité des environnements compromis, le service Windows n’est pas le point d’entrée initial, mais il devient le point de consolidation : élévation de privilèges, persistance, parfois mouvement latéral.
Sécuriser les services Windows, ce n’est pas cocher une checklist. C’est :
comprendre sous quel contexte ils tournent
contrôler ce qu’ils peuvent modifier
limiter ce qu’ils exposent
surveiller leur comportement dans le temps
Un service bien durci est rarement exploitable. Un service laissé par défaut l’est presque toujours.
