Tuesday, April 9, 2013

Poshing the hashes: Using PowerShell to play with hashes

UPDATE: As mentioned here, even after KB2871997, you could still 'Posh' the SID-500-Administrator's hashes.


What do Pen Testers generally do after dumping hashes (or creds)? I asked this question during my workshop at BlackHat Europe. The answer was use of tools like psexec (independent or msf) to replay or pass the hashes to get access to more machines. This could be more fun and useful with a combination of Windows Credential Editor (thanks Hernan!) and Powershell.

I call this Poshing the Hashes.


Update 2: Another post by me explains how to dump hashes using powershell. Current post explains how to use them.

Update: This is for a scenario where you have network access to other computers, like an internal pentest.

Assume we have dumped hashes of a target system using WCE. We can start a powershell session with these credentials using the -s and -c options of WCE.



This powershell session will have privileges of the user whose hashes were used in WCE. Please note that there is nothing which could be flagged by an AV as we are using WCE on our machine and rest of it is Windows' features.

Now, while I was writing this post, someone asked me on twitter if it is possible to check the hashes on multiple systems before trying them, like Keimpx. The solution I gave didn't work, so I wrote Create-MultipleSessions.ps1 which will check the credentials on multiple machines by using a WMI query (which pulls IP addresses on successful authentication).

Here is the source:


Here is Create-MultipleSessions in action against my lab systems.



Nice,we poshed some hashes! the hashes worked on couple of systems. If you want to pass credentials to the script, use -Creds parameter. This will open up a prompt which will ask for credentials.

Now, if powershell remoting is enabled in a target environment, which is generally true in a Windows environment nowadays (it is enabled by default for Server 2012), you can leverage it for your purpose. Since our attacking machine and target machine are not part of same domain, we must add the target to our attacking machines TrustedHosts list. This is designed to stop a user from sending his credentials to a rogue server. Lets just trust everyone :)


In the wce-started powershell window, we can use Enter-PSSession to connect to the target. By default only those users which are part of Local Administrator Group can use powershell remoting.



Bingo! We have an interactive and *elevated* powershell session on the remote machine, as the hashes used were of a local admin. Now we can have more post exploitation fun using Nishang.

Ok, an interactive shell on one computer is fine but what if we want to open sessions on many computers? You can use the -CreateSessions switch of Create-MultipleSessions.ps1 to create sessions to multiple computers.



We can use Enter-PSSession to connect to the session of choice.

Now, what if we want to execute a command or script on hundreds of computers? Powershell has a cmdlet Invoke-Command exactly for this purpose. To execute a command on multiple computers, lets use powershell session started using WCE


Notice that we have sucessfully executed $env:COMPUTERNAME on two computers.

Invoke-Command also supports -Credentials parameter.

Invoke-Command has another very useful parameter -FilePath. Using this you can execute a local script on remote computers, very handy! You can use many payloads available with Nishang using this for post-exploitation neatness ;)

I wrote Run-EXEonRemote which *drops* executables on remote machines and execute those. For example,  lets use Run-EXEonRemote to drop and execute WCE on multiple machines and dump plain text passwords.


Here is the source


Want to run an executable in memory using PowerShell? Some smart people are working on it.

Please note that Execution Policy is not a problem if you use -Filepath with Invoke-Command until the script use things like Import-Module. I have been unable to bypass the Execution Policy in such case. Still, as I have been saying, Execution Policy is not a security control but a user discretionary control.

Invoke-Command could also be used to run scripts as jobs.It could also be used to run scripts using Session parameter so that commands can have state. Use help Invoke-Command to see more. PowerShell help system is very good and really useful.

As we saw, it is better to use PowerShell Remoting if hashes or creds are available. A word of advice, stick with PowerShell v2 while Poshing the Hashes, PowerShell v3 failed me sometimes while connecting to machines with v2, even -Version parameter did not help. I have not looked deeper into the matter but it may be because of modifications in remoting protocol.

Create-MultipleSessions and Run-EXEonRemote have been added to Nishang. Please update your repos.

Hope this would be useful. Please leave comments and feedback.