Monday, December 31, 2012

BeEF Shank - BeEF MitM for Pentests

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.

Sunday, November 4, 2012

Revitalizing the Inter-Protocol Exploitation with BeEF Bind

My last two talks about BeEF were great successes. I presented together with Ty Miller at RuxCon 2012 in the land of the BeEF, Australia. Then I presented the same talk, unfortunately without Ty, at OWASP AppSec USA, in yet another land of the BeEF, Texas (Austin) :D

The first RuxCon talk was on the first day at 9:00AM in the morning, after a drinking night. The room was also much more full at 9:10AM,  and people couldn't get in :D

Ty and Me
Ty and I decided to release the new BeEF Bind research at RuxCon for various reasons:
  •  RuxCon is an old and underground conference, full of proper hackers and friends, not script-kiddies;
  •  many people from the project (Wade, Brendan, Christian, Ben, Scotty, basically everyone except Ryan, Heather, Saafan, Bart, and Quentin and me :-) are from Australia;
  •  I've never been in the land of the kangaroos.

The research is revitalizing Wade's research on IPEC (2007) in the following ways:
  •  We're using XmlHttpRequest instead of HTML forms to send cross-domain POST requests
  •  A new staging shellcode has been developed to be used specifically for this attack technique
  •  Everything has been merged into BeEF, with new exploitation reliability features

Tuesday, October 30, 2012

Mission impossible: to install BeEF on a VPS with only 128Mb of RAM

Today's guest post contributed by Matteo Campofiorito:

Several weeks ago I received a free VPS from ChunkHost, my goal was to install an instance of BeEF but my VPS has limited resources. Is it even possible? Here is my VPS configuration:
  • OS: Ubuntu 12.04.1 LTS (Linux 3.2.0-29 x86_64)
  • RAM: 128 MB
  • storage: 3GB
At first, everything went fine following BeEF's installation instruction on GitHub. But, when I executed "bundle install," I received an error installing "eventmachine." I googled around for a solution and realized that my problem was the limited RAM. With only 128MB, g++ fails miserably when it tries to compile eventmachine.

But, extra RAM costs money, so I found a workaround: create a swap file of 512MB. I used "dd" to create the file (here is a good howto about swap file creation), then I activated it and added to my fstab. Then, bundle install succeeded, no error received!

This was the only problem I had with BeEF installation. Everything else went fine, and the program runs smoothly.

I hooked several browsers (2 Firefox, 1 Internet Explorer 9 and one Chrome instance), and there is  no slowness at all. The web UI feels responsive and so does the VPS. Here are some screenshots of the top command:

Before BeEF

After BeEF

During Hooking
I hope this helps you in your endeavors!

About Matteo:
Matteo is an open source addicted, security enthusiast and father of an awesome daughter. He works for one of the most important tech web sites in Italy, and in his spare time he writes his rambling thoughts on You can reach him on Twitter as @matteoca

Thursday, October 11, 2012

BeEF and Pwnies - The Pwn Plug!

As a Pentester, you sometimes need to think out of the box and use multiple techniques in order to prove to a client that they are vulnerable even in their internal network.  I was recently working with a client which had a XSS vulnerability in one of their internal web applications that just was not accessible from the internet...

Until I introduced the client to BeEF and the Pwn Plug Elite.

Thursday, September 13, 2012

BeEF web cloning, BeEF mass mailing, Social Engineering with better BeEF!

After a week of hard work, I'm pleased to release a new Social Engineering extension that will come very handy during your social engineering attacks that involve Phishing, both email and web based.

Now BeEF has its own web cloner, and its own mass mailer! But, there are tools out there that do this already, you say. Why should I use BeEF to do this, you ask?

Because it's BeEF! While there are other tools out there to do these things, I've made some improvements to how these are done when adding them into BeEF. We're talking about things like cloning web pages with an exact path, automatic BeEF hooking, and finally a mass mailer that supports HTML emails... well, you should really read this whole post.

Monday, August 13, 2012

Happy Hooking! - BeEF autorun and Twitter notify

Today's post is contributed by Ryan Linn.

In previous posts, we’ve looked at both how to use BeEF in a real world pen test, as well as how to use the REST API to automate common tasks in BeEF. In this post, we’re going to take a look at how to use the REST API to auto-run multiple modules at one time, and set up Twitter notification.

