Wednesday, August 22, 2012

Kautilya 0.3.0 Released - Breaking Mac OS X with USB HID and much more

Previous update of Kautilya was a couple of months back. I was travelling a lot and working on Nishang in spare time. Only a trickle of effort was given to Kautilya.  Anyway, I invested the past weekend working on Kautilya and the result is Kautilya 0.3.0. This is an important update and one of the largest since Kautilya was released. I was jumping in excitement while coding this, so much so, that I jumped some version numbers too :)

This version adds "support" for Mac OS X pwange (tested on Lion running on VMWare virtual machine) and many new payloads for Windows and Linux. Update your repositories and enjoy!!

Kautilya could be found here https://code.google.com/p/kautilya/

Below is the CHANGELOG for 0.3.0

- Added "Get Target Credentials" payload for Windows.
- Added "DNS TXT Code Execution" payload for Windows.
- Added "Tracking Target Connectivity" payload for Windows.
- Added "Speak" payload for Windows.
- Added "Wait for Command" payload for Windows.
- Added "DNS TXT Code Execution" for Linux.
- Added "Perl Reverse Shell (MSF)" for Linux.
- Added payloads for Mac OS X, tested on OS X Lion runnning on a VMWare.
- Added "Download and Execute" for  OS X.
- Added "DNS TXT Code Execution" for  OS X.
- Added "Perl Reverse Shell (MSF)" from OS X
- Added "Ruby Reverse Shell (MSF)" for OS X
- Fixed a minor bug in "code execution using powershell" payload.
- An exception is added to Windows firewall for bind shell in "Rogue AP" payload
- Fixed a major bug in "Connect to Hotspot and Execute code". The SSID key was being stored in encrypted format which doesn't work (Windows seem to encrypt WLAN keys using some machine specific key). Now the key is stored in plain and WLAN profile import works on other systems too.
- Fixed a bug in "Hashdump and upload to pastebin" payload. The powershell command was being called from the dumpaste.vbs script without bypassing executionpolicy. This means password hashes were being dumped but not pasted to pastebin..
- Removed TYPESPEED from every payload which was being used as good luck mark and was borrowed from SET :)
- Implemented Left + Enter as a method to say yes to UAC prompt, previously it was Alt + Y. Thanks to Paul who commented this on my blog.
- Increased the delay at the beginning to 25 seconds.
- Replaced the older "linux_codeexec.ino" (which had hardcoded shellcode) with proper file.
- Minor improvements in some lonux payload. Files written to disk are now written in /tmp.


 I would love feedback, bug reports and feature requests. 

Tuesday, August 14, 2012

(Introducing) Nishang : PowerShell for Penetration Testing

I have been using PowerShell in penetration tests for some time now. It is a really powerful shell and scripting language which gives you access to interesting things on a Windows machine. There are many PowerShell scripts involved in Kautilya. In fact, these PowerShell scripts are the reason behind power of Windows payloads in Kautilya.

At some of my talks many nice folks have asked me about the availability of PowerShell scripts for use in Penetration Tests. I started writing new scripts and collecting older ones. After working on this for a while I had some useful collection of payloads and scripts. I call it Nishang. It is available on google code here http://code.google.com/p/nishang/

Nishang means quiver (container for arrows) in Sanskrit. Apt for a collection of payloads and scripts.

It is a collection of scripts and post exploitation framework in PowerShell. The aim is to increase the usage of PowerShell in offensive security and penetration test. Nishang is a result of my own requirements during real life pen tests. Since it is a post exploitation thingy it is assumed that you have a shell access on the machine or using a HID like Teensy to drop the script on the victim.

Why PowerShell? It is easy to learn and powerful (think of Bash in Unix ported to Windows) and is present on every modern Windows macine. If you use PowerShell "properly", most of the times you would need practically nothing for post exploitation other than powershell.

Currently, Nishang includes only those payloads and scripts which do not require you to be an administrator on the machine. That is, no priv shell is required. The payloads are of varied complexity (for the user), while there are simpler ones like Download, Keylogger and Information Gatherer to complex ones like DNS_TXT_Pwnage and Wait_For_Command. All the payloads and scripts come with help. Use

PS> Get-Help [payloadname.ps1] -full

