Monday, September 16, 2013

Pivoting to and poking other computers using powershell - Powerpreter and Nishang 0.3.1 - Part 2

This is second post in the series about powerpreter. You can read the first part here:

We can use Powerpreter to pivot to and poke other machines in a network. The assumption here is that we have local admin access to a machine in a network. That admin happens to have access to other machines in the network (as in many enterprise environments).


Powerpreter contains Pivot functionality. It depends on Powershell Remoting to function. It means all which could be done using Pivot could be done even with Invoke-Command too. In fact, Pivot is just a wrapper around Invoke-Command.

Pivot could be used in both interactive and non-interactive mode. We can use username and password or use credentials of current session (for example, using a WCE generated powershell session).

Lets see a non-interactive Pivot to a single machine.

We can use it on multiple machines too. Lets see a non-interactive Pivot to multiple machines.

Nice and easy, isn't it.

Non-interactive is good but nothing beats an interactive session on a machine :) Let see interactive pivoting on multiple machines with a WCE-generated powershell (using password hashes).

Nice, we have two sessions with us. We can use Get-PSSession cmdlet to list the sessions. To interact with a session use Use-Session function of powerpreter.

We can use built-in cmdlet Enter-PSSession to interact, then why we have a separate function for similar thing in powerpreter? This happens when one tries to use Enter-PSSession from a powershell remoting session.

Points to note in above example:
1. When using Pivot from remote, note that we used username in form of "computer\username".
2. We got an error while trying to use Enter-PSSession from remote session, AFAIK it is not supported.
3. But Use-Session from powerpreter worked!

Why did Use-Session work?

Invoke-Command is supported from a powershell remoting session. We are using it with -Session parameter to save state and use it interactively.

Now, lets have a look at couple more functionalities in powerpreter which could be used to poke other machines in the network.

As the name suggest we can use this to port scan other machines on a network.

Please note that we used the parameter -ScanPort to specify that we want a port scan, by default only a ping sweep is performed. There is a default port range which would be scanned but a custom port range could also be provided.

Lets look for a MSSQL Server on the network.

Bingo! We found one - already setup ;)

We can use this to Brute Force services like MSSQL, ActiveDirectory, Web or FTP on other machines. Default service is MSSQL. Lets brute force with sa username on above discovered server.

Yay we got one password! - this too has been setup already ;)

As you can see we could use a list of password (also IP and username) instead of using a single password. There is a small catch here, the password list should start with the word "password" like this.

Why? Have a look at the code snippet.

It is due to the ValueFromPipeLineByPropertyName property. See this for more details:

Ok we have username and password for the MSSQL Server, what next? See this earlier post to understand usage of Execute-Command-MSSQL: 

Function which can check for credentials on remote computers and can open PSSessions if the credentials work. See this old post to understand its working:

There are some code changes to powerpreter and other scripts in Nishang. So I am releasing Nishang 0.3.1 too. You can find the repository here:

As always I would like feedback, bugs, feature request and code contributions. Enjoy.

Friday, September 6, 2013

Kautilya 0.4.4 - dump lsa secrets, introduce vulns, improved backdoors and more

Here comes  Kautilya 0.4.4. This version adds three new payloads and improves couple of others.

Download and Execute Powerhell Script - As the name suggests this script downloads a powershell script and executes it on the target.

Remove Update - Remove all or security or a specific hotfix from the target. Great way to introduce vulnerability on a target.

LSA Secrets - Dump LSA Secrets from a victim. The payload detects 32-bit or 64-bit machine and calls the proper version of powershell accordingly.

I am always looking for contributors, if you want to contribute to Kautilya (or Nishang) do not hesitate to contact me.

Please refer to the CHANGELOG below for details.

- Added "Download and Execute Powershell Script" windows payload.
- Added "Remove Update" windows payload.
- Added "LSA Secrets" windows payload.
- Updated "DNS TXT Backdoor". It is much more easy to use now.
- Renamed Wait for Command to HTTP Backdoor
- HTTP Backdoor now keeps running till the stopstring is matched.
- An option has been added for no exfiltration of data. Choose 0 when Kautilya asks for exfil option.

Please update your repos or download the source from the repository here

On a related note, Paul - the maker of Teensy pushed some updates for non-English keyboards. See the thread here (Thanks to Lorenz for reporting this): Please let me know if it helps with the problems for non-English keyboard users.

 Please feel free to report bugs and feedback.

Saturday, August 10, 2013

(Introducing) Powerpreter and Nishang 0.3.0 : Easy post exploitation using powershell - Part 1

