FAT Analysis

We all are using the digital devices for storing our files, every day we are using tens of hundreds of files but we need to structure, arrange and organize the files as well. So, we have filesystem that tracks and organizes the files stored on an Operating System. It provides a translation between the files’ locations on the OS and their locations on the physical storage. A filesystem also tracks the file-related changes and options, such as file deletion, file access, file size and more.

Filesystems are an essential component in forensics. Threat actors often abuse it in attacks. Threat actor could use the hidden space within the filesystem to hide files or mark files as deleted.

“Deleting a file doesn’t mean the file is deleted on the physical storage. A forensic analyst needs to know where to find forensic artifacts on filesystems”.

TASK 3 — FAT32: Relevancy in Cyber Security

Previously we got an overview about the filesystems, but we also need to know the types of filesystems. Here, we will discuss the FAT32.

File Allocation Table (FAT) was introduced by the Microsoft when they released the windows 95 Service Release 2 in August 1996. It is very old and an outdated filesystem type, then are we studying the FAT32 when there are updated filesystem types? We need to know that FAT32 is still widely used in the systems. FAT32 is lightweight in design and due to it’s high compatibility with multiple Operating Systems, it has stayed relevant. FAT32 has a file size limit of 4GB and a volume limit of 2TB which some systems still don’t reach like USB storage devices, IoT devices, camera memory storage etc.

Attackers often use USBs formatted with FAT32 due to its high compatibility with different OSs and lack of permissions. FAT32 doesn’t include functionality for folder and file permissions. This means anybody can access a file or folder on a FAT32 partition. This offers attackers some flexibility to abuse FAT32. To analyze the FAT32 filesystem, we need to know the attackers tactics and techniques that can be leveraged to exploit the FAT32 filesystem. Most of these techniques are related to the tactic TA0005 Defense Evasion.

Answer the Questions Below

Q1. What is the name of the attack that targeted the Iranian nuclear program?
Ans: Stuxnet

Q2. What category of tactic is MITRE ATT&CK TA0005?
Ans: Defense Evasion

TASK 4 — FAT32 Structure: Reserved and FAT Areas

FAT32 Structure

A FAT32 partitioned volume typically consists of the following parts:

1. Reserved Area
   The reserved area contains the important filesystem structures required for the volume to function. The reserved sector always starts from sector 0 on the partition and includes:
   - Boot sector: First sector of a disk partition that contains the BIOS parameter Block, bootstrap code, and volume metadata.
   - FSinfo sector
   - Backup boot sector
   - Additional reserved sectors

The table below shows an overview of the different parts of the reserved area

A sector is the smallest addressable unit on a disk. In most cases the size of a sector is 512 bytes. So, if we apply this info to the table above, it means the following:

• The boot sector starts at sector 0 and encompasses 512 bytes.
• the FSinfo sector starts at sector 1 and encompasses 512 bytes.
• Sectors 2 to 5 are reserved sectors. The total size is 4 times 512 bytes.
• The additional reserved sectors start from sector 7 and stretch until the start of the FAT area. We need to analyze the boot sector to determine the complete size of the Reserved Area.

Boot Sector

The boot sector is the first sector (sector 0) on a FAT32 Partitioned volume. It contains the metadata of the partition. This information is essential for the OS toknow how to access the partition, where to look for the File Allocation Table, where the Root Directory is located, and where the Data Region begins. Let’s have a look at the available metadata. The highlighted fields are interesting when doing boot sector analysis.

Let’s take a look at a FAT32 boot sector on the VM. Open the HxD editor by double-clicking the logo on the Desktop. Then navigate to File -> Open and select the FAT32 image located at C:\FAT32_analysis\FAT32_structure.001. After opening the image, you should get a view similar to the one shown below.

The important parts that we need to know to interpret the data correctly:

