Once we monitored the network traffic and observed anything suspicious, you should follow some recommendations to keep your analysis organized and fruity. See here my favorite procedures when it comes to malicious traffic analysis:
· Use the sniffer to see the top-senders vs. destination host/destination port: here everything starts by knowing who is talking to whom and using which protocols. It’s easy to observe infected hosts by watching the “changed” behavior of them. From higher number of random generated ARP requests “ARP Storm” to DNS resolutions requests. And high SMTP traffic is another story.
see the ARP broadcast using a sniffer:
· Use the sniffer to see the full session data and take a look for any clues of what’s being sent between hosts. For example, HTTP packet could show you the requests to download files / upload files / bot-to-mothership traffic …etc. Every captured packet will be valuable to the analysis. This is like collecting the pieces of a crashed plane.
· If you got any unique pattern that keeps repeating whenever compromised hosts generate traffic, use this pattern as a “Sniffing filter” to make sniffer more specific and faster.
· Sniffers can send notifications: e-mail, page, snmp, or sms for anything shows up on the radar. For instance, if any host makes this specific http request, e-mail me!
· Getting a unique pattern will be the first step to write an IDS rule, or even a firewall rule. IDS rules writers depend on sniffers to get patterns and let the IDS look for them in a specific location in the packet and fire an alarm once it triggers.
· Save the sniffed packets and keep them for offline analysis, or even to share with other analysts on the Internet. Use “.cap”, “.tcpdump” as they are supported by most sniffers nowadays.
Here is a list of my recommended sniffers to be used:
Ok, enough talking about sniffers here. I will move on to another important player in the game, the IDS. It’s good to keep a running IDS all the time to detect what sniffers can’t see and observe. Because IDS’s have analysis engines, correlation engines, signatures, ability to reassemble packets and sessions. When I say this, I mean the IDS should be deployed in a way that can watch the IN/OUT of every network point (gatway, wifi, lans). IDS deployment should be done properly to make the IDS able to sniff and inspect every single packet in your network. Because IDS’s are basically sniffers, with additional engines and use signatures to detect attacks. So if your network contains switches, you should configure them to allow the SPAN/Monitoring port that will allow your IDS to sniff all of the traffic in your switch.
Using IDS to detect “in-the-wild” malwares depends on many factors:
- Are the signatures up-to-date to detect the latest malwares?
- Are they “generic” or “specific” signatures?
- Is the IDS deployed at the critical IN/OUT points inside your network?
To mention an example here, using Snort IDS (If you are in Kuwait – visit the Kuwait-sug) is a good start, since it’s free, sophisticated, and community supported. Installation & Deployment of Snort is out of the scope, and it has its own tutorial later.
Snort depends on signatures to detect attacks/malwares, for example see the following signature to detect one variant of the latest dominating botnet worm Storm (Later I’ll talk about it):
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT EVENTS Likely Storm Binary Requested (with_love.exe)"; flow:established,to_server; uricontent:"/with_love.exe"; nocase; classtype:trojan-activity; reference:url,asert.arbornetworks.com/2008/01/storm-loves-you-new-campaign-valentines-day-theme/; sid:2007761; rev:2;)
From the signature, it’s clear that (with_love.exe) is the Storm variant executable file, and usually will be downloaded using HTTP protocol.
I received another Storm variant in my e-mail, using the name (Valentine.exe). So we can modify the previous signature to detect it:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT EVENTS Likely Storm Binary Requested (Valentine.exe)"; flow:established,to_server; uricontent:"/valentine.exe"; nocase; classtype:trojan-activity; reference:url,asert.arbornetworks.com/2008/01/storm-loves-you-new-campaign-valentines-day-theme/; sid:2007761; rev:2;)
Another example is detecting bots outbound communication to the Command & Control server:
alert tcp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:”BLEEDING-EDGE TROJAN Trojan.Win32.Qhost C&C Traffic Outbound (case1)”; flow:established; dsize:>1000; content:”00 00 00 28 0a 00 00 02 0fService Pack 100”; classtype:trojan-activity; reference:url,/www.viruslist.com/en/viruses/encyclopedia?virusid=142254; sid:2007578; rev:1;)
Watch the hex data after content; it is the traffic pattern which we get it while we sniff the bot traffic to the “Mother-ship – a.k.a C&C”
Anyway, these are just few examples to show you the great detection and visibility of malwares in your network.
To install the IDS, you should deploy it here:
- Between the Internet router and your network: Installing the IDS at this point will give “Full Visibility” of the inbound/outbound traffic of the network. To achieve this point you should use a “Network TAP”.
- Inside the DMZ: to watch the attacks those target your critical servers in the DMZ. Also, any compromised server will be detected faster than manual inspection.
- Inside the LAN: the main battlefield between malwares and system admins. You should use the SPAN port in your switches to make IDS visibility better, because switches by design don’t broadcast traffic, it depends on unicast communications. SPAN Port duplicates the traffic from the Lan ports to the port which the IDS is connected to.
see the way a sniffer/IDS is connected to a SPAN port:
To be continued ...
|