virustotal-submit.py

Didier Stevens has created a nice little tool to submit malware samples to VirusTotal using python. The tool can be downloaded here. This is really handy for an intrusion analyst (as well as a malware researcher).
Consider this scenario: You're investigating an alert and pull the packets for the session that generated it. You discover the user downloaded, intentionally or not, a binary from some site, purpose unknown. You wget or curl down the file and inspect it with hexedit or bless, but can't determine for certain whether it's malicious or not.
Run  virustotal-submit.py and submit the file right from your packet box. No need to transfer the file to another box to submit it (I'm assuming you're not running X on your packet audit box). And you can build this into your own scripts and tools for automated submission (the public API has a limit of four files per minute).

You'll need a couple things to run the tool. There's one dependency, the python module "poster", found here. And you'll need a VirusTotal public API key. All you need to do to get one is create an account on the site at http://www.virustotal.com. Your key will be in your Community profile after you log in.

Cisco Buys Sourcefire

Sourcefire announced today they've entered into a definitive agreement to be acquired by Cisco for $2.7 billion dollars. While it will obviously be a while before we see if this is a good thing or a bad thing for the network security industry, my experience has been that when big, bloated companies like Cisco or IBM buy out a smaller competitor and integrate them, it usually doesn't work out well. (For example, IBM buying ISS).

Some of the biggest concerns I've heard so far is that Cisco will try to integrate the Snort ruleset into their own products (ala PIX), or they will close the rule set, not allowing modifications or custom rules, or licensing will go up (bet on it) or the worse case scenario, the SF talent will be crowded out and exit, leaving us with Cisco engineers "improving" the product. If that happens, long time Sourcefire customers can meet all those folks who ran ISS at the corner pub and commiserate together over a cold one or two or ten.

Noise vs. Pattern

When does malicious traffic directed towards your network become white noise instead of part of the overall threat picture? The oft-used example is the Code Red worm. To this day there are still infected servers spewing out traffic that has faded into the white noise of the Internet. Very few have Code Red signatures enabled on their IDS and even fewer would actually look at any alerts that were generated from them.
But what about current valid exploits directed against a non-affected server? What about PHP attacks launched against an .ASP server? Should we be concerned? What about taking action?

I think there are two schools of thought on this. An instructor I had in a SANS class phrased it this way: "If you can't play nice on my network, you can't play on my network."
I'd love to be able to follow that philosophy. Unfortunately there are other factors that come into play when you're defending someone else's network, especially a large one.

Shunning malicious IPs involves one of several scenario's. If you're running IPS and are doing in line blocking, it's automatic, assuming the signature or rule is set to block. That's the good news. The bad news is: it's automatic. IT managers shudder at the thought of a customer trying to access their public web app servers and being blocked by a false positive on the IPS, as well they should. That's still the overarching issue with IPS:  How much do you trust it not to accidentally block legitimate traffic. So, many times, the IPS is set to only block really noisy, old attacks that have almost a zero percent chance of false positives. Not terribly helpful.

