Incident Response Scripts
This document will highlight the tools that have been created for administrators or business owners to run in order to discern whether or not a system or group of systems within their environment have been affected by a breach or, malware. Please be advised that if you do not have an active incident response license we will not assist with any theoretical or actual breaches. Should you require our services please create an inquiry Incident Response Request Form and fill out our authority to assist document(s) before we can assist.
Microsoft Windows Operating Systems
Before running any of the tools within the zip file from the incident response page please be sure that your operating system has powershell installed and is the latest version. If powershell IS NOT the latest version, please DO NOT make any additional changes to the system. You will find a number of files within the windows directory once the archive has been unpacked. The files you should find are as follows:
| File / Script | Purpose | Execution Stage |
| winir.ps1 | Stats the initial investigation and executes the rest of the applications / scripts within the directory. This is the first script or application you should run from within this directory. Failure to do so will provide improper reporting. | First Script/Application that is to be run |
| irbrowser.exe | Binary application that is run AFTER the initial triage has been completed. This will read segments of windows that the powershell information will not read/access. | Must be manually run |
Please be advised you will need to execute the primary script as administrator, failure to do so will limit the view and depth of the investigation. After the investigation is complete. Once the scripts have been run successfully you will see a collection of log files that can be further scrutinized in order to determine if the system has been affected by an incident.
Ideally if your environment is logging information from Windows (object access, failures, successes, etc.) information from the event viewer will also be pulled and sampled. If you are not logging (policy review will be necessary at this point) the information generated will have no impact on the investigation. Below we have collected some interesting Windows ID's from the event viewer which should be scanned for if in the event you suspect an incident. If any of these ID's are found, a deeper look or logging into the system(s) affected will be warranted.
| Windows ID | Description |
| 4720 | User Password Change |
| 4722 | Enabling of a new account |
| 4724 | User password reset |
| 4728 | User account assigned to administrators group |
| 4624 | Successful logon to our system(s) |
| 4634 | Logoff activity of the account(s) |
| 4625 | Failed login attempts |
| 4672 | Normal user authentication with high / highest privileges |
| 4733 | Member or user removed from a security group |
| NULL SID / s-1-5-7 | Exploit or null session (legacy) |
| 4688 | A new process has been created (think malware or exploit) |
| 7045 | New service was installed on the system (potential malware/rootkit) |
| 4698 | A scheduled task was created (call home, malware execution, etc.) |
| 4731 | A security-enabled local group was created |
| 4732 | A member was added to a security-enabled local group |
| 4733 | A member was removed from a security-enabled local group |
| 4734 | A security enabled group was deleted |
| 1000 | Malware scan was started |
| 1001 | malware scan finished |
| 1002 | malware scan stopped (Cancelled) |
| 1005 | malware scan terminated due to error |
| 1006 | malware scan detected malware |
| 1008 | malware removal failed |
| 1010 | malware scan could not restore a file (quarantine) |
| 1115, 1116 | malware detection |
| 1117 | malware remediation action taken |
| 1119 | malware remediation error |
| 2001 | failed to update signatures |
| 2003 | failed to update engine |
| 2004 | reverting to last known good malware signatures |
| 3002 | real-time protection failed |
| 4723 | Attempt was made to change account password |
| 4725 | A user account was disabled |
| 4726 | A user account was deleted |
| 4738 | A user account was changed |
| 4781 | The name of an account was changed |
Additionally there will be a collection of registry locations that are exported in order to discern if malware has written to the system for persistency. These logs will need to be evaluated along with the binaries or scripts in which are being called to execute at those run times. Furthermore a collection of hashes from various locations within the system (where malware may begin it's entry point) will be included. You can submit those or investigate them on your own as links and hashes are generated for ease of use.
A snapshot of the systems network communications is also collected along with the executing application, communicating port and IP address. This is very important during an investigation and can help potentially link multiple systems that have been compromised. If you notice any of the suspicious activity in which was highlighted in the above (ID's or hashes that are malicious) the system needs to be further investigated. You can send the reports to us if in the event you have purchased Incident Response coverage from us.
Please note the incident response binary application (.EXE) will make writes/reads to the file system especially for the browser cache; especially if the browser is open and active! The application will in fact pull IPv4 and URL's that the system had visited.
Reading Edge webcachev01.dat: when you are attempting to read the history from edge, you will be required to make some changes to the system with esentutl.exe, you will need to navigate to the directory in which you are running the incident response / triage scripts from and issue the following command(s):
cd <location-of-report>920192390129
esentutl.exe /y C:\users\<USERNAME>\appdata\local\microsoft\windows\webcache\webcachev01.dat /vssrec V01 . \920192390129\<USERNAME>\ie\webcachev01.datPlease note the, 920192390129 is the ticket number generated for the incident and the <USERNAME> is the local user name of the system. Once this has been completed you can proceed to clicking on the "OK" on the prompt in order to begin reading the cache file. After which you may choose to include or delete the file after it is processed.
Linux Operating Systems
The Linux incident response scripts heavily differ from their windows operating system counterparts in one way. Most of the tools that will be running on the system will already be present on the box. However, this should be taken with a grain of salt! If in the event that the system has been compromised with a rootkit you will need to run the scripts and tools in a different and more secure manor! Rootkit detection is well beyond and outside the scope of this documentation and knowledge article however, if you feel the system has been affected by a rootkit we strongly urge you to file a report and fill out an authority to assist! With that out of the way, we will state that you need to be root in order to run the scripts.
The scripts will capture running applications, user names, firewall information (if any) system name, IP and network information as well as common paths where malware may have written to. In addition to each segment; the linux I.R. scripts will time-stamp all the events it is currently performing before it executes them. For instance, if we are attempting to obtain the list of running applications before ps aux us run, a date and time function will be called.
Before you can run the script, you need to switch into a terminal, become root and issue the ./ir.sh script once the script is executed you will receive feedback within the terminal letting you know at which stage the script is currently executing (network, filesystem, memory, etc.) Once the script is run the details of the collected system artifacts will be packed in a tar.gz file with a text file and multiple hashes demonstrating that they shouldn't have been altered if you plan alter the files, please let us know if they are being submitted for review! If you run into any issues or problems, please submit a trouble ticket through this service: Incident Response Trouble Ticket
This script should generate a listing of useful information for you to utilize during a breach investigation such as (but not limited to):
1) Users on the system from the /home directory along with hashes of all objects (desktop, documents, downloads)
2) Bash history, .ssh key information and connections, network connections
3) Running processes
4) Listing of users within the /etc/passwd file
5) Files created within the last 30 days
6) Files with more permissions than they should have
MacOS / OS X Operating Systems
Similar to their Linux counterparts (although MacOS / OS X are Unix systems) the incident response procedures for these systems remains somewhat relatively the same. One you unpack the files navigate to the macos_osx directory and chmod 755 the ir.sh file and run it with the ./ir.sh command. Please note that with any of these scripts you will need to be running as root before you execute the script. Failure to do so will provide inaccurate information and reporting. Once the script has been completed you should have a segment with the following details:
1) Directory structure of each user, and the users hash files
2) Each users history and ssh information
3) listing of running processes and Kext information
4) Network information (netstat, local computer name, etc.)
5) List of all open files
6) File system objects that have been created within the last 30 days (hashes)
7) List of users within the /etc/ password file.
Reporting an Incident Event:
Should you have an incident response contract with us, or you are seeking additional information regarding an event you can forward information within the incident response form found here: Incident Response Form.
If in the event an incident is lasting for some time (more than 2 weeks) your policies should include a BCDR event and clean up. If you do not have a clear Business Continuity / Disaster Recovery plan we strongly urge you to formulate one. For more information about this and any other policies you may fill out the following request form: