Diskrupt THM | Writeup

INTRO

After a series of walkthroughs on analyzing MBR, GPT, and File systems such as NTFS and FAT32 with file carving for data recovery, a new CTF room focused on analyzing disk images for forensics and data recovery has just been released. You can try out the room here:

TryHackMe | Diskrupt

Storyline

An underground research group, NexgEn e-Corps, has been working on a groundbreaking research paper on Quantum-Resistant Cryptography. The paper introduces a new encryption algorithm designed to resist quantum attacks. This research is a game-changer capable of securing global communications from quantum-powered adversaries.

Last night, the system sent an alert regarding the research paper being accessed from an unknown system on the network. The suspicion is on the newly joined intern Fatima, who has been seen around the research lab a few times.

She, being the insider with direct access to the laboratory resources, is suspected of stealing the research and attempting to erase all traces of her actions.

The forensics team has taken an image of her disk, but an unexpected system failure left behind fragments of critical evidence on her workstation and external storage devices.

1. What are the corrupted bytes in the boot sector that caused the disk to be damaged?

Opening the disk image labelled challenge.001 in a hex editor, we see this:

Boot Sector

I have limited the image size to only show the first 512 bytes of the disk image, which is the entirety of the boot sector. Looking at the last 2 bytes, “AC BD”, we see the culprit that prevents the disk from loading. The last 2 bytes of the disk image should be the MBR signature, “55 AA”, indicating that MBR has ended. Without these 2 specific bytes, the system would fail to load the disk and read its contents. Make sure to change these 2 bytes and save the changes to allow other tools to analyze the image successfully.

Fixed Boot Sector

Ans: ACBD

2. What are the bytes representing the total sector of the second partition? (Little Endian)

The partition table sits in between the bootloader code (First 446 bytes) and the MBR signature.

Highlighted Partitions

Highlighted above are the partitions. There are two existing partitions on the disk, and the size of each in sectors is highlighted in black. Since we are interested in the second partition, the size is hex “00 78 38 01”. However, this is in little-endian value, meaning the least significant value starts from the left. We have to convert it to big-endian by reversing the bytes to get
“01 38 78 00”.

Ans: 0x01387800

3. What is the size of the first partition in GB? (up to 2 decimals e.g: 15.25)

From above, if we highlight the bytes representing the number of sectors of the first partition, hex editor helps us to automatically convert it from little-endian to decimal.

Number of sectors of first partition

The image is a bit small, but the value converted is 63 401 984. This gives us the size of the first partition in sectors, and since each sector is 512 bytes, the size in Gigabytes would be:

63 401 984 sectors * 512 bytes = 32.46 Gigabyte (2d.p.)

However, the answer requires that we convert it to Gibibyte instead, so using an online convertor, you would get 30.23 GB.

Ans: 30.23

4. What is the size of the second partition in GB? (up to 2 decimals e.g: 15.25)

Using the same methods as above, we would get a size in sectors,
20 477 952.

20 477 952 sectors * 512 bytes = 10.48 Gigabyte (2d.p.)

Converted to Gibibytes would be 9.76 GB.

Ans: 9.76

5. In the NTFS partition, when was the text file related to the password created on the system?

For analysis of the NTFS partition, we would need to make use of automated tools.

1. Open the FIXED disk image in FTK imager.
2. Locate the Master File Table ($MFT) and extract it

Master File Table Extraction

3. Open CMD in the EZTOOLS directory (containing the tools we need) and run the command:

MFTECmd.exe -f ..\Evidence\$MFT --csv ..\Evidence\ --csvf MFT.csv

After that, a file named MFT.csv should be created inside the Evidence directory. Open it in Timeline Explorer for analysis. Since we are searching for a .txt file related to passwords, we can use these criteria as filters.

Password file creation date

Ans: 2025–03–19 22:01:57

6. What is the full name of the sensitive pdf document accessed on this disk?

For this particular question, there is residual data in the second partition, the FAT32 partition, although the file had been deleted. By viewing the root folder of that partition, we would be able to find the answer we are looking for.

Sensitive PDF name

Ans: Quantum-Resistant Cryptographic Algorithms.pdf

7. When this file was first found on this disk?

When I tried manual analysis to find out the creation date of the file, it turns out the file’s metadata had been edited and the creation date falsified in the FAT32 partition. However, since we know the name of the file, perhaps we could filter the MFT table to look for any records of similarly named files.

Sensitive PDF .lnk File

After applying the filter, the only file that came up with the same name was a .lnk file. On Windows, .lnk files are also known as shortcuts and allow files to be easily accessed without needing to navigate to the specific directory containing the original file. Trying the creation date, we get a correct answer!

Get Domon’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Ans: 2025–03–20 00:44:37

8. What is the entry number of the directory in the Journal that was created and then deleted for exfiltration purposes on the disk?

For this question, we must first extract the USNJRNL from the NTFS partition. This journal keeps an audit trail (log) of all actions performed on files in the NTFS partition.

