"Secrets" DPAPI ou DPAPI pour Pentesters

Le deuxième article basé sur les résultats de la performance de notre équipe à OFFZONE-2018. Cette fois, envisagez une discussion avec MainTrack «Windows DPAPI« Sekretiki »ou DPAPI pour pentesters».

Attention! Beaucoup de hêtres!

Lorsque je mène des campagnes RedTeam, je veux donner moins de raisons à la réaction de BlueTeam, mais il peut y en avoir plusieurs. Par exemple, exécuter mimikatz pour obtenir des mots de passe ou des certificats utilisateur. Même si nous avons pu lui «otmazyvat» de Kaspersky, BlueTeam a la possibilité de suivre en utilisant des outils spécialisés tels que Sysmon, Microsoft ATA, etc. Dans le même temps, je voudrais obtenir le maximum d'informations d'une machine utilisateur compromise. Au cours de campagnes menées à plusieurs reprises par RedTeam pour contrer de véritables équipes BlueTeam, nous sommes parvenus à la conclusion qu'il fallait éviter les actions pouvant servir d'indicateurs de compromis du système. Pour atteindre cet objectif est possible grâce à l'utilisation des mécanismes juridiques et des actions fournies par le système d'exploitation pour l'utilisateur.

L'un de ces outils juridiques est le mécanisme DPAPI (Windows Data Protection API), qui est utilisé par le système d'exploitation et diverses applications pour crypter les données utilisateur sensibles (principalement les mots de passe, les clés cryptographiques, etc.) Pour l'utilisateur final et ses applications, DPAPI semble extrêmement simple : Il n'y a que 2 fonctions - "crypter les données" et "décrypter les données". Dans cet article, je voudrais examiner l'utilité d'un tel mécanisme pour les pentesters lors des campagnes RedTeam.

Qu'est-ce que DPAPI? Seulement brièvement et en russe


Depuis 2000, tous les systèmes d'exploitation Windows ont commencé à utiliser le moteur DPAPI pour protéger les données des utilisateurs.

Si nous ignorons toute la cryptographie que nous avons examinée dans le rapport, pour décrypter les données cryptées via DPAPI, nous avons besoin: d'une clé principale, du SID de l'utilisateur, du hachage du mot de passe de l'utilisateur et du blob DPAPI lui-même (données DPAPI cryptées).

En général, le processus ressemble à ceci:



À l'intérieur de notre "chapeau cryptographique", il existe de nombreux mécanismes de cryptographie différents que nous ne considérerons pas dans cet article, afin de ne pas surcharger le lecteur. Nous notons seulement que la partie principale de DPAPI est le soi-disant Masterkey (clé principale). En termes simples, la clé principale est de 64 octets de données aléatoires chiffrées à l'aide de la préface, qui est générée à partir du mot de passe de l'utilisateur et de son SID.


Des paramètres supplémentaires participent également à la génération des pré-proies: le nombre d'itérations (IterN), le sel et le HMAC, qui peuvent varier d'un cas à l'autre. Les valeurs de ces paramètres sont stockées avec la clé principale dans un fichier.

Ainsi, en connaissant le mot de passe de l'utilisateur, son SID et en lisant les paramètres de génération à partir du fichier de clé principale (HMAC, Salt, InterN), nous pouvons générer un prépuce et décrypter la clé principale, c'est-à-dire obtenez les 64 octets très aléatoires que nous utiliserons pour déchiffrer les blobs DPAPI.

Et si je change mon mot de passe?


Habituellement, les mots de passe des utilisateurs changent à intervalles réguliers. Que se passe-t-il si l'utilisateur modifie le mot de passe? Où est passé le précédent? En effet, pour décrypter la clé principale, vous devez connaître le mot de passe de l'utilisateur, et rechiffrer toutes les clés principales de l'utilisateur à chaque fois est un plaisir trop cher. Dans ce cas, tout est pensé dans Windows.

