All of the answers from Brady Bunch Boondoggle, the Skillz H@ck1ng Challenge from February 2009, are revealed as we continue our story with Oliver and Mr. Brady discussing the packet capture of the kids’ hacking activity. While pondering who could help them with the analysis of the data, a bright light flashes with a rumble that shakes the house.

Oliver asks "What happened Mr. Brady?"

"I moved the island Oliver. We’re 3 months in the future now."

"Oh … OK. Who can we get to help us analyze this wireless packet capture?"

"Come on in Sam", Mr. Brady calls, "do you know a thing or two about analyzing wireless data?"

"Sure do, I was a Wireless IDS analyst for the VeriWorks Managed Security Operation Center before working in the meat industry. What do we know so far?"

"Last week Mr. Phillips had an audit team assess the office for wireless threats. We have a screen-shot from the Kismet tool here."

After a few seconds of analysis, Sam shared his thoughts with Mike and Oliver. "This Kismet screen-shot gives us lots of useful information and I can say that the kids’ AP was not active at the time of this assessment."

"I’m sure Greg hid the AP before this Kismet screen-shot was taken. Could they have escaped Kismet
detection by setting the AP to not broadcast the SSID?" Oliver asked.

Sam responds "Not a chance Oliver. Using the monitor-mode feature on wireless cards, Kismet sees all activity in the area. Even if the AP didn’t have any users connected, it would still send beacon frames at a rate of 10 per second. We can see that this Kismet capture lasted for 28 minutes in the bottom-right corner, so Kismet would have seen some activity from the AP, labeling the network name as ‘<no ssid>’."

"Could it have been hidden in the ‘Probe networks’ group instead?"

"No, that list is for client devices that are actively probing for networks. Let’s turn to the packet capture data to see if we can figure out how they evaded detection."

Copying the packet capture to his IMP-16, Sam starts his analysis using tools from the Wireshark suite.

Note to the reader: Yes, the date stamps on the packet capture do not come from 1974 when the IMP-16 was introduced. Please don’t get hung up on this.

"Well, for starters, this is a fairly large packet capture. Wireshark is going to have a lot of delay when applying filters and reloading data with this many frames, so I’ll create an extract of the first 1000 frames to focus my analysis on the events leading up to the hack with tcpdump."

Studying the first few screens of packets, Sam says "Boy, those kids sure are sneaky. Take a look."

"We start to see activity from an AP with the source 00:1a:70:fc:c0:6f in frame 8, 27.5 seconds into the packet capture. This is very unusual; only an AP would send a probe response frame with any legitimacy, and we would normally expect to see beacon frames sent at a rate of 10 per second from an AP, even when it isn’t actively used by any wireless clients. We also appear to be missing some data, since the first frame from this device has a sequence number of 1, not 0."

Oliver asks "Could it have been a problem with my wireless card capturing the data?"

"It’s not unusual to lose packets while capturing in monitor mode. Your wireless card capturing the data could experience interference, such as traffic from a nearby Bluetooth interface that would cause your view of the frame to be corrupt but otherwise valid for the active connection. Always keep in mind when looking at a packet capture, wireless or otherwise, that you might not be seeing the whole picture."

After another minute of analysis, Sam continues to unfold the details of the attack. "What is most interesting is the activity that continues after the probe responses in frames 8 and 9. We see the AP suddenly start to beacon only after sending probe responses, which presumably followed a probe request that we don’t see in this packet capture. The first beacon frame from the AP gives us a lot of information about this device."

"The ‘DS Parameter set’ field in the beacon’s tagged management information elements list tells us that the AP is on channel 11, which at is 2.462 GHz. We know the kids didn’t try to hide the AP by using a 5 GHz or otherwise uncommon frequency. The SSID does appear to be hidden, replaced here with ‘