Comptes administrateurs locaux : la porte dérobée cachée sur votre propre PC

Ce que « administrateur local » signifie vraiment (et pourquoi les attaquants l’adorent)

« Administrateur local » n’est pas une impression. C’est une capacité concrète : la possibilité de modifier un état pertinent pour la sécurité sur une seule machine sans avoir besoin du domaine, de l’IdP ou de votre plan de contrôle cloud.
Sous Windows, cela signifie généralement l’appartenance au groupe local Administrators (directement ou indirectement). Sur macOS, c’est typiquement l’appartenance au groupe admin plus des droits d’autorisation, et sur Linux, c’est la capacité de devenir root via sudo ou d’accéder directement à root.

Si vous pouvez exécuter du code en tant qu’admin/root, vous pouvez :

• Lire ou altérer des secrets stockés « localement » (jetons de navigateur, clés SSH, jetons API, identifiants mis en cache, blobs protégés par DPAPI dans le bon contexte).
• Installer de la persistance (services, agents de lancement, tâches planifiées, extensions noyau/pilotes si autorisé, éléments de démarrage).
• Désactiver ou rendre aveugles des outils de sécurité (pare-feu local, composants EDR, protection contre la falsification si mal configurée).
• Modifier la journalisation, l’heure et la posture d’audit (ou remplir les disques pour stopper la journalisation).
• Collecter des identifiants et se déplacer latéralement (surtout si des mots de passe d’admin locaux sont partagés ou prévisibles).

Voici la partie laide : beaucoup d’organisations dépensent de l’argent pour des contrôles centralisés puis distribuent l’admin local pour « garder les gens productifs ». Ce n’est pas de la productivité ; c’est du changement non maîtrisé avec un meilleur nom marketing.

Blague n°1 : Donner l’admin local à tout le monde, c’est comme donner à chacun une clé passe-partout parce que la porte colle parfois. Ça résout le problème de la porte—en faisant des « serrures » plutôt une suggestion.

La dure vérité : l’admin local n’est pas intrinsèquement malveillant. Il est intrinsèquement puissant. Votre travail est de faire en sorte que ce pouvoir soit (1) rare, (2) limité dans le temps, (3) traçable, et (4) résistant à la réutilisation.

Faits et histoire : comment on en est arrivé là

Ce problème n’est pas apparu parce que les gens sont négligents. Il est apparu parce que l’histoire de l’informatique est une longue suite d’exceptions « juste cette fois » qui sont devenues des politiques.
Quelques points de contexte qui valent la peine d’être connus, car ils expliquent les défauts contre lesquels vous luttez :

1. Les premières versions de Windows grand public ont normalisé « tout le monde est admin ». Windows 95/98 n’avait pas de frontières de sécurité de type NT ; les habitudes ultérieures ont perduré jusqu’à Windows XP où beaucoup d’utilisateurs fonctionnaient en tant qu’admin pour des raisons de compatibilité.
2. UAC de Windows (ère Vista) a été un reset culturel. UAC a poussé l’idée que l’admin doit être explicite et consenti, mais beaucoup d’organisations y ont répondu en le désactivant ou en formant les utilisateurs à cliquer « Oui ».
3. Le compte intégré Administrator de Windows précède les modèles d’identité modernes. Il existe pour le bootstrap et la récupération, mais en pratique il est devenu un compte « casse-glace » pratique—souvent sans le « casse-glace ».
4. Pass-the-Hash a émergé avec la réutilisation des identifiants NTLM. Si le même identifiant d’admin local existe sur plusieurs endpoints, un seul hash compromis devient une clé squelettique itinérante.
5. L’accès au groupe admin sur macOS est historiquement lié à « c’est ma machine personnelle ». Les paramètres par défaut d’Apple supposent un propriétaire unique avec des droits admin ; les entreprises greffent des politiques sur ce modèle.
6. Linux a supposé des systèmes multi-utilisateurs avec root comme autorité unique. sudo a été conçu pour minimiser les connexions directes en root tout en permettant une élévation contrôlée.
7. Microsoft LAPS a été une réponse directe aux mots de passe admin locaux partagés. Il a automatisé des mots de passe locaux uniques par appareil dans les environnements AD, car les humains ne les feraient jamais tourner de manière fiable.
8. Les MDM modernes ont rendu la gestion des privilèges sur endpoint possible—puis les gens l’ont évitée. Des outils comme Intune/Jamf peuvent appliquer le moindre privilège, mais la « commodité des développeurs » l’emporte souvent par défaut.
9. La protection contre la falsification des EDR est plus récente que vous ne le pensez. Beaucoup d’organisations exécutent encore des agents endpoint configurés comme si les attaquants n’allaient pas d’abord essayer de les arrêter localement.

Le fil historique est cohérent : l’admin local existe pour la récupération et le contrôle. Les organisations en font une commodité quotidienne. Les attaquants transforment la commodité en accès.

Modèle de menace : les chemins d’abus qui arrivent réellement

1) Le compte « je n’en ai eu besoin qu’une fois » devient permanent

Quelqu’un avait besoin d’admin pour un pilote d’imprimante, un client VPN, un débogueur, un client de base de données, une extension noyau, un plugin CAO, un paquet d’intermédiation de jetons de sécurité.
Un ticket a été ouvert. L’accès a été accordé. Personne n’a pensé à le révoquer. Des mois plus tard, cette machine sert de point d’appui.