Why would we want to do this? In the Real World series, we looked at number of modules that can be helpful when profiling browsers. But, what if we want to run them automatically so we don’t have to point and click for each new hooked zombie? By default, BeEF allows for a single module to be auto-run. But, we can auto-run a number of different modules, and even customize them for specific browsers using the REST API.

Now we can easily manage more zombies coming in at a time from a social engineering campaign. Also, we have ensured that we have maximized the information we can get from the browser regardless how long a browser is hooked!

Thursday, August 9, 2012


We've been so busy in the last months that we haven't even had the time to write a blog post with the changes :D

Anyway, here we are with a new tasty piece of BeEF,!

Here is the breakdown of the most important changes (without mentioning bugfixes, that are always there if you look at our GIT repo history):

Saturday, July 14, 2012

Opening closed ports on NAT device and bypassing stateful firewalls with BeEF

Today's guest post comes from Bart Leppens. Thank you!

In 2010 Samy Kamkar discovered a method that he called "NAT Pinning."  The idea was, an attacker lures a victim to a web page and that web page forces the victim's router or firewall to forward any port number back to the user's machine.  The router, firewall, NAT-device must support connection tracking.  Samy Kamkar has successfully tested this on a Belkin N1 Vision Wireless Router.

Now, IRC NAT Pinning is integrated in BeEF as a module. It requires the victim to use Firefox due to blocked port number 6667 in most other browsers.  In this example, iptables is used to demonstrate how it actually works.

Tuesday, July 3, 2012

Raspberry Pi with a side of BeEF

A guest post from our friend g13:

