BeEF - The Browser Exploitation Framework Blog: BeEF In a Real World Pen Test

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.

Tasting The BeEF

Because of our previous efforts, we now have a good number of hooked browsers. It’s time to start running modules.

First, we run a series of low-profile recon modules that gather information in order to enhance our understanding of the victims’ systems and eventually build better exploits without triggering any alarms. The recon phase includes:

Get Browser Cookies: We identify the victim’s cookie for the hooked website in the Details tab. This is a valuable piece of information in case the hook is via an XSS, because now we hijack the victim’s session and do actions on behalf of him.
Identify Platform Versions: From the details pane, we can identify the browser and OS types and versions. This is a crucial step for customizing exploits is to know the specific versions of the platform the victim uses. We use this to know what other modules we can use, or to find/craft other stable exploits. A lot of modules are IE specific and others are Chrome specific.
Hook Default Browser: Different browsers have different features that we want to (ab)use. So, to maximize our attack vectors, we run the “Host/Hook Default” module to try to hook the default browsers and hope that it is not the one currently hooked. Hooking multiple browsers ensures we can execute all possible modules. However, for stealthy execution, it is better to make sure that the victim has adobe pdf FF plugin, Adobe IE BHO or something similar according to the browser type. This makes inline PDF viewing possible. Otherwise, the user may see the PDF file downloading (and can cancel it) or can see the full adobe PDF reader popping up (and can close it).
Detect Software (IE only): We run the “Host/Detect Software” module that uses an IE hack-trick to attempt to get a list of directories in the “Program files” and “program files (x86)” folders. Using this, we can identify legacy/unmaintained programs installed on the victim’s machine that can be exploited later.

Conducting this exercise on Contoso’s hooked browsers, we found:

Most hooked browsers are using the latest version of Windows 7, a few people are using Windows XP and one using linux (probably a system admin, bingo!).
Most hooked browsers are using IE 8, a few are using Google Chrome and a few are using Firefox.
Most hooked browsers are using Microsoft Office, a few using a version of Real Player (very tempting for exploitation!)

More Aggressive Devouring

Now we want to run more aggressive modules and start exfiltrating data. However, those modules are likely to trigger the user’s attention as some of them requires user interaction and others make browsers behave abnormally.

The clipboard can be a Gold mine! Especially when, on Class A targets, we can find snippets of code, portions of contracts, financial records, and a lot more hanging on the system’s clipboard. We run “host/clipboard theft” module to get the hooked browsers’ clipboard and save it for future analysis.
In order to fingerprint the hooked browser’s host information such as network interface details, JVM version, and OS detailed version, we run the “host/get system info” module. JVM version particularly is very useful because Java exploits are much easier to pull off if you know the specific version of the JVM.
For the browsers hooked via the XSS exploit (refer to part 2 for more details), we can use their cookies and attempt to hijack their session. By manually setting our session ID to be the same as the victim’s session ID, we gain access to their account on the portal without having to log in! Now, we can do all sorts of data exfiltration by saving all possible information we find accessible to that account.
One effective technique to persuade top management about the seriousness of your pen test report is to take some pictures of Class-A targets via their webcams and put them in the report. We do this by running the “browser/webcam” module which takes a series of pictures off the hooked browsers’ webcam via Adobe flash. Although a warning is shown to the user, by customizing the text displayed in the warning, it is possible to manipulate the user into accepting the prompt.
If the enterprise has wireless networks, use the “host/get wireless keys” module. This module retrieves the wireless profiles saved on the hooked machine’s network manager. Then, we can import them into our machines and go snoop around near the victim’s physical location.
We can also save known sensitive files. The “misc/local file theft” module allows us to save common sensitive files such as ssh private keys, command line history files, and boot files. It's noteworthy to mention that this will only work when a user has been hooked via an HTML file opened from a local file on Safari or mobile Safari. It also works on the Android browsers and iPad Dropbox previewer. So, it is particularly successful when the hooked browser is a mobile device, where there are a lot of saved passwords and sensitive information for the “user convenience”.
Finally, to expand our exploitation, the Metasploit integration makes perfect sense. BeEF allows almost full Metasploit integration where you can see Metasploit modules inside BeEF’s module branches under “metasploit/*”. Now we can run a multi-handler and execute any of the the juicy metasploit modules suitable to the hooked system. This is fun beyond imagination! And beyond the scope of this text.

Following the scheme described above, we were able to achieve very good grounds penetrating Contoso’s first line of perimeter defenses.

In one of the clipboard snippets, we found a portion of the firewall configuration mapping and allowing access from an external high-address port (TCP/32111) to an internal (10.20.1.5) TCP/5900 which is the default port for a VNC server.. This allowed us to manually fingerprint the VNC listener identifying a known vulnerability, exploiting it and gaining access to this server. However, we found out that it is a test server, so it is a dead end. Also, we were able to identify part of the internal network schema by inspecting the IP address ranges and the allowed ports.
We were able to extract Contoso’s wireless network encryption key.
The file theft module harvested some good corporate credentials from mobile devices pulled from the browser history.
We took a snapshot off a Class-A target’s webcam which will fit very nicely next to the firewall configuration in the final report.
A few browsers were using a vulnerable version of Java. So, firing up Metasploit, with some obfuscation kung-fu, we were able to get meterpreter sessions, but it turned out to be for low profile people. However, this is a very good point for further hopping inside the network.

At this point, we have penetrated the first level of Contoso’s defenses accessing the user information. In the next post, we will talk about how to crack the inside network; maximizing damage and hopping into deeper layers. Also, we will discuss how to conduct this exercise as safely as possible without deviating out of scope, or getting hacked yourself!