Il existe un fichier spécial (CREDHIST), dont la tâche est de stocker tous les mots de passe des utilisateurs précédents. Il est également chiffré avec le mot de passe actuel de l'utilisateur et stocké sur la pile. Si le système échoue soudainement à déchiffrer la clé principale, il procède comme suit: en utilisant le mot de passe actuel, il déchiffre le premier enregistrement dans CREDHIST. Le mot de passe tente à nouveau de déchiffrer la clé principale, et ainsi de suite jusqu'à ce que les mots de passe de la chaîne soient épuisés ou que la clé principale soit déchiffrée.

Un peu sur les clés privées d'un contrôleur de domaine


Comme vous l'avez peut-être deviné, DPAPI est appliqué à tous les utilisateurs, y compris les utilisateurs de domaine. Afin de pouvoir réinitialiser le mot de passe à un utilisateur qui l'a oublié avec succès après une soirée du vendredi soir, vous avez besoin d'une clé de rechange qui sera stockée dans un endroit sûr. Selon Microsoft, un endroit aussi fiable est un contrôleur de domaine.

L'essence du mécanisme de déchiffrement de la clé principale après la réinitialisation du mot de passe utilisateur est la suivante: une paire de clés RSA - privées et publiques - est créée sur le contrôleur de domaine. La clé privée est stockée sur le contrôleur de domaine dans la base de données NTDS et s'appelle BCKUPKEY_xxxx (voir la figure ci-dessous), et la clé publique est distribuée à tous les systèmes de domaine et est utilisée pour générer un doublon de la clé principale lors de sa génération.

Après avoir créé une clé principale sur une machine de domaine, son doublon est également créé (ou plutôt, le matériau de la clé principale est ses 64 octets), qui est stocké avec la clé principale principale dans un fichier et est appelé clé de domaine. Si vous perdez la clé principale principale, c'est-à-dire lors de la réinitialisation du mot de passe de l'utilisateur, le système en envoie un duplicata au contrôleur de domaine et demande à le déchiffrer. Le contrôleur, après avoir autorisé l'utilisateur, déchiffre le duplicata et le renvoie au système, après quoi le matériel de la clé principale est déjà crypté à nouveau avec un nouveau mot de passe.



Ayant les privilèges appropriés dans le domaine (le plus souvent administrateur), vous pouvez obtenir ces clés RSA privées du contrôleur de domaine via le mécanisme de réplication et les utiliser pour décrypter davantage les clés principales créées sur les machines du domaine. Cela peut être fait en utilisant mimikatz ou DSInternals. Vous pouvez en savoir plus à ce sujet dans le wiki mimikatz ou le blog DSInternals .

Où sont stockées les clés principales et quelles sont-elles?


La clé principale peut être un utilisateur et un système, selon les secrets cryptés. La clé principale utilisateur est stockée dans le profil utilisateur de la manière suivante:

Users\%USER%\AppData\Roaming\Microsoft\Protect\%SID%\

Au cas où, le système stocke toutes les clés principales jamais utilisées par l'utilisateur. Après tout, elle ne sait pas à l'avance quel maître devra déchiffrer quelque chose avec une clé. Le GUID de la clé actuelle utilisée est stocké dans le fichier préféré.



Les clés principales du système sont stockées de la manière suivante:
windows\system32\Microsoft\Protect\S-1-5-18\

De même avec l'utilisateur - une clé principale est utilisée, dont le nom peut être trouvé dans le fichier préféré, où toutes les clés qui ont déjà été utilisées sont stockées.



Eh bien, que peut apporter ce DPAPI au Pentester?


Le DPAPI étant un mécanisme légal et simple, diverses applications tentent de l'utiliser. Parce que c'est pratique et sûr. Pour le moment, bien sûr.

