FONCTIONNEMENT DE LA DATA PROTECTION API (aka DPAPI) DE MICROSOFT



Sous Windows, le gestionnaire d'identification permet de sauvegarder des identifiants de connexion à une cible définie :



Ces identifiants peuvent par exemple concerner une connexion à un partage de fichiers (SMB) ou à une connexion Bureau à distance (RDP).

Afin de garantir la sécurité des identifiants enregistrés, ces derniers sont chiffrés grâce à une API appelée Data Protection, via la fonction "CryptProtectData".

Cette API établit un tunnel RPC local chiffré pour se connecter au processus LSASS et utilise ensuite les fonctions de la librairie CryptAPI en utilisant le fichier Crypt32.dll. Les fonctions s'exécutent donc dans le contexte de sécurité de LSA.

Dans un premier temps, l'API va générer une clé principale, appelée "Master Key". Cette clé est une sorte de gros mot de passe de 512 octets de données aléatoires. Cette clé n'est pas utilisée explicitement pour protéger les données. Au lieu de cela, une clé de session symétrique est calculée en fonction de la clé principale.

Pour protéger cette clé principale, le hash SHA-1 du mot de passe de l'utilisateur est utilisé. 16 octets aléatoires sont utilisés pour générer un grain de sel unique (appelé "IV") ainsi qu'un nombre aléatoire d'itérations. La fonction PBKDF2 (Password-Based Key Derivation Function 2.0) est utilisée avec autant d'itérations que définit précédemment, selon la norme cryptographique PKCS#5, pour obtenir une clé de chiffrement.

La clé de chiffrement est ensuite utilisée pour chiffrer la clé principale de manière symétrique grâce à un algorithme 3DES. Le grain de sel et le nombre d'itérations sont conservés de manière claire, sans chiffrement, et ensuite stockés avec la clé de chiffrement dans le répertoire AppData de l'utilisateur sous la forme d'un fichier MKF, pour "Master Key File", nommé par un GUID unique.



La clé principale de 512 octets précédemment générée est hashée via l'algorithme SHA-1, puis son hash est utilisé pour créér une clé de session symétrique via l'algorithme HMAC-SHA512. La clé de session permet de chiffrer les identifiants de l'utilisateur dans un fichier "blob" grâce à l'algorithme de chiffrement symétrique AES256.

Le fichier "blob", qui contient les informations d'identification chiffrées de l'utilisateur, est également stockée dans le répertoire AppData de l'utilisateur. Son contenu n'est qu'une suite de bytes parmi lesquels on retrouve de manière claire, sans chiffrement, le GUID du fichier Master Key File qui lui est lié.



Lorsqu'un ordinateur est membre d'un domaine, DPAPI dispose d'un mécanisme de sauvegarde pour permettre la déprotection des données en cas de perte du mot de passe de l'utilisateur (appelé "Credential Roaming"). Lors de l'installation d'un nouveau domaine sur un contrôleur de domaine, une paire de clés publique et privée est générée, associée à DPAPI.

Lorsqu'une clé principale est générée sur un poste client, ce dernier communique via un appel RPC authentifié avec un contrôleur de domaine pour récupérer une copie de la clé publique du domaine. Le client chiffre la clé principale avec la clé publique du contrôleur de domaine. Enfin, il stock cette nouvelle clé principale de secours dans son répertoire AppData, dans le Master Key File contenant la clé principale protégée par le mot de passe de l'utilisateur.



Si le déchiffrement de la clé principale ne peut pas s'effectuer via le hash du mot de passe de l'utilisateur, le client envoit la clé principale de secours à un contrôleur de domaine via un appel RPC authentifié. Le contrôleur de domaine peut déchiffrer la clé principale à l'aide de sa clé privée et la renvoit au client.

Avec un compte Administrateur du domaine, il est possible d'extraire manuellement la clé privée du contrôleur de domaine via un appel RPC authentifié, sous la forme d'un fichier "PVK", pour "Private Key File", afin de déchiffrer des fichiers Master Key File d'un poste client de manière hors ligne.



Dans le cas d'un changement de mot de passe d'un utilisateur, les fichiers Master Key File ne sont pas rechiffrés avec le nouveau hash du mot de passe automatiquement. Lors de la tentative de déchiffrement de la clé principale, si le hash SHA-1 du mot de passe de l'utilisateur n'est pas utilisable, le contenu du fichier CREDHIST, qui contient les hashs au format NT et au format SHA-1 des anciens mot de passe de l'utilisateur, sera récupéré afin de déchiffré le fichier Master Key File avec l'ancien mot de passe. La clé principale sera ensuite à nouveau chiffrée avec le nouveau mot de passe de l'utilisateur.



Dans le cadre du projet HEKATOMB la clé privée est extraite du contrôleur de domaine via un appel RPC authentifié et pour chaque poste du domaine, les fichiers blob et le fichier Master Key File qui leurs sont rattachés sont récupérés. Toutes les clés principales de secours sont déchiffrées grâce à la clé privée du contrôleur de domaine, permettant ainsi de déchiffrer le contenu des fichiers blob pour obtenir les identifiants qu'ils contiennent.



La paire de clés publique et privée du contrôleur de domaine peut être visualisée depuis la console "Utilisateurs et ordinateurs Active Directory" en activant l'affichage des fonctionnalités avancées.



La plus grosse vulnérabilité ici réside dans le fait qu'en cas de compromission, aucun mécanisme de renouvellement de ces certificats n'existent de manière officielle, et les manipulations manuelles qui permettent de le faire nécessitent autant d'efforts que de reconstruire un nouveau domaine...
N'ayant trouvé aucune documentation sur le sujet, j'ai posé la question à la personne la plus compétente que je connaisse sur ce sujet : MONSIEUR Benjamin Delpy, le créateur de Mimikatz :









Sources :

https://learn.microsoft.com/en-us/previous-versions/ms995355(v%3Dmsdn.10)


.