This Repository is for Live Forenisc Script
This repository is dedicated to developing automated tools for live digital forensics, applicable across both Linux and Windows platforms. Live forensics refers to the process of collecting and analyzing digital evidence from a computer system without shutting it down, which is crucial in cases where stopping the system could lead to the loss of valuable volatile data.
Assuming our scripts are stored on a USB drive, this drive is then attached to the system under investigation, be it compromised or under analysis. Our scripts are designed to run directly from the USB, facilitating a streamlined process in live forensic scenarios.
+---------------------+---------------------+
| | |
| Script Storage | Data Storage |
| Partition | Partition |
| | |
+---------------------+---------------------+
| |
| USB Drive |
| |
+-------------------------------------------+
For optimal functionality, the USB drive should be prepared with two distinct partitions. The first partition contains all our scripts along with the necessary programs required for their execution. The second partition is reserved for storing the data gathered by these scripts during the forensic process. This dual-partition setup ensures a clear separation between tools and collected data, enhancing both organization and efficiency in the live forensic investigation.
In addition to the fundamental concept of live forensics, our scripts are meticulously designed to collect both active and inactive data from the target system. The specific types of data gathered by our scripts are as follows:
- Active Data Collection
For active data, our scripts are capable of:
- Creating Memory and Virtual Memory dumps.
- Collecting network configuration and connection status.
- Gathering information about running processes and their resource usage.
- Retrieving details about the currently logged-in user.
- Compiling system event logs and registry information.
- Listing programs configured to start automatically during boot.
- Collecting information about scheduled tasks and clipboard history.
- Inactive Data Collection
For inactive data, our scripts focus on:
- Collecting file system metadata including MFT, Boot, Amcache.
- Retrieving registry files like SAM, SYSTEM, SOFTWARE, SECURITY.
- Gathering Prefetch and Superfetch data.
- Compiling Event Log files for the target host.
- Collecting Recycle Bin information.
- Retrieving browser artifacts including cache, cookies, history, and download history.
- Collecting System Restore Points (or System Volume Information).
- Gathering Portable Device Information.
- Retrieving Link File and JumpLists data.
(The above content lists what a script operating on Windows collects)
[*] It's important to note that the data available for collection can vary between different operating systems, hence some differences in the information gathered from Linux and Windows systems.
Furthermore, our script suite is divided into three main components. The main script allows users to choose whether to collect only active data, only inactive data, or both. This flexibility ensures that investigators can tailor the data collection process to the specific requirements of each forensic examination.
BASIC PREPARATION =>
STEP 1: prepare git terminal
download git terminal from https://git-scm.com/downloads
STEP 2: your account info
git config --global user.name "yourname"
git config --global user.email "youraccount@domain.com"
Repository Specific Preparation =>
STEP 1: Clone Unified-forensic-Toolkit
git clone https://github.com/64dB0y/Unified-forensic-Toolkit.git
STEP 2: Setup Git LFS
If this is your first time cloning the repository (because we use Git LFS), please follow these steps:
git lfs install
or
If you have already cloned our repository (and we use Git LFS), please follow these steps:
git lfs pull
All demonstrations presented from this point forward are performed with administrative privileges. This means that our project's scripts are designed to be executed on the premise that they are granted administrator-level permissions
One side should be smaller and the other larger. Ensure that the smaller partition has at least 4GB of capacity, and allocate as much space as possible for the other partition. In my case, when I tested with a single desktop, I secured about 70GB of data.
As can be seen from the result screen of diskmgmt.msc in the image, the USB is currently attached with the scripts stored in the E:\ drive, and a partition designated for storing the results of script execution appearing in the F:\ drive.
Attention! You must execute the script with Administrator Permissions!
Begin by inputting the case name and analyst's name, then designate the directory where the results will be stored. As shown in the image, you will be prompted to decide if you want to run ProcMon. This feature has been added to trace how information gathering is conducted later on. For simplicity in this demonstration, we've skipped this step by selecting the 'N' option.
At this stage, a root directory named after the computer name and timestamp is created in the target directory specified by the user. Within this root directory, all forthcoming active data will be stored in the 'Volatile_Information' directory, while inactive data will be saved in the 'NONVOLATILE' directory. Additionally, the timestamp will also be saved directly under the aforementioned computer name_timestamp directory as 'TimeStamp.log'. Furthermore, if 'main.bat' is set to utilize Procmon, the 'procmon_log.pml' file will be stored in this directory as well.
This is a script for collecting active data. As seen in the image, the script can perform various options. You can select the options in your preferred order, such as 2, 7, 3, or enter option 'a' to execute all options at once.
From now on, I will introduce only the notable contents within the active data script
We support a total of three memory dump tools: first is RamCapture, second is Winpmem, and third is CyLR
When you enter the 'R' option to execute RamCapture, a path will appear in the cmd. Insert this path into the space provided for RamCapture's location and press the 'Capture!' button to run it
If it has been completed, press 'Close'
To execute Winpmem, it is mandatory to enter the username and password. (As a note, it is recommended to enter the user account with SID 1001 if possible. This is to run it with administrative privileges.)
Continuing, if the account name and password have been entered successfully, a memory dump will be performed through Winpmem as illustrated in the figure.
Since CyLR compresses the results of the memory dump, the password for the compressed file must be specified in advance.
Once the compression password has been entered, you can see CyLR functioning as shown in the picture above.
The virtual memory dump is supported through the sysinternals procdump tool, and there are two main types that can be collected. One is a full memory dump, and the other is a kernel memory dump.
You might notice several errors quickly appearing at the beginning of a virtual memory dump using procdump, but then the dump proceeds normally after a moment. These initial errors are presumed to be related to permission issues.
(Note - Since the virtual memory dump generates a large amount of data, during development and testing, the process was briefly run and then stopped to move on.)
Once all the script executions are complete, the menu will reappear, and you can exit by pressing 'q'. However, if you selected the option to run both active and inactive scripts by pressing 3 in main.bat, the Inactive script will start executing immediately.
The Inactive Script also supports various options, as seen in the image. The difference from the active script is that the execution of the Inactive Script depends on whether the .NET FRAMEWORK is installed. If the .NET FRAMEWORK is installed, it utilizes kape to use tools appropriately for each stage. On the other hand, if the .NET FRAMEWORK is not installed, it primarily uses forecopy_handy for data collection and occasionally employs xcopy, a built-in command provided by Windows, for data gathering.
As you can see in the image above, the current system utilizes .NET FRAMEWORK version 4, which allows for the collection of Filesystem Metadata via kape.
For dump virtual memory and copy metadata files, you need LOTS of capacity We recommand more than 64GB
There is no need to partition in Linux If you can use Windows, just partion it in Windows It also works at Linux too But, If you cannot use Windows, you have to follow these steps:
First, search USB drive
lsblk
You can check the list of connected disks Identify USB to be used for forensics For example, it might be named as '/dev/sdb'
If you find your USB drive, you have to partition your USB
sudo fdisk /dev/sdb
n # Creating new partition
p # Select default partition type
# Enter Partition Number 1's Name #
# Starting Sector (To set it as default, press Enter Key) #
# End Sector (Enter capacity value as you want. For example, 2GB -> +2G)#
# We recommand 10GB for Partition Number 1
n # Creating new partition
p # Select default partition type
# Enter Partition Number 2's Name #
# Starting Sector (Enter to set the next exit sector of the previous partition) #
# End Sector (To set it as default, press Enter Key)#
w #Save changes and exit
Now your USB has two partitions Partiton 1 for Forensic Scripts and Partition 2 for saving Forensic Results
sudo partprobe
Now there will be two partitions named as '/dev/sdb1' and '/dev/sdb2'
Download all the scripts and files in /Linux/Unified directory And put it into the partition no.1
cd /
These directories are for mounting each partition of Forensic USB
mkdir mnt1
mkdir mnt2
Check which directory your USB has been connected If the directory is /dev/sdb1 and /dev/sdb2, mount each of it to mnt1 and mnt2
sudo mount /dev/sdb1 /mnt1
sudo mount /dev/sdb2 /mnt2
All the other script's permission wil be given by Forensic.bash
sudo chmod +x ./Forensic.bash
sudo ./Forensic.bash
You can enter your name and summary of case
(Linux's Active Data Collection Script)
(Linux's Inactive Data Collection Script)
Run all the scripts or you can select category you want to forensic
All the results will be save in '/mnt2' directory, which is second partition of your USB
After data collection, we support the creation of a separate report (Note, this report generation task should be carried out on a computer unrelated to the one affected by the security incident. After all, the goal of digital forensics is to minimize changes to the system). Our report briefly outlines what data has been collected, when (timestamp) it was collected, where it is located, and what its hash value is.
Unlike Linux, Windows currently generates reports only for active data because inactive data already provides ample information through kape.
Inside the I_HATE_LIVE_FORENSIC\Report\Windows directory, there is a file named Window_report_Final.py. You can use this program to generate the report.
Specify the target directory you wish to parse and the type of hash value you want to output.
If you're uncertain about which directory to specify,
simply select the directory under the target directory defined in main.bat, which is named after the computer name and timestamp.
If executed correctly, you should be able to see the results as follows:
The table in the image above represents a portion of the results from the generated report
There are two reporting programs for Linux forensic results as Linux ver and Windows ver You can download it from the link below Download Link https://drive.google.com/file/d/1OCibtjOtP8c1wfdwPdzDXEpZDdjflVGQ/view?usp=sharing
- How to run it in Linux
- Put 'Linux_Reporting_Tool_Linux' exe file to '/mnt2' directory
- Autorize and Run it
sudo chmod +x ./Linux_Reporting_Tool_Linux
sudo ./Linux_Reporting_Tool_Linux
- How to run it in Windows
- Put 'Linux_Reporting_Tool_Win.exe' file to '/mnt2' directory
- Run as administrator
All programs will create 'Forensic_Info.pdf' by default After default report has been created, you can select whether to generate additional reports
Windows:
-
In main.bat, after running ProcMon and later closing it, we provided commands for unloading the ProcMon driver and for deletion. However, the unload command still shows an error, and despite being in an administrator privilege terminal, the delete command fails due to insufficient permissions. This issue needs to be addressed.
-
On main.bat, there's a Procmon warning content. I will change the color of this warning string to emphasize it, aiming to make it more noticeable so that users can read and make informed decisions based on it.
-
In the memory dump step, stage 0 of active_data2.bat, it shows a specific path for copying in RamCapture. It would be beneficial if this path could be highlighted or emphasized in color.
-
In the memory dump step, stage 0 of active_data2.bat, the fact that Winpmem reveals the user account name and password in clear text is problematic. The user’s input should be made invisible.
-
Both active_data2.bat and inactive_new_ver_ver.bat allow users to choose stages to execute by entering numbered stages or the 'a' option. The issue is that after performing each option, it only indicates the options selected by the user, not exactly up to which stage has been completed. There needs to be a clear indication of the stages that have been completed.
-
Both active_data2.bat and inactive_new_ver_ver.bat scripts currently employ a timestamping method that is challenging to track accurately. Consequently, the timestamps recorded in the TimeStamp.log file may not be precise. We are actively exploring solutions to improve the accuracy of these timestamps (at the very least, we hope to achieve accurate timestamping in active_data2.bat soon)
-
Both active_data2.bat and inactive_new_ver_ver.bat scripts support HMAC.
-
With the Windows Reporting feature, the tables are currently arranged alphabetically. They need to be reorganized according to the order of stages as listed in each script.
-
The Windows Reporting feature should be able to indicate the page number from the "second page" onwards at the bottom of each page, for example, - 2 - or - 3 -.
Linux:
Both:
- Support GUI (with imgui or qtdesigner) - this will be considered if time permits
(The priority for improvements is to first address issues in each operating system as much as possible. Among these, instead of starting with scripts that support the execution of other scripts like main.bat and Forensic.bash, we aim to prioritize the enhancement of scripts that collect active and inactive data)
For Windows - you need to execute the terminal with Administrator privileges. For Linux -
[Note: This section will contain numbered or bulleted steps to ensure clarity and ease of understanding for users. Technical jargon will be avoided or explained where necessary.]
Currently, our project is licensed under the MIT License.
Contributions are what make the Open Source community such an amazing place to learn, inspire, and create. Any contributions you make are greatly appreciated. For detailed guidelines, please refer to ou CONTRIBUTING.md.