for help on executing a script or payload.

How to use it? The scripts can be used either if you have access to powershell prompt (when you have vnc or rdp etc) or if you have a windows command shell on the target. You must download the script on the target machine.

Below screenshots shows a quick example of the Information_Gather payload being downloaded and executed on a target machine.

One liner to download a script on the target


Execute the script. Note the parameters being passed ot the script.

The result of this payload (info uploaded to pastebin)

That was easy. All the scripts could be executed this way. Yay!

A word of caution, it may appear that your session has stuck after you execute the script. But you can eventually make your way out by repeatedly pressing enter. I am unaware of the reason behind this.

What's next? More scripts are in the development pipeline. Many of them require privileged shell on the target. Also, Niklas Goude has allowed me to add his powershell scripts to Nishang. They should be available with next release, thanks Niklas !

Also, the scripts are Tab ugly right now, that would be clean in next release.

I am looking forward for feedbacks, contributions and feature requests. I hope this would be useful.

Sunday, July 1, 2012

PowerShell Web Access: What could possibly go wrong?

I recently started playing with PowerShell Web Access. It is a nice feature of PowerShell 3.0 and could be really useful in enterprise environments. This post is result of my experiments with this feature from a Penetration Tester's point of view (may be as a backdoor). So let's get started.

For setting up of PowerShell Web Access, I used a virtual machine (a Windows Server 8 (2012?) Developer Preview) running on virtualbox. This Technet document explains it all. So AFAIU from the technet document, following cmdlets could be used to setup PSWA up and running.

  1. Install-WindowsFeature –Name WindowsPowerShellWebAccess
  2. Install-PswaWebApplication -UseTestCertificate
  3. Add-PswaAuthorizationRule UserName -ComputerName -ConfigurationName
PSWA also requires PS remoting to be enabled. "Enable-PSRemoting -force" could be used to enable that.


So let us consider a post exploitation scenario where we can run commands on a Windows Server 8 (2012?). Following commands could be used to setup PWSA assuming that it is not already installed.



Above command will install a PWSA web app with name "pentest" which will use a self signed certificate. Obviously, you would like to change the name during a Pen Test.


Above command adds an Authorization rule which governs the access control for PWSA.
The cmdlet takes three arguments:
  1. Username is username of the user which would be used for authenticating.
  2. Computername is name of the computer to which the user would have access.
  3. ConfigurationName is name of the session configuration.

During a Pen Test you may like access to all of the computers accessible to a user. There is a nice "tip" (with warning) in the technet document which says that you can use wildcards for all the options in Add-PswaAuthorizationRule cmdlet. That is what we have used in above example.

A * in all of the three fields indicate, "allow all authorized network users access to all computers on the network to which they typically have access, with access to all session configurations to which they typically have access."

What does this mean? This means that if you are able to have access to credentials of a user which is present on large number of machines in a network, you can use PWSA as a secure, encrypted and native method of accessing the systems (with its own set of restrictions). Of course, there are other ways too of accessing systems if you have credentials of such a user.

Be mindful while using wildcard on a client's machine as this will open up the network for everyone. A better option could be


Enable PSRemoting


So now we have a PowerShell web session open in front of us.



Now what? Let us try to do some nasty things with it. I am using credentials of an Administrative user.

Elevate to meterpreter
Well not "elevate" exactly :P. Many pentesters can't go without having a meterpreter on target. Using a simple PowerShell script we can download and execute a meterpreter binary.


And the result is


Have a look at my previous blog post for doing this more effectively and stealthily.

Persistent Jobs
In the above example, if you do not use any persistance available with meterpreter, your meterpreter session will close as soon as you logout of web session. To keep it running, you can schedule it as job. Remember, you can schedule only a PowerShell script as job. A quick dirty trick could be



This can be used for many post exploitation tasks which require scripts to be running on target machine.

Elevation to SYSTEM
Now, let us try for SYSTEM level access to the machine. Why? For fun and password hashes :)

Let us use the technique implemented in Kautilya. We will schedule a batch file as a task which will run with SYSTEM privilege. The batch file will call the powerdump script (available in msf) and the hashes will be dumped. Sounds easy? Yes it is.

