Après le dernier billet sur « pass the pass » et…
- les réactions positives de certains
- les réactions étranges d’autres
- une incitation très forte de newsoft à fouiller ma mémoire vive ;)
… voici la suite !
Le provider
Il n’y a pas que le provider TsPkg
qui « doit » conserver une copie du mot de passe de session en clair ; le provider WDigest
avait le même comportement bien avant l’apparition de TsPkg
(et il l’a toujours…)
- http://en.wikipedia.org/wiki/Digest_access_authentication
Une des composantes du premier hash étant variable (le REALM), USER et PASSWORD doivent être constamment accessibles en clair pour calculer le condensé de réponse
Problème
Bien que je n’ai jamais rencontré de véritable architecture reposant sur une authentification Digest et n’ayant toujours pas autorisé Windows à conserver mon mot de passe en clair, celui-ci se retrouve encore une fois en mémoire :
Téléchargement et fonctionnement
Une mise à jour de mimikatz, toujours en version « alpha », pour l’occasion :
Attention, cette version de mimikatz reste toujours en « alpha »…
A exécuter après avoir obtenu des droits administrateurs (ou system) :
privilege::debug inject::process lsass.exe sekurlsa.dll @getLogonPasswords
La commande privilege::debug
n’est pas obligatoire si vous êtes déjà system.
(plus d’information : http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa#getLogonPasswords et http://blog.gentilkiwi.com/mimikatz/librairies/sekurlsa/wdigest)
Nouvelles commandes (si besoin de séparation) :
@getMSV @getTsPkg @getWDigest
@getLogonPasswords
utilise les providers disponibles et connus par mimikatz
.
Améliorations
- ne garder que
kerberos
,msv1_0
etschannel
dans la liste des providers autorisés (se référer au billet d’origine sur « pass the pass »)
ils sont essentiels au fonctionnement des services Windows - demander à Microsoft la validité de ce mode de fonctionnement avec un minimum de provider