Friday, May 15, 2015

Week of PowerShell Shells - Day 5 - DNS, ICMP Shells and Wrap up

Welcome to the Day 5 of Week of PowerShell Shells. Today we will see interactive PowerShell shells using ICMP and DNS. Both ICMP and DNS are generally allowed through firewalls and are not as commonly used for shells as TCP or UDP. That makes both of them useful for attackers. Lets see how both could be used to serve our purpose. 

For using DNS, lets use Ron Bowes' awesome dnscat2 ( as a server. On the target Windows machine, we can use, once again, powercat ( We have used powercat earlier as well and it is of great use.

Use below command to start a dnscat2 server:
Use below command on the target to connect back:
And the result is:
Brilliant! We have an interactive PowerShell shell over legit DNS traffic. 

While dnscat2 supports an indirect connection as well, we used a direct connection to the dns server started by dnscat2.

If we ask Wireshark, it has no complaints:

While we are on this, Nishang has couple of interesting scripts which make use of DNS for command, script and msf shellcode execution. But there is no interactive shell. Please see this blog post for more details:

Now, lets move on to ICMP. For server/listener part, we will use icmpsh ( by Bernardo Damele (@inquisb). I have written a client/connect-back in PowerShell. I give you Invoke-PowerShellIcmp.

The current source code without help and credtis documentation:

Invoke-PowerShellIcmp is available in the Nishang repo here:

Use below command to disable ping replies (IPv4) and start a listener:
Use below command on the target:
Awesome! An interactive PowerShell session over ICMP.

Wireshark looks like this:

A video showing DNS shell and Invoke-PowerShellIcmp in action:

Those who wanted to know what to do after we get access to a target using these shells, please refer to my earlier blogposts.
For any of the Shells discussed in these five days, a PowerShell script could be executed with the help of the -EncodedCommand or -e parameter of powershell.exe.

For example, to execute Get-WLANKeys, encode it with the help of Invoke-Encode from Nishang. Make sure to remove the function declaration and help section.
which looks like this:

Then use the encodedscript in encodedcommand.txt with any of the shells:

or you can use the below one line to execute scripts from a local web server:

Please note that I encountered error in some of the shells if the encoded script is too long. I need more testing on this problem, so please provide feedback and report bugs.

The best way to pass parameters to modules or scripts when using -EncodedCommand is to include the parameter passing within the script.

To transfer files, the best way is to use following one line downloader. You can use a local web server like Apache/HFS.

Wrap up of the Week of PowerShell Shells

We have reached the end of Week of PowerShell shells. It was a wonderful yet tiresome experience. I learned a lot while writing these posts and hope you learned something as well. The goal was to keep the posts concise and usable without going into too much details. In fact, to achive this goal, no protocol level details were discussed. I would like to believe that through this series, I am able to spread awareness about the capabilities of PowerShell to more folks in the Infosec community.

Continuing with the shameless self promotion :), I would ask you to consider joining one of my upcoming two days training "PowerShell for Penetration Testers" at:
NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -

I hope you enjoyed reading the posts as much as I enjoyed writing them. Please leave comments, feedback and report bugs.

Thursday, May 14, 2015

Week of PowerShell Shells - Day 4 - WMI Shell

Welcome to the Day 4 of Week of PowerShell Shells. The Shell which we are going to discuss today is much different from the ones we have dicussed previously. Today, we will discuss a shell which utilizes WMI (Read more about WMI here). 

We can execute PowerShell commands and scripts using WMI using the Invoke-WmiMethod cmdlet. But the cmdlet does not return any output. It is the ReturnValue of 0 and a ProcessId which tells us that *may be* the command was executed successfully:
Notice that in the above example we need valid crednetials for the target machine.
I am no fan of WMI as it is not NAT and Firewall friendly, but having alternative techniques and methodologies are essential for a succesfull attacker. Inability to see the output kills the fun part of command/script execution. Fortunately, a very clever solution to this problem was discussed by Andrei Dumitrescu at HES 2014. The solution is to store the output in Base64 encoding into WMI namespaces. retrieve it and decode on the attacker's machine. The solution was implemented in PowerShell by Jesse Davis (@secabstraction) here:

Based entirely on Jesse's code, I give you Invoke-PowerShellWmi. A script which provides interactive PowerShell session using WMI.

Here is how to use it. The script will prompt for a password:

Note that like normal WMI operations, valid Administrative access/credentials for the target machine are required to use this script. This privilege could be achieved by dumping passwords in plaintext, stealing tokens etc.

Here is Invoke-PowerShellWmi in action:

Great! We can see output of PowerShell and native commands.