We will download the powerdump script and batch file using script used in the above example. The batch file should look like this.


Now let's scehdule it as a task which will run as SYSTEM

I am using harcoded paths as the batch will be running with SYSTEM priv and its TEMP directory is different (C:\Windows\Temp).

Let us run the task


Now if we check the contents of "C:\Users\<currentuser>\AppData\Local\Temp\dump.txt" we will find hashes :D


If you already have access to password of an Administrative user, why would you need to dump hashes? To gain access to more systems or similar stuff.

Many more things could be done using PSWA specially post exploitation activities. Look at it as one of the best web shell ever !!

Lastly, I have not seen any enterpise deployment of PSWA (as the OS itself is in review phase) so few things in this post could be wrong or based out of pure assumption. I hope the administrators will take care while deploying and users will be more careful while using this.

I will keep working on this and will write more posts about anything interesting. Also, if PSWA is ported to a Desktop OS ever, an implementation of this in Kautilya will be definitely done with a blog post detailing that.

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



Sunday, May 27, 2012

Fun with Sticky Keys, Utilman and Powershell

Recently, carnal0wnage and mubix blogged about sticky keys. I have implemented this in Kautilya and found this usefult during many internal penetration tests.

I thought of playing more with this and using this is as something more useful and powerful. I started using powershell as debugger for sethc.exe and no points for guessing this is what I get when I pressed shift 5 times (or Left Alt + Left Shift + PrntScr for that matter).


So powershell is getting executed but there is no interactive prompt (I have not looked into the reason for this). I tried executing a simple script (which calls calc.exe) by setting it as a debuuger to sethc.exe. I have to call powershell from cmd as without cmd powershell was throwing some errors.


and the result was


Wow the legendary calc is here!! Keep in mind that if you use any environment variable for path of your powershell script, it would not be same for different user profile. For example, in the above if you use %temp%\calc.ps1 as path of the script, on an unlocked system that would be Temp directory of currently logged in user "C:\Users\\AppData\Local\Temp\calc.ps1". But when the machine is locked %temp% would be "C:\Windows\Temp", because of SYSTEM profile will access it. Keep that in mind while testing.

So, I was able to call the powershell script. This means if you are able to drop a script on victim and set powershell with proper arguments as a debugger to sethc.exe (or utilman.exe), you can execute the script with SYSTEM privilege.

What if I can somehow download and execute a meterpreter executable on the victim? Yes it is quite easy using this powershell one liner.



This looks good, a meterpreter executable downloaded and executed on a locked machine! But pulling a meterpreter executable on a machine is not a good idea for obvious reasons. Why not pulling a powershell script which can execute code in memory? Yes I am talking about Matt's work from his blog Exploit Monday.


So what we have now? A powershell command which executes meterpreter from memory, set as debugger to sethc.exe which gets executed with SYSTEM level privilege. Wow!!

But is this over yet? Let's play more :) How to maintain access to the machine? Using persistence and other methods available with meterpreter is one option. I would like to use a little more powershell here.

Let's do this. Our powershell one liner will download another script (let's say payload.ps1). Payload.ps1 will keep polling a tinypaste id in an interval of one hour (or less) and would download and execute whatever powershell script is present there. So let's set our sethc.exe or Utilman.exe Debugger to below.

using this


and now the result is


So what we have now is a payload which uses tinypaste as its C&C thingy and executes powershell scripts there with SYSTEM privilege :D

This is quite similar to my unpublished work called Maareech which is a sort of automated domain takeover tool in powershell.

payload.ps1 is the following powershell script. I know its ugly, I am still learning to write clean powershell scripts.


The payload, which polls tinypaste after given interval is very similar to "Time based execution" payload of Kautilya (just one line is different) but still for sake of usage, will be added as "Externally controlled payload" in some upcoming version of Kautilya.

Hope you enjoyed this. Feedback and suggestions are welcome.

Wednesday, May 23, 2012

Teensy USB HID for Penetration Testers - Part 4 - Kautilya

In third part of this series, we discussed how to write sketches using Arduino and Teensyduino. In this part, let's have a look at Kautilya. Kautilya is a toolkit written by me which helps in easing usage of Teensy in a penetration test. It is named after the famous Indian strategist, economist and political scientist Chankaya (Kautilya is one of his alias).  I will touch some less complex payload of Kautilya in this post.

