5

BeEF is a great browser-based exploitation tool. But in some cases, people unknowingly get hooked due to beef when its hook.js is kept in an invisible iframe of an HTML source.

So how can we detect that our browser is actually hooked by BeEF communication server? If we have been hooked, then what are the measures to remove the hook?

Moreover, how could a person's browser, infected with BeEF, reverse and find its communication server (The place where the outgoing traffic is sent, like server:8080/ui/panel )?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Gerorge Timber
  • 464
  • 5
  • 17

2 Answers2

4

There are Yara rules submitted by SANS ISC to detect BeEF, and these could be repurposed by yarashop for the network layer as a early-warning detection system. The author shows how to utilize Volatility to read into a memory capture and look for BeEF-related signatures and communications -- https://isc.sans.edu/diary/When+Hunting+BeEF%2C+Yara+rules+%28Part+2%29/20505

In order to remove a Javascript hook, such as BeEF, you would typically only need to clear reopening pages/tabs, history, and cache before restarting all browser processes. However, in some persistent BeEF scenarios, you will also need to consider other offline browser stores, such as HTML5 offline cache.

You are right to want to look for BeEF, but you will also want to dig a little deeper. It is easy to obfuscate Javascript and can be difficult to modify your detectors to catch these obfuscations. Other Javascript-hooking packages, such as XSSF, Scanbox.js, or the metasploit-framework's auxiliary/gather/browser_info module can be utilized instead of BeEF.

Emerging Threats, recently acquired by Proofpoint, has a set of Snort rules -- https://rules.emergingthreats.net/open/snort-2.9.0/rules/ -- many of which cover BeEF, XSS, Scanbox, et al. You will especially want to check out the emerging-trojan.rules and emerging-web_client.rules files. There are specific entries for BeEF and Scanbox, as well as generic ones to catch active XSS from the client (i.e., browser) perspective.

Here are two articles that discuss how threat communitiies are converging on these Javascript-hooking technologies -- https://www.helpnetsecurity.com/2016/04/28/attackers-use-open-source/ -- http://www.securityweek.com/attackers-increasingly-abuse-open-source-security-tools

atdre
  • 18,885
  • 6
  • 58
  • 107
  • 2
    Example of why you should modify detectors to catch wacky obfuscations: https://jsfiddle.net/sxrr0fsj/ – dhaupin May 03 '16 at 20:20
  • Hahaha @dhaupin -- very clever! Note taken!! – atdre May 03 '16 at 20:38
  • Haha amen, I was kinda surprised too. Here is the original inspiration: http://thedailywtf.com/articles/bidding-on-security and then there is this unicode->glyph obfuscation too http://thedailywtf.com/articles/javascript-obfuscation which worries me in regards to sniffez. – dhaupin May 03 '16 at 21:52
  • http://deobfuscatejavascript.com – atdre May 03 '16 at 23:31
  • @dhaupin , the script which you just shared was it kind of Javascript based dropdown or just an obfuscated alert prompt script? – Gerorge Timber May 04 '16 at 02:36
  • @atdre Great Answer, If a Victim from BeEF (Persistent attack) Delete his Offline web content and User data & Also Cached web content, than he's safe from the Hook Right? Moreover, can a person exploit the Whole computer like Opening a Meterpreter, vnc session just by infecting browser with BeEF like Privielage escalation – Gerorge Timber May 04 '16 at 02:39
  • @GerorgeTimber : Thank you. One is not safe from BeEF if you do those things, but it should clean an infected browser. There may be more-advanced techniques -- best to check with Volatility or similar (e.g., Rekall framework), such as the ones you mention. If you click my persistent BeEF scenarios you will see tricks that can leverage Metasploit BAPv2 and/or hta_powershell to launch a meterpreter payload, PowerShellEmpire agent, or other implant. – atdre May 04 '16 at 03:22
  • GCHQ's CyberChef has some great transformations similar to Malzilla. The jsdetox, jsnice, and -- https://x01x012013.github.io/JavaScriptDecompiler/ -- tools are also great for performing malware analysis of JavaScript and web-script payloads – atdre Mar 23 '17 at 21:19
1

If the sole concern is "hook.js" browsers such as Mozilla, Firefox have script blockers addons (e.g. noscript), if you're using IE, you could enable script blocking which would render any javascripts moot. As for tracking the communications server, you could use netstat:

netstat -an | findstr 8080

That would only work if whomever set a port to 8080. Your best bet would be to change findstr to ESTA. Which will show established sessions. If there is a browser with an established session, you could use netstat with the pid variable and look at the PID in task manager:

netstat -ano | findstr ESTA
munkeyoto
  • 8,682
  • 16
  • 31