Another way to deal with pervasive attacks is to shun the IP at the border router. This is a process. First you must document the attacks that you are seeing, with logging and/or packets. You must then present your case to someone higher up (unless you're in management and have that authority) that the IP needs shunned and get their approval. Then you'll need to get change request approval. Even if there is a short path approval process for situations like this, this still takes time. You may find that by the time you shun the IP, the attacks have stopped and never come back again from that IP. That's a very good possibility because of the pervasiveness of botnets. An attacker never needs to use the same IP twice; he/she has many to choose from. That way his attack can't be shunned and it's very difficult for the defender to try and respond.

Another consideration is: Is there is human intelligence behind the attack? Is someone probing, looking for a way to exploit a host or is it a blind sweep of your whole address space and hundreds of other folks space as well. A real attack won't be that noisy unless the attacker is completely incompetent. Does the attack make any sense? Seeing zone transfer attempts against your web servers is a really good indication the attacker just wound up a script and is whacking against a whole range of IPs. Most of what we see today, or at least what I see, are fishing expeditions. They run for an hour, a few hours, and we never see that IP again.

So what's noise and what's of real concern? There isn't any easy answer to this. It all depends on how much analysis you can do and what can be determined, how large your public presence is and how pervasive the traffic is, how much of the traffic an organization would classify as an acceptable risk and what the return would be on your investment of time to respond and block the traffic.

Ask Yourself Questions

A lot of analysis is asking yourself questions and then using your tools and data to answer those questions. I was recently looking at some alerts that used a non-standard user agent in the client header, but the desktop team wasn't finding any indication of malware. My thought was an app was making requests and setting the user agent. All of the traffic from each machine was to one, business related site. If malware were involved, I would expect to see traffic to different sites all using that same user-agent. So my question to answer was "Does this machine use a different, standard user-agent to other sites?" To answer this I needed to go to a packet audit server that the traffic was captured at and pull all of the packets from that day in the hour they  happened and the hour before for good measure, then look at the web traffic and compare the user agents.

for i in $( ls -lah | grep 'Jul  8' | grep -w '1[7-8]' | awk '{print $9}' );do tcpdump -nn -r $i -s0 -X 'host x.x.x.x and (port 3128 or port 80)' -w work/$i.pcap;done

Each hours worth of data from that machine (and there were multiple captures per hour) on those ports is now in my work directory with a filename of the original packet capture filename and a .pcap extension. Now I need to use mergecap to concatenate all those captures into one file.

mergecap -w aggregate.pcap dmz1tap.*

Now I have all the traffic on one pcap called aggregate.pcap and can run it through  ngrep or through Wireshark and use the Find Packet function to search for the "User-Agent:" string. (That's under Edit, Find Packet). I need to change the type in the "By:" field to String and change the Search In type to "Packet bytes".

As expected, only certain packets used the user agent in question. Now the next question to ask myself is "Why do these particular connections use this non-standard user agent?" Ask, find answers, and repeat until the analysis is done.

VMX to OVF Conversion

I got back from taking the SEC542 class at SANSFIRE and needed to install the two virtual machines to my home machine to recreate the labs I did. SANS uses VMWare Player; I prefer Virtual Box. VBox will only import machines in the OVF (Open Virtualization Format) but VMWare uses VMX. I found that VMWare has a tool, called VMWare OVF Tool, that will convert one to the other, both directions. You can download the tool at:
http://communities.vmware.com/community/vmtn/automationtools/ovf (you'll need to create a My VMWare account, but it's free). Then just change to the \VMWare\VMWare OVF Tool\ directory and run:
"ovftool  (path_to_vmx_file) (path_to_save_ovf_file)". I put the .ovf file in the same directory as as the .vmx file. Then open up VirtualBox and go to File\Import Appliance and point it at your new .ovf file. Once it's done importing, you're ready to fire up your virtual machine. Nice. 

NIC Offloading and Packet Capturing

If you run a packet audit server or an IDS that does full packet captures, I recommend you read this article by Doug Burks from the Security Onion blog about disabling NIC offload features, found here.
You may find you really need the full data of packets and don't have it, if you don't do this. Doug is a GSE, the lead author of the Security Onion distro and an all-around helpful guy. Good stuff.

New NTOP

The primary author of ntop, Luca Deri has announced that a new, rewritten from the ground up version of ntop has been released. Renamed ntopng, info and download links are available here. If you're not familiar with this great open-source tool, ntop monitors traffic on an interface (or multiple interfaces) and tracks connections, bandwidth usage, protocols, top talkers and the like and supports taking netflows from infrastructure equipment (supports sFlow, NetFlow and IPFIX).  Putting an ntop instance on your packet audit box can be a great tool for tracking hosts from EOI's and can show you changes in traffic patterns that might indicate increased interest in your network from the outside. It can also quickly show you all the hosts an infected box talked to and how much traffic was passed, which might give you an indication of data leakage. It's not specifically designed as a NetSec tool, but it certainly fills the role as a good correlation tool. You can also feed it your pcaps to get a snapshot in time of network traffic you're interested in.