I mentioned in a previous post that the ZeuS scraper was more or less going to be kept in it’s then-current form while I work on a new and improved version, and I’m happy to say that it’s just been released with an expanded array of hosts to check as well.
Share and Enjoy!
There has been some impressive hoopla over the ZeuS DNS scraper I posted last week. There’s been even more chatter then I expected. I’ve received nothing but good feedback and have even gotten tweeted by Mikko Hyppönen and Lenny Zeltser, two people I have immense respect for. Anyway, I have continued messing around with the script, found and squashed a few bugs, and added a few features. So, now, I am releasing:
All of the old flags should continue to work, and most of the changes are under the hood. There is, however, one major bug that was squashed: apparently the old version would never update the local copy of the ZeuS domain block list, even when it was supposed to. So, I would highly recommend everyone use this newer version. The big feature that has been added in this script is the ability to limit the rate of queries being fed to the DNS server. When I was running v0.3, I would occasionally run into problems where the script would stall for a bit, presumably when the DNS server didn’t respond fast enough. Worried that the sheer amount of queries may be overwhelming the server and also trying to make this as low-impact as possible for folks to run, I added he –rate flag in which you can specify how many queries per second the script should send.
So, if you wanted to run it at 30 queries per second:
perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --rate 30
If no rate is specified, the script currently defaults at 25 queries per second, which (I assume) most normal DNS servers should be able to easily handle without breaking a sweat.
Also, this might probably the last version of this tool in it current form. I currently have a new and improved version baking in the oven that expands the capabilities and dataset of the tool. I hope to have this out and released within the next week or so.
UPDATE: There’s a new version, with 25% less bugs! Use this instead.
As some of you may know, I wear an Incident Response hat within my organization. As I like to be proactive and actively search for issues rather then just be an IDS alert monkey, I love pages like the Malware Domain List, the ZeuS Tracker, and malwareurl.com. While these are great resources, it is a bit difficult attempting to take the lists and apply them to the environment; most of their usefulness comes from when you have a questionable URL and need to see if someone else has reported it as a bad site. A great service, but not proactive.
While staring at the ZeuS Tracker Domain Block list and trying my usual method of snipe hunting manually entering domains to query the firewalls, a moment of inspiration hit: I don’t care about all the domains, just the domains that people visit. Who knows what domains people visit? The DNS servers! Now it was just a question of trying to coax the information out of the DNS servers. Thankfully, PaulDotCom Security Weekly came to the rescue: They have been talking about getting information out of DNS servers during penetration tests and a simple non-recursive DNS lookup on the local DNS server can tell you if someone queried for the host recently. A couple of quick experiments to verify this fact on my work’s main DNS servers confirmed this fact, and I set to work.
My first attempt was a simple script to take a pre-chewed version of the ZeuS Domain list, feed it through dig and pipe the output through grep. It worked, but I wanted something a touch more automated. Over the next couple of nights on the train, I whipped up a tool to automate the process a little more. The resulting tool is the ZeuS DNS Scraper. It’s a simple script written in Perl and should work straight out of the box with the default modules included in a Perl distribution.
Running the tool is fairly simple, there are only 4 options: –server, specifying which server(s) to query, –file, specifying where to put the downloaded ZeuS Tracker block list (defaulting to /tmp/ztbl.txt) , –download/–nodownload which specifies whether or not the script should attempt to download the block list, and –debug, which specifies the verbosity of the script.
A typical command line would be:
perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3
Which would download the block list, and then proceed to query 192.168.1.2 and 192.168.1.3 for each entry in the block list. You can specify as many as many servers as you like, however, the block list often hovers around a thousand entries, so each additional server adds another thousand or so queries.
Alternatively, once the list is downloaded, the script will download the block list only if the local copy is older then 60 minutes, (don’t worry it doesn’t update that frequently). You can also specify that the script doesn’t download the list again with the –nodownload option:
perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --nodownload
You can also turn on debugging with the debug option, which will display every step in the process:
perl zeusdnsscraper.pl --server 192.168.1.2 --server 192.168.1.3 --debug
When the script is run in default mode, a ‘.’ will appear after each query, while in debug mode it will display the result of the query and whether or not it found an entry.
Completed! NNNN queries made, 0 entries found! Hooray!
In this example, NNNN would be the number of queries sent, remember this increases which each additional server you need to query, and it has found 0 entries, indicating that the DNS servers queried have no cached entries for any of the domains. Congratulations, pat yourself on the back and grab yourself a nice frosty beverage from the refrigerator.
NNNN queries made, 4 entries found. Uh Oh. W.X.Y.Z has an entry in it's cache for www.example.net: 10.1.2.3 W.X.Y.Z has an entry in it's cache for www.example.net: 10.1.2.4 W.X.Y.Z has an entry in it's cache for www.example.com: 10.4.5.6 W.X.Y.Z has an entry in it's cache for www.example.org: 10.7.8.9
Well, crap. This time the beverage you need is probably kept in your attrition.org flask. NNNN is the number of queries the script made and the “4″ in this example is number of results found. In this example, “www.example.net” was cached with two separate addresses, while “www.example.com” and “www.example.org” both have one apiece. The W.X.Y.Z in the above example is the DNS server that responded, and the 10.X.X.X addresses are the IP addresses that the DNS server responded with. These IP addresses are what you are interested in.
This is where some good old detective work comes in. The presence of the cached entries on your DNS server only means that one of the clients on your network asked for the entry in question. Normally, it’s time to start plugging IP addresses in your firewall logs to see who’s been visiting them. Then it’s time to start cleaning.
Now, obviously, this sends a boat load of queries in a very rapid fashion to DNS servers. Make sure that your DNS server and your connection can handle the load and don’t run it against DNS servers that you do not have permission to do so. Also, some of the DNS entries have small enough TTLs that they may expire quickly, meaning that even if the script comes back clean, there could still be infected hosts.
I’d just like to say a big thanks to the folks over at abuse.ch for hosting the ZeuS Tracker. It’s a handy tool and it’s invaluable if you’re running even a moderately sized network.
ZeuS DNS Scraper
The InfoSec community was murmuring lately over a interview with Matt Knox, who wrote spyware in a previous life. I did feel that the interview, although done fairly well, was a bit soft and “DirectRevenue” did cause long-dormant synapses in my brain to start to wake up and scream in horror, but I dismissed them and didn’t look into it any futher.
Thankfully, Chris Boyd aka “Paperghost” did. Boy, did he ever…
The interview painted a “Hey, they did things that were of questionable morality, but they weren’t that bad!” picture and Knox did have a “Aw, shucks… Sorry!” demeanor to him. Which, as Chris points out, is kind of expected, since the interviewer is a friend. However, the State of New York documents paint a very different picture to the entire operation, and comments like:
Matt is a wonderful teacher, a great coder and a good friend. It was pretty awesome that he did this interview and gave us the inside scoop on how a noted adware company operated, both technically and from a business perspective… Nowadays he uses his skills to educate and create software for doctors.
Seem to try to whitewash the seriousness of the situation he had a hand in creating. I’ll give Knox credit for doing an interview, but I won’t give him a pass for coding such nastiness for a very, very long time. Everyone can make mistakes, but the questionable ethics that get them into such mistakes deserve to be scrutinized. As much as I would like to believe he has turned over a new leaf (and by the accounts I’ve see he has) there is this little nagging voice that says “Software for Doctors? He better not be touching patient records.”
I would enjoy a follow-up interview with Knox to address the question raised by Chris. I hope one is forthcoming.
PaperGhost runs VitalSecurity.org, a very informative and amusing look at malware. He’s full of amusing quotes such as:
Bruce Lee understood that there was no problem on this Earth that could not be solved by repeatedly punching someone in the face until they stopped getting up.
Over the past month or so, he’s outdone himself.
I occasionally take down phish sites and the such. However, PaperGhost has done everything short of handing down divine judgement to a bunch of script kiddies who think that phishing Myspace and Habbo Hotel accounts is the bleeding edge of computer coolness. PaperGhost has shown them that such enterprises do not end well:
A bit of reading, but highly enjoyable…
Nepenthes is a wonderful tool that is great for collection of various malware nastiness. It’s extremely useful and has provided me a fair share of amusement when I review the logs seeing all the various trash the Internet’s tubes try to dump onto my computer. I love Nepenthes.
Unfortunately for me, Nepenthes also completely sucks.
Nepenthes does some amazing things in the areas of collecting malware, examining payloads, and automatic analysis. However, from a user perspective, it’s a fetid pile of yak’s droppings and an abomination in the sight of God. The software seems to be in a perpetual state of debugging, which, by itself is OK, but it seems to constantly want you to run it from the console. This makes it difficult if you ever want to run it unattended, which in most cases you will want to do considering you’re essentially trawling for malware. Also, the logging facilities also seem to reflect this, as extracting meaningful messages from the log file is pretty close to reading tea leaves.
The thing that really drives me batty is trying to get Nepenthes and Honeyd to work together. The author seems to know that people want to do this and tries to explain what has happened, but provides a next-to-useless explanation and ends it with an update of “The Honeyd guy managed to do this, but I don’t know how.”
I know that almost all open source software is on some level classified as a hobby, but wouldn’t you at least try to make inquiries as to how to make it work, and or adjust the codebases to make this kind of setup easier? Instead, you have people like me who are using duct tape and bailing wire solutions to “fix” the problem, and are unable to recommend the software for use in production environments because of specifically that.
Which is sad, because I love Nepenthes.
Twitter
LinkedIn
Facebook
Flickr
FriendFeed