Par exemple, DPAPI est utilisé pour crypter les clés privées des certificats clients et système, les clés WIFI, Chrome (cookies, mots de passe), DropBox, Skype, RSA SecurID (une application logicielle qui génère des clés à usage unique). Et ce n'est en aucun cas une liste exhaustive.

La tâche du pentester est de décrypter les blobs nécessaires et d'obtenir des mots de passe, des cookies, etc.

Il existe plusieurs façons de procéder. D'une manière ou d'une autre, elles se résument toutes à deux transcriptions - en ligne et hors ligne. Le décryptage en ligne est lorsque sur la machine de l'utilisateur, nous appelons simplement les fonctions système pour décrypter les données et passer le blob DPAPI à l'entrée, et le système fait tout par lui-même - il recherche la clé principale avec laquelle le blob a été crypté, le décrypte en utilisant le SID de l'utilisateur et un hachage de mot de passe stocké dans la mémoire LSASS.

La figure ci-dessous montre un exemple d'appel de fonctions DPAPI pour le chiffrement et le déchiffrement sur PowerShell.



Tout d'abord, nous chiffrons notre secret (dans ce cas, le mot «mot de passe») en appelant la fonction [Security.Cryptography.ProtectedData] :: Protect (). Et nous le faisons deux fois - dans le premier cas en utilisant la clé principale de l'utilisateur (paramètre CurrentUser), et dans le second - la clé principale du système (paramètre LocalMachine). Ensuite, nous pouvons décrypter les blobs résultants en appelant la fonction inverse - [Security.Cryptography.ProtectedData] :: UnProtect ().

De plus, dans ce cas, la valeur du paramètre CurrentUser ou LocalMachine n'a pas d'importance, car le système lui-même trouve une clé principale appropriée pour décoder le blob et fait tout ce qui est nécessaire. Dans les deux cas, nous obtenons notre secret initial - le mot «mot de passe» (sa représentation octet par bit).

Lors du décryptage en ligne, il est important de comprendre dans quel contexte vous appelez la fonction UnProtect (). Pour que le déchiffrement réussisse, vous devez être dans une session utilisateur ou vous connecter sous une nouvelle session. La chose est le hachage de mot de passe, qui est stocké dans la mémoire LSASS. Si vous effectuez un appel en dehors de la session de l'utilisateur (par exemple, vous vous êtes connecté au système via le réseau via psexec ou meterpreter), vous n'avez donc pas besoin d'un hachage de mot de passe pour déchiffrer la clé principale. Il est, bien sûr, dans la prochaine session, mais LSASS ne vous le donnera pas, car il s'agit d'une autre session, bien qu'elle ait été créée sous le même utilisateur. Pour un décryptage en ligne réussi, vous devez soit migrer vers n'importe quel processus lancé par l'utilisateur connecté via l'interface graphique, soit vous connecter complètement au système, par exemple via RDP.

Une alternative à PowerShell pour le déchiffrement en ligne des objets blob DPAPI peut être un appel à mimiktaz :: blob avec le paramètre / Unprotect. En entrée, il reçoit un fichier binaire avec un blob DPAPI, et en sortie on obtient des données décryptées. Plus de cas utilisant mimikatz sont décrits sur le blog HarmJ0y.

La bille blanche est tombée. Que faire de ma ferme avec vidyuhi?


Étant donné que les clés principales DPAPI sont chiffrées sur le mot de passe de l'utilisateur, vous pouvez essayer le processus inverse - forcer le mot de passe de l'utilisateur par sa clé principale. Par exemple, nous avons reçu une connexion inverse de notre macro ou DDE du fichier docx envoyé. Nous pouvons prendre la clé principale de l'utilisateur et restaurer le mot de passe de l'utilisateur sans escalade de privilèges et lancement de mimikatz.

Puis-je utiliser Hashcat ou JohnTheRipper pour le mot de passe bruteforce? Mais avant cela, vous devez obtenir les paramètres de force brute à partir de la composition de John avec le script approprié:

 ./DPAPImk2john.py –S <sid> -mk <masterkey> -c <domain|local> 