2) Réutilisation des mots de passe d’admin local = mouvement latéral en mode facile

Si plusieurs machines partagent le même identifiant d’admin local (ou une variante prévisible), une seule compromission devient une compromission de flotte. Les attaquants n’ont pas besoin de casser votre domaine.
Ils le contournent : s’authentifier localement en utilisant un hash ou un mot de passe qui fonctionne partout.

3) « Admins fantômes » via des groupes imbriqués

Vous auditez le groupe local Administrators et voyez un groupe « IT Admins » et vous vous sentez bien. Mais ce groupe contient un autre groupe, qui contient un utilisateur que vous n’aviez pas prévu.
Ou pire : un groupe helpdesk contient des sous-traitants, ou un groupe hérité contient des comptes désactivés qui ne sont pas réellement désactivés là où ça compte.

4) Persistance via des contrôles locaux

L’admin local peut créer des services, des tâches planifiées, des démons de lancement, des éléments de démarrage, des abonnements d’événements WMI. Il peut planter un certificat racine. Il peut intercepter le mécanisme de mise à jour.
Une fois la persistance en place, votre réponse « réinitialiser le mot de passe » devient de la mise en scène.

5) Suppression des outils de sécurité

Beaucoup d’outils endpoint s’exécutent avec de hauts privilèges mais exposent des contrôles locaux : arrêter un service, décharger un pilote, modifier des exclusions, tuer un processus, ou simplement priver d’espace disque.
Si la protection contre la falsification n’est pas appliquée par quelque chose que l’attaquant ne peut pas modifier localement, ce n’est pas une protection. C’est une case cochée.

6) Vol d’identifiants depuis la machine locale

L’accès admin/root accélère la récolte d’identifiants. Sous Windows, pensez à la posture de protection de LSASS, aux paramètres hérités WDigest, aux identifiants de domaine mis en cache,
aux magasins de jetons du navigateur, aux clés Wi‑Fi, aux identifiants RDP enregistrés, et aux données DPAPI dans le bon contexte utilisateur. Sur macOS, pensez à l’accès au Trousseau (Keychain) avec élévation locale et contournements d’autorisation.
Sur Linux, pensez aux sockets d’agent SSH, aux clés privées, aux kubeconfigs, aux identifiants cloud dans des fichiers d’environnement, et aux erreurs de permission lisibles par tous.

Une idée souvent paraphrasée et attribuée à Gene Kim correspond à la réalité des opérations : la rapidité vient de la réduction du risque et du coût du changement, pas du contournement des contrôles.

Mode d’urgence : ce qu’il faut vérifier en 1ᵉʳ/2ᵉ/3ᵉ

Lorsque vous suspectez un abus d’admin local (ou que vous essayez de quantifier rapidement le risque), ne commencez pas par lire les documents de politique.
Commencez par les preuves sur les endpoints. Voici l’ordre de triage qui identifie rapidement le goulot d’étranglement :

Première étape : Qui est effectivement administrateur local maintenant ?

• Énumérez la composition du groupe d’administrateurs locaux.
• Développez les groupes imbriqués quand c’est possible (groupes de domaine, groupes locaux, principaux gérés par MDM).
• Cherchez les comptes obsolètes, les comptes casse-glace et les comptes fournisseurs « temporaires » qui sont encore là.

Deuxième étape : Les mots de passe d’admin locaux sont-ils uniques et tournés ?

• Vérifiez si LAPS (ou équivalent) est déployé et sain.
• Confirmez l’ancienneté des mots de passe, la cadence de rotation et l’audit des récupérations.
• Cherchez des scripts d’image qui réinitialisent l’admin local à une valeur connue.

Troisième étape : Un admin local peut-il devenir « admin de domaine » via l’accès aux identifiants ou des outils ?

• Vérifiez si des comptes privilégiés se connectent un jour aux postes de travail (ouvertures de session interactives).
• Vérifiez la posture de protection de LSASS/Credential Guard et la politique de sécurité locale.
• Vérifiez si des protocoles d’administration à distance (WinRM, WMI, outils de type PSExec, partages administratifs SMB) sont largement activés.

Quatrième étape : Un administrateur peut-il vous rendre aveugle ?

• Vérifiez l’application de la protection contre la falsification de l’EDR.
• Assurez-vous que les journaux d’audit sont rapidement transmis hors de l’hôte.
• Confirmez que les règles de pare-feu locales empêchent les mouvements latéraux peer-to-peer.

Si vous ne faites que ces quatre passes, vous trouverez généralement le « pourquoi c’est dangereux dans notre environnement » en une journée.

Tâches pratiques : 12+ vérifications réelles avec commandes, sorties et décisions

Les commandes ci‑dessous sont conçues pour être exécutables depuis un hôte de gestion Linux d’entreprise typique utilisé pour administrer des endpoints Windows/macOS/Linux,
ainsi que des vérifications locales que vous pouvez exécuter sur l’endpoint lui‑même. L’important n’est pas la marque de l’outil. L’important est de passer de « on pense » à « on sait ».

Tous les exemples utilisent une invite shell et des sorties réalistes. Considérez-les comme des modèles. Adaptez les noms d’hôtes et les chemins à votre environnement.

