End-users and Root Cause:
Incident Response comes in many forms. One of the more common problems that are experienced by an organization is malware intrusions coupled with the use of unauthorized software by their employees. When an organization employs an anti-malware solution such as a combination of anti-virus, anti-spyware, and host-based firewall technologies, the response to malware infections might seem simple. But just catching and quarantining the malware or uninstalling and deleting unauthorized software is usually not addressing the “root cause” of the problem. Root cause usually leads back to user behavior. This behavior may or may not be malicious or contrary to company acceptable use policies. It is the “may or may not” that has to be investigated, determined, and documented. If it is determined that the root cause points back to user behavior, then having enough evidence to reconstruct the moments leading up to an infection are critical to helping an individual understand the consequences of their actions and will provide supervisors the information they need to help provide additional guidance, counsel, or release the individual from employment.
Most people will be honest about their behavior, but there is also the occurrence of individuals who will adamantly deny their responsibility and the results of their actions. An individual can deny only so long as the evidence of their activity is not presented to them by their supervisors. To gather this information an incident response team has to be prepared on several levels. First, the incident response team has to be aware of the consequences of any actions they take during a response to an incident. Shutting down, turning on, malware scanning, logging on, and any number of responses are affecting the system in real time. As David Nardoni of First Response Consulting Services, Inc. points out in his presentation Digital Evidence & Computer Forensics, “Anti-virus programs change date/time stamps of every file they scan.” If the incident response team feels that there is potential for an escalated investigation then they need to either initiate the associated procedures for offline forensic investigations or contact a local third party organization that can perform the action as a service. Should the team decide that a full blown forensic investigation is not necessary they should still take into consideration that fact that they want to limit the amount of disruption to the system as possible. This can be accomplished by scripting as many information gathering actions as possible to ensure that the disruptions to the system can be traced back to the information gathering scripts and so that the actions are repeatable across systems.
Forced Investigative Limitations:
Unfortunately for some incident response teams responding to incidents is not very easy. There are plenty of organizations out there that only allow approved or commercial software within their environments. This means that the incident response teams must rely on the tools provided by the operating environment and any administrative tools that have been acquired and approved. Ed Skoudis recognized this dilemma and initiated a competition within his company to determine how is fellow employees would respond to malware outbreak with only Microsoft system resources at their disposal. The results of this competition were the famous Internet Storm Center diary entry Windows Command-Line Kung Fu with WMIC and the Skillz Spinal Hack challenge at The Ethical Hacker Network. Of course, these were responses to live malware and not necessarily evidence collection. The concept and methodology, however, can be employed to assist with a scripted information gathering response.
To help incident response teams gather information from a Windows environment I have generated a script that will gather some important system and user information. Specifically, the script gathers information from Microsoft Windows XP and 2003 Server systems because these operating systems are current, widely deployed, what I am currently focused on, and they also contain the Windows Management Instrumentation (WMI). WMI can be used to gather information from the command line, via scripting languages like VBScripting, JScript, Perl, or Python, or through the use of the Scriptomatic tool. WMI is very robust and can be used during incident responses to augment other tools or, as in this case, as the only response mechanism.
What To Script:
As with any type of programming it was necessary to identify certain requirements. These requirements focused on the types of information to be gathered, where that information is located, and how that information is to be output and stored. The following list will cover some, but not all, of the information from a system that are interesting and useful when trying to determine what happened during and incident and to ultimately determine the root cause of the situation. As with anything it can be argued that more information can be gathered by any number of tools that will be more through and easier to use. But the requirements for this scenario are also limited due to the policies that apply to the situation which limits tools to those provided by the operating system resources.
- User Account Information – information about a particular user is important. Of course, that is if you know which user is responsible for a particular action. In some cases it is useful to obtain information about all users. Information to gather about a user account on a Windows system includes:
- Account Name
- Full Name
- Security Identifier (SID) – there will be several default system accounts on each system. Microsoft Windows follows a naming convention for these and user accounts. Information about the SID naming convention can be found in the Microsoft Help and Support article Well-known security identifiers in Windows operating systems.
- Domain – although Domain information is important the script provided does not traverse or query any Domain level information. Contact your Domain Administrator for this information or add it in yourself.
- LocalAccount – the script provided in this article focuses on local accounts only. Contact your Domain Administrator for this information or add it in yourself.
- System Information – documenting system information is very important. In large organizations with hundreds or thousands of workstations it is very easy to get a location, host name, or an IP address mixed up. This will lead to gathering information from the wrong system and about the wrong local users. Linking the gathered information back to a particular system at a particular time is also very important. Information to gather about a Windows system includes:
- Hostname
- Manufacturer
- Operating System Type
- Operating System Version
- Operating System Service Pack Level
- Available Network Adapters and their configuration
- System Time
- PreFetch File Information – Windows operating systems maintains a folder of metadata about the last 128 programs that were executed on the system. This information is a good indication of the recent activity on a system. Although the script provided here will only gather information about the file itself, such as name and various time stamps, collected the files themselves could provide additional information about the user who executed the file and where the file was located, a thumb drive for example, when it was executed. Because of the constraints, analysis of these file will have to occur offline files and will require a third party tool to extract the interesting information. Harlan Carvey provides information about this in his book Windows Forensic Analysis and on his blog Windows Incident Response. It is important to note, this script will add at least two entries, depending on the options selected, to the PreFetch File list and could potentially knock two files off the list. It is also interesting to note that a file will be generated by any programs run of a
- Installed Software – It is important to know what has been installed on an Operating System. Although a specific incident may have included responding to a piece of malware or an unauthorized piece of software, the initial detail of an incident may only be the tip of the iceberg. Obtaining a list of all installed software will provide insight into what has been occurring on a system over a period of time. Software may point to vulnerabilities, malicious intent, or just plain old disregard for policy and authority. Information to gather about installed software includes:
- Software Name
- Installation Date
- Version
- Installation Location
- Windows Setup Log – My investigation into this type of incident response started with determining whether or not a user started a program off a
- USBSTOR Registry Key – The Forensics Wiki Howto USB History Viewing also pointed to the information captured in the USBSTOR registry key. This information is very important as it often, but not always, points back to some unique information that can help identify a storage media such as a
- Windows Firewall Exception List – Knowing how the firewall is configured is a very good thing. Also, knowing if a piece of malware, program, or user has modified these settings is also very interesting. Want to know why? Well, just read the Bypassing Windows Firewall post at governmentsecurity.org and I’m sure you will begin to understand.
- Log On and Off Events – Knowing when and where a user has been can be very helpful during interviews and conduct evaluations. I am willing to bet there is more than one instance out there of users who have adamantly denied accessing a system until they were presented with the Windows Event entry that showed when and where they accessed a system. The Windows Security Event log, if configured correctly, contains information pertaining to local and network user logins and local user logoffs.
- Event Logs – All kinds of information can be found in Windows Event logs. Obtaining and storing these logs may be very important for future analysis. The one good thing about saving the logs in their natural state is that the log can always be opened by the Windows Event Viewer and exported into a text or common-separated values (csv) file for sorting and pattern matching. But a text or csv file cannot be imported back into the format required by the Windows Event Viewer.
- Temporary Internet Information – A user’s temporary Internet files are a wealth of information. These files contain a running documentary of the sites a user visited, knowingly or unknowingly, while connecting to online services through Internet Explorer. So much information is collected that some people believe it is a breach of privacy to review these files. This, of course, all depends on the usability and privacy policies of the organization. In most companies the resource is owned by the company and any information stored on the computer is the property of the company and not the user. However, a quick review of the company’s policies should clear up and doubt one way or another. If the information can be collected there are several things to take into consideration. First is that these files are not stored like other files within the Windows operating system. A user’s Internet cache and history information are stored in separate index.dat files which are a “proprietary Microsoft file” format. The only way to successfully and quickly evaluate these files is to view them on the local system through the Windows Explorer window (time to take some screen shots which will add Microsoft Paint to your PreFetch files) or via a third party tool such as
- C:\Documents and Settings\<user>\Local Settings\Temporary Internet Files
- C:\Documents and Settings\<user>\Local Settings\History\History.IE5\
- C:\Documents and Settings\<user>\Cookies
- Running Processes – It is very important to know which services and programs are running on a system. Programs running in the background are not visible by the user even if that account is an administrator. Although the output of this command might show some of the programs and scripts run by the incident response team, these programs will be readily identifiable through the script documentation and code review. A list of important information to gather pertaining to each process includes:
- Process Name
- Command Line Options
- Process Identification (PID)
- Active Network Connections – Knowing which programs are running is interesting, but knowing which programs are running and are connected to remote systems or awaiting a connection are even more interesting and concerning. A properly run netstat command will list the connected, listening, or waiting network connections in addition to the PID associated with the process that is causing the network activity. The command used to accomplish this feat is netstat –ano.
- Anti-malware Logs – Up until this point all of the information gathered from the operating system have been very standardized. The anti-malware log files, however, will not prove to be as easily located. Each location will be vendor specific. In the script I have created a place holder for a function that will collect this information, but the function has been disabled. This function will have to be modified to match the local configuration and environment and then activated in order for it to properly copy anti-malware logs.
The Script:
Windows Resources Incident Response Script
First bug goes to Christian of un-excogitate.org. Thank you, Christian, I have updated the script and linked to the most recent version. Christian’s prize is a link on my Blogroll. Not very exciting but something.
Summary:
As I stated in the Windows Setup Log item, this effort originally began when I started investigating programs run off of USB Thumb Drives and other removable media. This effort was necessary because Windows event logging does not provide enough information to accurately determine what happened on the system, when it happened, and through which user account it was initiated. Determining these important bits of information is necessary to accurately determine the root cause of an event. To do this incident responders are required to think outside the box by using third party tools or developing their own. In the case that I have presented here the only option is the development of tools or scripts to locate and gather specific information. This means that the script I have created here could not be used in such a scenario. Of course, this was not my intent. If you and your team are able to use third party tools I would suggest locating, acquiring, testing, practicing, and implementing any number of third party tools that will gather all of this information and more in a quicker, more efficient manner with more informative and better structured output. However, the intent of this script was to firstly teach myself the tools and techniques provided by Windows operating systems. I am merely making this script public so that people who wish to follow this path will have a resource to which they can refer. I have placed many of the links that helped me investigate the information to be gathered and how to gather it in the script, in this article, and as list of references at the end. Hopefully I have commented the code enough so that it is helpful as well.
Acknowledgment:
I would like to thank Harlan Carvey of the Windows Incident Response blog and the author of Windows Forensic Analysis as he provided me with some good information and pointed me in the right direction. Not all of what he shared with me ended up here, but it is either in his blog or in his book so please pay one, or both, of them a visit.
Resources:
Windows Management Instrumentation
Windows Command-Line Kung Fu with WMIC
The Grammar of WMIC
Forensic Analysis of Internet Explorer Activity Files
Scriptomatic 2.0
XCOPY
Live Forensics on a Windows System: Using Windows Forensic Toolchest (WFT)
Digital Evidence & Computer Forensics
Computer Forensics Companies
Internet Storm Center
Skillz H@ck1ng Challenge Example 2: Spinal Hack
Microsoft TechNet Script Center
Microsoft Help and Support Well-known security identifiers in Windows operating systems
Windows Forensic Analysis
Windows Incident Response Blog
Forensics Wiki Howto: USB History Viewing
Bypassing Windows Firewall
Pasco - An Internet Explorer Activity Forensic Analysis Tool
Pasco v1.0
EnumKey Method of the StdRegProv Class
WMI Tasks: Registry
EnumValues Method of the StdRegProv Class
GetDWORDValue Method of the StdRegProv Class
WMI Registry Classes
Introduction to WMI WScript.Echo Technique
List All the Files in a Folder
Forensic Analysis of the Windows Registry Abstract
WMI Tasks: Event Logs
Backup Event Log With Time Syncronization… ( Vbscript )
How Can I Get a List of All My Internet Cookies?
List Local User Accounts Using WMI
List All Installed Software
Copy a Set of Files
Copy a Folder Using WMI
Live Forensics on a Windows System: Using Windows Forensic Toolchest(WFT)
The UserAssist utility
VBScript Rot13
Move Computer to another OU in AD based on IP address
How Can I Determine the System Time on a Computer?
Contents for Ezine 80 - ComSpec and CMD