This post is all about what I was unable to discuss during my talk at Defcon 21 "Powerpreter: Post Exploitation like a boss". In 45 minutes one can only highlight limited things, so this and some more posts would try to fill the gaps left during the talk.

Posts planned in this series are:
Introducing Powerpreter and Nishang 0.3.0 : Easy post exploitation using powershell - Part 1
Powerpreter and Nishang 0.3.0 : Pivoting and poking other computers - Part 2
Powerpreter and Nishang 0.3.0 : Persistence - Part 3
Powerpreter and Nishang 0.3.0 : Various methods to deploy and use - Part 4
Introducing Antak, Powerpreter and Nishang 0.3.0 : A webshell in powershell - Part 5
UPDATE: I have decided to finish the series in three parts. Part 4 and Part 5 would be posted as independent posts.

Powerpreter is a powershell module. I decided to make it a part of Nishang as there is a large amount of repeated code. This post assumes that we have Administrative access to a Windows 7 machine. Powerpreter can surely be used as a non-admin user but obviously with limited (but still useful as seen in below examples) functionalities. Like other scripts in Nishang, I have tried my best to keep powerpreter compatible to powershellv2 so you may see some code which could be done by a cmdlet in powershellv3 and v4.

Once we have access to a machine, powerpreter could be downloaded and imported in a powershell session for further fun. For using hashes or credentials with powershell remoting see my previous posts:

 From a powershell remoting session:

Now, to list the methods in the imported module:

We can list help for each function by using help. For example to get help for Check-VM

Now, lets have a look at some of these methods/commands/payloads. Some of the payloads in powerpreter have already been explained in blog posts about Nishang. I will explain only couple of those and some new functionality in powerpreter:

Take Get-WLAN-Keys for example

You can also use -exfil option if you would like to exfiltrate info to pastebin/gmail/tinypaste. See this for more detail:

Enable-DuplicateToken, Get-PassHashes and Get-LsaSecret.

Use Enable-DuplicateToken to escalate to SYSTEM and then use Get-PassHases or Get-LsaSecret depending on your requirement.

Let's see it in action from a meterpreter.

First we download the powerpreter. I use -encodedcommand option with powershell.exe in meterpreter to avoid any issues. StringtoBase64 in powerpreter could be used for this.

In case of Get-LsaSecret on 64-bit machine, 32-bit powershell needs to be run. So use this path for powershell.exe: C:\Windows\SysWOW64\WindowsPowerShell\v1.0 from powershell remoting session. But while using meterpreter if the process on target is 32-bit, no need to specifically call 32-bit powershell.

Get-LsaSecret is written by Niklas Goude and Get-Passhashes by David Kennedy


This backdoor can be controlled using a website whose content could be changed. Lets use pastebin for this.

It asks for four parameters. It keeps polling the url provided in CheckURL option for a string, provided in the Magicstring option. As soon as the string matches, it pulls a powershell script/command from PayloadURL.

Differents commands or scripts can be executed by changing the payloads in PayloadURL. After a sucessful execution, it waits for 60 seconds before polling again to avoid generating too much traffic.
The backdoor starts in a new process. With -exfil option, results of the backdoor could be exfiltrated.

This is how the backdoor process will look to naked eyes.

DNS TXT Backdoor
This backdoor uses DNS TXT records for receiving commands and scripts to execute as well as instructions to stop and start.

The backoor asks for various options. StartDomain is the one which would be polled by the backdoor for instructions. Three possibilities are present

  1. If txt record at Startdomain matches cmdstring, the backdoor will query txt record of commanddomain to look for a oneline command and will execute it on the target.
  2. If txt record at Startdomain matches psstring, the backdoor will look base64 encoded powershell script in txt record of psdomain.
  3. If txt record of Startdomain matches stopstring the payload stops.

As in case of HTTP-Backdoor this backdoor also runs in a new process and could use -exfil option. The below example shows a usage of backdoor.

We executed Get-Service on the target and results were exfiltrated to gmail.

Now lets have a look at Keylogger. Unfortunately, this does not work from a powershell remoting session. Lets run it from a meterpreter session.

The keylogger logs keys to a file in user temp directory of the target. The logged keys could be parsed using Parse_Keys script in Nishang. If you use -exfil option and select gmail , the key.log file would be sent as an attachment to the given gmail id.To avoid sending same keys repeatedly, after 30 reads key.log is flushed out.