Task 1: On Linux, list who can become root via sudo

cr0x@server:~$ sudo -l
Matching Defaults entries for alice on ws-143:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User alice may run the following commands on ws-143:
    (ALL : ALL) ALL

Ce que cela signifie : alice peut exécuter n’importe quoi en root. C’est effectivement un administrateur local.
Si vous voyez des règles spécifiques à certaines commandes (comme n’autoriser que systemctl restart pour un service), c’est plus proche du moindre privilège.

Décision : Si la règle est (ALL) ALL pour du personnel non admin, vous devez soit passer à un privilège à la demande, soit restreindre l’ensemble des commandes.
Si c’est déjà restreint, vérifiez qu’il n’est pas triviale d’échapper (shells, éditeurs, gestionnaires de paquets).

Task 2: On Linux, find sudoers entries and dangerous inclusions

cr0x@server:~$ sudo grep -R --line-number -E 'NOPASSWD|ALL=\(ALL\)|include|includedir' /etc/sudoers /etc/sudoers.d
/etc/sudoers:28:Defaults        env_reset
/etc/sudoers:44:#includedir /etc/sudoers.d
/etc/sudoers.d/devops:3:%devops ALL=(ALL) NOPASSWD:ALL
/etc/sudoers.d/ci:7:jenkins ALL=(root) NOPASSWD:/usr/bin/docker

Ce que cela signifie : %devops a un accès root sans mot de passe pour tout. jenkins peut exécuter docker en root (souvent équivalent à root).

Décision : Remplacez NOPASSWD large par une élévation juste-à-temps, ou au moins des listes d’autorisation de commandes qui n’autorisent pas les échappements de shell.
Traitez « l’accès docker » comme root sauf si vous avez fait le dur travail d’isolation.

Task 3: On Linux, confirm who is in the admin-meaningful groups

cr0x@server:~$ getent group sudo; getent group wheel
sudo:x:27:alice,bob
wheel:x:10:root

Ce que cela signifie : Les membres de sudo peuvent probablement escalader. Sur certaines distributions c’est wheel.

Décision : Si la composition des groupes ne correspond pas à votre roster d’admins prévu, corrigez la composition et ajoutez du monitoring pour les modifications.

Task 4: On Windows (via a Linux admin host), enumerate local Administrators using WinRM

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { net localgroup administrators }'
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

-------------------------------------------------------------------------------
CONTOSO\Domain Admins
CONTOSO\Workstation Support
ws-221\localadmin
The command completed successfully.

Ce que cela signifie : Deux groupes de domaine et un compte local ont l’admin. Domain Admins sur des postes est un mauvais signe : cela fait de chaque poste une opportunité de vol d’identifiants.

Décision : Retirez les groupes de haut niveau (Domain Admins) du groupe admin local sur les endpoints ; utilisez le tiering et des comptes séparés pour le support des postes.
Si ws-221\localadmin existe, assurez-vous qu’il est géré avec rotation des mots de passe et désactivé pour les connexions interactives sauf nécessité.

Task 5: On Windows, check whether the built-in Administrator is enabled

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { net user Administrator }'
User name                    Administrator
Account active               Yes
Account expires              Never

Password last set            1/12/2025 9:14:03 AM
Password expires             Never
Password changeable          1/12/2025 9:14:03 AM
Password required            Yes
User may change password     Yes

Ce que cela signifie : Le compte Administrator intégré est actif et a un mot de passe qui n’expire pas. C’est un point d’ancrage de persistance classique si un attaquant l’obtient une fois.

Décision : Désactivez-le quand c’est possible. Si vous devez le garder, imposez la rotation gérée par LAPS, interdisez la connexion réseau et surveillez son utilisation.

Task 6: On Windows, confirm LAPS / password rotation posture (modern Windows LAPS)

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { Get-Command Get-LapsADPassword -ErrorAction SilentlyContinue; reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\LAPS\Config" }'
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\LAPS\Config
    BackupDirectory    REG_DWORD    0x1
    PasswordAgeDays    REG_DWORD    0x1e
    AdminAccountName   REG_SZ       localadmin

Ce que cela signifie : La configuration LAPS existe : répertoire de sauvegarde activé (la valeur dépend de votre configuration), âge du mot de passe fixé à 30 jours, compte admin nommé localadmin.

Décision : Si la configuration LAPS manque ou est mal configurée, vous réutilisez probablement des mots de passe. Corrigez le déploiement avant de débattre d’autre chose.
Assurez-vous aussi que la récupération est auditée et limitée au plus petit ensemble d’opérateurs.

Task 7: On Windows, check who logged on interactively (privileged accounts on endpoints)

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { quser }'
 USERNAME              SESSIONNAME        ID  STATE   IDLE TIME  LOGON TIME
 alice                 console             1  Active      none   2/5/2026 8:01 AM
 contoso\da-mike                           2  Disc         1:12   2/4/2026 6:20 PM

Ce que cela signifie : Un compte de type admin de domaine (da-mike) s’est connecté à un poste. Si les identifiants de ce compte sont présents, la compromission locale peut devenir une compromission de domaine.

Décision : Appliquez des postes d’accès privilégiés (PAWs) ou un tiering équivalent. Bloquez les comptes de haut privilège d’ouvrir une session sur les endpoints.

Task 8: On Windows, check LSASS protection and Credential Guard posture

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL; reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity }'
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
    RunAsPPL    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
    EnableVirtualizationBasedSecurity    REG_DWORD    0x1

