Saturday, June 23, 2012

BeEF In a Real World Pen Test - Part 4: BeEFy Desserts

Welcome to the final installment of BeEF in a real world pentest.

You can read the previous installments in our blog.

But, to recap: in Part 1, we demonstrated how to build the con for our fictional target company Contoso. In Part 2, we set the hooks for our targets and got zombies on the line. In Part 3, we gathered information from our hooked targets and started exploiting that data.

In this episode, we will discuss how we can pivot and hop further inside the internal network and how we can foolproof our encounters to conduct a professional pen test within a given scope and time frame.

Based on our previous work, we have a slew of hooked browsers and we have penetrated the first level of defenses. At this point, we want to leverage our hooked browsers to pivot and hop inside the network.

Hopping Inside

We start off by identifying the computers in the same network of the hooked browsers. Since we already have the browser’s internal IP (refer to part 3), we run our scan against its class C network using the ping sweep modules. For firefox, we use the “network/Ping Sweep” module which does not require user interaction, and for other browsers we use the “network/Ping Sweep Java”.

Additionally, we fingerprint common appliances on the same network of the hooked browser using the “network/Internal Network Fingerprinting” module. This module will try to enumerate common appliances (printers, routers, media servers, ...etc) on some default IP address using pre-defined file signatures.

After we have identified some live IPs, we start scanning those IPs for open ports. Using the “network/Port Scanner” module, we can port scan internal IPs of a hooked browser (Firefox, and Chrome only). The module uses WebSockets and HTML5 techniques to conduct the scan.

To further investigate our internal targets, we can run a DNS enumeration scan on the internal network via the “Network/DNS Enumeration” module. The DNS enumeration module uses dictionary and timing attacks to identify common internal domain names such as (intranet, mail, print, ...etc). This can be very helpful in identifying internal resources.

Now that we have a good understanding of the internal network, the last step is to scan internal applications for further vulnerabilities. Using the “Tunneling Proxy” extension, we can chain our browser, a web vulnerability scanner such as Burp Suite and the hooked browser in a proxy chain. This video by Michele “antisnatchor” Orru best describes how this can be achieved.

We can even craft and send raw requests proxied via a hooked browser using the Rider extension tab. This allows us to conduct convoluted attacks on the internal web servers.

It is worth mentioning,  we can do more pivoting and hopping by leveraging the meterpreter shells we have on some non-important hosts and the compromised test server (see part 3) but that is beyond the scope of this text.


Now that we have fully penetrated our target, we want to point out some of the proofing tips that will help us keep the pen test clean and professional.

The first thing we need to take care of is preventing backfire from disgruntled employees and/or target sys admins. The last thing we want is to get hacked by our customers! To secure our own perimeter, we take a few precautions:
  • Limit the admin UI interface of BeEF to the internal IPs only that we actually use to administer BeEF. This can be achieved from the main config.yaml file by setting the “permitted_ui_subnet” to match the administration internal subnet.
  • Setup firewall rules on the BeEF server to block all external access except for the web port, metasploit payload delivery port and browser autopwn port (if applicable).

For larger numbers of hooked browsers, the performance of the default underlying DB driver (i.e. SQLite) drops dramatically leading sometimes to unexpected behaviours. If you are planning to have a large number of hooked browsers, use BeEF in MySQL DB mode. This can be configured in the main config.yaml file under “database:driver:” section. Also, changing the update timeout value to 1-2 seconds in updates.js (based on the connection speed) might give a performance boost.

It goes without saying that we need to have our written authorization of the penetration test. What is sometimes missing are small details that might cause problems. The following are examples of sensitive “grey” interactions that should be explicitly declared in the scope and agreed upon a priori:
  • Sending buzzing phishing emails (especially to or about C-Level execs).
  • Capturing employees personal information and using it to gain access to their corporate machines.
  • Extracting wireless keys from corporate machines given that there might be some personal wireless keys on laptops or BYOD-style devices.

