, , , , , , , , , ,

One of the tools I’ve installed, since hearing about Kyle Wilhoit’s recent work with decoy industrial systems, is the Browser Exploit Framework, otherwise known as BeEF. It’s an interesting security assessment tool, but it’s more about auditing clients instead of servers. I’d like to describe it as a Metasploit that works in reverse, as it runs a web server through which clients can be exploited.

Installation and Setup
BeEF is one of those programs that must be installed the old school way – in my case it took 4-5 hours of Dependency Hell, hacking and compiling to get it running with the correct version of the Ruby interpreter (it’s included wth Kali Linux though). Depending on how it goes, the process itself can be a learning curve.
I strongly recommend doing this on a fairly recent Linux installation, checking that curl and SQLite3 are installed first, that any dead repos are unselected/removed and that no software managers are running while BeEF installation scripts are launched.

Basic Usage
All we need is a router, an attacker machine running the framework, and a client machine with a browser pointing at the site being hosted. It’s possible to have both the client and Control Panel running in the same browser, but that’s not really a decent substitute for having it run over a network.
After the framework is installed, we run the server and connect to its interface in a web browser. This is basically where we administrate the honeypot, monitor all the browsers that connected to it and launch whatever exploits are available.


When everything’s set up, we use another machine on the network to visit the framework’s demo web pages, play around a bit and view the results.
The image below shows the framework’s Control Panel. Our client, with the IP address, connected with a Firefox browser running on a Linux system (or so the icons tell us). In the main window we can see the user had typed stuff into a text box, that the client’s mouse cursor moved to co-ordinates x337-y216, and that either the browser was minimised or another tab was selected.

Viewing client browser actions in the Control Panel

Viewing client browser actions in the Control Panel

Of course, it also means that a fake login page would capture usernames, email addresses, passwords and other information. Even worse, if an attacker could make it work as a proxy, or replace the genuine login page for a web service. This would make a pretty good demonstration to include in a security awareness/training event – easy to set up if and when Ruby works.

Like the Armitage GUI for Metasploit, the Control Panel lists a number of exploitation modules, and as with Metasploit we should be careful not to launch stuff that might irreversibly break a client’s system, or send payloads without the clients’ knowledge or consent. Ideally an effort would be made to determine precisely what an exploit does beforehand.

Exploits and other modules

Exploits and other modules

The following is where things might get interesting: Controlling the framework and attached clients through a command shell, which should allow a greater degree of flexibility.

BeEF command shell

BeEF command shell

And I suspect all this is a fraction of what’s possible using BeEF. What I found interesting throughout this little experiment is there’s no obvious indication on the other end that the browser’s hooked.

Real-World Deployment within Enterprise Networks
Web servers are everywhere – public web sites, intranet sites, router admin interfaces, wireless gateway login screens, even industrial control system interfaces – any of these could be impersonated by someone with half-decent web design skills. So, the framework has numerous potential uses both inside and outside a network.
There are also multiple ways of causing clients to connect their browsers to a deployed BeEF server within an enterprise network. One method is to duplicate an intranet’s home page, host it on an identical file path and use ARP poisoning to swipe the original server’s logical address, or manipulate local DNS resolution so a domain points to the attack server. From there it should be possible to hook the browser and forward the connection.
Another method is to set up a decoy wireless gateway with a legitimate-looking SSID that redirects people to a ‘login page’ hosted by the framework – perhaps a quicker way of acquiring wireless gateway keys.

What else can be done with this? Where Metasploit can be used against servers, BeEF covers something that might be overlooked in a typical security assessment – client device security. Even if those clients aren’t storing anything of interest, what are its users sending from them? Using the framework, it might be possible to gauge the impact of an attack that compromised the clients, and it provides a first-hand view of what information an attacker could gain through manipulating ARP or local DNS resolution.
Since browsers are persistently attached, once they’ve connected, a network administrator might conceivably use BeEF as a cheap logging/monitoring system.

Honeypots and Spider Webs?
Outside a network, the framework could be used as a publicly-accessible decoy or honeypot web server (or even a bastion host), as Kyle Wilhoit did.

One idea I’ve played with, which could make an interesting thesis if it could be done legally, is a network of decoys involving multiple servers running the framework. Done a certain way, it could be a spider’s web with plenty of redundancy, and whatever threats we’re tracking would be moving around a false network, from one decoy to another without being aware of it – like the NSA’s recent JS project, but almost invisible and 100 times worse.
In addition to the logistical problems of getting domains and bulletproof hosting that’s untraceable to the researcher, there are several non-technical problems to address during the planning stage. For this to work, it must be a totally convincing honeypot. A fake SCADA system would be explored by attackers with engineering backgrounds. A fake malicious hacking forum could attract the attention of highly skilled hackers and the authorities.

The other problem is knowing what to do exactly with the intelligence. At first it might seem like a daft question, but acting on it could easily betray the existence of the decoy. If we have organised criminals using it, but otherwise practicing reasonably good OPSEC, they’d know information could only leak from someone operating undercover.

Following that are questions about the quality of the intelligence. If it fails to convince the right people, the information gathered won’t be of much use. Advanced threats might even feed misinformation, in which case the setup becomes worse than useless, potentially resulting in gaping security holes in the wrong places if we’re doing this for threat intelligence. This is just a summary of things to be aware of.