Ce que cela signifie : LSASS est configuré pour s’exécuter comme un processus protégé, et VBS est activé. Cela augmente la difficulté du dump d’identifiants—mais ne rend pas l’admin local sûr.

Décision : Si ces paramètres sont désactivés sur vos endpoints, priorisez leur activation dans le cadre de la réduction du risque d’admin local.
S’ils sont activés, poursuivez quand même avec le moindre privilège et la rotation des mots de passe ; la défense en profondeur est la seule qui survive au contact des attaquants.

Task 9: On Windows, list local users and spot “mystery admins”

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { Get-LocalUser | Select-Object Name,Enabled,LastLogon }'
Name           Enabled LastLogon
----           ------- ---------
Administrator  True    1/28/2026 9:12:15 AM
DefaultAccount False
Guest          False
localadmin     True    2/3/2026 2:41:07 PM
svc_vendor     True    9/14/2025 11:20:55 AM

Ce que cela signifie : Un compte de service fournisseur existe et est activé. Les comptes de service sur les endpoints sont une poche de risque fréquente « personne n’en est propriétaire ».

Décision : S’il n’est pas requis, supprimez‑le. S’il est requis, faites tourner les identifiants, interdisez la connexion interactive et documentez le propriétaire et l’objet.

Task 10: On macOS, see who is an admin (local admin equivalent)

cr0x@server:~$ ssh admin@mac-17 'dscl . -read /Groups/admin GroupMembership'
GroupMembership: root itops alice

Ce que cela signifie : alice fait partie du groupe admin sur ce Mac.

Décision : Si les utilisateurs n’ont pas besoin d’admin au quotidien, retirez‑les et fournissez un flux d’élévation (admin temporaire, Self Service, ou PAM avec JIT).

Task 11: On macOS, verify whether the root user is enabled

cr0x@server:~$ ssh admin@mac-17 'dsenableroot -q; echo $?'
dsenableroot:: ***Root account is disabled.
0

Ce que cela signifie : Root est désactivé (bon). S’il était activé, il deviendrait une cible de grande valeur pour des attaques hors ligne et en ligne selon la politique.

Décision : Gardez root désactivé sauf s’il y a une raison opérationnelle contrôlée et auditée. Utilisez des workflows de type sudo ou des outils de gestion à la place.

Task 12: On Linux endpoints, check for passwordless root shells via sudo misconfig

cr0x@server:~$ sudo -l -U jenkins
Matching Defaults entries for jenkins on ci-runner-02:
    env_reset, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

User jenkins may run the following commands on ci-runner-02:
    (root) NOPASSWD: /usr/bin/docker

Ce que cela signifie : Dans de nombreuses configurations, docker accorde effectivement root (monter le système de fichiers hôte, démarrer des conteneurs privilégiés, accéder au socket docker).

Décision : Traitez‑le comme root et repensez : containers rootless, hôtes de build dédiés, ou retirez l’accès au socket docker et utilisez des outils de build plus sûrs.

Task 13: On Windows, check local security policy related to admin shares and remote admin surfaces

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy; Get-Service -Name WinRM | Select-Object Name,Status,StartType }'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    LocalAccountTokenFilterPolicy    REG_DWORD    0x1

Name  Status StartType
----  ------ ---------
WinRM Running Automatic

Ce que cela signifie : La politique de filtrage de token est fixée à 1, ce qui peut rendre les comptes locaux plus puissants sur le réseau dans certains contextes d’administration à distance. WinRM est activé.

Décision : Si vous n’avez pas besoin d’une administration à distance large des endpoints, restreignez‑la. Si vous en avez besoin, limitez‑la aux sous‑réseaux de management, exigez une authentification forte et surveillez.

Task 14: On Windows, spot local admin group changes via Security Event Logs

cr0x@server:~$ pwsh -NoLogo -Command 'Invoke-Command -ComputerName ws-221 -ScriptBlock { Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4732} -MaxEvents 2 | Format-List TimeCreated,Id,Message }'
TimeCreated : 2/5/2026 9:03:12 AM
Id          : 4732
Message     : A member was added to a security-enabled local group.
              Subject:  Security ID:  CONTOSO\itops-jane
              Group:    Security ID:  BUILTIN\Administrators
              Member:   Security ID:  CONTOSO\contractor-77

TimeCreated : 2/1/2026 1:22:44 PM
Id          : 4732
Message     : A member was added to a security-enabled local group.
              Subject:  Security ID:  CONTOSO\Workstation Support
              Group:    Security ID:  BUILTIN\Administrators
              Member:   Security ID:  CONTOSO\dev-team

Ce que cela signifie : La membership admin a été étendue à un sous-traitant et à un groupe entier de dev. C’est exactement ainsi que la « prolifération d’admin local » se produit : un changement bien intentionné, multiplié dans le temps.

Décision : Exigez une approbation/audit pour les changements de membership admin local, et alertez sur les ajouts de groupe. Réduisez le rayon d’impact en utilisant des groupes à portée d’appareil et du JIT.

