Basic Virus Defense

While I would encourage everyone to pitch in and report the malware that isn’t being detected, they should do this only after they have verified that their infrastructure is intact.

The management console provided by the anti-virus vendor should not be your only guide for managing anti-virus software. Machines that are turned off or are off the network do not check in with the server. If the anti-virus client is not running (“broken machines”), then it is not checking in with the server. That means you can’t tell broken machines from turned off machines when your only source of information is the anti-virus vendor console. Of course everything looks fine, when your only frame of reference is the anti-virus vendor console.

At a minimum, periodically check for machines whose virus protection service is not in a running state. You will need an independent inventory tool for this. I’ve used Microsoft’s Systems Management Server (SMS). In the following WQL example, you may wish to change “RTVScan” (Trend Micro’s real-time virus protection service) to the name of the real-time antivirus scan service you are using.

select SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Name, SMS_R_System.LastLogonUserDomain, SMS_R_System.LastLogonUserName, SMS_G_System_WORKSTATION_STATUS.LastHardwareScan, SMS_G_System_SERVICE.DisplayName, SMS_G_System_SERVICE.Name from  SMS_R_System inner join SMS_G_System_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SERVICE.Name like “ntrtscan” and SMS_G_System_SERVICE.State != “Running”

Note that a similar argument should be made for validating your security patch deployment tool. Your patch deployment can show that it has patched all the machines it can communicate with. Machines it cannot communicate with are not reported. That is, these machines are not patched and not reported.

Validate that your patch deployment solution is as thorough as it appears to be. Validate that your antivirus defense is as intact as it appears to be.

Then proceed with reporting that which your anti-virus vendor isn’t detecting.

Preventative measures:

• Apply patches or address software vulnerabilities through other measures.
• Install and maintain virus protection software.
• Use a firewall.

These preventative measures are complementary measures. Use information gleaned from malware detection alerts (even detected and blocked alerts) to supplement your firewall configuration. Specifically, drop all access to networks known to provide malware (such as Intercage and Inhoster).

A firewall drops network traffic. To defend yourself from external attacks, you should drop any unsolicited network traffic. Exceptions may be required to enable remote administration. At work, a corporate firewall should be protecting you. At home, your router should be (and probably is) performing this function for you. A laptop taken to hotel or wireless cafe will not have the benefit of the corporate firewall or home router and must have its own firewall software installed.

In addition to inbound traffic maintenance, a firewall performs outbound traffic maintenance. Outbound connections of only specific types should be supported. Your firewall’s default configuration is a good start.

Lesson learned: Have a firewall in place.

Many new variations of viruses appear each month. These new variations rarely reflect new software vulnerabilities; instead they use previously known software vulnerabilities and disguise their use in an attempt to evade detection by anti-virus software.

Lesson learned: Apply patches (or address software vulnerabilities through other measures).

Malware does not require a software vulnerability. Many instances of malware are willingly installed; these are the Trojan horses. Keeping out-to-date on software patches affords no protection from Trojan horses.

Lesson learned: Install antivirus software.

Application whitelisting (“permit only these applications to run”) is a good idea that requires time to collect information, has recurring maintenance costs (“adds” are a maintenance issue), will probably leave approved applications on the whitelist long after they have been retired (“deletes” are a maintenance issue), and provides no protection from in-memory threats. Hash collisions can create false confidence in application whitelists. As a preventative measure, application whitelists are a challenge to a changing environment. Application whitelists can still be used as a detective measure; this is part of configuration management.

When a new malware variation is released, a few thousand machines will be effected before a sample is isolated and submitted to an anti-virus vendor. A few thousand more machines will be effected before the anti-virus vendor releases detection for the variation. With multiple vendors, multiple submissions and varying virus pattern files released, there can be a few hundred thousand effected machines. This makes the labor of producing malware variants worthwhile.

Test to confirm that your anti-virus software is running using the eicar.com file or Detplock (“X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-CLOUD-TEST-FILE!$H+H*”). Test for spyware detection using spycar.org.

IBM ISS reports 14,000 pieces of malware a month. At AV-Test.org, you can see current statistics on anti-virus pattern file updates released in the past 7 days. In a 60,000 user environment, I could collect at least one sample of undetected malware each day.

An “install and walk away” approach to virus protection provides minimal protection. That is, installing an anti-virus product and configuring it to update on a regular and frequent basis provides minimal protection. Perhaps an occasional virus detection alert reminds you that the antivirus software is still running. The absence of alerts is an ambiguous result; having few or no alerts could mean there is little to report, or it could mean that anti-virus software is not doing an effective job.

When the “install and walk away” approach is adopted, or even when that approach is enhanced to include regular confirmation that anti-virus software is still running and accepting regular updates, there is still an opportunity for the malware author to evade anti-virus protection. In this scenario, frequently modifying the appearance of the virus (frequently changing its “signature”) can stay slightly ahead of the anti-virus product updates. This produces sufficient financial reward for the malware author.

What additional steps could you take? What would you do if you could?

Prepare for simple malware detection: Maintain a list of hash codes of known good software. fsum is a utility that computes hash codes quickly. You want this list if you suspect malware is running and you want to narrow your investigation by eliminating the known good software. Use fsum to compute a new list, then drop all the files that were on your old list. Keeping the hash code list up-to-date is a pain, but even an out-of-date list can quickly dismiss some files from consideration. (Incorporate hash codes into your change control process.) This can also assist if you intend to do application whitelisting (such as Windows AppLocker); you have identified applications.

When malware is detected

When malware is detected, what should you do?

The first question you should ask is “Is this evidence of criminal activity?” In general it is not. As a rule, a malware detection incident does not suggest criminal activity, so we can proceed. If there is reason to suspect criminal activity is involved, extraordinary measures will be required. This could include seizing the system involved. Any further root cause inspection should occur using an image of the system; the image should be created in a manner that does not modify the original system. In this unusual situation, you should notify others who investigate malware alert messages that no additional action should be taken. Take no additional action without coordination.

Lessons learned: Know what the criminal activity policy is and how the forensic procedure begins.

The second question you should ask is “Is this evidence of an internal policy violation?” or inappropriate behavior (such as a porn site, gambling, or web based external email account when this is counter to policy). You should know if appropriate management persons want to be notified.

Lessons learned: Know what the internal policy violation process is.

The final question will be “how should recovery be performed?” Between detection and recovery there are steps you can take to learn how your defenses can improve. See “Simple Malware Discovery Measures“.

When a malware alert appears, bear in mind:

A malware alert could indicate that the antivirus software is successfully protecting the system. In this case, follow-up should investigate where the malware came from. This information can be used to discover if any undetected malware arrived with the detected malware and to determine in that source (such as web site or a storage device) should be blocked in the future.

A malware alert could be a “false report.” A new virus signature file may detect benign code as malicious code.

A malware alert could indicate a successfully infected system. Learn where the infection came from, just as you would when a system was successfully protected. Restore the system to a trustworthy state. “Cleaning” is the least preferred option. See “Can you clean a virus?”

A malware alert could detect residue of an earlier successful infection. This would occur if someone “cleaned” the system instead of restoring it to a trustworthy state (in an effort to avoid reimaging, for example). Restore the system to a trustworthy state.