"Solvamus Omnes: Quid Sit Mala” or “When Malware Binds Us All” – Part 2By: Paul Horvath
It is Monday morning. You open your eyes as your alarm bellows into your ear. You awaken and think "Wow! The Barry Manilow concert was superb on Friday. I am glad I was able to go." Soon, your remnant glee dissolves as you realize the tasks awaiting you this morning. You still have the problems from last Friday looming over your head. You wonder on how other security professionals would handle the problems as you ask yourself:
- Why were we not alerted by our HIPS-based Antivirus and Network Intrusion Detection Systems?
- What must be done to identify the behaviors and Indicators of Compromise of the malware?
- How should Incident Response be handled in similar scenarios in the future?
Step 1: Determining the Shortcomings of your HIPS Antivirus
You think to yourself, "1977's Barry Manilow Live was perfect but why not my antivirus?" You start your first task: determining what your antivirus knows. Most antivirus software is heuristic in nature. Consequently, you have to make trade-offs; precision or completeness impact things like speed. In other words, with any new malware or malware technique, the heuristics for the new malware would constantly have to be updated.
You then think to yourself, "If only I had a way to compare heuristics of various antivirus vendors, I could ensure sanity throughout our deployment." After spending some time online, you come across a website that would do this for you – virustotal.com. Eagerly, you take your seven hashes from Friday and begin to query for them. Looking at the results, you see that of the 50+vendors used; only 10 of them suggest the hash indicates malice. Of these 10, your antivirus is not present. You realize that your deployment of antivirus is working as intended, yet heuristics would not have detected this as of the day of the incident. Your mind starts to wonder and you ask yourself, "What are my options to overcome the limitations of HIPS-based Antivirus? How would I be able to mitigate the shortcomings with other technologies?"
Step 2: Identifying the Behaviors of the Malware
You think of your musical Hero, Barry, and how he went from merely writing jingles to being a platinum-selling recording artist. How would I go from nearly non-existent Indicator of Compromise research to something substantial? After some research, you realize you need a sandbox environment to execute and explode the malware in such a way that you can record the forensic information for use. This brings you to an open source analysis system, Lastline, that allows recording of various forensic data such as registry modifications, network connections, filesystem artifacts, and other forensically-relevant data. Since you had your Incident Response team extract the malware from the afflicted systems, you now have your samples to detonate.
Post detonation, you acquire some key pieces of data which can be used as IOCs (indicators of compromise). The data includes two possible C2 (Command and Control) server IP addresses, four suspicious registry modifications, and some sample PCAPs. Within the PCAPs, you are able to identify suspicious user-agent strings. You think, "Swell, I now have a magnitude of forensic data that we could use to limit the risk and impact of incidents going forward. How can I apply this data into my organization?"
Step 3: Using Forensic Data in Risk Mitigation and Incident Response
Many organizations lack the ability to deploy systems which could use the gathered forensic data in such a way that cost-effectively serves the network and organization. Luckily, you deployed several tools on the network to use to your benefit.
You take your indicators of compromise and begin to deploy them. First, you have your firewall team ensure the aforementioned IPs are blocked at the firewall. Then you configure your log aggregation system to notify you of any connection attempts to the IP indicators as a countermeasure. Fortunately, you have also deployed the open source tool, Snort. With Snort, you are able to write your own rules from the intrusion engine. So you write a Snort rule to search in http and https streams for the suspicious user-agent string.
You are now relieved as you can report to the CEO that you have found a way to deploy effective countermeasures throughout the organization. Now you have one emotion to wholly describe the progress you have made thus far: Thankful. With thanks to the agility of your staff, your network resources, and your own resourcefulness, you have provided a thorough response to the incident. You return to your desk, put on your headphones, and listen to your favorite Barry Manilow song, "I Write the Songs".
As some of you readers may have noticed, the model for this post coincides closely with the Defense in Depth model. This model is much like an onion in that your defenses are modular and in layers. The issues a professional would face without advanced technologies are very real. Having advanced tools considerably enhance your security policies and implementation as threats are becoming ever more advanced as time continues.
If you haven't had a chance to check out Part 1 of this blog, well kudos to you for doing things your own way, but definitely check it out to see get the whole story.
 HIPS-Based Antivirus or Host Intrusion Prevention System Antivirus Software: http://en.wikipedia.org/wiki/Antivirus_software
 NIDS: http://en.wikipedia.org/wiki/Intrusion_detection_system
 Indicators of Compromise: http://en.wikipedia.org/wiki/Indicator_of_compromise
 a method employed by many computer antivirus programs designed to detect previously unknown computer viruses, as well as new variants of viruses already in the "wild"
 PCAP, Network Packet Capture: http://en.wikipedia.org/wiki/Pcap
 User-agent, a string used in http communications: http://en.wikipedia.org/wiki/User_agent
 Snort, network based intrusion detection: http://en.wikipedia.org/wiki/Snort_%28software%29
 Defense in depth model: http://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29