Ensuite, nous pouvons déjà envoyer le résultat du script à notre ferme avec des cartes vidéo et espérons que l'utilisateur a un mot de passe faible, car la vitesse de la force brute de la clé principale est approximativement comparable à la vitesse d'énumération WPA2, c'est-à-dire assez lentement.

Il convient de noter ici que dans le cas où une clé principale est générée sur un domaine Windows 10, 10 000 autres cycles d'algorithme PBKDF2 sont ajoutés à la génération de Prekey. Mais pire encore, ni Hashcat ni JohnTheRipper ne le savent (au moins au moment d'écrire ces lignes), ce qui signifie qu'ils ne pourront pas supprimer le mot de passe d'une telle clé principale.

"Pour enlever tout ce qui est mauvais, puis pour le découvrir ..."


Comme nous l'avons noté précédemment, l'exécution d'actions suspectes sur la machine de l'utilisateur peut susciter un intérêt supplémentaire de la part de l'équipe Blueteam, et cela, en conséquence, est lourd du fait que tout RedTeam s'arrêtera là. Un exemple est le lancement de PowerShell sur l'ordinateur d'un comptable ou d'une secrétaire, suivi d'une enquête sur l'incident. Afin de ne pas créer de suspicion inutile, il est préférable d'utiliser des méthodes hors ligne pour décoder les blobs DPAPI. Pour ce faire, vous devez d'abord récupérer tout ce dont vous avez besoin sur la machine, à savoir:

  • Clés maîtresses utilisateur
  • Clés principales du système
  • Fichier CREDHIST (s'il ne s'agit pas d'une machine de domaine);
  • Mot de passe utilisateur (ou son hachage sha1 / ntlm);
  • SID de l'utilisateur;
  • Blobs DPAPI que nous voulons décrypter.

Pour le déchiffrement en mode hors ligne, on ne peut pas se passer d'outils spécialisés. Ces outils peuvent être:

  • Mimikatz;
  • Impacket (à partir de la 18e version, il dispose de la fonctionnalité DPAPI);
  • Framework Dpapick.

Il s'agit du framework dpapick dont nous parlerons plus en détail.

Le framework python dpapick lui-même a été réalisé par le chercheur Jean-Michel Pikode en 2014 et est une implémentation des mécanismes DPAPI sur les crypto-bibliothèques Python. L'utilisation de python, ainsi que la structure du framework, permettent de l'adapter facilement aux différents mécanismes DPAPI. Dans sa version d'origine, dpapick n'était pas en mesure d'utiliser la clé de sauvegarde de domaine pour déchiffrer les clés principales et il manquait des mécanismes pour déchiffrer les clés principales créées sur Windows 10 en mode machine de domaine.

Après avoir corrigé ces lacunes et étendu la fonctionnalité de décryptage des objets blob DPAPI, dpapick s'est transformé en un très bon outil pour le décodage hors ligne de DPAPI. Ci-dessous, à titre d'exemples, nous montrerons les options d'utilisation de ce cadre pour déchiffrer les données utilisateur chiffrées via DPAPI.

Chrome - prenez et déchiffrez les cookies et les mots de passe


Les %localappdata%\Google\Chrome\User Data\Default\Cookies Chrome sont stockés dans le fichier %localappdata%\Google\Chrome\User Data\Default\Cookies
Les données de connexion se %localappdata%\Google\Chrome\User Data\Default\Login Data dans le fichier %localappdata%\Google\Chrome\User Data\Default\Login Data

Les deux fichiers sont des bases de données sqlite3 dans lesquelles des données sensibles sont stockées en tant qu'objets blob DPAPI. Dans le cadre de dpapick, il existe un dissecteur (analyseur) prêt à l'emploi de ces données (examples / chrome.py). Pour un décryptage réussi, il doit spécifier le répertoire avec les clés principales, le sid de l'utilisateur, son mot de passe ou l'emplacement de la clé privée du contrôleur de domaine, ainsi que le fichier sqlite3 de Chrome (cookie ou données de connexion).

Décryptage hors ligne du cookie Chrome avec mot de passe utilisateur

 ./chrome.py --cookie <cookiefile> --sid <SID> --password <..> --masterkey <masterkeydir> 

Décryptage hors connexion d'un cookie Chrome à l'aide d'un hachage à partir du mot de passe d'un utilisateur

 ./chrome.py --cookie <cookiefile> --sid <SID> --hash <..> --masterkey <masterkeydir> 

Décryptage hors ligne des mots de passe Chrome à l'aide d'une clé privée à partir d'un contrôleur de domaine

 ./chrome.py --chrome <login file> --pkey <rsa-priv.pem> --masterkey <masterkeydir> 

DPAPI pour les certificats clients


Les certificats clients sont beaucoup utilisés où - pour générer OTP, EFS ou l'authentification dans VPN, applications Web, etc.

Les certificats de clé publique eux-mêmes sont stockés dans le profil utilisateur:
%APPDATA%\Microsoft\SystemCertificates\My\Certificates\
Et les clés privées, à l'aide desquelles la signature est réellement effectuée ou d'autres opérations cryptographiques sont cryptées via DPAPI et sont également situées dans le profil utilisateur le long du chemin:

 %APPDATA%\Roaming\Microsoft\Crypto\RSA\<SID>\ 

Afin de déchiffrer avec succès les clés de certificat privées, puis de recréer les fichiers PFX, en plus des fichiers ci-dessus, nous avons également besoin des clés principales de l'utilisateur, ainsi que de son SID et de son mot de passe (ou d'une clé RSA privée du contrôleur).

