How to reveal Windows password ?

Hi !

Disclaimer

Any actions and or activities related to the material contained within this blog is solely your responsibility.The misuse of the information in this website can result in criminal charges brought against the persons in question. The authors will not be held responsible in the event any criminal charges be brought against any individuals misusing the information in this website to break the law.
This script is published for educational use only. I am no way responsible for any misuse of the information.
This article is related to Computer Security and I am not promote hacking / cracking / software piracy.
This article is not a GUIDE of Hacking. It is only provide information about the legal ways of retrieving the passwords. You shall not misuse the information to gain unauthorised access. However you may try out these hacks on your own computer at your own risk. Performing hack attempts (without permission) on computers that you do not own is illegal.

This article explains how to use my PowerShell tool to reveal the passwords used by users of the computers running under Windows 2003, 2008R2, 2012, 2012r2, Windows XP, 7 (32 and 64 bits) 8, and 8.1

Steps below are :
1) Get the tool
2) Extract the files in the ZIP
3) Launch PowerShell with Administrator Rights
4) Prepare your environment
5) Open the tool into PowerShell
6) Launch the tool
7) Get Windows 7/Windows server 2008 password

1) Get the tool

The first step is to download the tool. You can got it at this Github address which is the official repository : https://github.com/giMini/RWMC

Simply click on the download ZIP button at the bottom right of the screen :

2) Extract the files in the ZIP

Right click on RWMC-master.zip you just download (we assumed you download it into d:\donwload) and then on Extract All...

Clic on Extract button

You'll get a folder RWMC-master with the tool.

The files which are in the folder :

3) Launch PowerShell with Administrator Rights

First step: update your PowerShell version on the Microsoft website: https://www.microsoft.com/en-ca/download/details.aspx?id=40855

Choose the good version :

• Windows 7 SP1
  • x64: Windows6.1-KB2819745-x64-MultiPkg.msu
  • x86: Windows6.1-KB2819745-x86.msu
• Windows Server 2008 R2 SP1
  • x64: Windows6.1-KB2819745-x64-MultiPkg.msu
• Windows Server 2012 / Windows 8
  • x64: Windows8-RT-KB2799888-x64.msu

Once your computer is up-to-date, go to C:\Windows\System32\WindowsPowerShell\v1.0 and then right click on powershell_ise.exe

PowerShell Starting...

And your PowerShell opens !

4) Prepare your environment

Enter this command : "Set-ExecutionPolicy Unrestricted -force"

and press Enter

5) Open the tool in PowerShell

Browse to the place where you extract the tool you download in step 1. In this example, it is under d:\download\RWMC-master\RWMC-master\Reveal-MemoryCredentials, click on Reveal-MemoryCredentials.ps1 and then on Open.

If all went well, you should get this result (the script is opened in PowerShell) : 

6) Launch the tool

Great ! Now we can launch the script to reveal all the Windows password of the users who have logged on the machine (and the machine has not rebooted).

Click on the green arrow (or on "F5" on your keyboard)

You'll get two warnings, click Run Once each time :

If you see the white Rabbit, you passed the previous steps :-)

7) Get Windows passwords

a) At the prompt, enter the option "local" (to get the passwords on this computer)

...and get the passwords !

Finally, a window opens with all the passwords found on the machine!

b) Remotely

c) From a dump

• 1 = Windows 7 - 64 bits / 2008r2
• 132 = Windows 7 - 32 bits
• 2 = Windows 8/2012
• 2r2 = Windows 10/2012r2
• 8.1 = Windows 8.1
• 3 = Windows XP/2003

Enjoy !

 \

   \ /\   Follow the white Rabbit :-)

   ( )       Pierre-Alexandre Braeken

.( @ ). 

Fonctionnement de Kerberos sous Windows

Processus de log on pour l’utilisateur U

La première opération de l’utilisateur U est le logon dans le domaine. À travers une séquence spéciale, appelée SAS (Secure Attention Sequence) bien connue sous la séquence CTRL+ALT+DELETE, l’utilisateur U encode ses credentials (username et password ou SmartCard) à travers LogonUI. Ces credentials sont envoyés à LSASS (Local Security Authority Subsystem) qui utilise la fonction lsalookupauthenticationpackage pour déterminer quel provider utiliser. Ensuite, les credentials sont passés au provider grâce à la fonction LsaLogonUser.

Cas où le process est abandonné :

• Credentials incorrects
• Le provider indiqué n’est pas trouvé
• La méthode de logon n’est pas acceptée (interractive logon, network, batch, service)

