Sooner or later, everyone has to deal with a device that has been compromised, or there is a strong reason to believe that it has been compromised. Incident response is just as important as the security design of the network architecture, the regular security assessment tests, and the secure coding.
We will not try to cover the stages of the Incident Response process though; there is extensive documentation about this on the Internet. Rather, what we will try here is to summarize what information we need to collect from the supposedly compromised machine for analysis.
This post will detail the artifacts we will need to investigate a hacked Windows machine. It is based on a script we created with my colleague kolad85 (at) gmail.com. Initially, it started as a batch script that includes some sysinternals and UNIX tools, compiled as a single EXE file. Later, it was rewritten using AutoIT with a GUI. The script is executed on a supposedly compromised machine and collects volatile and non-volatile incident response data.
If we have to categorize the sources of the information, we can divide them in two broad categories: network level and host level. Basically, this means that for a successful investigation, we will need to have data both from the compromised machine and the network devices that may have been placed around it: firewalls, proxy servers, IDS/IPS.
Do not forget the most important rule, which is neglected much to often: all the information you collect, should be converted in one and the same time zone.
In many cases, you would have a hardware firewall device in front of the machine and another firewall on the machine itself. The same goes for the IDS – you can have NIDS/NIPS, and HIDS/HIPS. The information that falls in this category is the information that would be collected from devices, other than the machine itself.
There is no need to explain why it is important to collect information from the network perimeter.
If there is a firewall appliance in front of the supposedly compromised machine, it should be configured to log traffic coming from and to the Internet. Should a security incident occur, these logs would be useful to extract and analyze the information about the network flow between the attacking machine and any C&C centers and the victim.
While the main function of the network intrusion detection and prevention systems is to detect and prevent network attacks, its real strength is the ability to save the data in PCAP format. The device should be configured to log at least the data that triggered the alert, but, if possible, it is preferable to configure it to save all traffic for a period of time that depends on the respective infrastructure.
Environments are often configured to route outgoing traffic through a proxy server. The proxy logs can help identify traffic from the internal network to command and control centers, data exfiltration attempts, attacks against other external networks.
To distribute the server load on more than one server, in many cases organizations place load balancing devices in front of critical resources. It is essential that these devices are configured to forward the source IP address of the request to the destination. Otherwise, the IP address that will appear in the logs on the servers will be the IP address of the load balancer.
The most valuable information can be gathered from the host itself. Even the stealthiest of attackers can leave traces of their activity on the compromised machine. A skilled incident respond or forensic specialist will be able to find those traces if they have images of the disk(s) and the memory of the machine.
However, in cases, where imaging is not possible, the following information will ensure that there is enough data to determine if the machine is compromised. Of course, collecting the information below will change the current state of the machine, i.e. it is not forensically sound. The person, collecting the information, an the analyst should be aware of that. Also, they should document thoroughly who, what, when, why, and how the information was obtained and compiled.
Whenever possible, a memory dump should be made. Everything you execute is loaded into the memory; the whole registry is loaded in the memory; password hashes are loaded in the memory; network connections, services, processes, you name it.
With the help of volatility, you can extract a whole bunch of information for incident response and forensic analysis. Volatility is able to work with both Windows and Linux memory dumps and supports 32-bit and 64-bit architectures.
The logs are the best friend of every incident response and forensic specialist. The more of them you have, the better.
In a suspected compromise of a Windows box, it is essential to get the event logs. These are the security logs, application logs and logs from other facilities that are configured to keep event logs. If the machine is in an Active Directory, the security logs from the Domain Controllers should also be collected.
The event logs can be parsed and analyzed with LogParser.
Often, the AV software would detect malicious software, and this would show in the AV logs.
It is quite common for attackers to use scheduled tasks to leverage their privileges or to delay execution of certain payloads. The Schedlgu.txt file can contain valuable information in such cases.
The logs from the host intrusion detection or prevention systems will help identify events caught by the IDS/IPS.
With the shift towards client-side attacks, the browser history is a very important artifact for the incident response and forensic specialist. The NirSoft BrowsingHistoryView tool is able to collect the history of all major browsers. The added bonus is that it includes the history of all user profiles.
Another NirSoft tool – LastActivityView – allows you to collect a timeline of user activities. Unfortunately, it works only for the currently logged on user. Still, it produces a pretty good report of the user actions.
USB Device History
There are cases, where the compromise might have come from a USB device. Another useful NirSoft tool can list the USB devices that have been attached to the machine.
In most cases, attackers or malware would change aspects of the configuration of the machine. To keep their access, they would need persistent presence – a service or a software that executs on startup.
A change in the hosts file that instruct the machine to resolve legitimate services to to malicious IP addresses is a definite sign of a compromise.
The systeminfo command provides security information, information about the operating system configuration, and information about the hardware of the machine.
The Autoruns utility from Windows sysinternals is an extremely powerful tool, which shows programs and services that run automatically at startup or logon. If there is a backdoor on the system that executes on startup, it would be displayed by this utility. The command-line utlity is Autorunsc. However, it would only collect information about the user profile you are using to run the command. You can use wmic to get autoruns from other user profiles.
Up to now, except for the memory part, we have discussed only non-volatile data. But the volatile data is just as important, and it should be collected and reviewed thoroughly.
A listing of the currently running processes should be obtained. There are many ways to do this, but the pslist sysinternal is probably the best way to do this. It also allows you to show the processes in a ‘tree’ format
At least the following information should be collected:
* Currently opened ports: This can be done with `netstat -anbo`, but there is a better NirSoft Tool (CurrPorts) that produces a better output.
* DNS cache: The command `ipconfig /displaydns` will display the DNS cache, which can be useful to check for non-legitimate hosts.
* ARP table: The ARP table (arp -a) should be checked for suspicious entries.
* Routing table: The routing table (route print) has to be checked for irregularities.
The windows Prefetch folder contains files, previously executed on the box. The information in this folder can show what programs have been executed on the machine.
Unsigned DLL Files
The ListDLLs utility from Windows Internals can show all unsigned DLLs that are loaded into the processes. This is useful to spot any malicious DLLs.
Another Windows Sysinternal utility (handle -au) can be used to get all open handles (files, ports, registry keys, synchronization primitives, threads, and processes). The information will show the handle information for each process on the system.
MFT of Fixed Drives
The NTFS Master File Table is an extremely valuable source of information. It contains the metadata for all files and directories on the box. If you are creating a time-line, which you most certainly are, this information is a must.
The process of collecting the host data above can be scripted so that the output is compiled in an archived report, which can be easily transferred to the machine of the incident respond specialist. Then, the collected data can be used to compile a timeline of events and a picture of the configuration and the environment of the machine that will help spot malicious activity. This comes with a reminder that never gets old – all data with time stamps should be converted to the same timezone.
Of course, no two incidents are alike. Depending on the incident, you may need additional data or you may not have some of the data above, but this guideline is a good start.
What’s important is to be thorough and flexible.