Bon. Il semble que je peux plus hijacker votre AC à travers les sauvegardes. Vous avez fermé cette porte après mes dernières réflexions. Je suis un peu blessé, honnêtement. Mais black hat et tout, vous faire mal c'est ma job. Pas vrai?

Alors je vais trouver un autre chemin.

J'ai hijacké le poste de Suzie Q. Elle est tombée dans mon numéro de prince exotique, pis là je suis dedans. Elle est pas super privilégiée, ce qui est malheureux. Mais je suis patient. Le help desk va finir par passer pour me laisser un cadeau sous la forme d'identifiants d'administrateur global du desktop.

En attendant par contre, je vérifie toujours ce à quoi Suzie Q a accès.

C'est la partie où normalement je vous expliquerais les commandes de reconnaissance exactes. Je ne le ferai pas. Pas parce que les commandes sont secrètes. Elles ne le sont pas. AD est en lecture seule pour quiconque est authentifié, par design, avec quelques exceptions mineures. La configuration de votre AC, vos modèles, vos droits d'inscription publiés, chaque groupe dans lequel Suzie Q se trouve, tout ça est lisible pour moi à partir du moment où j'atterris sur sa machine. Vous donner les commandes transformerait juste ce billet en tutoriel. Le point n'est pas comment je trouve ce qu'elle a. Le point est que je peux.

Et qu'est-ce que Suzie Q a? Voyons voir. Des droits d'inscription sur un modèle User. Standard. Utilisateurs du domaine a Inscription dessus. Suzie est un Utilisateur du domaine. Moi aussi, maintenant.

Qu'est-ce que ce modèle me donne?

Authentification du client, pour commencer. Ça veut dire que je peux demander un certificat en tant que Suzie, ou en tant que la personne que j'usurpe une fois que le help desk passe, et l'utiliser comme preuve d'identité pour m'authentifier à n'importe quoi dans votre environnement qui fait confiance à votre AD. Applications web avec login style carte à puce. VPN. SaaS interne qui fait du SSO par cert. N'importe quoi. Le cert dit « c'est Suzie Q » et votre infrastructure croit le cert parce qu'il est signé par votre AC.

Mais voici celle que j'aime mieux. Encrypting File System.

Le modèle User publie aussi un certificat EFS. Je peux m'en émettre un, aucune question posée. Et EFS fonctionne comme ça : l'utilisateur a un cert, le cert chiffre une clé, la clé chiffre les fichiers. Si vous avez la clé privée du cert, vous déchiffrez. Sinon, vous ne déchiffrez pas.

Alors voici ce que je fais. Je m'émets un cert EFS frais au nom de Suzie. Je chiffre chaque fichier sur son drive avec mon nouveau cert. Documents. Tableurs. Plans de projet. La cache SharePoint. Tout. Ensuite je prends la clé privée de mon cert frais et je la brûle. Balancée dans le néant. Oubliée. Coupure propre, rien qui traîne.

Les fichiers de Suzie sont encore chiffrés. Magnifiquement chiffrés. Mathématiquement solides. Sauf que personne n'a la clé. Pas elle. Pas moi. Pas votre help desk.

Avant de partir, je dépose un fichier texte sur son bureau. Juste ça :

Bonne journée,
Hiro

Elle va le voir lundi matin. Elle va l'ouvrir avant n'importe quoi d'autre, parce que c'est la seule chose sur son bureau qui n'est pas derrière une icône de cadenas. C'est à ce moment-là qu'elle va comprendre.

Vous pensez restaurer à partir d'une sauvegarde? Peut-être. Ça dépend de ce que vous sauvegardez. Les fichiers protégés par EFS sur vos partages de fichiers? Même problème si le cert de l'utilisateur a été utilisé côté serveur. Certains environnements découvrent à la dure que les données chiffrées par EFS sont exactement aussi mortes que le cert qui les a chiffrées.

Vous pensez que votre agent de récupération de clé va vous sauver? Laissez-moi vérifier. Il y a un cert KRA configuré sur l'AC, mais il est expiré. Le remplacement n'a jamais été émis. La clé privée de l'original est sur une clé USB dans le tiroir du bureau de quelqu'un, au bureau qu'on a quitté il y a trois ans.

C'est pas du rançongiciel. Pas de note de rançon. Je demande pas d'argent. Je suis juste ici pour vous gâcher la semaine. Mission accomplie.

Hiro out.

Fin de la scène.

Si vous êtes un défenseur, voici ce que vous devez comprendre. L'attaque que je viens de décrire n'utilise aucun accès privilégié. Aucun exploit. Aucun malware au sens traditionnel. Elle utilise votre AC de la façon dont vous l'avez configurée. Si ça marche, c'est parce que la plupart des entreprises publient le modèle User — ou une copie — avec la permission Inscription accordée aux Utilisateurs du domaine, et le font depuis l'installation initiale de l'AC. Personne ne le révise parce que personne ne pense qu'un cert User est dangereux. Il l'est.

Trois choses à vérifier cette semaine

Un : qui peut s'inscrire à quoi. Ouvrez la console Modèles de certificats. Pour chaque modèle publié, regardez l'onglet Sécurité. Utilisateurs du domaine, Utilisateurs authentifiés, ou n'importe quel groupe large avec la permission Inscription sur un modèle qui publie Authentification du client ou EFS est votre problème. Le correctif, c'est de restreindre l'inscription à un groupe spécifique qui contient seulement les utilisateurs qui ont vraiment besoin de ce type de cert. La plupart des utilisateurs n'ont pas besoin d'EFS. Beaucoup n'ont pas besoin d'Authentification du client non plus, ça dépend de ce que votre environnement utilise les certs pour.

Deux : est-ce que vous avez vraiment un agent de récupération de clé qui fonctionne. Un cert KRA expiré, c'est pas un KRA. Un cert KRA dont la clé privée a été perdue dans une migration d'AC précédente, c'est pas un KRA. Un KRA configuré sur l'AC mais sans modèles activés pour le chiffrement qui le référencent, c'est pas un KRA. Vérifiez les trois. Si vous utilisez EFS dans votre environnement, vous avez besoin d'un KRA qui fonctionne, et vous devez tester la récupération à intervalles réguliers. Annuellement au minimum. Si la récupération ne fonctionne pas dans un exercice de table, elle ne fonctionnera pas quand vous en aurez besoin.

Trois : si EFS est même approprié pour votre environnement. EFS avait du sens en 2003 quand les portables étaient rares et que BitLocker n'existait pas. En 2026, le chiffrement complet du disque gère mieux le scénario de perte de portable, avec récupération centralisée via Active Directory ou Entra ID, sans complexité par-fichier, sans cycle de vie de cert par-utilisateur, sans dépendance KRA. Beaucoup d'organisations roulent encore EFS par défaut parce que personne ne l'a jamais éteint. Si vous êtes une de ces organisations, la question à répondre c'est si vous perdriez plus en retirant EFS ou en le laissant en place comme vecteur de rançongiciel non supervisé.

Hiro n'a pas besoin d'être sophistiqué. Il a besoin de patience et d'une payload de phishing qui fonctionne contre un seul utilisateur. Le reste de la chaîne d'attaque, c'est votre AC qui fait exactement ce que vous l'avez configurée à faire, signer des certs pour des utilisateurs qui ont des droits d'inscription.

La première étape c'est de savoir quels sont vraiment ces droits.