DNS TXT Code Execution
This payload could be used to pull shellcode from DNS TXT records. The shellcode is then executed in memory. We have to provide different domains for 32-bit and 64-bit shellcode. The payload will determine the architecture during execution and pull the shellcode accordingly.

We could use the command given in help of the payload to generate the shellcode using msf.

Lets see this in action on a 64-bit machine.


On the listener console:
The code execution code is written by Matt Graeber.

UPDATE: Since many of you asked - HTTP-Backdoor, DNS TXT Backdoor, Keylogger and DNS TXT Code Execution - all could be used by a non-admin user. Though to use powershell remoting we must have admin access to the remote machine, unless configured otherwise. So, if we have non-admin shell access to a machine we can still use above.

Special thanks to Lee Holmes for going through my ugly coding of powerpreter and suggesting changes.

Ok, that is enough in this post about Powerpreter. As powerpreter is going to be a part of Nishang, I would like to announce an updated version Nishang 0.3.0. Changes could be found in the CHANGELOG below.

- Added Powerpreter
- Added Execute-DNSTXT-Code
- Bug fix in Create-MultipleSessions.
- Changes to StringToBase64. It now supports Unicode encoding which makes it usable with -Encodedcommand
- More Changes to StringToBase64. Now a file can be converted.
- Added Copy-VSS
- Information_Gather shows output in better format now.
- Information_Gather renamed to Get-Information.
- Wait for command renamed to HTTP-Backdoor.
- Time_Execution renamed Execute-OnTime
- Invoke-PingSweep renamed to Port-Scan
- Invoke-Medusa renamed to Brute-Force

You can get Nishang and powerpreter here:

BTW Nishang has a logo of its own now :) Please let me know how you found it to be. It is "designed" in powerpoint and the background was removed using

Also, if you are looking for slides of my talk at Defcon, they are here:

Hope you enjoyed this post and it would be useful. As always, please let me know about bugs, feedback and feature requests.

Wednesday, May 8, 2013

Kautilya 0.4.3 - New exfiltration methods, faster payloads and call for contributors

While using Kautilya in penetration tests, one shortcoming of Kautilya always bug me. It is data exfiltration is with pastebin only. Specially with Keylogger module, the support only for pastebin reduces it to a PoC only thing. Not anymore, I give you Kautilya 0.4.3!

From this version onwards, Kautilya supports pastebin, gmail and tinypaste across all payloads which need to communicate with the internet. No more 10 posts limit which pastebin enforces. Gmail is the recommended choice for the keylogger payload because of the number of pastes or posts it does. If you have enabled two factor authentication for a gmail account, just generate a application specific password and use it with a payload, it works fine.

Tinypaste is also a good one as there are no limits on pasting.

Also, I have (finally) trimmed the variable names in powershell scripts which are generated by Kautilya. It means faster "typing" of payloads on a target. Enjoy!

If you want to contribute to Kautilya, contact me! You will be credited and there is guranteed fun.

Here is the CHANGELOG for Kautilya 0.4.3:

- Names of various payloads have been changed, mostly to remove pastebin from the name.
- Shortened variables names and poweshell cmdlets names in many payloads. Payloads are "typed" much faster by HID now.
- Fixed a bug on Get Target Credentials payload.
- Fixed a bug in DNS TXT Backdoor.
- Hashdump payload now uses TokenDuplication and does not schedules a task on the target, this means the payload is faster now.
- New communication options added to various payloads which exports data to pastebin/gmail/tinypaste.
- Posts to pastebin now use HTTPS.

You can get Kautilya from the google code repository.

As always, I look forward to comments, feedback and feature requests.

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.

Wednesday, February 13, 2013

Nishang 0.2.5 Released: Get WLAN keys in plain, Remove update and bug fixes.

This is a short & quick post about Nishang 0.2.5. Two new payloads which are borrowed from other sources (and went unnoticed for months lying in one of my VMs) have been added:

1. Get-WLAN-Keys dumps WLAN keys in clear text, handy!!. The code is borrowed from this code by Jan Egil Ring. An elevated shell is required to dump the keys.

2. Remove-Update could be used to remove all updates, all security updates or a particular update from a target machine. The script calls wusa.exe to do so. This is based on this post by Trevor Sullivan. This payload could be useful to re-introduce a patched vulnerability (an easy way of backdooring a system). Administrator access is required to remove most updates.

Also, some stupid bugs with Credentials payload hav been fixed. This payload has been bugging me (or I am bugging it :P) from the first release of Nishang. I hope to bring some peace to it.

The Nishang repo has been updated. Please update your repos.