En utilisant Dpapick et le mot de passe utilisateur, nous décryptons ceci:

 ./efs.py --certificates <cert dir> --rsakyes <RSA dir> --sid <..> --password <..> --masterkey <masterkeydir> 



Le paramètre facultatif rsaout dans la capture d'écran vous permet en outre d'exporter des clés RSA déchiffrées au format PEM. Le résultat du script est un fichier PFX recréé sans mot de passe, qui peut déjà être importé pour vous-même et utilisé aux fins prévues. Si dans les répertoires ci-dessus il y a plusieurs certificats et clés privées, alors dpapick essaiera de décrypter chacun d'eux et de créer plusieurs fichiers pfx.

Les mêmes actions peuvent être effectuées à l'aide d'une clé privée de domaine pour déchiffrer la clé principale en spécifiant le paramètre approprié:

 ./efs.py --certificates <cert dir> --rsakyes <RSA dir> --masterkey <masterkeydir> --pkey <domain bkp key> 

Un peu plus sur les "puces" du domaine


En parlant du domaine Active Directory, il convient de mentionner une fonctionnalité aussi merveilleuse que l'itinérance des informations d'identification - une fonction de domaine lorsque les clés principales, les mots de passe cryptés et les certificats «voyagent» pour l'utilisateur dans tout le domaine Active Directory. Ils ne sont pas liés à une machine spécifique et «arrivent» à l'ordinateur sur lequel l'utilisateur du domaine se connecte.

Lorsque cette "fonctionnalité" est activée, tous les certificats que l'utilisateur importe, ainsi que toutes ses clés et mots de passe privés, volent dans AD et sont stockés dans les attributs de compte correspondants: msPKIAccountCrdentailas et msPKIDPAPIMasterKeys.

Vous pouvez voir à quoi il ressemble dans AD, par exemple, via ldapsearch:

 ldapsearch -x -h dc1.lab.local -D “user1@lab.local" -s sub "samAccountname=user1" ldapsearch -x -h dc1.lab.local -D "admin@lab.local" -s sub "samAccountname=anyuser" 