Task 15: On Linux, detect recent changes to sudoers (simple but effective)

cr0x@server:~$ sudo find /etc/sudoers /etc/sudoers.d -type f -mtime -7 -ls
262376 4 -r--r----- 1 root root  820 Jan 30 10:21 /etc/sudoers
262401 4 -r--r----- 1 root root  112 Feb  3 14:05 /etc/sudoers.d/devops

Ce que cela signifie : Un fichier include sudoers a changé récemment. Cela peut être planifié. Cela peut aussi être un attaquant qui se donne la persistance.

Décision : Si le contrôle de changement n’explique pas cela, enquêtez immédiatement : qui l’a modifié, depuis où, et quelle authentification a été utilisée.

Task 16: On macOS, check recent privilege changes (admin group modifications)

cr0x@server:~$ ssh admin@mac-17 'log show --style compact --last 7d --predicate "process == \"opendirectoryd\" AND eventMessage CONTAINS \"admin\" " | tail -n 5'
2026-02-01 12:04:22.113 0x1a2c1  Default  0x0  0  opendirectoryd: (Accounts) groupmod: added user contractor-77 to group admin
2026-02-03 09:55:10.882 0x193a9  Default  0x0  0  opendirectoryd: (Accounts) groupmod: removed user contractor-77 from group admin

Ce que cela signifie : Quelqu’un a été ajouté au groupe admin, puis retiré. Cela peut être une élévation temporaire faite correctement—ou la preuve que quelqu’un a sondé le système.

Décision : Si vous avez un workflow d’élévation, confirmez qu’il correspond aux horodatages et aux enregistrements de demandes. Sinon, considérez‑le comme suspect et ajoutez du monitoring.

Trois mini-histoires d’entreprise venues du terrain

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déployé la MFA partout : VPN, e‑mail, portails admins, tout. L’équipe sécurité avait des tableaux de bord pleins de coches vertes et une diapositive propre intitulée « L’identité est résolue ».
Pendant ce temps, la gestion des endpoints était « suffisante » : une image standard, un compte admin local pour l’IT, et un tableur de mots de passe mis à jour « quand quelqu’un s’en souvient ».

La brèche a commencé par un employé victime d’un phishing. L’attaquant a obtenu une session utilisateur sur un portable et a rapidement découvert que le mot de passe admin local fonctionnait sur plusieurs autres machines.
Pas d’invite MFA. Pas de politique d’accès conditionnel. Juste un événement d’authentification local répété sur des endpoints comme en 2006.

L’hypothèse erronée était subtile : ils supposaient que contrôler les connexions aux services contrôlait le contrôle des appareils. Ce n’est pas le cas.
Une fois que l’attaquant avait l’admin local sur une série de machines, il a trouvé un poste où un compte IT privilégié s’était connecté « juste pour réparer Outlook ».
De là, l’exposition d’identifiants a transformé un événement poste de travail en un événement domaine.

Le travail post‑incident a été ennuyeux et efficace : déployer la rotation des mots de passe pour les admins locaux, retirer l’admin local permanent des utilisateurs finaux, et bloquer les comptes privilégiés sur les endpoints.
L’entreprise a conservé la MFA. Maintenant elle fait partie d’un système, pas d’un talisman.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une organisation globale avait une « initiative d’efficacité » pour réduire les tickets helpdesk. La plus grosse plainte concernait les installations logicielles : les développeurs avaient besoin d’outils, les ingénieurs de pilotes, les analystes de plugins.
La solution facile a été d’accorder l’admin local à des départements entiers.

Ça a marché, opérationnellement. Le volume de tickets a baissé. Le délai moyen pour « faire le travail » s’est amélioré. Le DSI a eu un rapport trimestriel satisfaisant.
Puis l’équipe sécurité endpoint a remarqué un autre indicateur : le temps de résidence du malware a augmenté, parce que l’admin local autorisait la persistance et l’ingérence des outils de sécurité.

Le revers s’est manifesté par des pannes. Pas des braquages hollywoodiens—un comportement de type ransomware ennuyeux : endpoints inutilisables, clients VPN cassés, certificats remplacés, agents de mise à jour morts.
L’organisation a dû réimage des machines à grande échelle, ce qui a effacé les économies de tickets et plus encore.

La solution n’était pas « ne jamais donner d’admin ». C’était de construire une voie pavée : installations en libre‑service via des catalogues gérés, paquets préapprouvés, et élévation limitée dans le temps pour les cas exceptionnels.
La leçon : « réduire les tickets » n’est pas une stratégie de sécurité. C’est un objectif de coût qui mangera volontiers votre budget risque.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société financière avait une pratique que personne n’adorait : le tiering des postes. Les admins avaient des comptes séparés pour le support des endpoints, et les privilèges au niveau domaine n’étaient pas autorisés à se connecter sur les postes de travail ordinaires.
Ils appliquaient aussi la rotation des mots de passe admin locaux et limitaient qui pouvait récupérer ces mots de passe. L’audit était strict, et oui, c’était ennuyeux.

Un après‑midi, un portable de développeur a été compromis via une faille de navigateur. L’attaquant a escaladé localement (comme font les attaquants) et a essayé le mouvement habituel : trouver quelque chose de réutilisable pour le déplacement latéral.
Ils ont trouvé des identifiants admin locaux—mais chaque machine avait un mot de passe unique qui tournait. Pass‑the‑hash n’est pas devenu pass‑the‑fleet.

