Security optimize

How to respond to a malware incident

When malware is suspected don't jump the gun on diagnosis and countermeasures. Follow these best practice guidelines to ensure an appropriate and measured response.
malware.jpg

Perhaps the most common security incident in any organization is the discovery of malware on its systems. But just because it can be a common occurrence, it doesn't mean it should be taken lightly or acted upon brashly. Let's take a look at some of the steps you can take when dealing with a malware outbreak and some tools that can help you along the way. Detecting and identifying a possible infection

Although it may seem straightforward, sometimes determining that a particular incident is due to malware could be tricky. The initial reports may come from different sources: a user could contact the help desk reporting trouble with their system; unusual traffic patterns could be detected in the firewall or internet access logs; or a specific system might not report back on the status of its antimalware software. Besides malware, each one of those cases could be explained by hardware failures or software misconfigurations, so each case should be investigated accordingly. Here are some checks and tools that can help in an investigation:

  • Check the status of the installed antimalware solution. If there is no protection installed or its definitions are out of date, even the most basic malware can enter the system. If, however, the antimalware software is malfunctioning in other ways (resident services won't start or its update process or scans fail constantly) you could be dealing with a more advanced piece of malware.
  • Check for suspicious or unknown processes running in the system. For Windows systems, Sysinternals Process Explorer is a very powerful task manager that can show processes that try to mask themselves as ordinary system processes.
  • To determine the source of suspicious network connections, the netstat utility and Sysinternals' Process Monitor are an excellent combination to help track down malware that is attempting to "call home" or attempting to spread.
  • Another tool from Sysinternals, the Rootkit Revealer, is very useful in detecting Rootkits or malware that uses advanced techniques in order to mask its presence on a system.
  • If you find a suspicious file and wish to determine whether or not it might be malware, VirusTotal is the site for you. You can upload a file (or scan a URL) that will be checked against multiple antimalware engines and the results from each engine will be presented along with any comments from its user community.
  • Also, most antimalware vendors provide ways to check suspicious files or submit malware samples or malicious files that are not detected by their products or their current definitions. You can also check their malware "encyclopedias" to help identify a particular piece of malware, its symptoms and evidence of its presence on a system.

Containment

Once the infection has been confirmed, the next step is its containment. Note that containment is not meant to be the definitive solution to an infection, but a temporary fix to prevent the spread of the malware and limit its impact. The containment strategy will depend on many factors, including the type of malware detected and the function or number of systems affected. Containment can be as simple as disconnecting the affected system from the network or more complex solutions such as removing an infected server from the network and activating the corresponding disaster recovery plans.  

Eradication  and preventing further infection

Once the affected system(s) are identified and contained, the next step is to eliminate the infection and restore the systems back to their normal state. The specific removal steps will depend on the malware identified: it could be as simple as reinstalling (or installing) an updated antimalware solution and performing a scan or as complex as having to manually remove registry entries or protected files.

Some antimalware vendors offer tools or versions of their products that don't require installation and can be run from a CD or USB drive in order to prevent them from being affected by malware residing on the system. For example:

Once the malware has been removed, steps must be taken to prevent reinfection. These steps could include fully patching the affected system (both the operating system and all third-party software), installing an up-to-date antimalware solution, and removing or disabling software or services that are not needed.

Lessons learned

Once malware has been removed and the system(s) have been brought back to production, a post-incident analysis is needed in order to identify the causes of the infection and the defenses that need improvement to prevent similar incidents from occurring in the future.

Improvements could include technical solutions (such as implementing automated tools for keeping systems patched and antimalware up to date or deploying tools such as EMET), increase user awareness (through mandatory training for instance) or the review of security policies and processes to ensure that they are up to date and remain relevant.

This is not a complete list of all the possible tools and steps you can take when dealing with a malware infection, but hopefully you can use these steps and tools to create your own malware response plan.

About

I am a technology specialist with over 10 years of experience performing a variety of corporate IT functions, including desktop and server operations, application development, and database administration. My latest role is in information security, fo...

7 comments
Shawn Quinn
Shawn Quinn

In the managed services SMB space, you just fix it. Fast as you can.

gregretro
gregretro

Rootkit Revealer? Really?! That was a great tool back in the XP days, but it doesn't run on 64-bit systems, and hasn't been updated in probably 5 years. Also, no mention of MalwareBytes, or the excellent OTL tool... and nothing about the Sysinternals tools Autoruns, PSInfo, PSFile or PSService.

I won't even get into the argument of wiping a machine immediately after malware detection vs leaving the machine up while triage happens. Definitely not a black and white situation - much more complex than that, but not worth diving into in comments.

An article like this is definitely needed - there is a dearth of good info out there - but it seems like this document pertains to incident response from 5 years ago, and should not be used for anything but the barest framework of response in today's world of malware response and triage.

bcscomp
bcscomp

RootkitRevealer v1.71

By Bryce Cogswell and Mark Russinovich

Published: November 1, 2006 - eh???

Tafadzwa Derek Tsvakanyi
Tafadzwa Derek Tsvakanyi

Trace the location of the malware file(if they are not hidden) before quarantine or deletion

tcavadias
tcavadias moderator Staff

The first rule of thumb would seem to be to immediately remove the malware not wait.

4nier
4nier

The "Best" response to an infected computer is to first remove it from the netowork, ask the user what they were doing, then rebuild the machine.