Malware Incident Response Steps on Windows, and Determining If the Threat Is Truly Gone

Last updated at Wed, 06 Dec 2017 01:23:44 GMT

Malware can be a sneaky little beast. Once it's on your computer or network, it may be hard to detect unless you're explicitly looking for it. When dealing with malware, it is extremely important to not only know the signs to look for, but also how to stop malware in a timely manner to reduce the spread of infection in the event that it's detected.

Malware can spread pretty quickly, especially in a corporate environment where company-wide email is used as the primary method of communication and transimission. At the end of the day, you need to be able to properly identify malware on an infected host, remove the malware from the host (and know that it is really gone), and then update your SIEM/IDS solution to help you determine that this strain of malware won't strike again. Let’s take a look at some examples.

Malware Use Case Examples

A Single Malware Event

A great example of a single malware incident you’d run into is when a user opens an attachment from an email, or downloads something from an unknown source on the internet. There are ultimately two ways the security team would discover this:

• The user admits they downloaded something that might be malicious
• Your IDS/antivirus solution detects an abnormality in the user's Windows event logs

Multiple Users Event

Malware that spreads to several users in the company is usually spread through email. For the most part, detection will be the same as above, but you will have to take another step in retrieving the email that was sent to determine all users that could possibly be affected by the same strain of malware. (You can use Komand for this!)

Identifying the Problem and Updating Your IDS solution

Keeping your antivirus updated is always the first step, as an outdated version may not catch new strains of malware. Overall though, the Windows event logs will be your best friend here. Although they are kind of noisy, we will use Windows Event Viewer to filter out normal activity and discover what is abnormal.

To properly identify suspicious activity in your event logs, you will need to filter out the “common noise” generated from normal computer activity. The most common approach to this is to start with all the Windows event activity logs and then whitelist to only what is important for malware detection.

Logs to focus on would be:

• Creation
• Deletion
• Installs
• Permission change logs (see screenshot below)

As you can see, I have created a custom filter within event viewer to only see what is important for malware detection. Understanding event IDs and what they do will help you drastically in this filtering process. Below are a few common event IDs to start with:

You can find a complete list of event ID’s here.

Once you have determined what events you can pull from the logs, and have whitelisted only the logs that are desired to be detected (i.e. creation/new processes), it is now time to further trim down the noise with a black list.

The idea here is to remove the “normal” noise from the predetermined whitelist that you created above. For example, events like “New Process Started” or any normal logons that a machine will make in a usual work day. Be mindful, though, on the timeframes of these events, as well. Maybe you want to filter out logon logs during normal business hours because they are too noisy, but it would be a good idea to re-enable them for after work hours to view any users that are logging in at odd times.

After collecting some event logs for a week or so, you will need to filter through them to determine what is normal in your business/company. This is done by right clicking the event ID column and sorting the list, then grouping the list. This will put the events in order and then group them by Event ID. As you can see below, you are now able to see which events are used more often than others.

Now you have a process for determining what is the “normal” activity. You will want to add these to your blacklist. You have two layers of filters that your Windows logs have to go through now. This will leave you with the most unique event IDs that are occurring on a user's computer.

Lastly, you will need to set up your IDS to look through these remaining logs for signs of initial compromise -- this can be done manually by an analyst at first, who would then update the IDS on only items that are relevant.

One common sign of compromise are process names that made it through both of your filters because they are spelled wrong. This is used to hide malware without detection by the human eye. Below are some examples of misspelled process names compared to what they should look like:

Misspelled examples:

• scvhost.exe

• chromme.exe

• dlllhost.exe

Correctly spelled examples:

Isolating the Threat

All malware will require some type of containment/removal action. The main objective here is to stop the spread to other machines and prevent any damage done to the infected computer. There are several ways to contain a confirmed malware event:

User Containment

This is where either the user or a person from the security team will take action to isolate malware (physically remove it from the floor, power off, etc).

Automated Containment

This is your antivirus/antimalware solution or a security orchestration and automation solution like Komand. Many common strains will be detected and isolated automatically. But new malware may get by if antivirus is outdated or if the malware has not been discovered yet.

Loss of Service/Connectivity Containment

Either physically or digitally disconnecting the machine from the network.

Each approach has its pros and cons. Below is a great use case example that may apply to your situation:

• Malware is discovered on company machine by an automated alert from the IDS system.
• The security team was able to respond to the alert by resolving the IP address on the alert to the specific computer name and its location.
• Since the security team takes daily backups of the companies C:/ drives, they are not too concerned with loss of data. They digitally disconnect the machine from the network and then physically remove it from the floor for further analysis.
• In the meantime, the user of that infected machine is issued a temporary computer where the daily backup is uploaded so the employee can continue working without too much delay.

The above example was based off your IDS/SIEM finding a pre-filtered process that was determined to be malicious. For user reported findings, you will need to remember to manually update your IDS to find these as they were clearly being let through to the user.

As a security team, you need to internally determine what is the best method for isolating the machine based on the model above. NIST and SANS offer guides on best practices for malware incident response procedures.

For more security deep dives, check out a few of our other articles:

• Incident Investigation: It's All About Context
• Fine Tuning Your Intrusion Detection System to Minimize False Positives
• Early Warning Detectors Using AWS Access Keys as Honeytokens