Kautilya has a menu driven UI which could be used to generate sketches without a need of knowing how to program a Teensy device. The toolkit is written in Ruby and is free and open source. It currently contains payloads for Windows 7 and Linux (tested on Ubuntu 11). Kautilya is specifically designed to support Teensy out of the box, there is absolutely no modification required to the hardware.My motive behind writing Kautilya is to bring Teensy to masses. During my talks about Kautilya and Teensy I observed that often Pen Testers do not have enough time to program a device for their usage. Payloads in Kautilya could be used for pre exploitation and post exploitation tasks other than the “usual” popping of shells. 

The process of writing payloads for a Windows 7 machine could be summed up as:

  1. Understand the operating system in terms of USB buffer.
  2. Understand the commands supported and learn to write powershell or/and vbs.
  3. Recognize the built-in security measures (like UAC and powershell script execution policy) which may check privileged commands and then learn how to bypass them.
  4. Understand the time taken by operating system in completing various commands.
  5. Write the commands and scripts on Teensy.
  6. Understand more quirks of the command line when Teensy types out thing on victim.
  7. Try not to be too noisy on the victim.
  8. Test the payload and reach to final reasonable sketch.
  9. Compile the sketch to Teensy device.
  10. Attach it to the victim machine actively or using Social Engineering.
  11. Enjoy the pwnage!
(Next few lines may look like self promotion ;) )

Kautilya automates steps 1-8 for you. Using Kautilya you just need to:
  1. Select a payload and select your options. A sketch (a .ino or .pde file) would be generated for you.
  2. Compile the sketch to Teensy device.
  3. Attach it to the victim machine actively or using Social Engineering.
  4. Enjoy the pwnage!
A screenshot of Kautilya 0.2.2
Kautilya is tested on Ruby 1.9.2. It requires ruby gems "colored" and "highline".

Let's have a look at some of the payloads for Windows in Kautilya. All the payloads are tested on a default install of Windows 7.

Add a user and Enable RDP
This payload adds an admin user to the victim. It also, enables and starts Terminal Service on the victim. An exception to Windows firewall is also added. This payload requires a user to be logged in with admin privileges.


The generated payload just needs to be compiled to a Teensy++. The device could then be connected to the victim. The victim will see start menu open up, some cmd being type and then a very small cmd window which type dark blue on black will do evil stuff for us...muhahaha



Let's have a look at the source code for better understanding. Many payloads in Kautilya are similar in structure to this one.


Download and Execute
This payload downloads an executable stored in text format from pastebin (or any other service which allows hosting of text without formatting), converts it back to exe on the victim and executes it in background. The exe must be converted into hex format using script exetotext.ps1 in extras folder of Kautilya. This script is originally an idea of Matt of Exploit-Monday blog.



In the above example, a windows reverse meterpreter is pasted to pastebin and the url is provided in the option.This payload could be used even with a low privilege user.

Forceful Browsing
This payload opens up a hidden instance of Internet Explorer using a COM obbject of Internet Explorer and browses to the provided URL. An ideal use case could be hosting an exploit of msf  or a hook of BeEF  on the given URL. This payload is one of my favorites as it is able to get executed on a normal user (non administrative) privilege and is very silent.

Sethc and Utilman Backdoor
This payload utilizes a useful hack in the Windows OS family. On a locked system, if you press Shift key five times (or Left Ctrl + Left Shift + Prnt Scr) i.e. sticky keys, sethc.exe is executed with SYSTEM level privileges. In a similar way, if Window key +U is pressed, utilmanager (which is utilman.exe ) is launched with SYSTEM privs. This payload attaches a an executable present on the machine as a debugger to sethc.exe and utilman.exe. The attahced executables can then be executed with SYSTEM level privileges on a locked Windows machine.


We had a look at some less complex payloads of Kautilya. In the next post (or posts) I will explain some more complex and powerful payloads. At least one post will cover breaking Linux (Ubuntu11) too.

I am thinking of creating some small videos demonstrating few payloads but only if some people ask for it ;) Please let me know if the length of blog posts is ok. Feedback and comments are welcome.