- Added Get-WLAN-Keys payload.
- Added Remove-Update payload.
- Fixed help in Credentials.ps1
- Minor changes in Donwload_Execute and Information_Gather.

Please send feedbacks and questions my way. Hope this would be useful.

Sunday, January 20, 2013

Introducing Prasadhak: Check running processes for known malwares using PowerShell

Once during a pen test, I got a complete acess to a box. It was a Windows 2008 server in a really bad shape. So bad that I wanted to check it for malwares as I was not sure about the integrity of the anti virus of the server. The client was also not sure as the server was just one of "those" servers who no one cared about as the services it offered were no longer required by business (I later gave a lecture to the client on why this is bad etc. etc.)

So I was in a fix, installing an AV was not an option and as always there was not enough time to do a manual sanity check of the system for malwares. I though of using Virustotal for this. Virustotal provides a nice API which could be used for automating the process of analysis of files. But there was a catch, I could not upload files from the system to the interent, confidentiality issues! So I decided to use search function for running processes. I would search for executables of running processes for malwares using Virustotal API, looks good.

So behold world, I give you, Prasadhak. A powershll script which will check running processes (actually their executables) for malware by searching md5 their md5 hashes on virustotal database. For those curious, Prasadhak means purifier in Sanskrit.

PowerShell being quite powerful there was not much of a problem getting the current processes and their corresponding executable. Please note that some of the process do not report their path.
A little problem was with the limitations on request by the API. Using the normal public API, one could make only 4 requests in a minute. So I have to adjust the code this way.

Another problem was that Virustotal API responded with JSON objects and I was unable to parse the responses properly. I tried various methods including this. The code worked fine for a single request but failed for a batch request. I got lazy and wrote the script for PowerShell v3 instead which comes with a ready made ConverFrom-Json cmdlet. This is my first script which would require powershell v3.

Prasadhak reports one of the following for each process whose executable path was detected based on the response from Virustotal:
  1. Not found in VT database for hashes which are not present in Virustotal Database.
  2. Something malicious is found with the link to complete analysis.
  3. This is reported clean for hashes which are reported clean.
  4. File queued for analysis.
You need to register a free account on virustotal to get the apikey which is required for using the API.

A sample run of Prasadhak on my machine with Administrator privilege

So two malicious processes were found, the first one is a known one and I ran it just to test Prasadhak. Second one is new for me, lets have a look at it.

So hfs server is detected as malware by many AVs. Interestingly, a modified meterpreter payload was not found in database as its hash was different from a "normal" meterpreter. A huge limitation of hash based detection (Do I sound like an AV vendor?)

Two major limitations I know of Prasadhak are:

1. Results of each process are not labelled with the process name. You will see that I have left commented portions of code for labelling the results, this was a quick attempt before this post. Please let me know if you modify the script to improve that.

2. The approach of Prasadhak is very limited. As we saw above, a meterpreter binary was not detected just because slight modifications were made to it. Many malwares are better in stealth.

Please note that only section of script which requires PowerShellv3 is the function "check". If you need to use this script using PowerShell v2, try using this code at codeplex.

The code could be found below

Prasadhak is available in Nishang's repository, please update your repos.

Hope this would be useful. There wold be a day when I will start writing non-ugly code.
Bugs, feedback and comments are welcome. 

Update - Minor changes  have been made to Prasadhak, the code above has been modified a bit.

P.S. - I planned to release Prasadhak later after some improvements but a similar blog post forced me to post this, now. Research collision anyone? Thanks to my friends who quickly consoled me when I was shocked after that post.. hee hee :)

Monday, January 14, 2013

(Quick Post) Check if your payload is running inside a VM using PowerShell

I was trying to improve some existing payloads of Nishang and Kautilya. One idea was to enumerate the environment in which the payloads would be running. I decided to start with detection of Virtual Environment. I found this post module in msf by Carlos Perez which is easy to understand. I quickly ported the script to powershell. This post is about that script. Though I still need to figure out a way to integrate this in other payloads without increasing the complexity, I am sharing the current script anyway :)

The script checks for a number of parameters like, registry keys and running services for Hyper-V, VMWare, Virtual PC, Virtual Box, Xen and QEMU.

A code snippet showing the logic for detection of Hyper-V.

This is how it looks like when ran inside a Windows 7 on VMWare.

I checked it only on VMWare. If somebody tests this for all the environments that would be great ;)

UPDATE: Thomas hac confirmed that the script detected a Hyper-V machine.

The script has been added to Nishang repo, please update your repo to get the script.

Hope this would be useful. Comments and suggestions are welcome.