Par défaut, un utilisateur ne peut recevoir que des attributs DPAPI pour son compte. Mais avec des privilèges élevés, cela peut être fait pour n'importe quel compte, y compris un compte d'ordinateur.

L'itinérance des informations d'identification est une technologie très pratique non seulement pour les administrateurs, mais aussi pour les pentesters. Après avoir accédé au contrôleur de domaine via ldap, vous pouvez fusionner tous les certificats utilisateur, ses clés principales et mots de passe cryptés via DPAPI (par exemple, les mots de passe pour la connexion aux lecteurs réseau).

Et pourquoi ne pas ajouter une telle fonctionnalité à dpapick, nous avons pensé - et lui avons appris à extraire automatiquement les certificats d'un contrôleur de domaine via ldap, à les déchiffrer et à générer des fichiers pfx.

 ./efs.py –ldap-server <..> --ldap-connect admin:Passw0rd@lab.local --ldap-user user1 --password Password1 ./efs.py –ldap-server <..> --ldap-connect admin:Passw0rd@lab.local --ldap-user user1 --pkey <rsa-priv.pem> 



Pour exécuter le script, il est nécessaire de spécifier le contrôleur de domaine en tant que serveur LDAP, les détails de la connexion à celui-ci, le nom du compte pour lequel nous recevons des certificats et un mot de passe pour déchiffrer la clé principale (ou une clé de sauvegarde privée du contrôleur).

Dropbox Parti en 60 secondes ...


Dropbox est un autre exemple d'utilisation de DPAPI pour stocker des secrets d'utilisateur. Les jetons d'autorisation pour Dropbox sont stockés dans des fichiers:

 c:\users\<username>\Appdata\Local\Dropbox\instance1\config.dbx c:\users\<username>\Appdata\Local\Dropbox\instance_db\instanse.dbx 

Ce sont des bases de données sqlite3 chiffrées contenant des données pour la connexion. Pour le chiffrement, une clé symétrique est utilisée, qui à son tour est chiffrée via DPAPI et stockée dans le registre:

HKCU\SOFTWARE\Dropbox\ks
HKCU\SOFTWARE\Dropbox\ks1


Ainsi, l'ordre général de détournement de dropbox est le suivant:

  1. nous prenons deux fichiers de base de données de l'ordinateur;
  2. nous obtenons les clés du registre et les décryptons en utilisant dpapick;
  3. en utilisant DPAPI, nous chiffrons les clés reçues sur notre machine et les mettons dans le registre;
  4. sur notre machine, nous remplaçons les fichiers de base de données et exécutons Dropbox.