The Raspberry Pi( is a $25 ARM GNU/Linux box that is the size of a credit card. The applications for this little device are seemingly endless. So naturally I picked one up and started working on some penetration testing scripts for this box. One of my goals was to get BeEF running; which I have done.

Saturday, June 23, 2012

BeEF In a Real World Pen Test - Part 4: BeEFy Desserts

Welcome to the final installment of BeEF in a real world pentest.

You can read the previous installments in our blog.

But, to recap: in Part 1, we demonstrated how to build the con for our fictional target company Contoso. In Part 2, we set the hooks for our targets and got zombies on the line. In Part 3, we gathered information from our hooked targets and started exploiting that data.

In this episode, we will discuss how we can pivot and hop further inside the internal network and how we can foolproof our encounters to conduct a professional pen test within a given scope and time frame.

Based on our previous work, we have a slew of hooked browsers and we have penetrated the first level of defenses. At this point, we want to leverage our hooked browsers to pivot and hop inside the network.

Hopping Inside

We start off by identifying the computers in the same network of the hooked browsers. Since we already have the browser’s internal IP (refer to part 3), we run our scan against its class C network using the ping sweep modules. For firefox, we use the “network/Ping Sweep” module which does not require user interaction, and for other browsers we use the “network/Ping Sweep Java”.

Additionally, we fingerprint common appliances on the same network of the hooked browser using the “network/Internal Network Fingerprinting” module. This module will try to enumerate common appliances (printers, routers, media servers, ...etc) on some default IP address using pre-defined file signatures.

After we have identified some live IPs, we start scanning those IPs for open ports. Using the “network/Port Scanner” module, we can port scan internal IPs of a hooked browser (Firefox, and Chrome only). The module uses WebSockets and HTML5 techniques to conduct the scan.

To further investigate our internal targets, we can run a DNS enumeration scan on the internal network via the “Network/DNS Enumeration” module. The DNS enumeration module uses dictionary and timing attacks to identify common internal domain names such as (intranet, mail, print, ...etc). This can be very helpful in identifying internal resources.

Now that we have a good understanding of the internal network, the last step is to scan internal applications for further vulnerabilities. Using the “Tunneling Proxy” extension, we can chain our browser, a web vulnerability scanner such as Burp Suite and the hooked browser in a proxy chain. This video by Michele “antisnatchor” Orru best describes how this can be achieved.

We can even craft and send raw requests proxied via a hooked browser using the Rider extension tab. This allows us to conduct convoluted attacks on the internal web servers.

It is worth mentioning,  we can do more pivoting and hopping by leveraging the meterpreter shells we have on some non-important hosts and the compromised test server (see part 3) but that is beyond the scope of this text.


Now that we have fully penetrated our target, we want to point out some of the proofing tips that will help us keep the pen test clean and professional.

The first thing we need to take care of is preventing backfire from disgruntled employees and/or target sys admins. The last thing we want is to get hacked by our customers! To secure our own perimeter, we take a few precautions:
  • Limit the admin UI interface of BeEF to the internal IPs only that we actually use to administer BeEF. This can be achieved from the main config.yaml file by setting the “permitted_ui_subnet” to match the administration internal subnet.
  • Setup firewall rules on the BeEF server to block all external access except for the web port, metasploit payload delivery port and browser autopwn port (if applicable).

For larger numbers of hooked browsers, the performance of the default underlying DB driver (i.e. SQLite) drops dramatically leading sometimes to unexpected behaviours. If you are planning to have a large number of hooked browsers, use BeEF in MySQL DB mode. This can be configured in the main config.yaml file under “database:driver:” section. Also, changing the update timeout value to 1-2 seconds in updates.js (based on the connection speed) might give a performance boost.

It goes without saying that we need to have our written authorization of the penetration test. What is sometimes missing are small details that might cause problems. The following are examples of sensitive “grey” interactions that should be explicitly declared in the scope and agreed upon a priori:
  • Sending buzzing phishing emails (especially to or about C-Level execs).
  • Capturing employees personal information and using it to gain access to their corporate machines.
  • Extracting wireless keys from corporate machines given that there might be some personal wireless keys on laptops or BYOD-style devices.

In order to keep the scope of the pen test from creeping to personal grounds, we can take some more precautions:
  • Limit the hooking subnets to only the IP ranges of the target company to prevent accidental or out of scope hooking of browsers. However, this will severely limit smartphones hooking as they will most likely get hooked via their 3G/4G interface.
  • Limit the hooking machines to only ones with a predefined set of referrer URLs that we use. This is a weak limitation but might be handy in case of mobile devices.
  • Do not save exported wireless keys that do not belong to the corporate wireless.
  • Do not save or use private photos and/or videos exported from the users’ profiles or harvested in the recon phase, as this is not corporate related and probably off limits.

Now that we have successfully penetrated the perimeter, hopped inside the internals of the network, and secured ourselves from backfire and scope creep, we are ready to write the report focusing on how our client will be able to fix the issues through which we were able go gain this access. 

Special thanks to Heather Pilkington for helping me out through this series, Michele Orru for his insightful comments, and all BeEF team for their great support!

BeEF, what a tasty piece of meat: HackPra talk

The 20th of June I gave a seminar at @HackPra in Bochum university, Germany.
First of all, thanks to Mario Heiderich and Marcus Niemietz for the invitation.

The talk went very well, covering several things:
  • communication channels: the default XHR-polling channel, and the new WebSocket channel;
  • XssRays integration: new enhancements (works with Webkit-based browsers that use XssAuditor, IE6 to 10);
  • abusing Chrome extensions: the Fake Flash Update module coded by Mike Haworth, and a few Chrome extension modules we have in BeEF (like the one you can use to inject the hook in all the open tabs). Imagine the impact of this (see screenshot below, where one of the tabs where the BeEF hook was injected is LinkedIn);

  • tunneling proxy: speed/performance enhancements while using WebSockets (4/5x times faster);
  • Evasion extension: for the first time, I was presenting the experimental Evasion extension. The aim of the extension is to obfuscate the hook and all code sent to the hooked browsers in order to evade passive regex-based filters. You can define your own obfuscation techniques, specifying in which order they need to be called. Right now we have 3 techniques: scramble (static string substitution, for example you don't see anymore beef in the hook), minify (awesome to save size) and base64. XOR is coming soon.
The talk went well, and as I promised there were a lot of live demos. Actually only one demo was not live. I've played again the Java mass pwner that uses RESTful API scripts, originally presented at AthCon 2012.

After the talk we all went to a GDATA building together with Karsten Tellmann, Felix @fluxfelix and other guys from @fluxfingers . Meeting Udo Strauch, the guy responsible for food and drinks, was a unique event :D His fine selection of rare beers was amazing: he particularly like some rare beers (honestly I didn't know them) from Teo Musso, an italian guy. The beers where really tasty and flavored, ans 8 to 10 percent :D 

We were partying hard until late in the night. The next day I met up with Reiners, Tilman Frosch, and partially followed (it was in encrypted German) Felix's awesome lecture about reversing.

To conclude, it was a great time. They really took good care of me. Definitely two non-conventional days for a university seminar. Really recommended to everyone (entrance was free as well of course).

You can enjoy the slides/recording here. This was the first time I could watch the recording of my talk the next day :D

Monday, June 11, 2012

BeEF In a Real World Pen Test - Part 3: Hot BeEF Steak

Welcome back to our series about using BeEF in a Real World Pentest. If you would like a recap of our work so far, you can read Part 1 and Part 2 in our blog.

In this post, we talk about how we exploit browsers to hop into the core of Contoso and exfiltrate data from its secure vaults.

Friday, June 8, 2012

BeEF up: Installing BeEF

We haven't forgotten about the BeEF in a Real World Pentest series. We're taking a break due to the new release, and getting you the stuff you need to use the tool we all know and love.
So, this week's post is about how to get up and running with BeEF.  

This one comes from our very own Ben Waugh.

Getting up and running with BeEF:

Monday, June 4, 2012


So, here we are with a fresh new BeEF release!

For those who want to know more about our development lifecycle, have a look here.

Obviously, with an Open Source project, it's a bit difficult to commit (well push, we're using Git at the end) the same amount of code/time every month, so it's normal to have months with more new features and addressed issues.

Last month's release ( was full of new code added to the repo. I will cover the main changes.

Monday, May 21, 2012

BeEF In a Real World Pen Test - Part 2: Tasty BeEF nuggets, line, hook and sinker (Social Engineering to get a hook)

In the first part of this series, we explained pre-hooking basics for reaching the maximum number of targets. In this post, we will go through the hooking process; taking into consideration the different social and technical aspects to hook the target’s browsers for as long as possible.

Preparing The Line
During recon of our target,, we harvested a few e-mails, and infiltrated some social media outlets. Some tips from the conversations we observed between employees led us to the non-official Facebook group for Contoso. Here, we learned that an internal football tournament is held yearly in a nearby stadium. It's organized by an internal "Sports Committee." 

We even found some pictures of last year's winners holding a trophy. We also spotted a couple of people talking about internal e-mails with special discounts on sunglasses as part of an employee benefit program.

On Twitter, we found a couple of interesting hash tags: #screwContosoBoard with quite a bit of anger from employees towards Contoso's management and board of directors.

We also bought a phishing domain "" and a valid SSL certificate for it. Finally, quick web vulnerability scanning identified a reflected cross-site scripting(XSS) vulnerability on Contoso's main website.

We will use this information to build our hooking strategy. We want to use our phishing domains and XSS exploit links to lure browsers at three main frontiers: Corporate email, Facebook and Twitter.

Monday, May 14, 2012

BeEF In a Real World Pen Test - Part 1: BeEFy Marinades (Pre-hooking Profiling and Trust Yield)

In this installment, we'll be talking about pre-hooking activities: how to build on the information from our target with social engineering to gain the trust required for stable BeEFed browsers.

Part I: Assumptions
Our engagement is a ten day project. As part of the standard engagement, the basic information we get from our client is:
  • Target company’s external IP address range.
  • The names of CEO, IT director, HR manager, and the names of a couple of normal employees.
  • The most important asset of the company (e.g. financial records, network availability,...etc ).

We'll want a phishing domain and some social media presence for our cons. For this scenario, we'll use Microsoft’s notorious fictional company, Contoso Ltd. (“We love Microsoft!”, as the Three Musketeers would say. Kudos Ed Skoudis, Kevin Johnson and Joshua Wright).

Friday, May 11, 2012

Teaser: BeEF In a Real World Pen Test

We post about some things we hope you'll think are pretty cool. But, we also know you want to know how BeEF can be used in a real world scenario. So, let’s talk about why BeEF is great for dinner, and why it’s a great addition to your social engineering and pentest diet.

On Monday, we'll begin a series to walk you through pentesting with BeEF, starting from initial research and continuing through final results.

In the first part of this series, we’ll walk you through clever ways to hook your victims using social media and some other tried and true phishing methods.

In the second part, we'll explore scope limiting your hooking, and explore how things like pop-under and man-in-the-browser attacks can assert persistence once you get your victim on the line.

In the third part, we’ll talk about how to collect information from the target, including what information you can get from cookies, the clipboard, and even the operating system. 

Then we’ll talk a bit about how you can use the information you’ve gathered to get further into the network.

Tuesday, May 8, 2012

Browsers, Browsers, Browsers!

While everyone is arguing about the next big thing in cloud or whether or not anti-virus is dead, we at the BeEF Project are quietly pwning the big gaping door everyone is leaving open: the browser.

We've found some clever ways to hook zombies that don't involve the traditional boring phishing email, and we've put some good hard thought on how to get other juicy nuggets from our initial foothold in the browser.

We don't care about your security infrastructure, either >=)

So, if you want a break from all the mainstream babble, keep an eye out for more releases about our proof of concept code. Maybe you'll even see us in Las Vegas.

Monday, April 30, 2012

Fresh meat: Release

Here at the BeEF project, we like to give props to our contributors and to those who inspire us. So, here's some info about our new release, and a little about the folks who made it happen:In addition to a major move, and taking a new job, Michele has made updates to the RESTful API Wiki, including two new endpoints:
  • /api/admin/login (added by Christian) which will get the api token by passing BeEF user/pass. As a consequence of this, the BeEF credentials have been moved to the main config.yaml. (they were in the config.yaml of the admin_ui extension before)
  • /api/hooks/:session gets all the hooked browser details (like plugins, technologies enabled and so on)
We'll probably be making a longer post about some tests we added for debug_modules, too.
Also, he's made XSSRays work with IE now, too (IE6 through IE9). A special thanks to Brendan for helping in testing.

Really, there have been a slew of other changes Michele has made, including:
  • The initialization extension has been moved into the core.
  • Added get_internal_ip module. Using an unsigned applet we can detect the internal ip of the victim. The previous module (Beffeine) had issues and this is the new replacement that works great.
  • Every HTTP endpoint of the framework, except for the admin_ui and the XssRays extension, now extends the Router class. This means that routes are managed by Sinatra, and when the web_imitation features are turned on those handlers will respond like an IIS or Apache server.
But, Michele isn't the only contributor to BeEF! For example, Brendan has given us the ability to detect whether anyone is using any of the 1,000 most popular Chrome extensions with the Get Chrome Extensions module. And, we now log a copy of the clipboard whenever a user copies or pastes text (IE6 only) with the Event Logger.

So, here's a shout out to all of the BeEF contributors, and the folks who inspire us. If you want to read more about the release or those who contributed, download the new version, or help out, check out our github or visit the project website.

Thank you for keeping up with us! Please let us know what you want to see, and what you find useful. We want your feedback, too!

Thursday, April 19, 2012

Why BeEF PHP is discontinued, and what's new in BeEF Ruby?

I'm sure a lot of you out there are still using the PHP version of BeEF. Actually, when I was speaking in various conferences about BeEF I realized that many people didn't know about the new Ruby BeEF.

The PHP version has been discontinued for various reasons:
  • It wasn't easy to extend from a core perspective.
  • When adding new modules, code was duplicated; you had to copy and paste a lot of code from previous modules, then add maybe 3 lines of Javascript as the new code, resulting in an anti-patterns.
  • There was no decent API.
  • IMHO PHP sucks for many reasons: it's got a ton of security issues, like Sendmail; it's not a true OO language, and programming with objects makes life easier. Ruby instead is OO, and the new BeEF heavily relies on that.
The new BeEF Ruby development started around mid-2010, with Wade's first post announcing it in October 2010. Rewriting BeEF from scratch was in Wade's to-do list for quite some time. It required a bunch of developers and a good language.

Friday, April 13, 2012

Cloudy with a chance of BeEF

Running BeEF from a local workstation poses some problems during a penetration test: it doesn't have a static IP address, the workstation gets turned on and off, and it really doesn't demonstrate the impact of Internet-borne threats. Pentesters have been turning more and more to online VPS services, or Amazon's EC2. For example, check out the lightning talk that I did at CloudCamp: leveraging the "cloud" during penetration tests 

This is where the idea of running BeEF on an Amazon EC2 instance started to simmer.

These days, the BeEF project uses IaaS and other cloud-esque services for a lot of the work. We have our continuous integration server running tests against our github hosted source code, heck, even this blog utilises SaaS (note to readers: if you think *aaS isn't already used throughout your organisation, you are sorely mistaken).

So here's a quick and dirty method to get you running the latest version of BeEF with an Amazon EC2 instance in no time. Before we begin though, this installation method is heavily inspired from RVM's installation method, so this will look familiar to RVM users.

You might be thinking, why not just create a canned Amazon Machine Image (AMI) of BeEF? When we considered all the different Amazon regions in which we'd have to host an AMI image, this method was just as simple, especially when dealing with all the changes to the framework over time. This process is still in its infancy though, so expect it to change in the future as the framework matures.

Tuesday, April 3, 2012

New and improved BeEF

Are you ready to thin the herd? It's a new release of BeEF! Here's what you'll get with today's release:
  • The much anticipated RESTful API we've been blogging about
  • QRCode extension (curiosity fed the BeEF!) 
  • Load configurations at the command line with a new -c function, as you requested, @_sid77
  • History extraction from IE and Firefox.

Read about it in this prior blog post.

QRCode extension

This module will generate a BeEF hook QRCode, so that you can hook nosy smartphone users with posters or other social engineering tactics. Devious devious! If you're lucky, you can check out Christian at this month's OWASP AppSec APAC where he'll be speaking about BeEF. Maybe he'll include some tasty bits about this.

The -c command line option

This will load a different master config.yaml file, that will be automatically ignored by GIT. We saw a bunch of people asking for this on Twitter, so we added it.

History Extraction

You should be able to see what sites have been visited if your zombies are using something IE or Firefox. We're working on support for Chrome and Opera, too. But, note, some of the privacy settings in Chrome may still prevent this from working, but where there is not specific blocking software or settings in place, this should get the history data accurately.

Other Stuff

... And we made fixes to the Rickroll module. Youtube keeps adding geo restrictions. But, BeEF is never going to give you up, never going to let you down.

Download the latest BeEF.

Saturday, March 31, 2012

RESTful API Demo

We promised you some goodies related to the RESTful API, and we're here to deliver! In this post, you'll see some practical ruby script to manipulate hooked assets. This should cover most of the basics of the API, but keep an eye out for some more advanced demos including Metasploit in the future.

Let's assume for a moment, you've already got your phish on the line. (There are so many ways to get them hooked, it didn't seem like we needed to talk about that in this article. But we'll definitely cover it. Wait and see!) We want to see how successful our phishing expedition has been, pull information about our zombies, and then play with them a bit to see what else we can get.

Tuesday, March 27, 2012

RESTful API from antisnatchor, with love

Have you ever wanted to do something with BeEF outside of the user interface? Maybe you don't have a GUI available on your pentest platform. Maybe you have a deep seated hatred of browsers that you are trying to turn into a love born of pure schadenfreude. Maybe you are just sentimental and could never give up lynx.

Well, wish no more! The new RESTful API for BeEF will let you use BeEF programmatically outside of the console. The API uses JSON for HTTP responses and HTTP POST requests that have a body. All you need is the pseudo-random token that is generated when BeEF starts. This will make sure that all the REST calls are authenticated.

So, now you can use simple scripts outside of the BeEF console to get information about hooked browsers, get logs and session information, or use command modules. For example, you can send a Metasploit module, or automate sending multiple scripts against hooked browsers for more complex attack scenarios. You can use the RESTful API to add your custom logic for a rule engine (in Ruby) that will analyze hooked browsers, then take automated action based on matching certain requirements/rules. You can even communicate with BeEF from IRB. Cool, huh?

We'll elaborate more on some fun ways to use this and other functionality in upcoming blog posts. For now, if you'd like to read more about the RESTful API, check out the Beef wiki.

Thursday, March 22, 2012

Welcome to the BeEF Blog!

Here at the BeEF Project, we've been working on a lot of things we're pretty stoked about. We've set up this blog as a platform for letting the world share our excitement and interact with us outside of the source repository.

In the coming days, we'll be posting more about what we've been up to and share our insights about where things are going. Keep an eye out for blog posts containing demos of new features, updates on project milestones, and maybe even some commentary about where BeEF fits in with current issues in Information Security.

We hope you are as excited as we are. We're looking forward to getting the word out.