L’attaquant a ensuite cherché des sessions à haute privilege à voler. Il n’y en avait pas. Les comptes admin de domaine ne se connectaient tout simplement pas aux endpoints.
L’attaquant a pu rendre ce portable misérable, mais il n’a pas pu en faire un pont vers les joyaux de la couronne.

La réponse à l’incident a été presque décevante : isoler l’appareil, réimage, invalider les jetons utilisateur, et passer à autre chose.
L’équipe a gardé son week-end parce qu’avant, elle avait choisi des contrôles ennuyeux plutôt qu’une réponse héroïque.

Contrôles de conception qui fonctionnent (sans tout casser)

Principe : Séparer « je peux réparer cette machine » de « je peux faire tourner l’entreprise »

Le plus grand gain opérationnel est le tiering. Pas en théorie. Dans le sens « l’attaquant tentera exactement cette pivotation ».
Les administrateurs de domaine (ou les administrateurs de locataire cloud, ou tout équivalent) ne devraient jamais se connecter aux endpoints. Jamais.
Si vous devez enfreindre cette règle pendant un incident, traitez‑le comme un brûlage contrôlé : documenté, limité dans le temps, revu.

Utilisez l’élévation just‑in‑time, pas l’admin permanent

L’admin local permanent est une nuisance attractive. L’élévation limitée dans le temps change l’économie : une session utilisateur compromise n’entraîne pas automatiquement un admin persistant.
Vous voulez un chemin d’approbation (ou une approbation automatique basée sur une politique) qui accorde l’admin pour des minutes, pas des mois.

Rendez les mots de passe admin locaux uniques par appareil et faites‑les tourner

C’est non négociable. Si un seul identifiant admin local fonctionne sur de nombreux endpoints, vous avez construit une autoroute interne pour vers les worms.
Utilisez la rotation de type LAPS sur Windows. Sur macOS/Linux, utilisez votre outil de gestion pour définir des identifiants uniques ou supprimez complètement le concept en supprimant les utilisateurs admin locaux et en vous reposant sur une élévation contrôlée centralisée.

Désactivez ou contraignez les comptes intégrés

Le compte Administrator intégré sur Windows et root sur macOS/Linux sont utiles pour la récupération. Ils sont aussi des cibles universellement connues.
Si vous pouvez désactiver, faites‑le. Si vous ne pouvez pas, contraignez :

• Interdire la connexion réseau pour l’admin local quand c’est faisable.
• Exiger une politique de mot de passe forte et une rotation.
• Journaliser et alerter sur toute utilisation (succès et échec).
• Retirer ces comptes des workflows « quotidien ». L’admin doit être un outil, pas un mode de vie.

Arrêtez de traiter les machines des développeurs comme « spéciales »

Les développeurs ont souvent besoin d’outils qui touchent des composants bas niveau : débogueurs, hyperviseurs, runtimes de conteneurs, VPN, modules noyau.
Mais la réponse n’est pas « leur donner l’admin local pour toujours ». La réponse est :

• Fournir des canaux d’installation gérés pour les outils approuvés.
• Utiliser des conteneurs/devices isolés quand c’est possible pour compartimenter le risque.
• Préférer des alternatives au moindre privilège (containers sans root, pilotes en espace utilisateur, paquets signés).
• Donner de l’admin temporaire seulement quand la plateforme l’exige vraiment.

Instrumenter les changements d’admin local comme des changements de production

Si quelqu’un ajoute un utilisateur aux administrateurs locaux, c’est un événement de sécurité et un changement opérationnel. Traitez‑le comme tel :
journalisation centralisée, alertes, et une trace qui survit à l’effacement de l’endpoint.

Citation (idée paraphrasée)

« L’espérance n’est pas une stratégie » (idée souvent paraphrasée attribuée à divers leaders des opérations et de l’ingénierie).

L’attribution importe ici : ce sentiment est courant dans la culture SRE même si la formulation exacte varie. Le sens opérationnel est précis : vous avez besoin de contrôles exécutoires, pas d’attentes.

Blague n°2 : La seule chose plus permanente qu’une « exception admin temporaire » est une imprimante qui casse cinq minutes avant une réunion.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: « Nous avons retiré l’admin local, et tout s’est cassé »

Cause racine : Vous aviez des dépendances cachées sur les droits admin : installateurs, mises à jour, pilotes, applications héritées écrivant dans des chemins protégés, ou outils de dev s’attendant à un accès système.

Correction : Inventoriez les actions en échec, puis pave the road : déployez les apps via des canaux gérés, corrigez les permissions de fichiers, utilisez des installations par utilisateur, et implémentez de l’élévation JIT pour les vrais cas limites.

2) Symptom: « L’EDR est installé, mais les attaquants l’ont quand même désactivé »

Cause racine : La protection contre la falsification n’est pas activée, pas appliquée, ou peut être override localement par des admins.

Correction : Appliquez la protection contre la falsification via une politique centralisée que les admins locaux ne peuvent pas modifier. Transmettez les logs hors hôte rapidement. Alertez sur les tentatives d’arrêt de service et les modifications d’exclusion.