In order to keep the scope of the pen test from creeping to personal grounds, we can take some more precautions:
  • Limit the hooking subnets to only the IP ranges of the target company to prevent accidental or out of scope hooking of browsers. However, this will severely limit smartphones hooking as they will most likely get hooked via their 3G/4G interface.
  • Limit the hooking machines to only ones with a predefined set of referrer URLs that we use. This is a weak limitation but might be handy in case of mobile devices.
  • Do not save exported wireless keys that do not belong to the corporate wireless.
  • Do not save or use private photos and/or videos exported from the users’ profiles or harvested in the recon phase, as this is not corporate related and probably off limits.

Now that we have successfully penetrated the perimeter, hopped inside the internals of the network, and secured ourselves from backfire and scope creep, we are ready to write the report focusing on how our client will be able to fix the issues through which we were able go gain this access. 

Special thanks to Heather Pilkington for helping me out through this series, Michele Orru for his insightful comments, and all BeEF team for their great support!

BeEF, what a tasty piece of meat: HackPra talk

The 20th of June I gave a seminar at @HackPra in Bochum university, Germany.
First of all, thanks to Mario Heiderich and Marcus Niemietz for the invitation.

The talk went very well, covering several things:
  • communication channels: the default XHR-polling channel, and the new WebSocket channel;
  • XssRays integration: new enhancements (works with Webkit-based browsers that use XssAuditor, IE6 to 10);
  • abusing Chrome extensions: the Fake Flash Update module coded by Mike Haworth, and a few Chrome extension modules we have in BeEF (like the one you can use to inject the hook in all the open tabs). Imagine the impact of this (see screenshot below, where one of the tabs where the BeEF hook was injected is LinkedIn);

  • tunneling proxy: speed/performance enhancements while using WebSockets (4/5x times faster);
  • Evasion extension: for the first time, I was presenting the experimental Evasion extension. The aim of the extension is to obfuscate the hook and all code sent to the hooked browsers in order to evade passive regex-based filters. You can define your own obfuscation techniques, specifying in which order they need to be called. Right now we have 3 techniques: scramble (static string substitution, for example you don't see anymore beef in the hook), minify (awesome to save size) and base64. XOR is coming soon.
The talk went well, and as I promised there were a lot of live demos. Actually only one demo was not live. I've played again the Java mass pwner that uses RESTful API scripts, originally presented at AthCon 2012.

After the talk we all went to a GDATA building together with Karsten Tellmann, Felix @fluxfelix and other guys from @fluxfingers . Meeting Udo Strauch, the guy responsible for food and drinks, was a unique event :D His fine selection of rare beers was amazing: he particularly like some rare beers (honestly I didn't know them) from Teo Musso, an italian guy. The beers where really tasty and flavored, ans 8 to 10 percent :D 

We were partying hard until late in the night. The next day I met up with Reiners, Tilman Frosch, and partially followed (it was in encrypted German) Felix's awesome lecture about reversing.

To conclude, it was a great time. They really took good care of me. Definitely two non-conventional days for a university seminar. Really recommended to everyone (entrance was free as well of course).

You can enjoy the slides/recording here. This was the first time I could watch the recording of my talk the next day :D

Monday, June 11, 2012

BeEF In a Real World Pen Test - Part 3: Hot BeEF Steak

Welcome back to our series about using BeEF in a Real World Pentest. If you would like a recap of our work so far, you can read Part 1 and Part 2 in our blog.

In this post, we talk about how we exploit browsers to hop into the core of Contoso and exfiltrate data from its secure vaults.

Friday, June 8, 2012

BeEF up: Installing BeEF

We haven't forgotten about the BeEF in a Real World Pentest series. We're taking a break due to the new release, and getting you the stuff you need to use the tool we all know and love.
So, this week's post is about how to get up and running with BeEF.  

This one comes from our very own Ben Waugh.

Getting up and running with BeEF:

Monday, June 4, 2012


So, here we are with a fresh new BeEF release!

For those who want to know more about our development lifecycle, have a look here.

Obviously, with an Open Source project, it's a bit difficult to commit (well push, we're using Git at the end) the same amount of code/time every month, so it's normal to have months with more new features and addressed issues.

Last month's release ( was full of new code added to the repo. I will cover the main changes.