• ON the left side, the offset (h) column is displayed. This column indicates teh offset position in the partition you are looking at. For example, 0000 0000 is the starting address of the partition. In the current configuration each row shows exactly 16 bytes. So if a sector is 512 bytes, the sector will encompass 32 rows of 16 bytes.
• The first row starting with the address 00 needs to be interpreted together with the offset (h) column. The values refer to addresses. Starting at offset 00000000 you will have the addresses 00000000, 00000001, 00000002, and so on.
• In the second row at 4th byte with the value 4D indicates the value present at that address. For example, the address 00000003 contains the value 4D.
• The Decode Text column contains the translated values read at a certain address.
• The Byte Order field is important. Certain fields’ values can be displayed in Little Endian or Big Endian. This refers to how bytes are read.
• The Data Inspecter screen shows the value in different representations. This way, we don’t have to manually convert it from hexadecimal.

2. FAT Area

The FAT area contains the File Allocation Table (FAT1) and its backup (FAT2) and has the following functions:

• It contains information about the allocation of clusters to a file or directory and the next free clusters.
• It helps with the fragmentation (data sotred in non-contiguous clusters) of files. It keeps track of all the clusters that are assigned to a file.
• It does integrity checking to identify ba clusters and mark them not to be used for storing data. Each entry in the FAT is 32 bits, but only 28 bits are effectively used. It is this 32-bit value that is referenced in the filesystem name FAT32.
• The first sector of a FAT32 volume contains a structure called the BIOS Parameter Block (BPB). The FAT specification defines exactly what each offset means.

Answer the Questions Below:

Q1. We have a hypothetical file B and its cluster chain starts at cluster F and ends at cluster 10 . What would be the value of the FAT entry at cluster F? Provide the value as you would read it in the HxD editor (e.g. 00001111). Note: File B is not a file on the image.
Ans: 10000000

Explanation:

To find the FAT entry at cluster F, we need to find the Reserved sector first and also we need to know from where the FAT starts

So, If we look at the image file, we have an offset 0xOE and its value is 7E 18 (the reserved sector count field is the 2 bytes log field, so it occupies both 0x0E and 0x0F). The FAT32 specification defines BPB_RsvdSecCnt at offset 0x0E and gives it a size of 2 bytes. So when doing forensic analysis, you essentially have a map of the FAT32 boot sector.

As it is in little-endian format, we need to reverse it before finding the decimal value

7E 18 → 18 7E
Therefore, 0x187E = 6270

So, Reserved Sector Count = 6270

• Now, we need to find the Bytes per sector; for that we need to look at offset 0x0B

It also, holds a 2 bytes so bytes per sector field starts from 0x0B and ends at 0x0C. So, the HEX values are 00 02 and we need to find the exact value by converting them into decimals. Because FAT32 stores numbers in little-endian, so it becomes:
0B 0C → 0C 0B
00 02 → 02 00

After converting it in decimal, the offset 0x0200 = 512 bytes.

• Now, we have everything needed to find the start of the FAT. As we have
  studied previously, The first FAT starts immediately after the reserved area. Therefore:
  FAT Start Sector = Reserved Sector Count
  So:
  FAT Start Sector = 6270
  But HxD works with byte offsets, so we need to convert the sector number into a byte offset.
  Therefore:
  FAT Start Offset = 6270 x 512 = 3210240 bytes
  Now, convert it to the Hexadecimal which becomes:
  0030FC00
  Therefore our FAT1 Starts at 0x0030FC00.

We have located the location of the starting FAT1, now we will go back to the question, it says, File B’s cluster chain starts at cluster F and ends at cluster 10.

• Each FAT32 entry is 4 bytes. Therefore, starting at 0x30FC00:
  FAT[0] → 0x30FC00–0x30FC03
  FAT[1] → 0x30FC04–0x30FC07
  FAT[3] → 0x30FC08–0x30FC0B
  …
  …
• F is a hexadecimal and it’s decimal value is 15. Each fat entry is 4 bytes so 15*4=60. 60 decimal is 0x3C. So, the FAT[F] is located at 0x30FC3C.
  Therefore, the actual FAT entry F starts at offset 0x30FC3C and the actual FAT entry is = 00 00 00 00 in an actual image but we have to find the FAT entry of a hypothetical file B.