3) Symptom: « Nous avons la MFA ; comment ont-ils bougé latéralement ? »

Cause racine : Le mouvement latéral a utilisé une authentification locale (mots de passe admin locaux partagés, NTLM/SMB, identifiants mis en cache) et non vos portes MFA.

Correction : Mots de passe locaux uniques, réduire les surfaces d’administration à distance, resserrer l’usage de NTLM quand possible, et appliquer le tiering pour que les endpoints ne détiennent pas de secrets privilégiés.

4) Symptom: « Le compte d’un sous‑traitant réapparaît comme admin local »

Cause racine : La nestation de groupes ou les règles d’affectation d’appareils les ré-ajoutent ; ou un script d’image/provisionnement attribue à répétition des admins locaux.

Correction : Auditez la source de la vérité : politiques MDM, GPO, scripts de provisioning. Retirez le sous‑traitant des groupes en amont. Ajoutez des alertes sur les changements de membership admin local.

5) Symptom: « Nous faisons tourner les mots de passe, mais le même mot de passe apparaît sur plusieurs machines »

Cause racine : La rotation n’est pas réellement déployée partout, ou certaines OU/classes d’appareils sont exclues, ou des clones sont faits depuis un template après la définition du mot de passe.

Correction : Validez la santé de la rotation par appareil, assurez-vous que le provisioning s’exécute avant l’exposition des appareils, et bloquez les workflows d’imagerie qui estampillent des identifiants identiques après l’enrôlement.

6) Symptom: « Nous ne pouvons pas désactiver Administrator intégré à cause de la récupération »

Cause racine : Pas de vrai processus casse‑glace, donc le compte fait double emploi entre récupération et commodité quotidienne.

Correction : Créez un vrai workflow casse‑glace : identifiants stockés dans un coffre contrôlé, accès audité, runbooks testés, et rotation automatique après usage. Puis désactivez ou contraignez fortement l’Administrator intégré pour les opérations quotidiennes.

7) Symptom: « Les admins Mac réapparaissent après qu’on les ait retirés »

Cause racine : Politique MDM/Jamf, scripts d’enrôlement, ou outils de migration ré-ajoutent les utilisateurs au groupe admin.

Correction : Trouvez le mécanisme d’application, ajustez le scope, et implémentez l’admin temporaire via la politique plutôt que par membership permanent de groupe.

8) Symptom: « Les serveurs Linux vont bien, mais les postes dev ont root partout »

Cause racine : Les postes de travail ont été traités comme machines personnelles ; NOPASSWD et des règles sudo larges ont été utilisées pour éviter les frictions.

Correction : Appliquez des contrôles de grade serveur aux postes : restreindre sudoers, exiger une authentification, journaliser sudo, et utiliser des environnements de développement qui n’ont pas besoin du root de l’hôte.

Listes de vérification / plan étape par étape

Plan étape par étape : réduire le risque admin local sans provoquer une révolte

1. Mesurez l’état actuel.
   • Comptez les admins locaux effectifs par classe d’endpoint (Windows/macOS/Linux).
   • Identifiez quels groupes accordent l’admin et pourquoi.
   • Identifiez quelles applications/pilotes nécessitent une élévation.
2. Corrigez d’abord les problèmes catastrophiques.
   • Déployez la rotation unique des mots de passe admin locaux (Windows LAPS ou équivalent).
   • Retirez Domain Admins (ou admins locataires cloud) des groupes admin locaux des endpoints.
   • Bloquez les comptes privilégiés d’ouvrir une session interactive sur les postes de travail.
3. Construisez un workflow d’élévation.
   • Admin limité dans le temps pour les utilisateurs approuvés.
   • Élévation tracée par ticket pour les cas non approuvés.
   • Expiration automatique et journalisation.
4. Pave the road pour les besoins courants.
   • Catalogue d’apps géré pour installations/mises à jour.
   • Déploiement de pilotes préapprouvés.
   • Packaging et support des outils développeurs.
5. Verrouillez les surfaces d’admin local.
   • Interdire la connexion réseau pour l’admin local quand c’est possible.
   • Restreindre WinRM/WMI/partages SMB administratifs aux réseaux de gestion.
   • Activer les protections LSASS et le durcissement des identifiants.
6. Instrumenter et alerter.
   • Alerter sur les changements de groupe admin local.
   • Alerter sur l’activation de l’Administrator intégré.
   • Alerter sur les tentatives d’arrêt de l’EDR et sur les changements d’exclusion.
7. Déployer par vagues.
   • Pilotez avec l’IT, puis les power users, puis la population générale.
   • Suivez les cassures par catégorie et corrigez systématiquement.
8. Rendre ça durable.
   • Politique : pas d’admin local permanent sauf rôles approuvés.
   • Audits trimestriels de la composition admin et des exceptions.
   • Mettre fin aux outils hérités nécessitant constamment des droits admin.

Checklist opérationnelle : à quoi ressemble le « bon »

• Les endpoints ont des mots de passe admin locaux uniques ou aucun admin local utilisable.
• L’admin/root intégré est désactivé ou fortement contraint et surveillé.
• Les changements de membership admin local génèrent des alertes avec identités responsables.
• Les comptes privilégiés sont empêchés de se connecter aux endpoints (tiering/PAWs).
• Les installations logicielles passent par des canaux gérés, pas par des sessions admin ad‑hoc.
• La protection contre la falsification EDR ne peut pas être désactivée par des admins locaux.
• Les services d’administration à distance sont restreints aux réseaux de gestion et fortement authentifiés.