Le provider Kerberos entre dans un processus que nous expliquons en 6 étapes :

Version simple du fonctionnement de Kerberos

L’utilisateur U veut accéder à une ressource R sur le serveur S intégré au domaine D

1) Le client U, à travers Kerberos, contacte le KDC (Key Distribution Center) afin d’obtenir un TGT (Ticket Granting Ticket) en donnant son identité, le service name (dans le cas de AS_REQ, c’est toujours le service krbtgt) et un timestamp encrypté avec son secret (dérivé du password ou long-term-key). Ce timestamp (ainsi que d’autres données, comme l’ip et le lifetime) est en fait un authenticator qui permet de prouver au KDC que U est bien U.

2) KDC décrypte le message avec le secret partagé avec U (vérification dans sa base), vérifie la valeur du timestamp proposé (refuse si la différence entre le timestamp et son heure est de plus de 5 minutes (par défaut ou que le timestamp est plus petit ou égal au timestamp du précédent authenticator). Ensuite le service d’authentification crée une clé de session de logon (nécessaire pour s’adresser au TGS) qu’il crypte avec le secret partagé. Il crée alors le TGT qui inclut les informations de l’utilisateur (dont le user RID et les group memberships), le lifetime et la clé de session de logon cryptée. Enfin, il crypte le TGT avec son propre secret (password du compte krbtgt) et envoi à U le TGT et la clé de session de logon cryptée. Le TGT peut seulement être décrypté par un KDC valide ! Un RODC a son propre compte krbtgt avec un password propre. Ce qui veut dire qu’un utilisateur présentant un TGT provenant d’un RODC à un RWDC, le RWDC dump le TGT et en génère un nouveau.

3) Le client reçoit deux messages, le TGT et la clé de session de logon. Le client décrypte la clé de session avec son secret et le met en cache. En plus de ceci, le client stocke également le TGT dans son cache (klist permet d’afficher les tickets mis en cache). Dès lors que le client veut accéder à un service sur le réseau, il fait une demande au service Ticket-Granting-Service du KDC. Sa demande contient un authenticator encrypté avec la clé de session de logon et composé du username et d’un timestamp, le nom du service qu’il veut joindre (Service Principal Name*) et le TGT.

4) Le KDC reçoit la demande de ticket de service. Il la traite complètement seulement si le SPN est unique et le timestamp est dans le range acceptable et le TGT est valide et non expiré. Le Ticket-Granting-Service décrypte le TGT avec son secret (password de krbtgt) et extrait la clé de session de logon. Cette clé de session lui permet donc de décrypter l’authenticator. S’il y parvient avec succès, il extrait du TGT les informations de l’utilisateur. Ensuite, le TGS crée une clé de session de service.

Le TGS crée deux messages:

• un message contenant le SPN, le timestamp récupéré après avoir décrypté l’authenticator et la clé de session de service à Ce message est encrypté avec la clé de session de logon
• le Ticket de service contenant le username U, le SPN, la clé de session de service et le timestamp à ce message est encrypté avec le secret du service (long term key du server sur lequel réside le service)

5) Le client U envoie le ticket de service par une requête au serveur S. La requête contient l’authenticator (time stamp et username), qui est encrypté avec la clé de session de service et le ticket de service.

6) Le serveur reçoit la requête et décrypte le ticket de service en utilisant son secret et extrait la clé de session de service. Ensuite il utilise la clé de session de service pour décrypter l’authenticator et pour l’évaluer. Si le test est OK, le serveur encrypte l’authenticator avec la clé de session de service et renvoie l’authenticator au client. Le client décrypte l’authenticator, récupère le timestamp, et s’il s’agit du même que l’original, c’est bon la connexion s’opère, le client a accès au service demandé.

Les packets sont constitués comme suit :

*Que sont les Principal Names ?

User Principal Name (UPN)
Doit être unique au sein d’une forêt. Il s’agit d’un attribut d’un objet Active Directory. Il ne peut contenir qu’une seule valeur (exemple: bob@contoso.com)

Service Principal Name (SPN)
Doit être unique au sein d’une forêt. Il est défini au niveau du contexte de sécurité du compte pour lequel il tourne. Il est du type Service/hostname (on peut également spécifier un numéro de port). Le SPN est très important dans un domaine Active Directory. En effet, c’est grâce à lui que tous les services possibles dans un réseau Active Directory sont accédés. Ils doivent être uniques pour un type de service car sinon, KDC est dans l’impossibilité de déterminer quel host héberge le service.