• The question is giving us a hypothetical scenario. It says:
  File B starts at F and ends at 10. What does the FAT need to contain to represent that. There is a simple FAT rule “FAT[current cluster] = next cluster. We are given here F → 10 → END. Therefore, FAT[F] = 10.
• FAT stores 32-bit value, therefore the value of the FAT entry at cluster F is 10000000.

Q2. Using the FAT32_structure.001 image, answer the following question: At which offset does the FAT2 table start ( give in the offset value without spaces)? Remember, FAT1 starts right after the Reserved Sectors and FAT2 starts right after FAT1.
Ans: 387E00

Explanation:

FAT2 starts immediately after the FAT1. So, To find the offset value of the starting of FAT1 we will use the following formula:

Reserved Sectors + sectors per FAT x Bytes Per Second

In our case,
- Reserved Sectors = 6270
- Sectors per FAT = 961
- Bytes Per Second = 512
Therefore, 6270 + 961 * 512 = 3702272. Now, convert it into HEX and the value is 387E00.

TASK 5 — FAT32 Structure: Data Area

In the previous task we discussed the general structure of the FAT32 filesystem and the Reserved and FAT area’s. This task will handle the the data area.

Data Area
The data area is the part where the root directory and the data region are present. The root directory is similar to an index that stores meta information about the files stored in the data region. The first two clusters of the data area are reserved for system use. These two clusters are not physical clusters but virtual ones. The root directory starts from the third cluster on (cluster 2). It is important to note that since FAT32, the root directory does not have reserved clusters. It will first use the starting cluster and then expand to the following free cluster mentioned in the FAT.
The root directory contains two types of entries: Long File Name (LFN) and Short File Name (SFN).

Long File Name
An LFN entry stores the name of a file. This type of format was implemented due to the limitations of the Short File Name format. A filename could only consist of 8 bytes for the filename, and 3 bytes for the extension. Each LFN entry has a corresponding SFN entry. A filename may be spread amongst multiple LFN entries. To keep track of this, a sequence number is used in the first byte. The first nibble indicates whether the entry is the last or if the entry has been deleted. The second nibble indicates the sequence number.

Short File Name
A SFN entry stores a file’s attributes and its starting cluster. This value is then used to find it’s corresponding FAT entry.

Answer the Questions Below:

Q1. What is the filename of the file that starts at cluster 9?
Ans: Careers.txt

Explanation:

Somewhere in the directory, there is an entry describing a file. We need to find the directory entry whose starting cluster is 9. Then we read the filename from that entry.

Previously, we have calculated the Reserved sector, bytes per second and number of sectors. Now, we have to calculate where the data region begins.

The data region comes after both FATs.

Therefore: First Data Sector = Reserved Sectors + (FAT Size x Number of FATs)

First Data Sector = 6270 + (961 x 2) = 8192

So: The data region begins at sector 8192.

Now, convert Sector 8192 to a byte offset

Each sector is: 512 bytes
Therefore, 8192 x 512 = 4194304 bytes
Convert it to HEX
4194304 → 0x400000
Therefore: 00400000 is the beginning of the data region.

The cluster 9 begins from 0x400E00 and it carries the content written inside the file. In the below screenshot, we can see the filename in the directory entry : 004001C0

Q2. What is the creation time of the file that starts at cluster 9? Please provide the hexadecimal value of the Creation time field.
Ans: F484

Explanation:

In the previous question, we found the file name and now we need to find the creation time of the file. In SFN, we know that the filename carries 8 bytes and it’s extension carries 3 bytes. Following table gives us the information of the specific offsets:

As our primary goal is to find the Creation Time, so we will focus on it. The creation time is 2 bytes long and starts from 0x0E and ends at 0x0F. The offset of the directory entry of the filename we found earlier is: 004001C0. In the below screenshot we can see the exact bytes of the filename 0x00–0x0A.

From the table above, the creation Time field is 0x0E — 0x0F.

TASK 6 — Analysis Techniques & Tools

There are many techniques for analyzing the FAT32 filesystem. These techniques are not unique to the FAT32 filesystem and can also be used to examine different filesystems. We can divide these techniques into roughly two categories: file system integrity and structural analysis and data recovery and content analysis. In the next tasks, we will do a hands-on activity to explore the more commonly used techniques.

