What if, to avoid tracking our post-exploitation communication back to our BeEF server, we were able to hook a bunch of browsers within an organisation, and make them talk to each other, instead of talking to our BeEF server? Perhaps we could keep one as the data channel (controlling peer)?
The answer is WebRTC. I recently had an amazing opportunity to present this at Kiwicon 2014, and I was keen to get the code into BeEF. This blog post provides a brief summary of WebRTC and how it works. Since there's quite a bit of ground to cover, this will be the first of a two part series.
Retaining post-exploitation communication with hooked-browsers is one of the more interesting issues with BeEF.
BeEF has options to use the WebSocket protocol as well, which shifts the comms from a polling mechanism to a more bi-directional streaming method of sending and receiving data between the server and browsers. Other more esoteric options are also being investigated, such as the use of DNS channels.
One of the issues with these methods is, all of your communication channels go back to the BeEF server. There are methods available to try and hide or obfuscate the presence of your BeEF server. But, most of these will still lead back to your BeEF Server eventually. For example, you could:
- run multiple BeEF servers,
- run servers with multiple interfaces,
- run multiple proxies pointing to your BeEF server,
- use reduced polling periods,
- use TLS encapsulation (similar issue, comms are still being sent to the BeEF server).
If you're targeting a wide variety of targets, having things track back to your BeEF server may not matter so much. If you're targeting a single organisation, though, this information is very useful to incident responders. If they detect one browser talking to your BeEF server, they'll very quickly spot the others. (This is still a big IF. As of today, no AV engines are detecting the stock-standard, un-obfuscated hook.js .. which is not altogether that surprising).
|Virustotal report for stock hook.js|