We had a great time doing our workshop at BSides London recently. In fact we had a great time in general – the conference was lots of fun.
This was the first long(ish) workshop I had ever prepared for a conference, and I was surprised at how much work was involved in it (compared to an ordinary presentation). We not only had to create the presentation, but build the infrastructure, create Kali builds on USB sticks, set up the demos, prepare a worksheet for the participants and prepare the two ‘test reports’ I had promised in the description of the workshop. Then we had to test, test, test in an attempt to appease the dark god of demos!
We were coming down from Scotland to London for the event and quickly discovered a major drawback – we had a lot of kit…. We needed two PC laptops to be the Nessus Servers and host the vms for the demos. We also had a Surface Pro for running the demo, a Surface RT (just for kicks) and a MacBook Air to run Rory’s presentation. Add in a switch and cables (because we didn’t like the idea of trying to run eight sets of Nessus scans over wireless) plus a fourway and sundry hardprint materials for the participants and we had three huge rucksacks full of stuff. Going down the stairs at the station I was scared I was going to tip over backwards.
Anyway after a brief panic when we thought the five hundred bottle openers we had ordered for the conference swagbags had not turned up, we found them and then got set up. We were a bit nervous that after all the effort, no one would be interested. When I checked the subscription sheet, we had ten signups for 8 slots (the room was on the small side). And then people started to turn up – and there were loads more than on the sheet. Unfortunately, we did not have room to let everyone participate in the demos, but we managed to fit everyone (16 people!) into the room although it was a bit on the hot and crowded side.
So the purpose of the workshop was to show people who were technical, but not professional testers, to prepare for a review by eliminating all easily correctable faults in advance of the test. This would enable the tester to focus on serious issues rather than finding and documenting things such as missing patches and SSLv2. The example given was of the imaginary UWC company – and we showed off two mock reports an ‘before’ with 58 vulnerabilities, and an ‘after’ with 6. The ‘sting’ was supposed to be that amongst the six – was a critical SQL vulnerability which the tester had not had time to investigate in the first scenario, but found in the second.
We did four demos:- nmap, Nessus, and two Metasploits. The second Metasploit was the classic which really impressed me when I started testing – using an unpatched workstation to steal an Admin’s token and use it to add a user to the Domain Admins group on a fully patched DC. The dark god did not really visit us – and everyone seemed to get on well.
We hope everyone enjoyed the workshop and thank you for coming. Hopefully we will be able to reuse the materials in the future.
I’ve attached our presentation. Conducting a DIY Security Review – latest