PowerShell scripts could be executed as well using the -EncodedCommand parameter of PowerShell:
Nice! We executed encoded Invoke-PowerShellTcpOneLine using WMI.

The default shell available is PowerShell but cmd can be used as well using the -ShellType parameter.

Looking at WireShark, this obviosuly is a genuine WMI traffic. 

The pcap is available here:

The Namespaces created in the process are marked with "SYSINFOS" unless specified otherwise by the user.  Make sure to use "exit" command when closing the shell as it initiates a cleanup of the target system. 
A video demonstration of Invoke-PowerShellWmi:

Remember, much more could be achieved with PowerShell once you have access to a machine. You may like to see my other blog posts for that. 

Hope you enjoyed it! Please leave feedback and comments.

Once again, to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:
NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -

Wednesday, May 13, 2015

Week of PowerShell shells - Day 3 - HTTPS Shells

Welcome to the day 3 of week of PowerShell shells. Lets focus on HTTP/HTTPS today. The traffic over HTTPS is mostly considered safe and often overlooked by the blue teams and system administrators. This makes HTTPS a desirable channel for our shells. I have stolen Casey Smith's (@subTee) Poshrat ( and tweaked it a bit. I give you Invoke-PoshRatHttps. 

Invoke-PoshRatHttps, as the name suggests, establishes an encrypted medium of communication between the target and the attacker. This was lacking in the previous shells we saw on Day 1 and Day 2. It could be found in the Nishang repository here:

Invoke-PoshRatHttps requires Administrative access on the attacker's machine to listen on ports and install SSL certificates. Lets set up a listener on a machine:
Note that the listener needs two ports. One for initial connect and another for encrypted communication. 
On a target, we just need to execute the below command (note the HTTP):
A user could be tricked to open a HTA file as well. Though the kind of warnings shown by browsers reduce the chances of a successful attack. A target needs to open the below URL:

Lets see it in action:
Awesome! An interactive and encrypted reverse PowerShell!

In Wireshark we can see that only the initial connect request is sent over HTTP, everything else is over HTTPS. The initial unencrypted connect is used to setup the HTTPS channel :
The pcap is available at:

Note that Invoke-PoshRatHttps installs Root certificates by the name of "Windows Update Agent" and the IPAddress specified on your machine and opens incoming traffic on the specified ports. The firewall rules are named "Windows Update HTTPS" and "Windows Update HTTP".

There is a HTTP version as well, Invoke-PoshRatHttp.
What makes Invoke-PoshRatHttps awesome is that the client part is very small and could be used with wide variety of techniques where there are size limitations. 

To clean up the machine after using Invoke-PoshRatHttps, we can use Remove-PoshRat. It needs to be run from an elevated PowerShell.

Nishang has another HTTPS shell Invoke-PsGcat which uses Gmail for command and script execution. I have blogged about it earlier:

A video showing usage of Invoke-PoshRatHttps:

Please note that I am deliberately not going into what can be done after we get shell access to a target. For that please see my previous blog posts.

Hope this proves to be useful. Please leave feedback and comments.

If you enjoyed the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -

Tuesday, May 12, 2015

Week of PowerShell Shells - Day 2 - UDP Shells

Welcome to the day 2 of Week of PowerShell Shells. Today we will see how UDP could be used for interactive PowerShell shells. I love UDP because many security and infrastructure teams love to ignore it. I have seen client environments where UDP ports like 53, 161 and even 389 are not properly filtered and monitored. Lets use this condition for our benefit and get some shells. 

Let me introduce to you, Invoke-PowerShellUdp. It is similar to Invoke-PowerShellTcp in syntax. Here is the current source without the credits and help documentation:
It is available in the Shells directory of Nishang repository

A screenshot of Invoke-PowerShellUdp reverse shell in action:

An interactive PowerShell reverse shell over UDP using IPv6:
A bind connection:

Pcaps for all of the above could be found here on my Google drive:

Invoke-PowerShellUdp has a one line version as well with many lines of code stripped down. It is a reverse only version and IPAddress and Port number needs to be hardcoded. Below is the current source of Invoke-PowerShellUdpOneLine

Powercat could also be used for getting interactive PowerShell over UDP.

That is all for today! Hope you enjoyed it.

If you enjoyed the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:
NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -

Monday, May 11, 2015

Week of PowerShell Shells - Announcement and Day 1