FAQ

1) L’admin local est‑il toujours une faille de sécurité ?

C’est toujours une concentration de risque. Si c’est une faille inacceptable dépend de votre modèle de menace et des contrôles compensatoires.
Si vous avez des identifiants uniques par appareil, une journalisation forte, de l’élévation JIT et du tiering, vous pouvez gérer le risque. Si vous avez des mots de passe partagés et de l’admin permanent, c’est une faille.

2) Pourquoi ne pas simplement supprimer tous les admins locaux et en finir ?

Parce que réalité : pilotes, outils d’accessibilité, composants VPN, agents de sécurité, et certains workflows de dev nécessitent réellement des opérations élevées.
L’approche correcte est de supprimer l’admin permanent et de le remplacer par des installations gérées et une élévation limitée dans le temps.

3) Qu’est‑ce qui est pire : un utilisateur avec admin local, ou un compte admin local partagé ?

Le partage d’un admin local entre appareils est généralement pire car il permet un mouvement latéral rapide.
Un utilisateur seul avec l’admin sur sa machine reste risqué, mais cela ne devient pas automatiquement un identifiant de flotte.

4) La MFA peut‑elle corriger l’abus d’admin local ?

La MFA peut protéger l’accès aux services centralisés. L’authentification locale contourne souvent totalement la MFA.
Vous avez besoin de contrôles endpoint : mots de passe admin locaux uniques, réduction des surfaces d’admin à distance, et protection des identifiants.

5) Si nous utilisons Windows LAPS, sommes‑nous à l’abri des problèmes d’admin local ?

Vous êtes plus protégés contre le problème du « même mot de passe pour tous ». Vous n’êtes pas à l’abri de l’admin local en tant que privilège.
Un attaquant avec l’admin sur une machine peut toujours persister, falsifier et récolter ce à quoi cette machine a accès. LAPS est un contrôle nécessaire, pas une ligne d’arrivée.

6) Qu’en est‑il des développeurs qui ont besoin d’admin pour Docker ou la virtualisation ?

Traitez la capacité à contrôler l’hyperviseur/runtime de conteneurs comme un privilège élevé. Préférez les containers rootless, des outils VM gérés, ou des hôtes dev dédiés.
Si vous devez accorder l’admin, rendez‑le temporaire et journalisé, et isolez les identifiants sensibles loin de ces machines.

7) Comment détecter la prolifération d’admin local dans le temps ?

Surveillez les changements de membership des groupes admin locaux et alertez sur les ajouts. Prenez périodiquement des instantanés de la composition admin effective et différez‑les.
La prolifération n’est pas un événement ponctuel ; c’est de l’entropie. Vous avez besoin d’une boucle de contrôle.

8) Quel est le gain le plus rapide si nous ne pouvons faire qu’une seule chose ce trimestre ?

Assurez‑vous que les mots de passe admin locaux sont uniques par appareil et sont tournés, et retirez les groupes d’identité de haut niveau des admins locaux des endpoints.
Ce changement seul casse souvent la chaîne de mouvement latéral la plus courante.

9) Les comptes admin locaux sont‑ils équivalents aux rôles « device admin » dans un MDM cloud ?

Pas exactement. Les rôles cloud donnent une capacité administrative sur les plans de gestion ; l’admin local donne du pouvoir sur le dispositif lui‑même.
Ils se recoupent opérationnellement, mais les attaquants se soucient du chemin le plus court vers l’exécution de code et la persistance—souvent local.

10) Comment conserver un accès casse‑glace sans garder une porte dérobée permanente ?

Construisez un vrai processus casse‑glace : identifiants stockés dans un coffre contrôlé, accès audité, runbooks testés, et rotation automatique après usage.
Puis désactivez ou restreignez le compte pour les opérations normales et alertez sur toute utilisation.

Conclusion : prochaines étapes pratiques

Les comptes administrateurs locaux sont la porte dérobée cachée que vous avez installée vous‑même—généralement pour de bonnes raisons, et presque toujours laissée ouverte plus longtemps que prévu.
Les attaquants n’ont pas besoin de battre votre pile d’identité s’ils peuvent devenir la machine.

Faites ceci ensuite, dans l’ordre :

1. Auditez la composition admin local effective sur les endpoints et éliminez les admins accidentels (surtout les surprises de groupes imbriqués).
2. Assurez‑vous que les mots de passe admin locaux sont uniques par appareil et tournent automatiquement.
3. Retirez les niveaux d’identité à haute privilège des endpoints ; empêchez les admins de domaine/locataire de se connecter aux postes de travail.
4. Implémentez l’élévation juste‑à‑temps et une voie pavée pour les installations afin de ne pas recréer des « exceptions » sous un autre nom.
5. Alertez sur les changements d’admin local et assurez‑vous que les journaux endpoints quittent rapidement l’hôte.

L’objectif n’est pas la pureté. L’objectif est de rendre la compromission contenue, récupérable et ennuyeuse. L’ennuyeux est le meilleur compliment qu’un intervenant en incident puisse faire à votre architecture.