├── 0. FAQ └── README.md ├── 1. How to setup IR Toolkit? └── README.md ├── 2. Forensic Data Collection └── README.md ├── 3. Analyzing Forensic Data ├── AmCache │ └── README.md ├── Browser History Logs │ └── README.md ├── Convert EVTX to CSV │ └── README.md ├── Hayabusa │ └── README.md ├── LNK Files │ └── README.md ├── MFT │ └── README.md ├── Prefetch │ └── README.md ├── README.md ├── ShimCache │ └── README.md └── USN Journal │ └── README.md ├── 4. Malware Triage ├── README.md ├── Windows Defender │ └── README.md └── YARA │ └── README.md ├── 5. DFIR Tips and Tricks ├── CrashDump of a Process │ └── README.md ├── README.md ├── Windows Defender MpLogs │ ├── MpLogParser.ps1 │ └── README.md └── Windows Error Reporting │ ├── README.md │ └── WERParser.ps1 └── README.md /0. FAQ/README.md: -------------------------------------------------------------------------------- 1 | # Frequently Asked Questions 2 | 3 | - **Q:** I’ve received a high or critical severity alert in my EDR on a machine that I suspect is compromised. What should I do next? 4 | **A:** Run `CyLR.exe` (a forensic tool) via Live Response or another method to collect some forensic data. Once complete, ensure you retrieve the ZIP file containing this data. Afterward, you can proceed to isolate the server from the network. 5 | 6 | - **Q:** Antivirus solutions sometimes generate false positives. When should I take alerts more seriously during an investigation? 7 | **A:** Florian Roth created a helpful Antivirus Cheat Sheet that can assist professionals with initial triage. You can find it [here](https://www.nextron-systems.com/?s=antivirus). 8 | 9 | - **Q:** I’ve called in an Incident Response firm for help. What should I prepare to make the investigation go as smoothly as possible? 10 | **A:** Have a few team members with system access ready to collect the requested forensic data for the IR team. If you have an EDR solution, creating temporary accounts for the IR team to access it directly will also streamline the process. 11 | 12 | 13 | 14 | # Common mistake 15 | 16 | Imagine you’re a small or medium business with a limited budget for full-time staff. Then, on a Monday morning, you get an alert from your EDR solution about suspicious activity on your Exchange server. It looks like the attacker is actively moving within your environment, and the natural reaction is to quickly shut down the server to contain the attack. But this is where things can go wrong, shutting down the server at this point would mean losing valuable forensic data and possibly other critical information needed to understand the full extent of the attack. 17 | 18 | ![image](https://github.com/user-attachments/assets/028fc209-4aeb-4f07-86f9-cd381d78c153) 19 | 20 | 21 | --- 22 | 23 | ## Why do we need to collect forensic data? 24 | 25 | We need to collect forensic data before starting recovery because it captures important details about the attack and how it started, which systems were affected, and whether any data was taken. If we skip this step, we might lose evidence that shows the full picture, leaving us open to further attacks or missing the root cause. It also helps meet legal requirements and ensures we’re not just putting a temporary fix in place. 26 | 27 | --- 28 | 29 | ## Call an Incident Response firm 30 | 31 | Collecting forensic data is essential, as it supports the investigation during incident response. Even if you lack the resources to analyze thousands of systems, capturing data from the initial machine you suspect is compromised provides a starting point with valuable insights. From there, you can bring in IR professionals who specialize in full forensic analysis, helping you gain a broader picture of how the attack started, what systems were affected, and what actions the attacker took. This comprehensive view ensures a thorough response and helps address any vulnerabilities used in the attack. 32 | -------------------------------------------------------------------------------- /1. How to setup IR Toolkit?/README.md: -------------------------------------------------------------------------------- 1 | # How to Set Up an IR Toolkit 2 | 3 | This guide explains how to set up a virtual environment for your Incident Response (IR) toolkit using Hyper-V Manager and download the tools you’ll need for your investigations. 4 | 5 | --- 6 | 7 | ## Step 1: Setting Up a Virtual Machine in Hyper-V Manager 8 | 9 | ### Prerequisites 10 | 11 | - **Hyper-V Enabled**: Hyper-V needs to be enabled on your Windows system. You can enable it by going to: 12 | - **Control Panel** > **Programs** > **Turn Windows features on or off** > Check **Hyper-V** and **Virtual Machine Platform**. 13 | 14 | ### Creating a New Virtual Machine 15 | 16 | 1. **Open Hyper-V Manager**: 17 | - Press `Win + X` > Select **Hyper-V Manager**. 18 | 19 | 2. **Create a New Virtual Machine**: 20 | - In the **Actions** panel, select **New** > **Quick Create** > **Windows 10 MSIX packaging environment**. 21 | 22 | ![image](https://github.com/user-attachments/assets/79c578a2-ed1c-40ac-88a8-76607698ee60) 23 | 24 | 25 | 3. **Configure the VM Settings**: 26 | - **Name**: Give your VM a descriptive name (e.g., `IR-Toolkit-VM`). 27 | - **Generation**: Choose **Generation 1** for broad compatibility unless you need advanced features from **Generation 2**. 28 | - **Assign Memory**: Allocate at least **4 GB** of RAM for basic tasks. 29 | - **Configure Networking**: Select a network adapter if you need internet connectivity; otherwise, leave it disconnected for a secure, isolated environment. 30 | 31 | 4. **Configure Post-Installation Settings**: 32 | - Adjust **CPU and RAM** allocations based on your system’s resources and IR requirements. 33 | 34 | --- 35 | 36 | ## Step 2: Downloading and Installing Necessary Tools 37 | 38 | Once your VM is set up, you’ll want to install the core tools for your IR toolkit. Here’s a list of recommended tools and how to get them: 39 | 40 | ### Tool Installation Guide 41 | 42 | 1. **Forensics Tools**: 43 | - **CyLR**: https://github.com/orlikoski/CyLR/releases/tag/2.2.0 44 | 45 | 2. **Log Analysis**: 46 | - **LogParser**: https://www.microsoft.com/en-us/download/details.aspx?id=24659 47 | - **Eric Zimmerman tools**: https://ericzimmerman.github.io/#!index.md 48 | - **Hayabusa**: https://github.com/Yamato-Security/hayabusa/releases 49 | 50 | 3. **Malware Triage**: 51 | - **PE Studio**: https://www.winitor.com/download 52 | - **YARA**: https://github.com/virustotal/yara/releases 53 | - **Capa**: https://github.com/mandiant/capa/releases 54 | - **SysInternals:** https://learn.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite 55 | - **Loki YARA Scanner**: https://github.com/Neo23x0/Loki/releases 56 | - **Cobalt Strike Config Extractor**: https://blog.didierstevens.com/programs/cobalt-strike-tools/ 57 | 58 | 4. **Others** 59 | - **Python for Windows**: https://www.python.org/downloads/windows - Make sure to select "Add python.exe to PATH" 60 | - **SQL Lite Browser**: https://sqlitebrowser.org/dl/ 61 | - **TOR Browser**: https://www.torproject.org/download/ 62 | - **MemProcFS**: https://github.com/ufrisk/MemProcFS/releases/ 63 | - **Azure Data Explorer Cluster**: https://learn.microsoft.com/en-us/azure/data-explorer/start-for-free 64 | 65 | This VM is now ready to serve as your IR toolkit environment. Please make sure to create a snapshot of your VM once everything has been configured and installed. 66 | 67 | -------------------------------------------------------------------------------- /2. Forensic Data Collection/README.md: -------------------------------------------------------------------------------- 1 | # CyLR 2 | 3 | CyLR is a one-time, point-in-time data collection tool that runs as a single executable. It’s built to quickly gather key forensic artifacts from NTFS systems with minimal impact and doesn’t run continuously in the background. CyLR collects data without using the Windows API, making the process faster and more discreet. You can customize what it gathers, including in-use, hidden, and system files like alternate data streams. The data is saved in a ZIP file, with options to adjust compression, add a password, and send it to an SFTP location if needed. 4 | 5 | --- 6 | 7 | ## Compatibility 8 | 9 | CyLR is based on .NET Core and runs smoothly on Windows, Linux, and macOS, with standalone versions for each platform available from version 2.0 onward. 10 | 11 | ## How to run this tool? 12 | 13 | 1. Run the following command as an **Administrator**: 14 | 15 | ``` 16 | CyLR.exe --usnjrnl 17 | ``` 18 | 19 | The *--usnjrnl* option ensures that USN Journal artifacts are included in the collection. Without this option, USN Journal data will not be collected. 20 | 21 | ![image](https://github.com/user-attachments/assets/cc524d02-01a1-430d-a314-38e999164a0e) 22 | 23 | 2. After collecting all the data, CyLR generates a ZIP file in the same directory where CyLR.exe was run, with the computer name included in the file name by default. This ZIP file should then be shared with the incident response team for further analysis. 24 | 25 | ![image](https://github.com/user-attachments/assets/d071c488-4316-44c3-b679-18b522947e87) 26 | 27 | ## Forensic Metadata/Artifacts Collected by CyLR 28 | 29 | This provides a high-level overview of the forensic artifacts that CyLR currently collects: 30 | 31 | | Artifact | Artifact | 32 | | --------------------------------------- | --------------------------------------- | 33 | | Windows Event Logs | NTFS Update Sequence Number Journal ($UsnJrnl:$J) | 34 | | Windows Prefetch Files | Scheduled Tasks | 35 | | Windows Shortcut Files (.LNK, Jumplists, etc.) | AmCache | 36 | | Web Browser History | ShimCache (AppCompatCache) | 37 | | PowerShell Console History | Iconcache Database | 38 | | NTFS Master File Table ($MFT) | Activitiescache Database | 39 | 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/AmCache/README.md: -------------------------------------------------------------------------------- 1 | # AmCache 2 | 3 | AmCache is a Windows registry hive file that records detailed metadata about executables, drivers, and installed applications on a system. It includes information like SHA1 hashes, file paths, installation dates, and publisher details. While it cannot confirm program execution (because of automated OS scans that log files for compatibility checks), it provides evidence of file presence. AmCache is useful in DFIR for timeline creation, threat hunting, and correlating hashes with known malicious files. 4 | 5 | ![image](https://github.com/user-attachments/assets/28004575-8850-4000-ae4d-5c2f44a6bd4a) 6 | 7 | ## How to start 8 | 9 | 1. Use AppCompatCacheParser.exe to parse the AmCache.hve file into a CSV format, which can then be loaded into tools like Timeline Explorer. To do this, run the following command: 10 | 11 | ``` 12 | AmcacheParser.exe -f "E:\Windows\AppCompat\Programs\Amcache.hve" --csv C:\Temp 13 | ``` 14 | 15 | ![image](https://github.com/user-attachments/assets/a64856f0-5edb-480a-84bc-6dda61e4b252) 16 | 17 | 2. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 18 | 19 | ![image](https://github.com/user-attachments/assets/b3df5b67-636a-4297-b7e3-0be1b6a1fff1) 20 | 21 | 3. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. 22 | 23 | ![image](https://github.com/user-attachments/assets/beb252aa-98d3-43e8-9c18-5b4aa9eee380) 24 | 25 | A good thing to know is that the timestamp in the *"FileKeyLastWriteTimestamp"* column of AmCache represents the last time that the entry for the file in question was modified, which is not necessarily when the file was executed. 26 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/Browser History Logs/README.md: -------------------------------------------------------------------------------- 1 | # Browser History 2 | 3 | Browser history logs track the websites and web pages a user visits, along with details like URLs, timestamps, and sometimes additional metadata. In DFIR, these logs can be valuable for tracing user activity, identifying malicious websites, building timelines, and detecting potential data exfiltration attempts. The location of where these browser history logs are stored is the following: 4 | 5 | - **Google Chrome**: 6 | ``` 7 | C:\Users\{Username}\AppData\Local\Google\Chrome\User Data\Default\History 8 | ``` 9 | - **Microsoft Edge**: 10 | ``` 11 | C:\Users\{Username}\AppData\Local\Microsoft\Edge\User Data\Default\History 12 | ``` 13 | - **Mozilla Firefox**: 14 | ``` 15 | C:\Users\{Username}\AppData\Roaming\Mozilla\Firefox\Profiles\{ProfileFolder}\places.sqlite 16 | ``` 17 | 18 | ## How to start? 19 | 20 | We can use SQL Lite Browser to parse the browser history logs. SQLite Browser (also known as DB Browser for SQLite) is a free, open-source tool used to interact with SQLite databases. It provides an easy-to-use interface for viewing, editing, and querying SQLite databases without needing to know SQL commands in detail. 21 | 22 | 1. In my example, the Edge browser history logs happens to be stored at the following location: 23 | ``` 24 | C:\Users\Admin\Desktop\CyLR_win-x64\DESKTOP-9FOGEDE\C\Users\Admin\AppData\Local\Microsoft\Edge\User Data\Default 25 | ``` 26 | 27 | ![image](https://github.com/user-attachments/assets/ae10a1ed-beb0-4a2c-a75a-894e31f643e9) 28 | 29 | 2. Load the History file in SQL Lite Browser 30 | 31 | ![image](https://github.com/user-attachments/assets/612357fb-f04b-4efb-937a-a9b0f5960e44) 32 | 33 | 3. Click on ''urls'' and then Browse table 34 | 35 | ![image](https://github.com/user-attachments/assets/8d94deb6-c383-4368-bba2-152bdc0ed9c7) 36 | 37 | 4. We have now a list of URLs that were visited 38 | 39 | ![image](https://github.com/user-attachments/assets/d2d096bb-176e-4c2a-861e-05fa7fd20af0) 40 | 41 | However, the last_visit_time column isn't properly formatted in UTC, which is commonly expected in DFIR investigations. 42 | 43 | ![image](https://github.com/user-attachments/assets/0d143ab0-fa0f-4388-8c73-3fc2566fc229) 44 | 45 | 5. Click on View and then Execute SQL and run the following SQL Lite query: 46 | 47 | ``` 48 | SELECT 49 | url, 50 | title, 51 | visit_count, 52 | datetime((last_visit_time / 1000000) - 11644473600, 'unixepoch') AS last_visit_time_utc 53 | FROM urls; 54 | ``` 55 | 56 | ![image](https://github.com/user-attachments/assets/961c5f56-4c51-4c42-a221-fc1ee1ae3cf3) 57 | 58 | 59 | 60 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/Convert EVTX to CSV/README.md: -------------------------------------------------------------------------------- 1 | # EVTX 2 | 3 | 4 | EVTX files are Windows event log files that store records of system, application, and security events on the computer. They’re used by the Windows Event Viewer to display details about things like hardware changes, software activity, and login attempts. EVTX files are saved in **C:\Windows\System32\winevt\Logs** by default, and they’re useful for tracking what’s happening on a system whether for troubleshooting issues or investigating security events. 5 | 6 | ## How to start? 7 | 8 | 1. Use EvtxECmd.exe to parse the EVTX files into a CSV format, which can then be loaded into tools like Timeline Explorer. To do this, run the following command: 9 | 10 | ``` 11 | EvtxECmd.exe -f C:\Users\Admin\Desktop\DC\C\Windows\System32\winevt\Logs\Security.evtx --csv C:\Temp\DFIR 12 | ``` 13 | 14 | ![image](https://github.com/user-attachments/assets/25061fe7-a6d6-4e40-96ad-5bd2036fa703) 15 | 16 | 2. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 17 | 18 | ![image](https://github.com/user-attachments/assets/62d5edc0-068e-4745-86ba-68bca7c14042) 19 | 20 | 3. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. For EVTX files, this is typically recommended and it's much more efficient than searching in Timeline Explorer. 21 | 22 | ![image](https://github.com/user-attachments/assets/09b27e00-32c4-4773-831a-ea04cac2178e) 23 | 24 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/Hayabusa/README.md: -------------------------------------------------------------------------------- 1 | # Hayabusa 2 | 3 | **Hayabusa** is an open-source tool developed by Yamato Security that helps analyze Windows Event Logs. It was created to make detecting malicious activity or attacks easier by processing and searching through these logs for signs of suspicious behavior. 4 | 5 | One of the key features of Hayabusa is its use of Sigma rules, which are community-driven, generic detection rules for logs. Sigma provides a framework to define detection logic in a simple, readable format, which can then be applied across various log sources, including Windows Event Logs. Hayabusa translates these Sigma rules into queries that can search through the parsed event logs for patterns that match known attack techniques. 6 | 7 | 8 | --- 9 | 10 | ## How to start? 11 | 12 | 1. Start by extracting the ZIP file from the machine where you collected the forensic data. 13 | 14 | ![image](https://github.com/user-attachments/assets/c2df754d-9076-45eb-8335-7c8d7ff28c6e) 15 | 16 | 2. Run the following command to scan the evtx files with Hayabusa: 17 | 18 | ``` 19 | hayabusa-2.17.0-win-x64.exe csv-timeline -d C:\Users\Admin\Desktop\DC\C\Windows\System32\winevt\Logs -o DC.csv 20 | ``` 21 | 22 | ![image](https://github.com/user-attachments/assets/d0313e12-e7d0-4fa1-9c4b-fa6680cd2a6e) 23 | 24 | 3. You'll now be prompted to choose an option in the scan wizard. I recommend selecting option **5**, which includes all event and alert rules. 25 | 26 | ![image](https://github.com/user-attachments/assets/ba9c0ed3-440b-41b5-814c-27c7c1c53f7f) 27 | 28 | 4. Next, you'll be prompted to choose a set of detection rules to load, which may include deprecated, unsupported, or noisy rules, among others. Here’s what I selected in this example: 29 | 30 | ![image](https://github.com/user-attachments/assets/2cd1c64d-49ab-42d0-ac49-010c74dcec43) 31 | 32 | 5. When the scan finishes, you’ll see a summary of all triggered detections, each marked with a severity level: high, medium, low or informational. 33 | 34 | ![image](https://github.com/user-attachments/assets/e837a44b-a4e7-489e-b584-3d2065f535ac) 35 | 36 | 6. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output from Hayabusa and analyze the raw data. 37 | 38 | ![image](https://github.com/user-attachments/assets/0cd6f5c7-ab5b-40dd-836e-361319392772) 39 | 40 | 7. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. 41 | 42 | ![image](https://github.com/user-attachments/assets/fcd6ae7d-5310-4ba9-af7a-71f82e4ab555) 43 | 44 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/LNK Files/README.md: -------------------------------------------------------------------------------- 1 | # LNK Files 2 | 3 | LNK files (also known as shortcut files) are small files with the .lnk extension in Windows that point to other files, folders, or applications. These files store information like the path to the target file, timestamps (when the target was created, accessed, or modified), and details about the system or drive where the target file resides. They get created automatically when users create a shortcut, and sometimes even by the system itself (e.g., in "Recent Items"). 4 | 5 | ## How to start? 6 | 7 | 1. Use LECmd.exe to parse the .lnk file into a readable format, which can then be further examined. To do this, run the following command: 8 | 9 | ``` 10 | LECmd.exe -f C:\Users\xxxx\AppData\Roaming\Microsoft\Windows\Recent\Document1.lnk 11 | ``` 12 | 13 | ![image](https://github.com/user-attachments/assets/4c882451-e695-4ec6-8071-8232463eeab4) 14 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/MFT/README.md: -------------------------------------------------------------------------------- 1 | # Master File Table (MFT) 2 | 3 | The Master File Table (MFT) is a core component of the NTFS file system, which keeps track of all files and directories on a drive, including metadata such as file names, timestamps, and file sizes. In DFIR, analyzing the MFT helps investigators trace file activity and determine when files were created, modified, or accessed. This can provide valuable evidence during an investigation. 4 | 5 | ## How to start? 6 | 7 | 1. Use MFTECmd.exe to parse the $MFT file into a CSV format, which can then be loaded into tools like Timeline Explorer. To do this, run the following command: 8 | 9 | ``` 10 | MFTECmd.exe -f "C:\Users\Admin\Desktop\DC\C\$MFT" --csv C:\Temp\DFIR 11 | ``` 12 | 13 | ![image](https://github.com/user-attachments/assets/1005bb0b-7cb9-48e9-becb-3e1b7a73d408) 14 | 15 | 2. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 16 | 17 | ![image](https://github.com/user-attachments/assets/721a053a-4e56-4d90-b8b6-5e7dc27c807f) 18 | 19 | 3. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. 20 | 21 | ![image](https://github.com/user-attachments/assets/469883cf-9853-47ec-8d31-df0d1d0c9004) 22 | 23 | 24 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/Prefetch/README.md: -------------------------------------------------------------------------------- 1 | # Prefetch 2 | 3 | Prefetch is a Windows feature that optimizes the performance of frequently accessed applications by preloading portions of their files into memory. It stores information about the last 8 executions of an executable, including timestamps and file paths. These Prefetch files (.pf) are located in the **C:\Windows\Prefetch** directory and are created when a program is run. 4 | 5 | ## How to start? 6 | 7 | 1. Use PECmd.exe to parse the .PF file into a readable format, which can then be further examined. To do this, run the following command: 8 | 9 | ``` 10 | PECmd.exe -f "C:\Windows\Prefetch\LBB.EXE-368666EF.pf" 11 | ``` 12 | 13 | The information shows the last time the binary was executed. 14 | 15 | ![image](https://github.com/user-attachments/assets/644e5908-4e5f-4625-b18d-d4779e2b9eb4) 16 | 17 | 2. As you can see, LockBit 3.0 (LBB) was actively encrypting multiple files, clearly visible in the provided data. 18 | 19 | ![image](https://github.com/user-attachments/assets/1f9be41a-7bef-4aff-b024-2944c838ead6) 20 | 21 | 3. All folders where the ransomware is generating its ransom note 22 | 23 | ![image](https://github.com/user-attachments/assets/8afdb7c4-38a6-4f08-abdd-fbb3aa9b62cb) 24 | 25 | 26 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/README.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | This section explains how to parse and extract collected forensic data using Eric Zimmerman’s tools, and how to use Hayabusa with Sigma rules to scan Windows Event logs for indicators. 4 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/ShimCache/README.md: -------------------------------------------------------------------------------- 1 | # ShimCache 2 | 3 | ShimCache, also known as the AppCompatCache, is a feature of Windows that records information about executables that have been accessed on a system. It logs details such as the file path, size, and last modification time but does not track actual execution or timestamp of execution. Its primary purpose is to ensure compatibility of applications when Windows updates are applied. 4 | 5 | ShimCache is useful for determining whether a file was present on the system, even if it was deleted or not executed. However, like AmCache, it cannot confirm program execution definitively. 6 | 7 | ## How to start? 8 | 9 | 1. Use AppCompatCacheParser.exe to parse the SYSTEM Hive file into a CSV format, which can then be loaded into tools like Timeline Explorer. To do this, run the following command: 10 | 11 | ``` 12 | AppCompatCacheParser.exe -f "C:\Users\Admin\Desktop\DC\C\Windows\System32\config\SYSTEM" --csv C:\Temp 13 | ``` 14 | 15 | ![image](https://github.com/user-attachments/assets/5e479490-19cd-4a1a-a669-ec1b671c815c) 16 | 17 | 18 | 2. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 19 | 20 | ![image](https://github.com/user-attachments/assets/b0e72215-9cae-45b8-83a4-989ea089633e) 21 | 22 | 3. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. 23 | 24 | ![image](https://github.com/user-attachments/assets/c5c2cadb-7320-4469-a150-c5be9522f415) 25 | 26 | ## Good thing to know 27 | 28 | The AppCompatCache, or ShimCache, doesn't have a direct *"execution"* flag to confirm if a file was actually run on the system. In earlier Windows versions, there wasn’t a reliable way to tell if a file had been executed based on ShimCache alone. Windows 10 improved this by adding a flag that gives a better indication of execution, though it's not foolproof. Forensic analysts still need to check other sources, like Prefetch files or event logs, to be certain a file was executed. 29 | 30 | In ShimCache, the *"LastModifiedTime"* refers to when the file’s contents were last changed, not when it was executed or accessed. This timestamp shows the last time the file itself was modified, and it’s recorded when the file is added to the cache. However, it can be misleading, as it reflects the file’s modification time rather than the actual time it was opened or run by the system or user. 31 | 32 | -------------------------------------------------------------------------------- /3. Analyzing Forensic Data/USN Journal/README.md: -------------------------------------------------------------------------------- 1 | # USN Journal 2 | 3 | 4 | The USN (Update Sequence Number) Journal is an NTFS feature that logs file and directory changes on a volume, such as creations, deletions, modifications, and renames. Stored in a hidden file called **$UsnJrnl** within the **$Extend** directory, it tracks changes as they occur. 5 | 6 | ![image](https://github.com/user-attachments/assets/7925345c-f2ad-46b5-bd36-d1a7823bfa70) 7 | 8 | ## How to start? 9 | 10 | 1. Use MFTECmd.exe to parse the $UsnJrnl file into a CSV format, which can then be loaded into tools like Timeline Explorer. To do this, run the following command: 11 | 12 | ``` 13 | MFTECmd.exe -f "C:\Users\Admin\Desktop\DC\C\$MFT" --csv C:\Temp 14 | ``` 15 | 16 | ![image](https://github.com/user-attachments/assets/3e364d88-4b6b-4f33-ba56-145d4b7e7378) 17 | 18 | 2. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 19 | 20 | ![image](https://github.com/user-attachments/assets/d9dcfa30-32aa-4688-907a-82a05d895e0d) 21 | 22 | 3. You can also load the .CSV file into Azure Data Explorer (ADX), where Microsoft provides a free 100 GB cluster. This lets you run Kusto queries to analyze the data. 23 | 24 | ![image](https://github.com/user-attachments/assets/24e3fa68-5bf7-44b7-b068-d1d1ee0c5d56) 25 | 26 | 27 | 28 | -------------------------------------------------------------------------------- /4. Malware Triage/README.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | 4 | This Malware Triage section is focused solely on quick triage to determine if a sample is indeed "malicious" and likely malware. It doesn’t cover in-depth analysis, such as reverse engineering or examining specific functions like UAC bypass or log deletion. For a detailed breakdown of all capabilities in a sample, it’s best to consult professionals who specialize in malware analysis. 5 | 6 | ## How to start? 7 | 8 | 1. First, we need to install **Windows Sandbox** on our machine, as it will be used for dynamic analysis. Source: https://learn.microsoft.com/en-us/windows/security/application-security/application-isolation/windows-sandbox/windows-sandbox-overview 9 | 10 | ![image](https://github.com/user-attachments/assets/484bd6a0-c7ed-49cb-8112-a97b4f466c94) 11 | 12 | 2. Next, we need to configure AV exclusions on our **Forensics VM** by excluding the **Downloads** folder and the **C:\Temp** folder. If you haven't setup your **Forensics VM** yet... Please do this first: https://github.com/DebugPrivilege/OpenProject/tree/main/1.%20How%20to%20setup%20IR%20Toolkit%3F 13 | 14 | To exclude the **Downloads** folder from Windows Defender AV: 15 | 16 | ``` 17 | Add-MpPreference -ExclusionPath "C:\Users\YourUsername\Downloads" 18 | ``` 19 | 20 | To exclude the **C:\Temp** folder from Windows Defender AV: 21 | 22 | ``` 23 | Add-MpPreference -ExclusionPath "C:\Temp" 24 | ``` 25 | 26 | ![image](https://github.com/user-attachments/assets/1f34aa3b-b854-4b07-ac2a-ba5029621881) 27 | 28 | ## How can a customer share Malware safely? 29 | 30 | The customer should compress the malware sample into a **.7z** file using **7zip** and set the password to infected (without quotes). After that, they can share the file via a shared OneDrive, for example. It can be downloaded here: https://7-zip.org/download.html 31 | 32 | ## What is the first thing you should do when receiving a malware sample? 33 | 34 | Start by running **Sigcheck.exe** from SysInternals to obtain the **SHA256** hash of the sample. Then, copy this hash and check it on **VirusTotal** for any existing detections. Consider these questions: Is the binary unsigned? Does it include any description or company information in the PE header? 35 | 36 | ![image](https://github.com/user-attachments/assets/51b34372-98be-4217-9a93-d69912a57a0c) 37 | 38 | VirusTotal identified the file as malicious. It's also a good idea to check the "Community" tab for comments from other users, which may provide helpful insights into the nature of the malware sample. 39 | 40 | ![image](https://github.com/user-attachments/assets/1134b4db-806f-450c-8264-42da368b05e8) 41 | 42 | ## What is the next step? 43 | 44 | Use the capa.exe tool to analyze the binary and reveal any specific functionalities it might contain. You can do this by running the following command: 45 | 46 | ``` 47 | capa.exe C:\Temp\LBB.exe 48 | ``` 49 | 50 | When malware is packed, it means the malware has been compressed or encrypted using special software to make it harder to detect or analyze. This "packing" hides the actual malicious code from analysts, which makes it more difficult to see what the malware does until it's unpacked. 51 | 52 | ![image](https://github.com/user-attachments/assets/2bb8403d-41e9-4ed9-bb09-e1aaf20b6878) 53 | 54 | Otherwise if the malware is not packed, you may see something like this: 55 | 56 | ![image](https://github.com/user-attachments/assets/8ab46d38-7424-43d0-9051-9c96675869f1) 57 | 58 | Another useful tool is PE Studio, which can be used to analyze Windows executables to assess security risks without needing to execute the file. It helps to identify suspicious characteristics, such as unusual metadata imports, functions, and other indicators that may suggest malicious behavior. 59 | 60 | ![image](https://github.com/user-attachments/assets/dc22fe17-7397-410e-913b-af93f4b76def) 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | -------------------------------------------------------------------------------- /4. Malware Triage/Windows Defender/README.md: -------------------------------------------------------------------------------- 1 | ## Windows Defender AV 2 | 3 | 4 | Windows Defender AV can be useful for leveraging its intelligence to detect potentially malicious files, especially in cases where YARA rules may have missed them. 5 | 6 | ## How to start? 7 | 8 | 1. First, gather all the malware samples you’ve received and place them in a single folder. For this example, we’ll store the samples in the C:\Temp folder, which we have also excluded from Windows Defender AV. 9 | 10 | ![image](https://github.com/user-attachments/assets/5407a32f-296c-47da-a8e1-accdc7bd1ed7) 11 | 12 | 2. Now, let's place a malware sample in the Desktop folder, which hasn’t been excluded from Windows Defender AV, so it should trigger an alert. 13 | 14 | ![image](https://github.com/user-attachments/assets/346e8101-6589-4e5d-b6af-c388843fed8f) 15 | 16 | In this example, Windows Defender AV identified the binary as Cobalt Strike. 17 | -------------------------------------------------------------------------------- /4. Malware Triage/YARA/README.md: -------------------------------------------------------------------------------- 1 | # YARA 2 | 3 | YARA is a tool that helps identify and classify malware by using rules to find specific patterns in files, like strings or code fragments. It's useful in malware analysis because you can create custom rules to detect known malware or find related files that share similar traits. 4 | 5 | You can use **LOKI** to quickly run a set of YARA rules across multiple binaries to check for signs of malware or suspicious behavior. **LOKI** is a scanner that comes with a collection of pre-built YARA rules and can also run custom rules you provide. This makes it a powerful tool for performing quick triage and detecting potential threats in binaries by matching them against known malware patterns. 6 | 7 | ## How to start? 8 | 9 | 1. First, gather all the malware samples you’ve received and place them in a single folder. For this example, we’ll store the samples in the C:\Temp folder, which we have also excluded from Windows Defender AV. 10 | 11 | ![image](https://github.com/user-attachments/assets/3cf62ded-9cd6-438a-a1c2-b02fd8909972) 12 | 13 | 2. Run the following LOKI command: 14 | 15 | ``` 16 | loki.exe -p C:\Temp --noprocscan 17 | ``` 18 | LOKI flagged some malware samples in the **C:\Temp** folder as suspicious and issued a warning, recommending further analysis of these samples. 19 | 20 | ![image](https://github.com/user-attachments/assets/8445758a-e37b-4741-b258-6984ad8365fd) 21 | 22 | When Loki triggers an alert highlighted in red, it’s typically a strong indication that the file is malicious, rather than just suspicious. 23 | 24 | ![image](https://github.com/user-attachments/assets/38470e88-0a49-4f7d-98d1-0b5921216706) 25 | 26 | ## How to exend YARA rules? 27 | 28 | Loki has a subfolder within the **signature-base** directory that holds all the YARA rules. 29 | 30 | ![image](https://github.com/user-attachments/assets/24d917a2-529a-4d7b-a03e-6bbcabbc9ba5) 31 | 32 | In this example, there are a few malware samples in the **C:\Temp** folder, but none of the current YARA rules are detecting anything malicious. 33 | 34 | ![image](https://github.com/user-attachments/assets/d5ed3d11-eb94-4454-9a21-76535e8504ef) 35 | 36 | For example, the team at Elastic Security has created a collection of YARA rules that we can download and place into the "yara" subfolder within the signature-base directory. See: https://github.com/elastic/protections-artifacts/ 37 | 38 | ![image](https://github.com/user-attachments/assets/3a02dc25-6f61-4cc4-88e9-d960dd21bc61) 39 | 40 | In this example, we've downloaded the YARA rules from the Elastic Security repository and copied all the .yar files into LOKI's "yara" folder. 41 | 42 | ![image](https://github.com/user-attachments/assets/476320bf-9532-4413-8d37-9e431ced51e5) 43 | 44 | Scanning the **C:\Temp** folder now shows some results: 45 | 46 | ![image](https://github.com/user-attachments/assets/ebe90dfa-935a-4a87-b819-e1892e316f85) 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/CrashDump of a Process/README.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | A crash dump of a process is a file that captures the state of a program at the moment it crashes or encounters a serious error. This file includes detailed information such as the memory in use, active threads, registers, and call stacks, which can help developers or analysts understand what went wrong. 4 | 5 | Sometimes malware crashes during execution, leaving behind a crash dump. These dumps capture memory and other details at the moment of the crash, which can be valuable for investigations. By scanning crash dumps with YARA, you can identify patterns or indicators of malware. 6 | 7 | ![image](https://github.com/user-attachments/assets/ab430173-edf2-4b42-862d-2db4d13d953d) 8 | 9 | 10 | ## How to start? 11 | 12 | When a process crashes, a crash dump can be generated and saved in `C:\ProgramData\Microsoft\Windows\WER\Temp`, but this isn't the default behavior. A specific registry value needs to be set to store dumps locally; otherwise, they are sent to the Microsoft Watson database by default. 13 | 14 | In an investigation of a Windows Server 2022 machine, two folders were found to contain process crash dumps by default, without any specific registry settings configured. The two folders are the following: 15 | 16 | ``` 17 | C:\Users\\AppData\Local\CrashDumps 18 | ``` 19 | 20 | ![image](https://github.com/user-attachments/assets/d6ab6899-71ee-4dec-bdf8-66427c0c984f) 21 | 22 | ``` 23 | C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps 24 | ``` 25 | 26 | ![image](https://github.com/user-attachments/assets/88ffbb79-fa1c-4733-9769-57a66841713d) 27 | 28 | 1. Run the following LOKI command: 29 | 30 | ``` 31 | loki.exe -p C:\Users\Admin\Desktop\CrashDumps --noprocscan 32 | ``` 33 | 34 | LOKI flagged a memory dump as Cobalt Strike: 35 | 36 | ![image](https://github.com/user-attachments/assets/d43fed17-cb79-41a3-a80e-56495a476d2b) 37 | 38 | 2. After Loki flags a memory dump as Cobalt Strike, you can use the Python script **1768.py** on the dump to attempt extracting the Beacon configuration, which includes details about the C2 server and other settings. 39 | 40 | ``` 41 | python 1768.py -e C:\Users\Admin\Desktop\CrashDumps\updater.exe.7612.dmp 42 | ``` 43 | 44 | ![image](https://github.com/user-attachments/assets/f469dbe1-8020-4b82-98c4-04f0b12a15b0) 45 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/README.md: -------------------------------------------------------------------------------- 1 | # Summary 2 | 3 | This section covers various tips and techniques for analyzing lesser-known artifacts that can still be valuable in an investigation. 4 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/Windows Defender MpLogs/MpLogParser.ps1: -------------------------------------------------------------------------------- 1 | <# 2 | .SYNOPSIS 3 | Parses MpLog files from Windows Defender's support folder or a specified file to extract event details. 4 | 5 | .DESCRIPTION 6 | This script: 7 | 1. Scans a specified MpLog file or all `MpLog-*` files in the specified directory (defaults to the Windows Defender support folder). 8 | 2. Extracts information from: 9 | - SDN Query events 10 | - Suspicious command lines 11 | - Detection clean and add events 12 | - Process image data (e.g., TotalTime, Count, MaxTime, EstimatedImpact) 13 | - Memory scan (EMS detection) events 14 | 3. Displays results in the console or saves them to CSV if a file path is provided. 15 | 16 | .PARAMETER FilePath 17 | Specifies a path to a single MpLog file for parsing. If omitted, the script defaults to scanning all `MpLog-*` files in the specified directory. 18 | 19 | .PARAMETER Directory 20 | Specifies the directory to scan for all `MpLog-*` files. If omitted, the script defaults to `C:\ProgramData\Microsoft\Windows Defender\Support`. 21 | 22 | .PARAMETER CsvOutput 23 | Specifies the file path for saving output in CSV format. If omitted, results are displayed in the console. 24 | 25 | .EXAMPLE 26 | .\MpLogParser.ps1 27 | # Parses all `MpLog-*` files in the default Windows Defender support folder and displays results in the console. 28 | 29 | .EXAMPLE 30 | .\MpLogParser.ps1 -FilePath "C:\Custom\Path\MpLog-Example.log" 31 | # Parses a specific MpLog file and displays all extracted information. 32 | 33 | .EXAMPLE 34 | .\MpLogParser.ps1 -Directory "C:\Users\Admin\Desktop" 35 | # Parses all `MpLog-*` files in the specified directory. 36 | 37 | .EXAMPLE 38 | .\MpLogParser.ps1 -CsvOutput "C:\Output\AllResults.csv" 39 | # Parses all `MpLog-*` files in the default Windows Defender folder and saves results to CSV. 40 | 41 | .NOTES 42 | Author: DebugPrivilege 43 | #> 44 | 45 | param ( 46 | [string]$CsvOutput, # Path to save CSV output; enables CSV export if specified 47 | [string]$Directory = "C:\ProgramData\Microsoft\Windows Defender\Support", # Default directory 48 | [string]$FilePath # Custom path to a specific MpLog file 49 | ) 50 | 51 | # Define arrays to store the parsed data 52 | $parsedSDNQuery = @() 53 | $parsedSuspiciousCLI = @() 54 | $parsedDetectionEvent = @() 55 | $parsedProcessImage = @() 56 | $parsedMemoryScan = @() 57 | 58 | # Function to convert FILETIME to UTC datetime 59 | function Convert-FileTimeToUTC { 60 | param ( 61 | [long]$fileTime 62 | ) 63 | # Define start date as January 1, 1601 64 | $startDate = [DateTime]::FromFileTimeUtc(0) 65 | # Add the FILETIME interval to start date 66 | return $startDate.AddTicks($fileTime) 67 | } 68 | 69 | # Check if a specific file path is provided; if so, only parse that file 70 | if ($FilePath) { 71 | # Check if the specified file exists 72 | if (Test-Path -Path $FilePath) { 73 | $logFiles = @($FilePath) # Use the single file path in an array 74 | } else { 75 | Write-Output "Specified file does not exist: $FilePath" 76 | exit 77 | } 78 | } else { 79 | # If no specific file path is provided, get all MpLog files in the default directory 80 | $logFiles = Get-ChildItem -Path $Directory -Filter "MpLog-*.log" -File 81 | } 82 | 83 | # Loop through each log file 84 | foreach ($logFile in $logFiles) { 85 | # Determine the path for Get-Content based on whether a single file or directory scan is used 86 | $filePathToRead = if ($FilePath) { $FilePath } else { $logFile.FullName } 87 | 88 | # Read the file line by line 89 | $lines = Get-Content -Path $filePathToRead 90 | 91 | foreach ($line in $lines) { 92 | # Parse SDN query events (now includes both SHA1 and SHA256) 93 | if ($line -match "(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) SDN:Issuing SDN query for (\\?.+?) \((\\?.+?)\) \(sha1=(\w{40}), sha2=(\w{64})\)") { 94 | $timestamp = $matches[1] 95 | $filePath = $matches[2] 96 | $sha1 = $matches[4] 97 | $sha256 = $matches[5] 98 | 99 | # Store SDN query result 100 | $parsedSDNQuery += [PSCustomObject]@{ 101 | Timestamp = $timestamp 102 | FilePath = $filePath 103 | SHA1 = $sha1 104 | SHA256 = $sha256 105 | } 106 | } 107 | 108 | # Parse suspicious command line detections 109 | if ($line -match "(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) Engine:command line reported as (.+?): (.+?)\((.+?)\)") { 110 | $timestamp = $matches[1] 111 | $detectionType = $matches[2] 112 | $filePath = $matches[3] 113 | $commandLine = $matches[4] 114 | 115 | # Store suspicious CLI result 116 | $parsedSuspiciousCLI += [PSCustomObject]@{ 117 | Timestamp = $timestamp 118 | FilePath = $filePath 119 | CommandLine = $commandLine 120 | DetectionType = $detectionType 121 | } 122 | } 123 | 124 | # Parse detection events 125 | if ($line -match "(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) DETECTION_CLEANEVENT (\S+) (\S+) (\S+) (\S+) (.+)") { 126 | $timestamp = $matches[1] 127 | $source = $matches[2] 128 | $action = $matches[3] 129 | $threatID = $matches[4] 130 | $threatName = $matches[5] 131 | $details = $matches[6] 132 | 133 | # Extract additional details if available 134 | $containerFile = if ($details -match "containerfile:(\S+)") { $matches[1] } else { "" } 135 | $filePath = if ($details -match "file:(\S+)") { $matches[1] } else { "" } 136 | $webFile = if ($details -match "webfile:(\S+)") { $matches[1] } else { "" } 137 | $processData = if ($details -match "pid:(\d+),ProcessStart:(\d+)") { 138 | $processID = $matches[1] 139 | $startTime = Convert-FileTimeToUTC([long]$matches[2]) 140 | "PID: $processID, StartTime: $startTime" 141 | } else { "" } 142 | 143 | # Store detection clean event result with consistent columns 144 | $parsedDetectionEvent += [PSCustomObject]@{ 145 | Timestamp = $timestamp 146 | ThreatName = $threatName 147 | Source = $source 148 | Action = $action 149 | ThreatID = $threatID 150 | ContainerFile = $containerFile 151 | FilePath = $filePath 152 | WebFile = $webFile 153 | ProcessData = $processData 154 | PropBag = "" 155 | } 156 | } 157 | 158 | # Parse DETECTION_ADD events 159 | elseif ($line -match "(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) DETECTION_ADD#\d+ (\S+) (.+)") { 160 | $timestamp = $matches[1] 161 | $threatName = $matches[2] 162 | $details = $matches[3] 163 | 164 | # Extract additional details if available 165 | $webFile = if ($details -match "webfile:(\S+)") { $matches[1] } else { "" } 166 | $containerFile = if ($details -match "containerfile:(\S+)") { $matches[1] } else { "" } 167 | $processData = if ($details -match "pid:(\d+),ProcessStart:(\d+)") { 168 | $processID = $matches[1] 169 | $startTime = Convert-FileTimeToUTC([long]$matches[2]) 170 | "PID: $processID, StartTime: $startTime" 171 | } else { "" } 172 | $propBag = if ($details -match "PropBag \[length: \d+, data: (\S+)\]") { $matches[1] } else { "(null)" } 173 | 174 | # Store detection add event result with consistent columns 175 | $parsedDetectionEvent += [PSCustomObject]@{ 176 | Timestamp = $timestamp 177 | ThreatName = $threatName 178 | Source = "" 179 | Action = "" 180 | ThreatID = "" 181 | ContainerFile = $containerFile 182 | FilePath = "" 183 | WebFile = $webFile 184 | ProcessData = $processData 185 | PropBag = $propBag 186 | } 187 | } 188 | 189 | # Parse EMS detection events (Memory scan) by default 190 | if ($line -match "(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z) Engine:EMS detection: (\S+), sigseq=(\S+), sigsha=(\S+), pid=(\d+)") { 191 | $timestamp = $matches[1] 192 | $threatName = $matches[2] 193 | $sigSeq = $matches[3] 194 | $sigSha = $matches[4] 195 | $processID = $matches[5] 196 | 197 | # Store EMS detection event 198 | $parsedMemoryScan += [PSCustomObject]@{ 199 | Timestamp = $timestamp 200 | ThreatName = $threatName 201 | SigSeq = $sigSeq 202 | SigSha = $sigSha 203 | ProcessID = $processID 204 | } 205 | } 206 | 207 | # Parse process image data 208 | if ($line -match "ProcessImageName: (\S+), (?:Pid: (\d+), )?TotalTime: (\d+), Count: (\d+), MaxTime: (\d+), MaxTimeFile: (\S+), EstimatedImpact: (\d+)%") { 209 | $processImageName = $matches[1] 210 | $processID = if ($matches[2]) { $matches[2] } else { "" } 211 | $totalTime = $matches[3] 212 | $count = $matches[4] 213 | $maxTime = $matches[5] 214 | $maxTimeFile = $matches[6] 215 | $estimatedImpact = $matches[7] 216 | 217 | # Store process image result 218 | $parsedProcessImage += [PSCustomObject]@{ 219 | ProcessImageName = $processImageName 220 | ProcessID = $processID 221 | TotalTime = $totalTime 222 | Count = $count 223 | MaxTime = $maxTime 224 | MaxTimeFile = $maxTimeFile 225 | EstimatedImpact = "$estimatedImpact%" 226 | } 227 | } 228 | } 229 | } 230 | 231 | # Display all results in the console 232 | if ($parsedSDNQuery.Count -gt 0) { 233 | Write-Output "SDN Query Results:" 234 | $parsedSDNQuery | Format-Table -Property Timestamp, FilePath, SHA1, SHA256 -AutoSize 235 | } 236 | 237 | if ($parsedSuspiciousCLI.Count -gt 0) { 238 | Write-Output "`nSuspicious Command Line Results:" 239 | $parsedSuspiciousCLI | Format-Table -Property Timestamp, FilePath, CommandLine, DetectionType -AutoSize 240 | } 241 | 242 | if ($parsedDetectionEvent.Count -gt 0) { 243 | Write-Output "`nDetection Event Results:" 244 | $parsedDetectionEvent | Format-Table -Property Timestamp, ThreatName, Source, Action, ThreatID, ContainerFile, FilePath, WebFile, ProcessData, PropBag -AutoSize 245 | } 246 | 247 | if ($parsedMemoryScan.Count -gt 0) { 248 | Write-Output "`nMemory Scan Results:" 249 | $parsedMemoryScan | Format-Table -Property Timestamp, ThreatName, SigSeq, SigSha, ProcessID -AutoSize 250 | } 251 | 252 | if ($parsedProcessImage.Count -gt 0) { 253 | Write-Output "`nProcess Image Results:" 254 | $parsedProcessImage | Format-Table -Property ProcessImageName, ProcessID, TotalTime, Count, MaxTime, MaxTimeFile, EstimatedImpact -AutoSize 255 | } 256 | 257 | # Export all data to CSV if CsvOutput is specified 258 | if ($CsvOutput) { 259 | try { 260 | $parsedSDNQuery | Export-Csv -Path ([System.IO.Path]::ChangeExtension($CsvOutput, "_SDNQuery.csv")) -NoTypeInformation -Force 261 | $parsedSuspiciousCLI | Export-Csv -Path ([System.IO.Path]::ChangeExtension($CsvOutput, "_SuspiciousCLI.csv")) -NoTypeInformation -Force 262 | $parsedDetectionEvent | Export-Csv -Path ([System.IO.Path]::ChangeExtension($CsvOutput, "_DetectionEvent.csv")) -NoTypeInformation -Force 263 | $parsedMemoryScan | Export-Csv -Path ([System.IO.Path]::ChangeExtension($CsvOutput, "_MemoryScan.csv")) -NoTypeInformation -Force 264 | $parsedProcessImage | Export-Csv -Path ([System.IO.Path]::ChangeExtension($CsvOutput, "_ProcessImage.csv")) -NoTypeInformation -Force 265 | Write-Output "All data exported to CSV files successfully." 266 | } catch { 267 | Write-Output "Failed to export data to CSV: $_" 268 | } 269 | } 270 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/Windows Defender MpLogs/README.md: -------------------------------------------------------------------------------- 1 | # Microsoft Protection Logs 2 | 3 | MpLogs are diagnostic logs generated by Microsoft Defender Antivirus that record detailed information about Defender’s security actions, such as malware detections, scans, and command-line operations flagged as suspicious. Stored in `C:\ProgramData\Microsoft\Windows Defender\Support`, these logs contain data like file paths, timestamps, threat names, and process metrics. During DFIR, MpLogs are valuable for tracing malware activity and identifying the files or processes that triggered alerts, such as malicious PowerShell commands or attempts to disable Defender for example. 4 | 5 | I created this script for Live Response scenarios with Defender for Endpoint. When an alert is triggered on an endpoint, it helps me quickly gather diagnostic logs generated by Windows Defender Antivirus to give me a broader insight to check if there were additional detections or suspicious activity. 6 | 7 | ## How to parse MpLogs 8 | 9 | 1. If you run this script without any arguments, it will look for the MpLog file on the local machine in `C:\ProgramData\Microsoft\Windows Defender\Support` and display all parsed results in the console. 10 | 11 | ``` 12 | .\MpLogParser.ps1 13 | ``` 14 | 15 | ![image](https://github.com/user-attachments/assets/bcd28891-cffd-4da0-97fa-9467ce4b137f) 16 | 17 | 2. If you use the `-CsvOutput` parameter, you can specify a folder to save all identified results from the MpLogs as a CSV file. 18 | 19 | ``` 20 | .\MpLogParser.ps1 -CsvOutput C:\MpResults\Results.csv 21 | ``` 22 | 23 | ![image](https://github.com/user-attachments/assets/acb113a9-82b9-4270-8591-ab4c129a7040) 24 | 25 | 26 | 3. If you receive a disk image or VHD(X) from a customer and need to parse the MpLog file, you can use the `-FilePath` parameter to specify the exact location of the MpLog file. 27 | 28 | ``` 29 | .\MpLogParser.ps1 -FilePath C:\Users\Admin\Desktop\MPLog-20240704-220133.log 30 | ``` 31 | 32 | ![image](https://github.com/user-attachments/assets/1d471d0f-d1bc-4ce7-92a9-2548db62f0c5) 33 | 34 | 4. You can combine the `-CsvOutput` parameter with `-FilePath` as well to save the results in CSV format. 35 | 36 | ``` 37 | .\MpLogParser.ps1 -FilePath .\MPLog-20240704-220133.log -CsvOutput C:\MpResults\Results.csv 38 | ``` 39 | 40 | 5. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 41 | 42 | ![image](https://github.com/user-attachments/assets/4a13a700-efd2-4d93-aa0b-d6166706ebb3) 43 | 44 | 45 | 46 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/Windows Error Reporting/README.md: -------------------------------------------------------------------------------- 1 | # Windows Error Reporting (WER) 2 | 3 | Windows Error Reporting (WER) logs application crashes and system errors in `.wer` files, which captures information like crash timestamps, application paths, and a **SHA1** hash that uniquely identifies the crashed application. In DFIR, this **SHA1** hash can be useful because it helps analysts quickly identify specific applications or potentially malicious files. 4 | 5 | @svch0st posted a Twitter thread on the value of `.wer` files in DFIR, which can be found here: https://x.com/svch0st/status/1550720565480247296. This write-up isn’t about reinventing the wheel, but it’s demonstrating a PowerShell script to help parse `.wer` files and gather essential information that we then can use to analyze further. 6 | 7 | ## How to parse WER files? 8 | 9 | 1. When working with a disk image, VHD(X), or similar, the `WERParser.ps1` script can quickly extract valuable information from all `Report.wer` files. Running the script without any parameters will default to scanning the local machine in the directories `C:\ProgramData\Microsoft\Windows\WER\ReportArchive` and `C:\ProgramData\Microsoft\Windows\WER\ReportQueue` 10 | 11 | Run the following command as an administrator: 12 | ``` 13 | .\WERParser.ps1 14 | ``` 15 | 16 | The `AppPath` can be quite lengthy, which limits the visibility of other columns in the console output. 17 | 18 | ![image](https://github.com/user-attachments/assets/603e2da5-7ea7-42e8-ba66-50f3b53acabb) 19 | 20 | 2. By using the `-OutputCsv` option, we can specify a file path to save the output in a CSV file that includes all columns. 21 | 22 | ``` 23 | .\WERParser.ps1 -OutputCsv C:\Temp\Output.csv 24 | ``` 25 | 26 | ![image](https://github.com/user-attachments/assets/e9d70407-659c-4f67-8003-b78754dbf074) 27 | 28 | 3. Now, you can use Eric Zimmerman’s Timeline Explorer to load the .CSV output and analyze the raw data. 29 | 30 | ![image](https://github.com/user-attachments/assets/a4b1f4c9-f351-4ff0-90bb-2e9f174a3b5f) 31 | 32 | 4. The `-FilePath` option can be used when the WER folder is shared with us or when we’ve extracted it from a disk image, for instance. 33 | 34 | ``` 35 | .\WERParser.ps1 -FilePath C:\Users\Admin\Desktop\WER -OutputCsv C:\Temp\Results.csv 36 | ``` 37 | 38 | ![image](https://github.com/user-attachments/assets/05d89d4b-d6cb-4270-952c-b05d238289e4) 39 | 40 | 5. Similar to the previous example, we can now load the CSV file into Timeline Explorer or Azure Data Explorer for further analysis. 41 | 42 | ![image](https://github.com/user-attachments/assets/5fc9f1da-1336-485d-8bf2-489a79e8821c) 43 | 44 | 6. Here’s how it looks when we load the CSV file into Azure Data Explorer, allowing us to run queries on the data. 45 | 46 | ![image](https://github.com/user-attachments/assets/6a82f449-70c5-4a72-b0e4-a2f2ca98e137) 47 | 48 | 49 | -------------------------------------------------------------------------------- /5. DFIR Tips and Tricks/Windows Error Reporting/WERParser.ps1: -------------------------------------------------------------------------------- 1 | <# 2 | .SYNOPSIS 3 | This script scans Windows Error Reporting (WER) directories for application crash reports, extracts key details such as event timestamps, SHA1 hashes, application names, and paths, and optionally saves the output to a CSV file. 4 | 5 | .DESCRIPTION 6 | The script performs the following tasks: 7 | 1. Scans specified directories (or default WER directories if none specified) for WER crash reports. 8 | 2. Extracts relevant fields from each Report.wer file, including: 9 | - EventTime in UTC 10 | - SHA1 hash of the application 11 | - Application name 12 | - Application path (AppPath) 13 | 3. Outputs results to the console or saves them as a CSV file if an output path is provided. 14 | 15 | .PARAMETER FilePath 16 | Specifies a custom directory path to scan for Report.wer files. If not provided, the script defaults to the standard WER ReportArchive and ReportQueue directories. 17 | 18 | .PARAMETER OutputCsv 19 | Specifies a file path to save the output in CSV format. If not provided, the script outputs the results to the console. 20 | 21 | .EXAMPLE 22 | # Example 1: Scan default WER directories and display results in the console 23 | .\WERParser.ps1 24 | 25 | .EXAMPLE 26 | # Example 2: Scan a specific directory and display results in the console 27 | .\WERParser.ps1 -FilePath "C:\Custom\Path" 28 | 29 | .EXAMPLE 30 | # Example 3: Scan default WER directories and save results to a CSV file 31 | .\WERParser.ps1 -OutputCsv "C:\Output\Results.csv" 32 | 33 | .EXAMPLE 34 | # Example 4: Scan a specific directory and save results to a CSV file 35 | .\WERParser.ps1 -FilePath "C:\Custom\Path" -OutputCsv "C:\Output\Results.csv" 36 | 37 | # Author: DebugPrivilege 38 | # Required Dependencies: None 39 | #> 40 | 41 | param ( 42 | [string]$FilePath, 43 | [string]$OutputCsv 44 | ) 45 | 46 | # Define default paths if no FilePath parameter is provided 47 | $reportDirectories = if ($FilePath) { @($FilePath) } else { 48 | @("C:\ProgramData\Microsoft\Windows\WER\ReportArchive", "C:\ProgramData\Microsoft\Windows\WER\ReportQueue") 49 | } 50 | 51 | # Function to convert FILETIME to UTC DateTime 52 | function Convert-FileTimeToUTC { 53 | param ( 54 | [string]$fileTime 55 | ) 56 | # Convert FILETIME (100-nanosecond intervals) to .NET DateTime 57 | $dateTime = [DateTime]::FromFileTimeUtc([Int64]$fileTime) 58 | return $dateTime.ToString("yyyy-MM-dd HH:mm:ss") 59 | } 60 | 61 | # Function to extract and parse necessary fields from Report.wer 62 | function Get-ParsedReportInfo { 63 | param ( 64 | [string]$filePath 65 | ) 66 | # Read file contents and look for the required lines 67 | $fileContent = Get-Content -Path $filePath 68 | $eventTime = $null 69 | $targetAppId = $null 70 | $appPath = $null 71 | 72 | foreach ($line in $fileContent) { 73 | if ($line -match "^EventTime=(\d+)") { 74 | $eventTime = $matches[1] 75 | } 76 | elseif ($line -match "^TargetAppId=(.+)") { 77 | # Capture the TargetAppId value 78 | $targetAppId = $matches[1] 79 | # Remove prefix like "W:" or "U:" if present 80 | $targetAppId = $targetAppId -replace "^[WU]:", "" 81 | } 82 | elseif ($line -match "^AppPath=(.+)") { 83 | $appPath = $matches[1] 84 | } 85 | } 86 | 87 | if ($eventTime -and $targetAppId) { 88 | # Convert EventTime to UTC 89 | $eventTimeUTC = Convert-FileTimeToUTC -fileTime $eventTime 90 | 91 | # Split TargetAppId to get SHA1 and AppName 92 | $parsedIdParts = $targetAppId -split '!' 93 | if ($parsedIdParts.Count -ge 3) { 94 | # Trim leading 0000 from SHA1 if present 95 | $sha1 = $parsedIdParts[1] -replace "^0000", "" 96 | $appName = $parsedIdParts[2] 97 | return @{ 98 | EventTimeUTC = $eventTimeUTC 99 | SHA1 = $sha1 100 | AppName = $appName 101 | AppPath = $appPath 102 | } 103 | } 104 | } 105 | return $null 106 | } 107 | 108 | # Enumerate through specified or default directories, find Report.wer files, and parse necessary fields 109 | $results = foreach ($dir in $reportDirectories) { 110 | Get-ChildItem -Path $dir -Recurse -Filter "Report.wer" | ForEach-Object { 111 | $parsedReportInfo = Get-ParsedReportInfo -filePath $_.FullName 112 | if ($parsedReportInfo) { 113 | [PSCustomObject]$parsedReportInfo 114 | } 115 | } 116 | } 117 | 118 | # Output results 119 | if ($OutputCsv) { 120 | # Save results to CSV 121 | $results | Export-Csv -Path $OutputCsv -NoTypeInformation -Encoding UTF8 122 | Write-Output "Results have been saved to $OutputCsv" 123 | } else { 124 | # Display results in the console 125 | $results | Format-Table -AutoSize 126 | } 127 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OpenProject 2 | 3 | **OpenProject** is a guide on using open-source tools for Incident Response (IR). This repo shares workflows, tool setups, and practical steps for detecting, analyzing, and handling security incidents. It’s made for security pros and anyone interested in building an effective IR toolkit using free resources. 4 | 5 | --- 6 | 7 | ## Key Features 8 | 9 | - **Tool Guides**: Step-by-step instructions for setting up and using key open-source IR tools. 10 | - **Workflow Examples**: Practical workflows to speed up response time during incidents. 11 | - **Analysis Techniques**: Methods for investigating and understanding security events. 12 | 13 | ## Tools Covered 14 | 15 | OpenProject covers a range of tools often used in Incident Response, including: 16 | 17 | - **Forensic Tools**: For collecting and analyzing data from affected devices. 18 | - **Log Analysis**: For reviewing logs to trace incidents. 19 | --------------------------------------------------------------------------------