Incident Response Steps: Potentially Compromised Windows System


In this article

This Incident Response Cheat Sheet is for performing live analysis on a system you suspect is compromised. It is important to follow through each step in sequence as you handle an incident.

Step 1: Preparation

The more you know about the system in its normal state, the more chances you have to detect any fraudulent activity originating from the system.

Top

Step 2: Identification

We highly recommend the SysInternals suite of tools to help with investigating a system, especially Process Explorer and TCPView. SysInternals is available for download at https://docs.microsoft.com/en-us/sysinternals/

Unusual accounts

Unusual files

Unusual registry entries

Unusual processes and services

Unusual network  services running

Unusual network activity

Check startup folders of user accounts

Check for unusual automated tasks

Check for unusual log entries

If you are using Splunk:

Check for Rootkits

Check for Malware

Run at least one anti-virus product on the whole disk. If possible use several anti-virus products. The anti-virus must absolutely be up-to-date.

Top

Step 3: Containment

Determine, by questioning the owner of the system, what other systems they have access to or have logged into.
NOTE: Any user who accessed the compromised machine during the time it was compromised should change their passphrase IMMEDIATELY. 

Determine if the system contains sensitive data such as Social Security Numbers or credit card numbers by reviewing your asset inventory or interviewing the users of the system. If the system stored sensitive data, contact the Division of IT Security Operations Center immediately at soc@umd.edu or 301-226-4225.

Choose one of the following options to proceed, taking into account the criticality of the compromised system:

Option 1 - For critical systems that CANNOT be disconnected from the network

If the machine is considered critical for your department/unit’s business activity and CANNOT be disconnected from the network:

Option 2 - For non-critical systems that CAN be disconnected from the network

If the machine is not critical for department/unit’s business activity and CAN be disconnected from the network:

OR

Top

Step 4: Eradication

Top

Step 5: Recovery

Top

StepP 6: Lessons learned

A report should be written and made available discussing the following themes.

Ensure that all parties involved in the incident handling process agree to what is written in the report. If someone strongly disagrees, they should write their own report to document the incident from their point of view.

The report(s) should be reviewed by the team and potentially upper management and discussed in a meeting held within two weeks of resuming production.

Top