Hard Disk Analysis Methodology
Last updated
Last updated
These are the materials used during the sharing session: https://drive.google.com/drive/folders/1m-hdQjVSC_LC-kLsJWL7Vobxa0cSQt8k?usp=drive_link
Password to DESKTOP-FHNAS8D.zip : lets_start_digging_for_fsec_artefacts
In context, there was some confusion about the tools during the sharing session. So, let me explain. There are only 2 applications to be installed, meaning you need to open up the installation wizard. Those include:
AccessData_FTK_Imager_4.7.1.exe
DB.Browser.for.SQLite-3.12.2-win64.msi
The rest of the tools such as the ones in folders do not require an installation as they already have the executable for their respective functions. To elaborate, you only have to go into the folder to launch the application.
You will understand once you start getting your hands dirty
To start this off, when you play a CTF and specialise in the Forensics category, you will typically find pcap files, and steganography challenges within beginner-friendly CTF challenges. However, when you get to more advanced CTFs, you will find more advanced challenges such as:
Full File System Analysis
Triage Analysis
Memory Forensics
Malware Analysis
Furthermore, these categories can intertwine with each other or more often, with other categories. However, for this sharing session, I shared about Full File System Analysis. With that said, whenever you see file extensions such as these:
.e01 ( EnCase format )
.raw
.ad1 ( Access Data format )
They are disk images, or in other words, they are a bit-by-bit copy of a computer's hard disk. Basically, they are a clone of a computer's hard disk. Every file and folder is within the disk image. However, as a beginner, you wouldn't know how to start analysing it. As a Digital Forensics student, my lecturers, specifically 4 of them all said you analyse it based on the case, and that is true. However, their response is based on the context of a police investigation and not a cyber attack. So, throughout many CTFs and Challenge Creations, I have made my own methodology.
Assuming you launched AccessData_FTK_Imager_4.7.1.exe and installed the application, you can now launch FTK Imager. To open the disk image provided, go to File -> Add Evidence Item
Select Image File as the type of evidence that is being imported.
Now, just select the .E01 file through the file browser or the Browse button.
Now, in the "Evidence Tree", you can basically see the folders present on the hard disk and you can expand them with the "+" button.
However, to actually see what's in that directory, click on the folder you want and look at the "File List".
So, the methodology starts by asking, "Where do users usually store their files?". Without complicating the whole methodology with Cloud drives which can be made into a blog post by itself, these are the usual places you would find artifacts within a hard disk:
Desktop
Documents
Downloads
It wouldn't be fair if I didn't tell you that there might be multiple users within the victim machine. However, for simplicity's sake, there is only one user for our case. The default users you would see in a Windows machine are:
All Users
Default
Default User
Public
The rest would be actual user accounts such as the Administrator account and in our case, john.kramer aka jigsaw.
Anyway, a common place where users will place their files are within the Desktop because it's convenient. Having only one user on the hard disk, going into john.kramer's Desktop reveals a file called flag.txt giving us our first flag!
Another location where users might store sensitive data is the Documents folder. Now, in our case, there are a lot of documents here, some are .docx files and some of them are .pdf files. In more advanced CTF challenges, these files may contain macros which may execute commands on your machine. However, there are no malicious documents here... yet.
Anyway, the only way to take a look at these files is to export them. So, you can select them one by one or you can select a few of them and Right Click -> Export Files. You can then export them to whatever location you want them to be.
Analysing the files one by one, you'll find the flag within Dinosaurs_Anatomy_Adaptations_Technology.docx !
The last location where you can find an IOC or Indication of Compromise is the Downloads folder. This folder will tell you whether the victim has downloaded a suspicious file or not.
As you can see here, a suspicious file was downloaded onto the victim's machine. This is indicated by the .docx extension followed up by the .exe extension which hides the file's true intention. In more advanced CTFs, the challenge may require you to reverse the aforementioned file. However, in our case, you just need to read the file.
Now getting deeper into the methodology, once a red teamer gains access to a machine through a web application, weak or stolen credentials, they would be normally a low-privileged user. With that said, they would need tools to escalate their privileges. When they escalate their privileges, they might transfer other tools for persistence or tools to do more damage to the victim machine. However, saying all of this, where do red teamers normally transfer their tools to?
The answer to that is world writable directories, these are directories that can be overwritten by anyone who has access to the victim machine. Those directories are normally:
C:\Windows\Temp\
C:\Windows\Tasks\
Within C:\Windows\Tasks we can see a very suspicious file here named dinokiller.exe. Further analysis will be done later on.
As for C:\Windows\Temp\, nothing seems to be suspicious for now...
Could this be a hint towards something?
Unfortunately, blue-teaming challenges will require a blue-teaming mindset. What does that mean? That means a heavy reliance on log files, well most of the time.
For a Full File System acquisition, deleted files are recoverable. So luckily for us, we can go hunting for it. It will be within the $Recycle.Bin folder.
However, as there are multiple users within the machine including non-useable users, their deleted files are separated according to their SIDs or Security Identifiers. Instead of keeping track of usernames, Windows will keep track of users according to their SIDs. From here, it's a trial-and-error game.
So, when you finally find the correct SID folder, you will notice that the file containing the flag has a weird file name. Well, when you delete a file on Windows, it will not store it as its original name. Instead a temporary name will be given to it and a reference to that file's original name will be stored as well.
Now, another way to look for IOCs is through the browser history. This will give you the links users have visited and what they have downloaded as well.
Assuming you have installed DB.Browser.for.SQLite-3.12.2-win64.msi, let's start finding the file that contains the user's browser history. For our case, I'll just be going through Chrome as there will be another challenge that involves Firefox. With that said the locations of the browser history are the following:
For Chrome
For Firefox
Most browsers store the user's browser history in sqlite format, which is basically a portable version of a SQL server. So, export the files mentioned and using SQLite Browser, open the history file for Chrome.
If you have never used SQLite Browser before, it's alright, I'll walk you through it. Once the file has been loaded, go to "Browse Data".
Then under "Tables", select "urls".
In more advanced CTFs, there will be hundreds, if not thousands of records. But for us, a little searching will reveal the flag to us!
Now in context, this can also be done for Chrome. However, for diversity's sake I'll show you how to extract and decrypt Firefox passwords. When you log into a website, your browser will usually ask you whether you want to save your credentials. If you clicked on "Yes", it will be encrypted and saved into a file for you.
To decrypt Firefox passwords, first of all, you need this tool. You can use it on Windows or Linux, but I prefer to use it on Linux.
To download this on Linux, you can just use git
Then, you need to extract this entire directory from the image file.
Finally, use the tool to decrypt the credentials
PowerShell is a command line interface in Windows which is a major upgrade to the Windows Command Prompt. With the upgrade, comes with other features as well. In our case, it involves the record of every PowerShell command ever executed. Whenever a user executes a command in PowerShell, it will be recorded in a file located in:
However, as you can see when we located the file, it contains a weird string. But before you start launching your own PowerShell instance, this weird string can be anything, it could be a command to download malware and execute it and you will see that in more advanced CTFs. Fortunately enough, it isn't and I'm not here to teach you PowerShell.
So, if we can't use our own PowerShell instance, how do we know what does the weird string do? Well, if you know PowerShell, you can write a Python script to deobfuscate the PowerShell script. If you're brave enough, you can load a virtual machine to execute the script there. Lastly, if the script is simple enough and you know a little bit about PowerShell, you can head over to this online PowerShell interpreter.
Copying over the PowerShell script and running it will give us the flag.
From here on out, the flow will be a bit different. First, go into Arsenal-Image-Mounter-v3.11.290 and launch ArsenalImageMounter.exe. This application allows us to mount the image file onto our machine as if it was a drive. It requires some dependencies, so just agree to install what it needs to install.
Just click "OK", you DO NOT need to enter a license key.
From here, click "Mount disk image" and select the image file.
Just make sure the configuration is as such and click on "OK".
Now, we're going to use a different tool called KAPE or Kroll Artifact Parser and Extractor. This tool will help us extract the important system files from the image file so that we won't have to do that manually by going through every single folder and file. In Forensics terminology, this is called a Triage. So, go into KAPE folder and launch gkape.exe.
Once gkape.exe launches, select Use Target Options and deselect Flush.
It is important to DESELECT
Flushbecause if you don't, wherever you chose yourTarget destinationto be, the files within that folder will be DELETED.
Then, select your Target source which is the extra drive that appeared on your machine and choose a Target destination. It is recommended to create a folder specially for the Target destination.
Lastly, search for "Kape" and select "KapeTriage"
Once you have made the necessary configurations, click on "Execute".
Now, you can remove the drive through ArsenalImageMounter.exe.
There is no flag in this section, so I'll understand if you want to skip it. Anyway, this is a gold mine for Blue Teamers. However, what is Windows Prefetch? Windows Prefetch are files within Windows which record the last successful execution of an application. For Windows, it speeds up its performance as its memory manager will just need to read the information from the file and execute the file. For Blue Teamers, it will tell us what kind of executables were launched which will tell us the IOC.
Going into PECmd launch a terminal there.
Before, launching the executable, let me explain what is PECmd. PECmd is a tool made to parse or in simple terms go through Prefetch files. The output will give you the executables that were launched, when they were launched, how many times they were launched and lastly, the DLLs that the executable needs. The prefetch files are located here:
So, within your terminal, this is the command needed to parse ALL of the prefetch files within the prefetch directory. -d is the directory where the Prefetch files are located, --csv is the folder that will be created for the results and --csvf is the file name of the results.
The output file will be a .csv file, and your first instinct is to open this up in Microsoft Excel right? Well, no. There is another tool that was developed for opening .csv files for Digital Forensics purposes. So, go into TimelineExplorer and launch TimelineExplorer.exe.
Once you've launched TimelineExplorer.exe, go to File -> Open and locate where the .csv files are. There will be 2 files, PECmd.csv and PECmd_Timeline.csv. PECmd.csv is the summary of all the executables launched on the machine, meaning there will not be any duplicates. However, PECmd_Timeline.csv will contain duplicates as it will show you the timeline of when each executable was launched.
Analysing PECmd.csv, you will find that the suspicious file we found earlier is present.
Similar to any system out there, whatever you do on a computer whether it's Linux, Mac or Windows, it is logged. For Windows, generally, most activities will be stored within what Windows calls Windows Event Logs. The logs mentioned will be under C:\\Windows\System32\winevt\logs\.
However, the logs are stored in .evtx format, which is a .xml variant. So, for this, we can use a tool called hayabusa. hayabusa is a tool that can parse or go through .evtx files and output them to a .csv for us. At the same time, it uses sigma rules, which basically is a phonebook of malicious activities to determine what, if any, malicious activity was done based on the symptoms or artifacts present.
The basic syntax of hayabusa is as follows:
csv-timeline will analyse the .evtx files and output the results into a .csv file sorted based on the sequence of activities. -d specifies the directory of the logs, and -o specifies the location and name of the output file.
In the context of a CTF, I generally use the 5th detection rule. However, choose whichever based on the challenge.
Again, in the context of a CTF, I generally use this configuration to basically get everything.
Once configured, hayabusa will start parsing the log files and output them into a .csv file. Once done, use TimelineExplorer.exe again to open the .csv file. Right here, based on the challenge, you can filter based on the time, the rules set by hayabusa (It will take some experience to know the specific rule names), the detection level, the computer the logs are from and where the record is from.
You can also filter it by the Event ID, you can Google more on this but basically every event or action in Windows has an ID. You can also filter it by the record ID and lastly if you know what the flag is in the context of the artifact, you can also filter it by the details.
For example, if a challenge asks you to state when a brute-forcing attack was done, you can filter it by the "Rule Title" with "PW Guessing" instead of looking mindlessly at Failed Logons, and there will be a lot in more advanced CTFs. It can detect malicious PowerShell scripts if there's any...
So, when an attacker has access to a machine, they would want to maintain that access. Most of the time they would use the registry to do so. The registry is where Windows store the machines' and user's settings and configurations. Most threat actors will use the following registry keys to maintain access or persistence in a victim's machine:
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce
HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run
HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce
HKEY_LOCAL_MACHINE refers to the machine as a whole and HKEY_CURRENT_USER refers to the current user that is logged on. As we wouldn't know how the threat actor maintains access to the machine, it's best to check all of them. Furthermore, the difference between the Run key and the RunOnce key is that the Runkey will run every time the machine boots up whereas the RunOnce key will run only once in its lifetime let's say for example an installation file which requires the machine to run after it reboots. However, both keys have one purpose, which is to run an executable when the machine boots up.
For this case, the flag will be within the current user's registry. Every user will have a NTUSER.DAT which stores the user's configurations and settings on the machine. It is located in C:\Users\john.kramer. So, if the machine has multiple users, it's important to choose the right user's NTUSER.DAT file.
Now, go into Registry Explorer and launch RegistryExplorer.exe. Once the application has launched, go to File -> Load hive and locate the NTUSER.DAT file.
Just click "No" for this.
And "Yes" for this.
Going to the Registry keys mentioned before reveals the flag!
So, remember the executable we found? dinokiller.exe? Let's do analysis on it! The basic approach to any malware/ransomware is to strings the executable first.
So, if you find any strings in any executable containing the word "python" or "py", that is an indicator that the file is compiled using Python, which means you can recover the source code. Most malware/ransomware are compiled using C, C++ or nowadays Rust, which means you need to go through the process of analysing the executable through a disassembler. However, Python compiled executables are different.
To begin recovering the source code, you need this tool:
Again, you can use git on Linux to retrieve this tool.
Another tool which is required is decompyle3, so using pip, install it like this:
To recover the source code, use pyinstxtractor.py
Now, go into dinokiller.exe_extracted/. What you would notice in this directory is that there is a lot of .pyc files. These are Python-compiled bytecode, which is a type of intermediary code that a compiler creates by translating source code into bytecode.
To decompile it, use decompyle3. As a general rule of thumb, always decompile the .pyc file which has the same name as the executable.
Now, within the context of a CTF, whenever there is a ransomware, there are 2 things to look out for. Most challenges will use AES-256 in CBC mode to encrypt files and AES-256 involves 2 things, the key and the initialization vector (IV). I'm not a crypto guy but just remember you need those 2 things to decrypt any file which is encrypted using that algorithm.
I have no idea why but decompyle3 was unable to recover the key and iv properly so here's the key and iv. (maybe that's why most challenges I did they encode the key and iv with base64 lol)
Looking at the source code again, there seems to be a directory listed there. You can probably take a guess that the executable encrypts the file within that directory with the key and IV specified in the source code. However, to confirm that theory, let's go into that directory back in FTK Imager!
Going to that directory reveals a file and when viewed shows us a weird string which can indicate that it has indeed been encrypted by dinokiller.exe.
Using CyberChef, an online tool to decrypt, and decode things, you can load the encrypted file into the "Input" field and grab the "AES Decrypt" Recipe from the menu on the left which you can get by searching for it. Then you can put the key just as it is as well as the IV into its respective fields and set the Input and Output to "Raw". Doing so reveals the flag!
In conclusion, is this methodology a concrete methodology for all cases? No. However, it does introduce how you should approach a Forensics challenge, where you should tackle it with the mind of a User, a Red Teamer and a Blue Teamer. Furthermore, if you really want to learn more about Forensics specifically realistic cases, go join more advanced CTFs and learn from them, go to HacktheBox Sherlocks and learn. However, if you want more realistic scenarios, you can always build an environment. Basically, what I'm saying is to mess around with stuff and learn from it. With that said, there are a total of 10 flags in the image file given, but only the solutions to 9 of them are given. Can you get the last one?