Vous devez savoir que des autorisations spéciales sont définies pour les branches de registre ci-dessus. Ils ne peuvent être lus que par l'utilisateur. Ni l'administrateur ni le système ne peuvent les lire. Ainsi, si vous accédez au registre au nom d'un autre utilisateur (même un administrateur), vous devez d'abord définir les autorisations appropriées sur les branches de registre spécifiées. Par exemple, alors (PowerShell):

 $Sid="S-1-5-21-3463664321-2923530833-3546627382-1000"; $key=[Microsoft.Win32.Registry]::USERS.OpenSubKey("$sid\SOFTWARE\Dropbox\ks",[Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::ChangePermissions); $acl = $key.GetAccessControl(); $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("administrator","FullControl","Allow"); $acl.SetAccessRule($rule); $key.SetAccessControl($acl); $key_path = "REGISTRY::HKEY_USERS\$Sid\SOFTWARE\Dropbox\ks"; (Get-ItemProperty -Path $key_path -Name Client).Client; 

Les clés ks et ks1 contiennent l'en-tête (8 octets) de la version dbx avant le blob DPAPI et le blob md5 HMAC DPAPI (16 derniers octets). Le blob DPAPI lui-même commence par le 9e octet 0x01000000D0 ... Ces octets doivent être copiés au format base64 dans un fichier, qui est ensuite déchiffré via dpapick:

 ./filegeneric.py --sid <..> --password <..> --masterkey <..> --base64file <..> 

Ensuite, sur votre machine, vous devez crypter les clés reçues à la dernière étape avec notre clé principale et mettre le résultat dans les branches de registre appropriées.

Pour le chiffrement, il est plus pratique d'utiliser PowerShell:

 $hdata="4efebbdf394d4003317fc5c357beac4b"; [Byte[]] $dv0_entropy = 0xd1,0x14,0xa5,0x52,0x12,0x65,0x5f,0x74,0xbd,0x77,0x2e,0x37,0xe6,0x4a,0xee,0x9b; $data = ($hdata -split "(?<=\G\w{2})(?=\w{2})" | %{ [Convert]::ToByte( $_, 16 ) }); Add-Type -AssemblyName System.Security; $dk1 = [system.security.cryptography.protecteddata]::Protect($data,$dv0_entropy,[System.Security.Cryptography.DataProtectionScope]::CurrentUser); $pr=([System.BitConverter]::ToString($dk1));$pr $OBJ_hmac = New-Object System.Security.Cryptography.HMACMD5 $hmac = $OBJ_hmac.ComputeHash($dk1) $pr=([System.BitConverter]::ToString($hmac));$pr 

Dans ce cas, hdata est la clé reçue au stade du déchiffrement. dv0_entropy est la constante d'entropie utilisée par DBOX dans DPAPI. Au blob résultant, vous devez attribuer un en-tête de 8 octets 0x00000000F6000000 à l'avant et HMACMD5 + 0x00 à l'arrière
Après cela, vous pouvez écrire des données dans les clés de registre appropriées.

DPAPI et RSA SecurID


RSA SecurID est un programme client utilisé pour générer un mot de passe à usage unique, développé par RSA.

Il est assez populaire pour les grandes entreprises et utilise également le DPAPI, mais un peu plus compliqué. Dans ce cas, les ingénieurs RSA ont décidé de devenir confus et ont appliqué des schémas DPAPI plus complexes.

Les données de jeton sont stockées dans le fichier %LOCALAPPDATA%\RSA\SecurIDStorage , qui est la base de données sqlite3. Chaque jeton chiffré contient son EnTokenSid chiffré (paramètres pour l'initialisation initiale de l'algorithme de génération de code). EnTokenSid est généré sur la base de DBKey, SID du jeton et SID utilisateur, et DBKey est déjà généré par le décryptage DPAPI DBKeyEnc dans la séquence suivante:
DBKeyEnc = DPAPI(CurrenUser, DPAPI(LocalSystem(DBKey))

C'est-à-dire Tout d'abord, la clé DB est chiffrée avec la clé principale du système, puis le blob DPAPI résultant est à nouveau chiffré avec la clé principale de l'utilisateur.

Également dans la base de données, il y a CryptoCheckSum de CheckSum:
CryptoCheckSum = blob DPAPI (CurrenUser)

Ainsi, pour que le SecurIDStorage fusionné fonctionne sur votre machine, vous devez:

  1. En raison du fait que le SID de l'utilisateur est impliqué dans la formation du EncTokenSid, il est nécessaire de définir le SID de l'utilisateur actuel dans la machine virtuelle à la même valeur que le SID de l'utilisateur dont la base SecurIDStorage est prise. L'utilitaire NewSid de SysInternals nous y aidera;
  2. Déchiffrer DBKeyEnc en utilisant la clé principale et le mot de passe de l'utilisateur ou la clé privée du domaine (dans le cas où la machine est un domaine);
  3. Déchiffrez le résultat du déchiffrement précédent à l'aide de la clé principale du système et de la valeur du paramètre DPAPI_SYSTEM;
  4. Déchiffrer CryptoCheckSum à l'aide de la clé principale de l'utilisateur
  5. Chiffrez les valeurs DBKey et CheckSum reçues dans l'ordre inverse déjà sur votre machine virtuelle;
  6. Dans certaines versions de SecurID, vous devrez également définir la taille du disque dur de la machine virtuelle sur la même taille que la taille du disque dur de la machine source, comme le programme le vérifie au démarrage.

Comme mentionné ci-dessus, afin de déchiffrer DBKeyEnc, en plus de la clé principale de l'utilisateur, nous aurons également besoin d'une clé principale du système, ainsi que de la valeur DPAPI_SYSTEM, avec laquelle les clés principales du système sont déchiffrées. DAPPI_SYSTEM est en fait un prépuce déjà formé, participant à la formation des clés principales du système. Vous pouvez l'obtenir à partir de la mémoire LSASS (via mimikatz ou en analysant le vidage de processus) ou à partir des branches de registre correspondantes (HKLM \ SYSTEM, HKLM \ SECURITY), en les vidant et en analysant le même Impacket.

Ensuite, nous pouvons utiliser le DPAPI_SYSTEM obtenu pour déchiffrer les blobs nécessaires à l'aide de dpapick (l'analyseur est examples / filegeneric.py), comme indiqué dans les captures d'écran suivantes:

1) Mise en ligne de DPAPI_SYSTEM via mimikatz



