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 (https://github.com/iagox86/dnscat2) as a server. On the target Windows machine, we can use, once again, powercat (https://github.com/besimorhino/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: http://www.labofapenetrationtester.com/2015/01/fun-with-dns-txt-records-and-powershell.html

Now, lets move on to ICMP. For server/listener part, we will use icmpsh (https://github.com/inquisb/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: https://github.com/samratashok/nishang/tree/master/Shells

Use below command to disable ping replies (IPv4) and start a listener:
Use below command on the target:
Aaand:
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) - https://nolacon.com/powershell-for-penetration-testers/
Shakacon, Honolulu (July 6-7th) - http://shakacon.org/

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: https://github.com/secabstraction/WmiSploit.

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: https://drive.google.com/folderview?id=0B-Hsu8q12kG3fnBMWlhFQ2VqaDFLM3BheVpyOFdrUExKcGRLbjExcURfMHBaSkNCanFiQWM&usp=sharing

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) - https://nolacon.com/powershell-for-penetration-testers/
Shakacon, Honolulu (July 6-7th) - http://shakacon.org/

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 (https://github.com/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: https://github.com/samratashok/nishang/tree/master/Shells

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: https://drive.google.com/folderview?id=0B-Hsu8q12kG3fkVMaWlQejI4bmktVFlnZHd5Y3pjcHcxRVppQVM1Y1ZYamI5RlYxNExhY2s&usp=sharing


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: http://www.labofapenetrationtester.com/2015/04/pillage-the-village-powershell-version.html


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) - https://nolacon.com/powershell-for-penetration-testers/
Shakacon, Honolulu (July 6-7th) - http://shakacon.org/