credentials

Responder & User Account Credentials – First Come, First Served

Christopher Truncer Pen Test Techniques , , 3 Comments

Responder is an awesome tool that was created by Laurent Gaffie and can be extremely effective to use on pen tests.  I recently had the opportunity to use Responder, and it returned valid domain credentials within about 10 minutes.  I wanted to write this post as an opportunity to document what worked for myself.  With that said, Larry Spohn also wrote an excellent blog post on essentially the same attack which can be viewed here, so be sure to go and check that post out as well!

Responder can return results two different ways.  We can try to receive the NTLM Challenge hash(es) from workstations, or Responder can return credentials via basic authentication.  Ideally, the easiest for an attacker to work with will be basic auth based authentication due to the data being easily reversible since it is base64 encoded.

The specific vulnerability that is being attacked in this situation is that workstations will be configured to automatically detect proxy settings for the network they are operating on by default.  When a workstation attempts to find the proxy settings needed, it does so by requesting for “WPAD” initially over DHCP.   If the workstation doesn’t receive a response, it will then make multiple DNS requests.  If DNS also doesn’t return any results, the workstation will finally fall back to requesting over NetBIOS (source). If configured to do so, Responder will can act as a rogue wpad proxy.  Responder can then serve a PAC file (configured as you see fit) and attempt to proxy all connections through itself.

