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 :

• http://blog.gentilkiwi.com/mimikatz

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 et schannel 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