File System Integrity & Structural Analysis
This category focuses on detecting corruption, tampering, and anomalies in the filesystem by analyzing its metadata, structural consistency, and organization. More often than not, we will combine several techniques to do our analysis. The table below shows each technique we can apply to the FAT32 filesystem, together with the fields needed and a short description of what the technique encompasses.

Data Recovery & Content Analysis
This section focuses on the recovery of deleted and hidden data, checking data in allocated and unallocated spaces, and searches for specific content patterns. We can combine multiple of these techniques to ensure a holistic analysis. The table below shows each technique we can apply to the FAT32 filesystem, together with the fields needed and a short description of what the technique encompasses.

Answer The Questions Below:

Q1. Which analysis technique can we use to look for hidden files and directories?
Ans: Directory Structure and File Name Analysis

TASK 7 — T1564.001 Hidden Files and Directories

Many attackers set the malicious files hidden or avoid the file deletion from the user. This happens because some users have not enabled show hidden files on their OS. Let’s take an example, suppose a user finds a USB on a road, he goes straight to the room and opens his laptop and inserts his USB; When he opens a USB he doesn’t finds anything on the USB so he get’s happy I have got a free USB but on the other side the attacker is happy and delighted that the user took the bait because the attacker had a malware hidden on the USB.

In FAT32 filesystem, its easy to alter a file’s attributes because there is no permission system implemented on FAT32 filesystem.

Here, we have two types of analysis:

• Manual Analysis
• Automated Analysis

1. Manual Analysis: In manual analysis we analyze the SFN entries in the root directory. This can be done by applying the Directory Structure and File Name Analysis technique, which we have studied in the previous task. In task 5, we already saw how we can find the details of any hidden file by analyzing the SFN entries in the root directory and now, in this task we will use the automated analysis.
2. Automated Analysis: Manual analysis can be quite lengthy. It is also prone to mistakes during the various calculations that need to be made. To speed up our analysis, we can use automated tools. We will use Autopsy to analyze the FAT32_HIDDEN image and find the relevant forensic artifacts.

In automated analysis we will use the Autopsy tool for the forensic analysis of the image. To create the case and load the image, follow the task writeup given in the task. Once the image is loaded and we will start the analysis.

Once the image is loaded, we can see the data sources by expanding the data sources section. When we expand our loaded image, we can see the multiple directories inside the image. We can analyze every directory but for now there is an interesting directory worth to be analyzed M@LOv3. Let’s click on this directory and see what’s inside there.

Once we click on the directory, it opens a page right below the directory structure, which contains the 3 important fields; Hex, File Metadata and Annotations. The Hex field shows the raw data in the hexadecimal format. Also, we can see the LFN and SFN there as well which we will be discussing further.

After clicking on the File Metadata field, we see File Attributes under the From The Sleuth Kit istat Tool, which shows us the file permissions are only Read Only, It is a Directory and is Hidden. Also, we can see the timestamps there, when the file was last accessed, when it was written or modified.

Answer the Questions Below:

Q1. What is the short file name of the hidden file in the M@lL0v3 directory?
Ans: BEMYVA~1

Explanation:

Get Red_Ghost’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In the Hex Tab if we look at the SFN entry of the directory we can see the SFN of the hidden file in the M@1L0v3 directory.

Q2. What is the flag found during automated analysis?
Ans: THM{F0uNdTh3H!Dd3nF1l3}

Explanation:
Now, we will see what’s inside the directory, which files the hidden directory has stored. For that we need to enter in the directory highlighted in the below screenshot:

Here we can see 2 folders and a file. We, can see the Modifed Time, change Time, Access Time, Created Time, Size etc here. As we can see a file whose SFN have been found in the previous question. Let’s double click on this file and take a look at it’s content.

Oh! Look what we found, it’s a flag we were looking for

This is how we can use an automated tool like Autopsy to do the Automated Analysis.

TASK 8 — T1070.006 Indicator Removal: Timestomp

