BeEF - the browser exploitation framework. I think (thought) I had a basic working understanding of how it works. Recently, though, I was watching, this DEFCON talk, where a hacker used a man-in-the-middle attack to inject a BeEF hook into a lot of browsers. Fine. However, he claimed that his hook persisted even after the victim disconnected from his proxy or navigated to another page because "the JavaScript was running in the cache." Only clearing the cache could free the hooked browser. How is this possible?

My understanding was that BeEF exploits (and the hook) were JS based and worked like an XSS attack, rather than exploiting a vulnerability in the browser executable itself. I know it is possible to store some information in localstorage or cookies, but how is it possible to execute javascript across tabs/sessions? Is my understanding of BeEF wrong? or JavaScript? I have looked for the actual payload.js file to see what its really doing but I cant find it anywhere. Thanks four your help


BeEF is best run from the MITMf tool -- both are available in most versions (especially recent) of Kali Linux. MITMf has an extension to BeEF not found in other places called BeEFAutorun. Both BeEFAutorun and BeEF Autorun Rule Engine (ARE) work similarly to XSSF and Trustwave SpiderLabs' beef_injection_framework, but the built-in ARE is superior and works out-of-the box. MITMf is a competitor to Ettercap (older) and bettercap (newer and includes a beefbox proxy module). Videos from TheBeefProject here.

That said, BeEF and XSSF -- no matter how delivered or automated -- both have their benefits and drawbacks. Neither has a built-in cache-persistent capability. This cache technique might only apply to browsers that support HTML5 offline storage, although most today do. The original technique was discovered by Lavakumar Kuppan and discussed on his website, andlabs (tool site down, but blog post is still up), as well as in the book HTML5 Security in the section on Application Cache. An html manifest tag can specify a cache.manifest file where storage occurs. A man-in-the-middle condition, control of a proxy server, browser hook (e.g., BeEF) etc, is required to initiate the attack. Code to perform the attack has been slightly modernized from the original code and available on GitHub as squid-imposter.

how is it possible to execute javascript across tabs/sessions?

This functionality is already available in the BeEF Modules that provide persistence. In particular, a BeEF attacker should consider using both the man_in_the_browser and the iframe_above modules unless they want a temporary injection. If all you need is a temporary injection (such as via your own hosted, malicious site, via an XSS, or other quick mechanism), then I would use the invisible_iframe module to provide a link to a metasploit-framework browser_autopwn listener. This technique is provided in the book, Gray Hat Hacking The Ethical Hacker's Handbook, 4th Edition. I think that this book has the most thorough coverage on BeEF and MetaSploit integration, but Mastering Kali Linux for Advanced Penetration Testing, Intermediate Security Testing by Daniel Dieterle, and The Browser Hacker's Handbook also make mention to many of these techniques.

It's interesting to compare the code from BeEF to XSSF. For example, keeping persistence across tabs in XSSF is performed by the ghostify and iframeize modules. One thing I enjoy with XSSF is the direct integration to the msfconsole command-line interface. BeEF does provide a Console, as well, though. A book that is in progress called Holistic InfoSec for Web Developers has an excellent section on configuring BeEF that includes metasploit-framework integration and setup of the BeEF Console. The author also has a YouTube channel where BeEF is extensively covered in demos 1 and 3. The XSSF console is incredibly flexible when time-pressured, implementing commands such as xssf_add_auto_attack detect_properties, which can be very useful in live scenarios and cyber exercises. The setup and teardown of XSSF Tunnels is excellent. BeEF has more modules and is easier to troubleshoot if you need extra console (BeEF has both web-based and command-line consoles, as well as this third-party contributed command-line version named beefconsole.rb) and debugging (e.g., beef cli options) capabilities. Particularly awesome is the MS Office detection module -- and a PowerShell-friendly Meterpreter-delivered social-engineering attack against Internet Explorer with hta_powershell. Finally, BeEF supports channels over WebRTC, making it one of the coolest tools on the block.

  • Other options may include attacks on proxy servers, such as this one -- news.softpedia.com/news/…
    – atdre
    May 17 '16 at 16:14
  • The book, Applied Network Security, covers BeEF with bettercap, MITMf, and SET (which have their own unique attack modules, some of which provide persistence), and the latest book, Mastering Kali Linux for Web Penetration Testing, covers BeEF in a few unique ways including a XSS zombie handler named MLITM in the WebSploit framework -- sourceforge.net/p/websploit/wiki/Home
    – atdre
    Jul 4 '17 at 19:03

I don't know if this is his method, but you can associate a window.open event to a click action and call window.focus which effectively gives you a pop-under window. That can be useful to keep your hook while they go about their business in a different window. Having a poisoned javascript file in the cache can allow you to hook the system when the corresponding webpages are loaded and the resource is run. Every time they visit site-x that uses the poisoned javascript file as a resource you have them. Look into metasploit to do this. It would indeed require the user to clear their cache.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.