2) Obtenir DPAPI_SYSTEM via Impacket hors ligne



3) Décryptage DPAPIck avec les clés principales utilisateur et système



Feuille de triche


Afin de ne pas oublier la place de données spécifiques, nous les placerons dans une section distincte:

Clés principales personnalisées

 %APPDATA%\Microsoft\Protect\<SID>\* 

Clés principales du système

 Windows\System32\Microsoft\Protect\* 

DPAPI_SYSTEM

 LSASecrets – online SYSTEM, SECURITY (reg save …, system\backup, etc) 

Certificats utilisateur

 %APPDATA%\Microsoft\SystemCertificates\My\Certificates\ %APPDATA%\Microsoft\Crypto\RSA\<SID>\ 

Certificats système

 HKLM:\SOFTWARE\Microsoft\SystemCertificates\MY\Certificates\* C:\Programdata\Microsoft\Crypto\RSA\MachineKeys\ 

Chrome

 %localappdata%\Google\Chrome\User Data\Default\Cookies %localappdata%\Google\Chrome\User Data\Default\Login Data 

Dropbox

 HKCU\SOFTWARE\Dropbox\ks HKCU\SOFTWARE\Dropbox\ks1 %APPDATA%\Local\Dropbox\instance1\config.dbx %APPDATA%\Local\Dropbox\instance_db\instanse.dbx 

Rsa securid

 %LOCALAPPDATA%\RSA\SecurIDStorage 

Petite conclusion


Le DPAPI est une chose magnifique - l'essentiel est de comprendre comment il peut être utilisé lors des pentests et des études RedTeam.

Dans cet article, nous avons examiné quelques exemples où le déchiffrement DPAPI peut être appliqué. En fait, la portée est beaucoup plus large. Par exemple, nous n'avons pas considéré les clés RDP (* .rdg), Icloud (fichier pList), Skype (*. Xml) pour la connexion au Wi-Fi. Partout DPAPI est appliqué et les parseurs correspondants sont implémentés dans le cadre du framework dpapick.

Une version modifiée de dpapick est disponible sur notre GitHub . Nous vous invitons à utiliser cet outil pour décrypter DPAPI et nous vous serons reconnaissants pour le développement de dpapick.

Et des informations intéressantes peuvent être trouvées dans notre chaîne dans les télégrammes . Nous racontons IB à travers les yeux de RedTeam.

PS Merci aux organisateurs d'OFFZONE-2018 pour une conférence sympa!

PPS La deuxième partie de l'article ici

Source: https://habr.com/ru/post/fr434514/


All Articles