Attackers will often change the timestamps to evade the detection. There are several types of timestamps attacker can modify:

• Creation Time
• Last Access Time
• Modify Time

Depending on the attacker’s goal, he will change one or multiple of them. Some examples:

• An attacker edits a legitimate configuration file on the lab machine. To ensure the changes are not easily picked up, he alters the Last access time and the Modify time.
• An attacker adds a new file to a folder, checks the timestamps of the other files, and modifies his file accordingly so the timestamps are similar.

Depending on the sophistication of the attacker, he might make some mistakes while altering timestamps. Some examples are:

• The creation timestamp is later than its last modified or accessed timestamp.
• The timestamps are very old or recent compared to other files in the folder.

Detecting time stomping is not always easy, even less so with FAT32 since it doesn’t implement journaling. There are some key detection techniques we can use:

• We can cross-reference the file’s current timestamps with other log records of the file’s timestamps. For example, we can use Windows Event logs and compare them with data we retrieved from the image.
• We can implement tools that monitor file integrity.
• We can focus on detecting tools that can alter timestamps like timestamp.exe. We can focus on looking for inconsistencies in the timestamps, such as the creation time being later than the last accessed time.

For timeline analysis, we can use manual analysis or Automated Analysis like we did in previous task. For Manual Analysis, we will use HxD editor tool and for Automated Analysis, we will use our favourite tool Autopsy to make the analysis automated.

Answer the Questions Below:

Q1. What is the Accessed timestamp of the discovered suspicious file?
Ans: 2018–01–10 00:00:00

Explanation:

Let’s start by creating a case same as we did in the previous task. Once the case is created load the Timestomp image in the Autopsy and then we will begin our analysis.

We will utilize the incredible tool included in the Autopsy specifically for Timestamp Analysis i.e., Timeline

The below screenshot opens the Timeline Tool and here we need to do some configurations which can make our analysis easier. Like we will change the scale to Linear as it helps us seeing the number of events for any given year easier.

Before we continue analyzing, it is important to note that you should configure the Display Times In option according to the standard you agree on with your team. You should be consequent with the chosen option, as it can alter the analysis results significantly. If your team only works in one location without any 3rd parties, it would make sense to configure it to Local Time Zone. This way, the timestamps can easily be matched with, for example, working hours.

In the year 2018, If we look at the left bottom file, we will see only one file which was accessed.

This way we can leverage the autopsy to find the timestamps of any files that has been made by the attacker or any individual.

Now, you all will be wondering how I identified this file. In 2018 we can see that the install.txt file was accessed in 2018 and if we keep looking this file in other years and we will see the file event in 2025 where it has been created. It shows that if the file has been accessed in 2018 then how it is possible that this same file has been created in 2025.

So, we can conclude that this file’s timestamp has been changed by the attacker.

Q2. What is the flag found during the automated analysis?
Ans: THM{T1m3St0Mp3D}

Explanation:

As we have identified the suspicious file and the changes that are made by the attacker. So, now we will check the contents of this file, as it makes me wonder why the attacker changed the timestamps of this file. There must be something suspicious that the attacker is trying to hide. So, let’s click on the file and check the content inside the file.

What!!!!!!!!!!! We were looking for a flag and we found exactly inside this file install.txt.

I hope, after doing this basic analysis you all are now familiar with how timestamps can be analyzed by leveraging the autopsy.

TASK 9 — T1070.004 File Deletion and T1070.009 Clear Persistence

MITRE ATT&CK techniques T1070.004 File Deletion and T1070.009 go hand in hand. An attacker will delete any evidence that could be traced back to them, or that could help a defender undo the attack. Clearing persistence is broader than just deleting files on disk, but for the context of this task, we will narrow the scope to detecting persistence on a FAT32 partition.

In this task we will analyze a FAT32 image that contains deleted files and retrieve its contents. We will start with manual analysis by opening the FAT32 image in the HxD editor, then continue with automated analysis using Autopsy.

Manual Analysis
Continuing with the VM, open the HxD editor, navigate to the menu bar, click file, and then open. Navigate to the C:\FAT32_analysis\ directory, select the image FAT32_DELETED.001, and click Open.