PowerShell as an essential tool for Penetration Testers and Red Teamers needs no introduction. Its tight integration with Windows operating system allows us to do a variety of interesting stuff which other PowerShell hackers and I have blogged and coded over time. Still, during my talks and trainings I see both attackers and defenders unaware of what PowerShell is capable of and how it can make their life easy. I have also met infosec folks who were dismissive of PowerShell just because it comes from Microsoft. To generate awareness and spread the goodness of PowerShell in the infosec community, I am glad to announce a Week of PowerShell shells.

On each day of the current week, from 11th May to 15th May 2015, I will publish/discuss a blog post and accompanying open source tools for getting interactive PowerShell on a target using different methods, techniques and protocols.

Day 1 - Interactive PowerShell shells over TCP
Day 2 - Interactive PowerShell shells over UDP (Click Here)
Day 3 - Interactive PowerShell shells over HTTP/HTTPS (Click Here)
Day 4 - Interactive PowerShell shells with WMI (Click Here)
Day 5 - Interactive PowerShell shells over ICMP and DNS (Click Here)

Without further ado, lets get started with Day 1.

Day 1 - Interactive PowerShell shells over TCP

Lets start with a reverse shell. It is based on this awesome post at Nettitude by Ben Turner (@benpturner) and Dave Hardy (@davehardy20). Using the scripts with metasploit is well documented in that article. After removing some code and changing few things, I give you Invoke-PowerShellTcp. This script is capable of providing a reverse as well as a bind interactive PowerShell. The current source code (without the help documentation ) looks like this:

It could be found in the Shells directory of Nishang

A screenshot of it in action. A listener is running on Kali linux:

A listener could be set up on a Windows machine as well. Lets use powercat ( as a listener:

Using Invoke-PowerShellTcp as a bind shell:

The ability to have an interactive PowerShell helps us in many situations. One good example would be my previous blog post about Dumping users passwords in plaintext for Windows 8.1 and Server 2012. In that case, it was not possible to achieve the results without an interactive PowerShell.

Note that we can use powercat as well. 

Choose whatever you like depending on the scenario at hand.

If you see the source code of Invoke-PowerShellTcp, it is really small and therefore can be used with various attack techniques like Weaponized MS Office documents, Human Interface Devices (see Kautilya), Drive by downloads, DNS TXT records etc. where a shorter script is desirable. In fact, it could further be shortened if we remove some error handling and fancy user input. I give you Invoke-PowerShellTcpOneLine.

Further shortened version which does not show output and could fit in two tweets:

A quick video shows how Invoke-PowerShellTcp could be used with a weaponized MS Word document:

If you enjoyed the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -

Tuesday, May 5, 2015

Dumping user passwords in plaintext on Windows 8.1 and Server 2012

Couple of days back, I read this very interesting post on the TrustedSec's blog. According to the post,  it is possible to dump passwords in plain from Windows 8.1 with a simple Registry hack. All we need to do is:

1. Create the registry key property "UseLogonCredential" at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest and set its value to 1.
2. Lock the target computer.
3. Run Mimikatz when a user logs in.

Simple, isn't it? We can use PowerShell to easily achieve the above steps. 

Registry key property can be created with:
The target computer can be locked with the code found here (Thanks @subTee) :
The computer unlock event can be captured with (Thanks @mattifestation) :

Above could be assembled in a PowerShell script for easy use. Let me give you Invoke-MimikatzWdigestDowngrade.ps1. The name is too long for a single script but I like it :) It uses Invoke-Mimikatz from PowerSploit (thanks to @JoesphBialek and @gentilkiwi for that). Invoke-MimikatzWdigestDowngrade is available here in the github repo of Nishang.

Here is the script in action on a Windows Server 2012:

Without the downgrade, Invoke-Mimikatz on a Server 2012 machine looks like this:

And with Invoke-MimikatzWdigestDowngrade (AFTER the user unlocks the machine):
Bingo! We successfully dumped user password in plain.

Notice that the event trigger started a job and we may need to use Get-Job | Recieve-Job cmdlets to see the output.

Below video shows the script in action:

For access to the remote machine, I used PowerShell shells like Powercat and couple of custom PowerShell shells which I will publish soon. 
Unfortunately, in my tests, the script doesn't work from PowerShell remoting and meterpreter. As far as I know, inability to run scripts in user context is the reason for failure in PowerShell remoting. But I am unaware of why it is not working with meterpreter.

This is one of the various examples where PowerShell enahnces a penetration test by combining various simple techniques together. Knowing PowerShell is crucial for better security testing from both red team's and blue team's perspective.  

Things to note/Meh! :

If you liked the post and want to learn more and/or want to support my research and work, join me for a two days training "PowerShell for Penetration Testers" at:

NolaCon, New Orleans (June 10-11th) -
Shakacon, Honolulu (July 6-7th) -