One trick Responder can do (if configured to do so) is to respond to http requests from workstations that are attempting to access local resources (such as http://intranetsite).  The nifty aspect to this trick is to the user, the pop-up will appear as a normal looking authentication box that is prompting the user to enter their credentials.  Once entered, the credentials are transferred to the attacker, base64 decoded, and displayed to the attacker.  So, that’s the background to this attack, how about lets check it out?

First, we’re going to need to configure how Responder is going to operate on the network.  We’re going to need to pass it a couple command line options:

  • -i <IP Address or network interface> – The IP address to listen on
  • –wpad – Tells Responder to start a “rogue” wpad proxy server
  • -b – Tells Responder to return Basic Authentication information vs. NTLM
  • -F – Tells Responder to force NTLM or Basic authentication from any machine attempting to access the wpad file
  • -f – Tells Responder to fingerprint the host

Starting Responder

As you can see, Responder is pretty simple to setup and get up and running.  Once the previous command has been run, you should see something similar to the following:

Responder Started

This is roughly what Responder is going to look like once it is up and running.  For now, you can sit and wait for information to start coming in.  A good time to utilize Responder is when you’re first getting started on an assessment.  Responder can be one of the first tools you get running, and you can just leave it be and check back in on the results later.

Once Responder has been running for a while, check out if there’s been any juicy information returned to us!  Below is a what your output will likely look similar to:

Responder Output

What’s awesome to see here, is the “HTTP-User & Password:” line!  We can see the username “testuser” and password “badpassword” were returned to us, so now we have the first set of user credentials!  From a user’s perspective, this is what the popup looked like on a Win 8.1 desktop:

WPAD Desktop

This is a fairly typical screen and users are *LIKELY* going to enter their account information without a second thought.

At any point, you can stop running Responder, and it will have logged all credential information into a file for viewing.  In my case, this is what I have on my attacker platform:

Responder Loot File

If the same user were to keep entering their username and password, there would be duplicate (or more) entries of the credentials within the loot file.

Responder is an extremely powerful tool that can be used to quickly grab credentials when plugged into a network segment that users are also operating on.  I highly recommend using it as it can be a great way to get an initial foothold into your target network.

Multiple Methods for Dropping Payloads with Credentials (or Hashes)

Christopher Truncer Featured Category, Pen Test Techniques , , 2 Comments

I like the cliche that “There’s more than one way to skin a cat” because it’s how I like to operate.  I like to have a lot of different options to choose from when attempting to reach a certain goal.  In my previous post, I showed how psexec_command can be used to trigger an executable once it’s been placed on a machine.  But this could lead to the question, how can we get our payload on to our target machines in the first place?

This post won’t go into how to get your initial compromise, I assume you’ve already done that, and you’ve been able to dump hashes (and now because of mimikatz’s awesomeness) and/or cleartext credentials.  So the next step in an assessment is not to blindly move around a network, but to identify targets of value.  Once you’ve done this, our goal is to get our payload onto that target.  I’m going to show you a couple of different ways that you can do this, and I’d love to hear from anyone else on other ways to place a binary on a machine.

But for now, our first method, a normal shell.

Note: All methods displayed below will only work if the account you are operating as has permissions to drop binaries/files in the locations you are doing so.  Otherwise, it won’t work.

Windows Shell:

We can use a normal shell within windows to help us move our payload around the network.  The nice thing about using the built in shell is that it doesn’t require the use of any other tools and is simply using built in OS capabilities.  In our picture below, I’m interacting with a shell prompt spawned on a machine through a meterpreter session.  We can see that we have a binary called “evilpayload.exe”.  So, our goal is to move this payload from one machine to another.  This is easily done by using the copy command from within the shell and pointing our payload (which in this case is already on our compromised machine) towards a share on our target machine, as demoed below:

windowsshellcopy

Metasploit Upload:

Metasploit has the capability to simply upload a file to a machine when provided with all the required options.  To use this, call the auxiliary/admin/smb/upload_file module.  As you’ll see in the picture below, I’ve provided a sample set of values that will allow the module to upload my payload to the target machine.  One item to note, the picture does not show the SMBUser, SMBPass, and the SMBDomain values being used with the module.  You will need to provide values for those (advanced) options in order for the module to authenticate and upload the payload to your target machine.

Once all options have been provided, executing the module will upload your binary to the target machine.

msfupload

Chris Gates wrote up an awesome attack path he encountered and used the upload_file module, and can be seen here.

Metasploit Psexec:

The metasploit psexec module can be used to upload a binary, either custom compiled or generated by the metasploit framework, onto the target machine.  The obvious difference with this module is that after uploading the binary to your target machine, the framework will create a system service which executes the payload, as compared to almost all other methods within this post that simply drop the binary on the system.

As you view the screenshot below, we can se that our binary was uploaded and triggered, so we received our callback.  One item to note is that even when providing a custom executable (as I did below), the executable is renamed when it is dropped on the target machine.  In the event that you need to trigger your executable again, you’ll need to note the executable’s name on disk (in this instance, it is LtcvppBc.exe).

psexec

SMBClient.py:

The impacket library has been something that I’ve been playing around with for a little bit lately.  It has a lot of cool capabilities and allows you to write scripts to interact with a variety of protocols, one of them being SMB.  SMBClient.py is a sample script written by the developers of the impacket library to show how the library can be used to interact with SMB.  Smbclient script will let us connect to a remote share with either cleartext credentials or a hashes and upload our binary.

To initiate the connection, we’ll use open and then the ip address of the machine we want to connect to.  Once we’ve connected to the machine, we’ll authenticate with the credentials we’ve already obtained via the login command (if we only had hashes, we would use the login_hash command).  Once authenticated, we type shares to see the list of shares to connect to, and then use the C$ share.  Now, it’s simply invoking the put command, along with the file we want to upload, and then it’s complete.  You can use the ls command to verify that your file has been placed on the remote machine.

A sample workflow on how this can be used is in the screenshot below.

smbclient

Psexec.py:

The impacket library developers also left us with another awesome script for uploading files to a machine, and it’s their implementation of psexec, using the impacket library, within a python script.  This script will let us spawn a command shell on the target machine, but also comes with extra capabilities, such as the ability to upload files.  We can use this script to upload our payload, and then execute it.  Great part about it, is that our session is going to be running as System!

To call psexec.py, we provide it with the credentials we want to authenticate to the machine with, the IP address of the victim machine, and the process we want to spawn.  After this, it’s simply using the put command to drop our payload on the machine, and then we can just call it within the command shell.

Larry Spohn also wrote a great post on combining Veil with psexec.py which you can read here.

A sample workflow of the psexec.py script can be seen below:

psexec

 

I hope this has helped to give everyone multiple different options to drop files on machines when you have user credentials.  There are other ways as well, and I’m interested in hearing other methods that have been useful for you.