Navigate to offset 00400000 by pressing CTRL+G and entering the offset value. Similar to the image in the previous task, the root directory is spread over multiple clusters. In this FAT32 image, the clusters assigned to the root directory are non-contiguous. We have to look at the FAT table entries to deduct where the root directory entries continue—the FAT entry for the root directory points at cluster 17. So, we should find the next root directory entries starting from cluster 15 (17 minus two virtual reserved clusters). Cluster 15 starts at offset 00401E00.

Now that we have located all the root directory entries, we can analyze them and find deleted files. We are looking for entries starting with the hexadecimal value E5. Below is an overview of all the SFN root directory entries. For each entry, we listed the filename and the hexadecimal value. Additionally, we have highlighted the deleted entries.

The highlighted entries are worth investigating. A first look shows that they are LFN and SFN entries. Inspecting the filename, they seem linked. Let’s have a closer look at the SFN entry.

Findings
The SFN entry refers to cluster 28 as the starting point for the file’s content. We can recover the content of the deleted file by navigating to cluster 28, which starts at offset 00403400, as shown in the image below.

Automated Analysis
Similar to the previous tasks, manual analysis takes some time and is prone to mistakes during the various calculations. The image provided for this task was also adjusted to make it easier to find the deleted files. In reality, the size of the partition and the number of files and directories are much larger. Doing manual analysis would take up too much time. A tool like Autopsy can make this much easier for us. Let’s analyze the image with Autopsy.

Open Autopsy, create a new case and add the image FAT32_DELETED.001 as a Data Source (similar to what we did in task 7).

Similar to the previous task, we can explore the structure of the image by navigating to Data Sources, FAT32_DELETED.001_1 Host, FAT32_DELETED.001. We can then explore the folders and list their details.

There are two locations where we can look for the deleted files:

• The directory where the file was deleted.
• The $RECYCLE.BIN directory.

Once the Image is loaded we can see the following interface and we need to enter in the directory containing the files

Answer the Questions Below:

Q1. Which hexadecimal sequence identifies a deleted file?
Ans: E5

Explanation:

As we have read previously, Every deleted file entry starts with the E5 as mentioned in the screenshot below:

Q2. What is the output of the deleted PowerShell script after executing it? Note: In real-life investigations, we will only execute a suspicious file in a sandboxed environment.
Ans: THM{r3Tr!3v3D_3v!d3nC3}

Explanation

In the manual analysis, we have identified the deleted file and when we moved to the cluster 28 and we saw the content of the deleted file which was some powershell script type something. If we run that script in the powershell we will get the flag.

We can do this via Automated Analysis using Autopsy as well. What do we need to do is to load the image, jump the recycle bin folder of the image because every deleted file is stored in the Recycle bin. There we will find some files

Just copy the content and run it in the powershell as .ps1 file or you can also extract this file also

After running the powershell script and boom we got what we were looking flag, the most precious thing in the cybersecurity challenges, the one and only The Flag!!!!!!!!!!!!!!!!!!!!!!!!!!!

Note: I have saved the content I copied from the Autopsy as exploit.ps1, so don’t get confused.

TASK 10 — Challenge

The THM SOC has retrieved an image from a compromised system and has submitted it to the forensic analysis team for further investigation. As a forensic analyst, you are tasked with analyzing the submitted image and discovering relevant forensic artifacts. Please answer the questions below to complete the investigation (if you want a more demanding challenge, you can answer all the questions using only the HxD editor.)

Image details:

• Name: FAT32_CHALLENGE.001
• Location: C:\FAT32_analysis

Answer the Questions Below:

Q1. At which offset does the FAT1 table begin? Fill in the complete offset number XXXXXXXX.
Ans: 0020FC00

Explanation:

Here, we need to find the offset value from where the FAT1 table begins, For that we need to follow the following steps:

1. We need to find the Reserved Sector Count of the image:
   - Reserved Sector Count is the 2 Byte Field that starts from the offset 0x0E to 0x0F
   -So, In our case it will be 7E 10, after converting it into big endian it will become 7E 10 → 10 7E and it’s decimal value is 4222
   Therefore, The Reserved Sector Count is 4222

