Arbor Networks: Security to the Core

One of the things we’re doing in our work, and that will likely appear in our VBCon 06 paper, is understanding the distribution of OS’ per botnet command and control (c&c) server. I’ve been using a few tools to do this (it is in bulk…thousands of botnet servers; scripting “nmap -O” is the last resort), but the initial runs came up with disparate results.

The first tool I’ve been using is p0f2 in SYN-ACK mode, in conjunction with a tool to fling the proper SYN packet the server’s way. Catch the returning SYN-ACK and passively fingerprint the OS (in this case, with some stimulation, though it’s not really needed), and hopefully get the data in only a few packets.

The other tool I’ve been using is xprobe2, which is built on Ofir Arkin’s work on ICMP-based fingerprinting. Active, but only requires a few packets. More results than p0f, but somewhat inaccurate.

The third tool I used was a home-grown passive scanner titled “jscan” that uses the p0f fingerprint database. Results compared with the p0f2 results returned tons of “unknown” hosts.

The results, as you can see, differ depending on the tool, and neither one is very convincing (each is based on about 1500 botnet c&c servers attempted - about a third responding). While it would be neat to run a botnet IRC server on an HP printer, I don’t think that HP JetDirect printers are really that popular for the task. Same with Foundry devices. Alas, these images probably wont appear in the paper; I don’t think they’re accurate enough. However, the work itself continues, and hopefully with improved accuracy.

When you have to analyze a bunch of things quickly, you get used to doing it in parallel (using threads) or aggressively (using an event-driven mechanism). In this case what I did was use threads to fire off connections that p0f could fingerprint, closing them after establishment. The xprobe2 analysis was serialized, however, and slow (~ one hour). I may have to investigate an nmap-based approach in the near future.

Here’s your take-away: any good researcher knows the limits of the tools and techniques that they’re working with (and their environment), and can adapt. A good reader of the research can assess the methods used and determine if the results make sense. In either case, while it’s useful to have some sort of pre-conceived notion of what you expect (i.e. few, if any, devices like HP printers hosting botnet channels), you shouldn’t refuse to believe the data or mis-manage the experiment to confirm what may be an incorrect assumption. Wildly disparate results like these above should indicate that it’s a poorly designed experiment to blame. In this case I think it’s a matter of the tools being poorly suited to the task and needing to adapt my methods.

This entry was posted on Thursday, April 13th, 2006 at 10:02 am and is filed under Botnets, Interesting Research. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.