Happy New Year, everyone!
This guest post is brought to you by Ryan Linn.
At BlackHat Briefings this past summer, Steve Ocepek and I released Ruby code that would assist folks who want to use BeEF on internal penetration tests. Some may wonder, why would you want to do that? More and more internal resources are moving to Sharepoint, tools moving to web based intranet sites, and personal information moving away from mainframes and thick clients into web clients with database back-ends. Being able to attack the browser effectively on internal tests is going to become more crucial in giving realistic feedback on potential impact of an intrusion.
So our goal at BlackHat this year was to demonstrate how to effectively utilize the browser among local machines on the network. We created two tools to help utilize BeEF effectively on internal tests. The first was a tool called shank. Shank is an ARP Spoofing tool used to execute smarter Man-In-The-Middle (MITM) attacks injecting the BeEF hook into browsers surfing on the network.
Shank has two distinct parts. The first part is the MITM engine that begins by ARP spoofing the local network. Once the network has been successfully poisoned, shank begins polling the local BeEF instance to determine which browsers are already hooked. If shank sees a web response destined for a poisoned client that hasn’t already been hooked by BeEF, shank will insert the BeEF hook into the response. Once the browser is hooked, shank won’t inject another response until the BeEF hook is lost. This ensures that while the browser is actively browsing the web, it will stay hooked by shank.
So where do we go from here? Once we have a browser hooked, we want to get as much information as we can from each browser. BeEF lets us auto-run one module for each browser, but what if we wanted to do a large amount of fingerprinting for each browser we hook. This is where the autorun.rb comes into place. For each browser we hook, we check in autorun.rb to detect if this is a new hook. If it is a new hook, we have an array of modules that we want to run against the hooked browser.
These modules can do anything from figure out what version of Java and Flash is running, to determining all the interfaces on a machine to determine if a VPN session is active or if a host is multi-homed. Based on that logic, and since this is all in Ruby, additional logic can be added for reactions based on the fingerprints such as auto-launching MSF modules, or other types of attacks based on versions of Flash or the presence of VPN interfaces. This increases the functionality of BeEF through external triggers thanks to Michele’s REST API interface.
Leveraging these tools can greatly enhance your internal penetration tests, and this is a proof of concept to help with internal tests. If you want to try any of this out for yourself, you can get the code at github. I also encourage you to checkout the whitepaper.
If you have any suggestions for other things to add to BeEF, feel free to add them to our feature tracker, and we’ll take a shot. If you’d like to help out with BeEF let us know!