A Comprehensive Overview of Malware Incident Response

Many organizations have a team dedicated to responding to cyberattacks. This team is commonly known as a computer security incident response team (CSIRT) or a cybersecurity incident response team.

The first step in responding to a malware incident is identification. This involves identifying the nature and scope of the threat.

Detection

The first step in any security incident response cycle is detection. Every adversary leaves footprints on networks that EDR or SIEM systems can capture — ports accessed, network addresses visited, high data transfers, and other anomalies are all indicators of an ongoing compromise.

A digital investigator can use these signals to search for and identify malware artifacts, such as the presence of distinctive libraries or packed files. Performing a risk analysis of the compromised host also helps investigators identify possible attack vectors, such as patch levels, password strength, and other weaknesses that could be exploited.

The goal of this stage is to find all the ways the threat made it into the organization and to understand its activity. This includes looking at logs from the affected system, such as firewall and proxy events, and searching for evidence in external intelligence sources, such as antivirus scanners. Attackers are increasingly sophisticated and can exploit low-hanging fruit such as unpatched vulnerabilities, ineffective MFA policies, and weak passwords. In some cases, attackers can even gain entry to a system via USB devices, such as the Stuxnet worm that attacked Iran’s nuclear facilities in 2010. During this phase, IR teams will review crash logs and look for evidence of programs that have crashed or exited unexpectedly. They may also investigate whether the malicious program created or changed files, accessed external resources, and communicated with C&C botnet servers.

Containment

The next phase of malware incident response is containment. This is a crucial step because it helps to limit the spread of a threat and protects the organization. Containment involves deploying pre-determined procedures for isolation at the network, host, account, and application levels. It also includes protocols for evidence gathering aligned to specific investigative needs. Finally, it sets processes for controlled reconnection of isolated assets to mitigate business disruption.

For example, the forensic review of an infected endpoint can include reviewing file permissions, comparing creation dates against log files, and searching for unusual scripts (using hash analysis to exclude known applications). It can also check the contents of directories such as /usr/bin and /sbin, looking for files that shouldn’t be present. This is often an excellent place to find malware binaries that the adversary has dropped since they can contain additional attack code or instructions.

The containment phase can help to detect new threats, and it is also an excellent time to update SEIMs and TIPs with the latest IOCs from malware analysis. This will allow them to provide more timely and higher-fidelity alerts that can aid teams in detecting similar attacks in the future. This is why it’s essential to use malware analysis solutions that enable extracting IOCs and feeding them into security orchestration platforms.

Eradication

Malware analysis directly affects the incident response cycle’s Identification, Containment, and Eradication phases. Additionally, it can play a role in the Lessons Learned and Recovery phases.

The identification phase identifies the threat, whether the malware is known by name (e.g., AV signatures), whether it is detected by the organization’s detection or prevention systems, and the likely impact within the environment. This also includes examination of logs from IPS/IDS and firewall systems and searches for indicators such as spoofed command-and-control IP addresses, network communications with remote locations, or siphoned infostealer cookies.

During containment, the organization may isolate the affected infrastructure by taking systems offline at the switch level and performing manual or automated removal processes. Alternatively, affected systems may be restored from trusted backups. If so, examining those backups for evidence of additional malware or symlinks lurking on the system is critical.

Eradication is the final step in ensuring all environmental threats are eliminated. Sometimes, this requires deleting all files from affected systems and reinstalling them from clean image backups. In other cases, following existing remediation protocols, such as resetting application credentials and invalidating session cookies stolen by infostealer malware, is necessary.

Recovery

Malware incidents can be complex. Depending on the nature of an infection, it can take days to fully understand what is happening and how it can be stopped. This is why it is essential to follow a systematic process to address incidents as they occur. The four steps of the incident response cycle – Identification, Containment, Eradication, and Recovery – are critical for the success of an organization’s malware incident response.

During the Identification phase, determine whether any affected systems or services are infected (or potentially infected). Validate all malware discoveries to ensure they are accurate and that you are aware of the full scope of the incident. Reset any credentials that may have been compromised during the attack while adhering to best practices for creating and managing new passwords.

Isolate any infected systems using the IoCs gathered during the Identification phase and ensure that all relevant observables are captured (e.g., sampled malware binaries, MAC addresses of proxies used for communication with threat actors). Take steps to prevent lateral movement by suspending the login credentials of compromised users. Consider submitting the sampled malware to the appropriate threat intelligence sources and Cyber Security Information Sharing Partnerships.

Secure artifacts, affected systems, and any other data deemed necessary by the CIRT Lead (in consultation with forensic support as required). Consider restoring impacted systems from clean backups taken before the infection (if possible) or rebuilding them using fresh builds first tested in an isolated environment. Document lessons learned and apply them to the organization’s cybersecurity policies, processes, procedures, and CIRP.