What’s different about this approach?

Treat virus detection notifications as intrusion detection alerts. The anticipated (“straw man”) complaints are “But there are so many! Does it really make financial sense to investigate them all? And isn’t that what anti-virus vendors are supposed to be doing?”

If there are that many, then take steps to reduce the number. Block access to web sites or entire address ranges. It may seem a Herculean effort (much like the Fifth Labor of Hercules: the cleaning of the Augean stables), but tackling at least some of the offenders gets this down to a manageable task. They are so many alerts precisely because steps are not taken to address them.

Passing this responsibility off to antivirus vendors is irresponsible. It misrepresents the nature of system management. Do configuration management.

The subject of “Intrusion Detection” focuses upon network traffic. If you are detecting intrusions, you should expand your scope to include any computer inventory system at your disposal. This would include looking for anomalous services running or anomalous executables found. Similarly, root cause analysis (familiarly but inaccurately referred to as Forensics) should expand its scope from hard drive analysis to include network traffic. One approach can supplement the other; malware in motion requires malware at rest and vice versa.

Malware rarely travels alone.

With the rise of the “blended threat,” automated detection of one element in the threat allows for manual detection of other elements in the threat. For example: The specially-crafted PDF files which exploited an Adobe Acrobat Reader vulnerability (CVE-2009-0658) in February of 2009, dropped malware which was already detected. Symantec now detects the specially-crafted PDF files as infected with Trojan.Pidief.E. The specially-crafted PDF file then proceeds to install additional malware that was already detected as Backdoor.Trojan. The zero-day Acrobat Reader vulnerability was readily discovered by investigating the detected instances of Backdoor.Trojan.

In other words, investigating instances of Backdoor.Trojan would have revealed that a maliciously-crafted PDF was attempting to install the malware. While the Acrobat Reader vulnerability was unknown until it was exploited (that is, was a zero-day vulnerability), its malicious payload was previously known.

The lesson to learn: Follow up when exploit of a vulnerability is detected in order to learn of undetected exploits. See Simple Malware Discovery Measures for easy follow up methods. Reduce the gap between compromise and detection of the compromise. Expect a breach, so plan to detect the breach.

Contrast this with the typical incident investigation. A typical incident investigation may begin with:

• Someone notices, in the event log of the intrusion detection system, an alert regarding suspicious network activity.
• Someone notices, in the event log of the DNS system, an attempt to resolve a suspicious domain name.

The next step is to notify the desktop support organization of the activity and ask to have the machine at the IP address involved investigated. Recommendations should include “check to see if security patches were installed, check to see if antivirus software is installed and current.” Also recommended: check the machine’s behavior; see, for example, “Detecting and Removing Malicious Code” (by Matthew Tanase in SecurityFocus, July 22, 2002).

This is a good practice. However, consider the delays involved before investigation begins. Someone notices the event in the log and forwards a request for investigation. That request goes to a different organization, and that organization assigns a person to investigate. Those tasks often do not occur in the same day. Consider the information the investigator has to work with. They will have little more than when the event occurred and the IP address involved. With DHCP, this amounts to geographic and temporal proximity. A desktop support organization is commonly asked to check a floor for an event that occurred yesterday.

Note that the situation is not necessarily that dire; if the event is associated with a VPN connection, you should be able to learn the machine and user at the specific IP address at the specific time from the VPN log files. Alternately, if NetFlow messages are collected and can be analyzed, the source machine can be identified.

Consider the reasons to begin an investigation. The DNS resolution is suspicious only because it is a well-known, previously reported domain name (seen in a SANS event handler log, for example). The network activity is suspicious because it has a well-known, previously reported pattern.

That is, only some of the investigations will begin and only some of those will have a chance for resolution. You may never know what compromised system was responsible for the event.

Instead, begin with the systems. Find ways to locate the potentially compromised systems by investigating the virus detections that were successfully blocked and by using system inventories to find anomalous systems. In that way you know which systems to examine and you find compromises that were not previously reported.

See the Zone Alarm description of Nine Ball.

How does the threat work?

1. Victim visits legitimate infected site.
2. Victim is redirected to a series of different sites owned by attacker.
3. The final redirect is to a malicious drive-by download site, which attempts to download malware to victim’s computer through a number of exploits including MDAC, AOL SuperBuddy, Adobe Reader, and QuickTime exploits.
4. The malicious programs typically attempt to steal information from the victim via a keystroke logger.
5. Once a user has already visited the malicious web page, these repeat visitors are re-directed to the search engine site Ask.com. We assume this design is a technique to evade investigation.

The Nine Ball attack uses many exploits. They do not all need to be successful. Nine Ball needs at least one of its attack vectors to be successful. Similarly, detection of only one of the exploits gives the Nine Ball attack away, if you look for it.

See the F-Secure demonstration of their Internet Security Technology Preview (ISTP) and the 0-day Vulnerability in MSVIDCTL.DLL. Notice that the payload of this browser-based attack is malware that they already detected as Trojan.Agent.ANCF. That is, malware rarely travels alone.

Normal
0

false
false
false

EN-US
X-NONE
X-NONE

MicrosoftInternetExplorer4

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:””;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin-top:0in;
mso-para-margin-right:0in;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:”Times New Roman”;
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}

Vulnerability test methods for application security assessments