This morning, a good friend of mine asked two questions based on our webcast yesterday.  They were such good questions, I figured I’d address them here.

First off, he asked about how a pen tester could verify that the hooked browser near the start of our sample scenario is within the scope of the project.  It’s a great question, and we plan on getting into details about how to do that in the second and third webcasts in the series.  We’ll talk about different architectural approaches using client-side and web-server-side code to determine where on the network the browser is located to make sure it is kosher to include it in the pen test.   So, stay tuned on that one.  We’ve got a bunch of slides summarizing a variety of approaches.

His second question revolved around how to get customers who procure pen tests to include such combined work in their tests.  I jokingly responded saying that you should do webcasts on the subject and hope your customers listen in and get the idea.  But, more seriously, I explained that we do try to discuss combined tests up front during the initial scoping meetings with our clients to gauge their interest.  Sometimes, they do sign up for a test that is a combination of the two or three vectors we discussed: network, web, and wireless.  But, rather often, they tell us that they only have budget for one of those vectors, such as wireless.  I told my friend that we then commence on the given test that the client has planned.  Then, when we make some progress and get some form of access, we ask our client, “Do you want us to see how far we can go here?”  They often do, thereby placing the more complex and powerful combined attack vectors in play.  Customers often get excited by this, because they can see that we’ve scratched the surface and, with the increase in scope, will likely be able to help them make their case for security improvements.  So, the short answer to my friend’s second question is to try to scope it in up front, and if that fails, consider running it by the client after a major discovery during a traditional non-combined pen test.

i got an email that it was recorded and hosted on the sans site (webcast archives)

I missed it live but I watched the archive yesterday.  It was really good to see how different pen testers approach different customer scenarios.

I am looking forward to Part II and will spend some time with BeEF until then.

I seldom find Bluetooth AP's using the RFCOMM, PPP or Bluetooth Network Encapsulation Protocol (BNEP).  Most of my experience with Bluetooth AP's has not been in manipulating clients using the device, but in leveraging it as a network access mechanism that escapes 802.11 rogue AP identification.

It's probably not common to find users leveraging a Bluetooth AP for wireless connectivity due to the greater cost associated with the hardware and the relative popularity of 802.11.  However, that doesn't mean there aren't other uses for Bluetooth AP's...

Thanks,

-Josh

Great webcast guys, finally got it it . Now that I have listened to it, I have new tools to play around with.

Kevin - I was just browsing through the samurai CD and could not see BeEF on it. As there plans to put it there ?

Thanks

VJ

In the next few posts, I am going to post some of the questions we received after the web cast was finished as well as answering them.

Kevin

BEeF and metasploit actually fit into two different niches. 

Metasploit is an framework for creating, building and delivering exploits. 

BEeF is a framework for delivering browser payloads, but does not provide any means for creating or building them.