2. Now, The second step will be to find the Bytes Per Second:
— Bytes Per Second count is also a 2 Byte Field that starts from an offset 0x0B to 0x0C
- So, In our case it will be 00 02, after converting it into big endian it will become 00 02 → 02 00 and it’s decimal value is 512
- Therefore, it has 512 bytes per second.

3. The Third Step will be to find the FAT Start Sector. As we have studied in the previous tasks that FAT Start Sector is equal to the Reserved Sector.
— Therefore, the FAT Start offset = 4222

4. The Fourth Step will be to find the FAT Start Offset, which is equal to the Reserved Sector Count * Bytes Per Second
— Therefore, FAT Start Offset = 4222 * 512 = 2161664
— Convert it to the hexadecimal which gives us 0020FC00

Q2. What is the name of the hidden directory on the image? (Excluding the System Volume Information folder and the Recycle Bin).
Ans: Exfiltrated_Data

Explanation:

Load the image in the Autopsy and expand the images. As we have previously studied that, If we click on the file/directory and check the metadata, we will see there the attributes value will be shown as hidden. So, here as well we will use the same approach.

I searched over every directory and I found the user mary under the users directory there I found a directory which i found interesting, as it was named as exfiltrated data which is clearly looks suspicious by name. So when i further drill down the file I found an hidden attribute under the “From The Slueth Kit istot Tool” section in metadata as mentioned in the screenshot.

Q3. What is the flag found in the hidden directory?
Ans: THM{D@t@3xf!lL}

Explanation:

In the Q2. we found the hidden directory. Now, we will explore this directory what we will find inside the directory and there I found 2 files exfil.zip which definitely carries the exfiltrated data but now, we are interested in the second file i.e., flag.txt. Double click on the file and boom we got the Flag!!!!!!!

Q4. What is the size (bytes) of the archive file in the hidden directory?
Ans: 10862

Explanation:

As in the Q3, while looking for a flag and I found 2 files there. Flag.txt and exfil.zip. Here we are asked about the size of the archive/zip file. I simply, clicked on the exfil.zip and it’s right side i found a size column.

Q5. What is the name of the deleted file that is present on the image?
Ans: Reverseshell.py

Explanation:

On the left hand side of the Autopsy, there are multiple sections like data sources, file type etc. Right over there is a section named as Deleted Files. There, I found 2 options File System and All. So, I clicked on both to check what it contains inside and I found the only one file located inside both of these directories. So, attacker could have first installed a reverseshell once he has achieved his objectives, he must have deleted this file to remove his persistence inside the system.

Q6. What is the flag included in the deleted file?
Ans: THM{B@ckD00rF0unD}

Explanation:

In Q5. We found the deleted file as now we have recovered the file so it’s important to check it’s content and know the reason why attacker deleted it and what was the content of this file and know the intention as well. So, to get the content of the file, simply right click on the file and extract it to your Desktop then open in any editor as I opened in the notepad and here I found the desired flag.

Q7. What is the name of the file that has suspicious timestamp(s) (name.extension)?
Ans: Legal_Affairs_Notes.txt

Explanation:

In previous Tasks, we studied that there is a tool in the autopsy that is specifically developed for timestamp analysis. As we know the attacker could try to change the timestamps to evade the detections but he can made mistakes as well. So, in this question I utilized the timeline tool and I found the changes were made for the different files in 2 years. 1 is 2020 and the recent changes were made in 2025. I 2020 I found a change made in only one file as mentioned in the screenshot, On this date it was last accessed.

And in 2025 the same file was modified so this huge 5 years of gap is a clear suspicious indication of timestamp modification.

Q8. What is the flag included in the file with suspicious timestamps?
Ans: THM{D@t@g@tH3r!nG}

In the same page we opened previously where we saw the file created timestamp of the Legal_Affairs_Notes.txt, now we will check it’s contents. On the bottom right side corner, there the content is being displayed and I clearly spotted the flag and finish this room with this flag.