The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics",
as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".

Thursday, March 12, 2009

Malware for Incident Responders - Examples

I thought that now would be a good time to take a step back and look at the malware characteristics that have been presented, and see how they can be used to understand malware so that such incidents can be prevented, detected, and better responded to, not only by first responders, but also by forensic analysts. During many malware incidents, you'll hear things like, "we cleaned the systems, but they keep getting infected", or "we don't know how the malware is infecting systems." My hope is that the characteristics will provide a framework that can be used to answer these, and other questions.

Initial Infection VectorOne thing we're always curious about is how the malware originally got on a system or into an infrastructure. Many times we see malware on a system and find out that it makes its way through the network like a worm, exploiting a vulnerability or a specific set of vulnerabilities. However, many times, these vulnerabilities are obviated at the perimeter, either by the fact that the ports are not accessible via the firewall, or the network is NAT'd behind the firewall, or something similar. So the question remains, how did the malware originally make its way into the network? Where is patient zero?

Initial infection vectors (IIVs) can come from a variety of sources. For example, a user opens an email attachment and either the worm kicks off or a downloader gets installed, which then reaches out and grabs the worm. Other IIVs can include the web browser, USB thumb drives, etc. Heck, even digital cameras can be the IIV for malware!

Propagation Mechanism(s)Propagation mechanisms are how the malware "gets around" and infects other systems once it's in your infrastructure. Some malware...worms, in particular...like to propagate by exploiting vulnerabilities on the network. Some worms use just one exploit, and others actually use multiple exploits, going with the one that works. This may also be the initial infection vector, or it may be how the malware propagates once it's on your network.

Very often, malware will exploit operational business functionality in order to propagate. From the exploit example, worms will not only exploit vulnerabilities, but also exploit the operational business functionality of not patching systems in a timely manner. A lot of malware currently exploits the operational business functionality of having all users run with Administrator privileges. The release of Conficker has seen a move to exploit file sharing; by placing a copy of the malware at the root of a share, and adding an autorun.inf file, the malware exploits the operational business functionality of file servers (as well as the fact that MS dropped the ball with respect to the NoDriveTypeAutorun Registry setting).

Persistence Mechanism(s)Persistence mechanisms are those artifacts that allow malware to survive a reboot. Jesse Kornblum's "Rootkit Paradox" paper points out that rootkits (a form of malware) wants to remain hidden from view but at the same time, it wants to run; extending that paradox just a bit, something similar can be said for most malware...it wants to run, but in most cases it also wants to remain persistent across reboots. As such, there are a finite number of ways that malware (any software, really) can do this on Windows systems. Most of us are familiar with some of the persistence mechanisms in the Registry, in particular the ubiquitous "Run" key.

Another popular means of ensuring persistence is to load the malware as a Windows Service, or in the case of kernel-mode rootkits, as a device driver (*.sys file). This can be further extended by not only loading the malware as a service, but loading it as a DLL under the Svchost service. Doing so has the effect of loading the malware and hiding it in plain sight; by that, I mean that if a responder lists the running processes, either through Task Manager or some other tool, the malware won't be readily visible, as its running as part of another service.

A variant of this persistence mechanism that I've personally seen in the field is to install two services...one that's the actual malware, and another that checks to make sure that the malware is running after the system has been rebooted. I assisted a customer with a situation like this where they had identified one persistence mechanism, "cleaned" the system by removing the key and the files, and then rebooted...only to have the malware return. Identifying the other service allowed us to finally clean the systems.

Yet another persistence mechanism is to use Scheduled Tasks, also referred to as "AT jobs". Conficker is a recent example of malware that uses this persistence mechanism...the responder users an AV vendor's tool to remove the malware file itself, as well as any Registry keys, but shortly after the malware is removed, it's back again!

ArtifactsArtifacts differ from persistence mechanisms in that they are both essentially artifacts, but persistence mechanisms allow the malware to survive reboots and remain...well...persistent. Many times, malware will leave artifacts or "footprints" of its presence, either by design or simply by its interaction with the system. For example, some malware modifies the hosts file; this isn't a persistence mechanism, but it is a modification that the malware is designed to do. Some malware does this so that processes on the system that need to make network connections...AV updates, for example...don't succefully resolve the domains that they intend to for updates, etc.

Other artifacts can include disabled or even deleted security applications and services, as well as modifications to the Windows Firewall to register the malware as an exception to the firewall rules, allowing it to communicate to the Internet.

Artifacts are not limited to host systems (ie, Registry entries, files created or modified, log file entries, etc.); artifacts can also be found in network traffic, or in log files on other systems or devices. For example, one of the big things I've seen in a number of malware write-ups is malware's "phone home" capability, reaching out either to an IRC server or requesting a URL so that the infected systems are logged in the web server logs. Many AV companies are listing the various URLs, and malware authors have been randomizing the domain selection, making it a full time job to develop and maintain blacklists on firewalls and web proxies. However, the point is that while these URLs or IP addresses do change, they are transient artifacts that are found in the network connections on the system, as well as in network traffic.

The examples I've provided are not a complete list by any means. However, they are meant to illustrate a framework which can be used to understand and address malware from several perspectives, including initial triage of an incident, on-site or first response to a known or as-yet-unidentified malware incident, or forensic analysis following an incident. Once the framework is in-place, there are a number of resources that can be used to fill in the gaps, if you will: vendor-provided analysis, static/dynamic analysis of the malware itself, or analysis of captured network traffic and log data.

2 comments:

Anonymous
said...

I think this is a really good general dissection of malware, and a good way to break the subject down and make it understandable to an audience to whom it may not be very familiar. Im currently in the process of writing Incident Response procedure for the office here and this has given me a new way of looking at the subject which I can translate to the document to help make it understandable to others.

A few comments:

While the vast majority of malware will have persistence mechanisms there are a few examples that don't (SQL Slammer is one). So only looking for signs of a persistent threat (by checking the finite list of Windows startup locations for example) could result in you missing a piece of malware on a system.

In some cases the Initial Infection Vector and the Propogation mechanism could be describing the same bit of malware functionality. For example, in the case of worms, they initially infect a system by a network service being exploited by an already infected host, and they propagate by .... scanning other hosts and exploiting a network service. Of course there are many examples (as you've noted) where these vectors are different.

Good point about the persistence mechanism for SQL Slammer, but it's not about having to have something to fill in that blank. The persistence mechanism will be a subset of the overall artifacts.

In some cases the Initial Infection Vector and the Propogation mechanism could be describing the same bit of malware functionality.

Exactly! This isn't about having different information to fill in all the blanks...some will overlap. It's about having a way to think about malware in the context of the systems and an environment it infects, leading into the business environment that it disrupts.