1. In FTK imager, navigate to [root], $Extend then $USNJRNL. Make sure to click on $USNJRNL to see its contents
2. Extract the $J file only

$J File Extraction

3. Open CMD in the EZTOOLS directory (containing the tools we need) and run the command:

MFTECmd.exe -f ..\Evidence\$J --csv ..\Evidence\ --csvf J.csv

Open the newly generated J.csv file in Timeline Explorer. From the question, we can filter results to contain only directories, no extensions and have update reasons of FileDelete. If you were to search for values in the Name column using partial keywords of data or exfiltration, you would find a directory appropriately named data Exfil.

Alternatively, when I was enumerating the disk image and clicking through the files on the FAT32 partition, I stumbled upon a zip file with this message:

[CONFIDENTIAL]
Internal Memo – Final Stages

The operation is nearing completion. The files from the research department have been copied as planned. The document titled **”Confidential_Research.docx”** contained everything we needed. I made sure to clean up any obvious traces, but I must ensure that no logs remain on the system.

### **Steps Taken:**
- Extracted the required data from the main disk partition.
- Created a backup ZIP (`stolen.zip`) and stored it on the external drive.
- Removed all directory entries pointing to the ZIP file.
- Cleared the prefetch cache to minimize traces.
- Overwrote sections of the FAT table to make recovery difficult.

The access logs show minimal interactions under my profile. However, I noticed some anomaly logs related to external media access. I need to double-check **$MFT** and **$LogFile** for any inconsistencies.

### **Contingency Plan**
If anything goes wrong, the final failsafe will trigger at 12:00 UTC. The hidden location contains an encrypted volume with backups of essential materials. If recovery attempts are detected, I will wipe it remotely.

Any unintended recovery attempts should be stopped immediately. If forensic teams recover anything, they will still need the final **decryption key** to make sense of it.

**Key hint:** It is hidden inside the last known document I worked on.

— -

This should be my final entry before I execute the plan. To confirm, below is the flag for you to keep it secret.

[REDACTED]

The exfiltration was done by compressing all exfiltrated files into a zip file. If we try filtering the journal for .zip extensions, we are left with only a few results:

What stands out among the results is a plainly named New Compressed (zipped) Folder.zip. If we scroll over to the Update Reasons column, we find out that the last update made was RenameOldName. RenameOldName entries store the old name in the Name column, and that is why we don’t see the new name, which perhaps could be stolen.zip. Filtering the Entry Number column by the Parent Entry Number discovered, we find our directory:

Ans: 163896

9. What is the starting offset of the first zip file found after the offset 4E7B00000?

Heading to our hex editor, let's go to the offset specified first.

Seems we are placed at the start of a PNG file. We are looking for the first zip file starting from where we currently are. Different types of files have different file signature headers. According to a great resource:

50 4B 03 04 14 00 06 00 PK……
DOCX, PPTX, XLSX Microsoft Office Open XML Format (OOXML) Document
NOTE: There is no subheader for MS OOXML files as there is with
DOC, PPT, and XLS files. To better understand the format of these files,
rename any OOXML file to have a .ZIP extension and then unZIP the file;
look at the resultant file named [Content_Types].xml to see the content
types. In particular, look for the <Override PartName= tag, where you
will find word, ppt, or xl, respectively.

Trailer: Look for 50 4B 05 06 (PK..) followed by 18 additional bytes
at the end of the file.

We are looking for a file with the starting header signature of 50 4B… For my search, I prefer to enter the first 6 characters, so I will be searching for a string of characters of exactly “50 4B 03"

Ans: 4E7B0E000

10. What is the ending offset of the zip file?

Trailer: Look for 50 4B 05 06 (PK..) followed by 18 additional bytes
at the end of the file.

Scrolling to the end of the zip file, we want to count exactly 18 bytes after PK.. or in hex would be after “50 4B 05 06”.

Ans: 4E7B0E43D

11. What is the flag hidden within the file inside the zip file?

Using the Select block tool under Edit, we can copy the entire zip file in hex from the starting offset to the ending offset that we have found. Click on File in the hex editor and New. Paste the copied hex values. Go to File, Save as… and save the new file as secret.zip.

Extract the saved zip file, and inside the extracted directory will be a .txt file containing the flag!

Ans: FIND THE FLAG YOURSELF!

12. In the FAT32 partition, a tool related to the disk wiping was installed and then deleted. Can you find the name of that executable?

The simplest way to answer this is to go to the root folder of partition 2, the FAT32 partition, using FTK imager and you will find a deleted executable named DiskWipe.exe!

Ans: diskwipe.exe

CONCLUSION

Great room that tests all the fundamental skills needed to be a good digital forensics investigator regarding disks. Learnt a lot from this room, and it was a great room for testing all the skills attained from the series of previous disk forensics rooms! Some complaints for this room would be specifying the size of the partition to be Gibibyte instead, as I was stumped for a long time thinking GB meant gigabyte. Thanks to TryHackMe and Dex01 for this great room! 👍👏