Disk Image Forensics Write Up
Recovering a Deleted Encrypted Archive with Autopsy and CyberChef
Challenge summary :A workstation disk image appeared to contain ordinary cleanup and handover files. The objective was to find an important item that had been removed before review. The investigation recovered a deleted encrypted ZIP file from the NTFS file system. The password was reconstructed from Base64 clues found in browser history and PowerShell history. The decrypted token revealed the final flag.
Figure 1. Starting a new Autopsy case
Explanation and steps
This screenshot shows the first New Case Information window in Autopsy. A new case is required so Autopsy can store the database search hits extracted files and analysis results in one organized folder.
The case type was kept as Single User because the evidence is one workstation disk image. The base directory points to the working folder where the case data will be stored.
At this stage the investigator only needs to choose a clear case name and press Next. No command line work is required.
Figure 2. Confirming the case folder
Explanation and steps
This screenshot shows the same case information step with the working folder selected. The base directory is important because Autopsy will create its case database inside that location.
A simple case name such as disk_forensics is enough. The optional page can be left empty because the challenge does not require examiner information or agency information.
After confirming the case name and location the next action is to press Next and then Finish on the optional information page.
Figure 3. Creating the case database
Explanation and steps
Autopsy started creating the case database. This database stores parsed file system records artifact results and keyword search data.
The progress window must finish before adding the evidence. Waiting here avoids partial setup and keeps the investigation stable.
After the database is created Autopsy opens the Add Data Source wizard.
Figure 4. Selecting the host option
Explanation and steps
Autopsy asked how to organize the host. The default option Generate new host name based on data source name was selected.
This option is correct for a single disk image because the host name can be generated automatically from the evidence source.
No custom host name is needed. Pressing Next moves to the data source type and file selection stages.
Figure 5. Choosing the disk image as evidence
Explanation and steps
The raw disk image DISK.dd was selected as the data source. This is the extracted disk image from the provided challenge ZIP file.
The timezone was set to Asia Amman. This makes file times easier to read in the local investigation context. Sector size was left as Auto Detect because Autopsy can identify the file system layout automatically.
The BitLocker password and hash fields were left empty because the image was readable and no known hash set was needed.
Figure 6. Adding the disk image
Explanation and steps
Autopsy began adding the selected DISK.dd file to the case. This step reads the partition table and prepares the file system for analysis.
The message about known file search not being executed is not a problem. It only means no known hash database was supplied.
The important part is that the disk image is now being processed and file analysis will begin after the data source is added.
Figure 7. Initial analysis progress
Explanation and steps
The disk image was successfully added and Autopsy started ingest analysis. The left panel now shows Data Sources File Views Data Artifacts Analysis Results OS Accounts Tags and Reports.
The progress bar at the bottom shows that analysis is still running. Even while it is running Autopsy can already show some file system entries and deleted files.
For best results it is better to wait until analysis reaches a higher percentage before relying on all artifacts.
Figure 8. Opening File Views
Explanation and steps
The File Views section groups evidence into useful categories. This is faster than manually browsing every folder in the file system.
Because the challenge says something important may have been removed before review the Deleted Files category is the most relevant place to check first.
Opening Deleted Files prepares the investigation to find files that were removed from the workstation before review.
Figure 9. Finding the deleted archive
Explanation and steps
Inside File Views then Deleted Files then File System Autopsy displayed a deleted ZIP archive named Possible_Flag_.zip.
The file is marked as deleted and unallocated. This means the file was removed from the active file system but its content was still recoverable from the disk image.
The archive size is about 49945 bytes which confirms it is not an empty artifact. This was the key recovered item.
Figure 10. Saving the recovered deleted file
Explanation and steps
The deleted file was extracted from Autopsy to an Export folder. This creates a safe copy of Possible_Flag_.zip outside the disk image.
The original filename was kept so the recovered evidence can be matched to the Autopsy result.
After saving the file the next step is to open the archive and inspect its contents.
Figure 11. Opening the recovered archive
Explanation and steps
Windows Explorer opened the recovered ZIP archive and showed three files named attachment.bin case_context and final_review_token.
Get kynxsoft’s stories in your inbox
Join Medium for free to get updates from this writer.
The Password column showed Yes. This proves that the archive contents are encrypted and require a password.
At this point the investigation changes from deleted file recovery to password clue recovery.
Figure 12. Entering the ZIP password
Explanation and steps
When final_review_token was opened Windows requested a password. This confirmed that the file could not be read until the correct archive password was recovered.
The password was not brute forced. Instead the investigation looked for user activity artifacts such as browser history and PowerShell history.
This method is better in a forensic challenge because the password was intentionally hidden in the disk artifacts.
Figure 13. Recovering the final token
Explanation and steps
After entering the correct password the final_review_token text file opened successfully.
The text content revealed the flag CrypteraCTF{Y0u_4r3_Th3_B3st_D1g1t4L_F0r3ns1cs}. If the challenge platform is case sensitive the flag should be copied exactly as it appears in the recovered token.
This confirms that the lost item was the deleted encrypted archive and that the decrypted token was the final objective.
Figure 14. Reviewing normal metadata artifacts
Explanation and steps
The Metadata artifact view showed ordinary files such as report_attachment_index.pdf and cleanup_summary.pdf.
These files match the cleanup and handover theme in the challenge description. They provide context but do not directly reveal the password.
The useful password clues were found later in browser and PowerShell artifacts rather than in these normal PDF metadata entries.
Figure 15. Searching for the first password clue
Explanation and steps
A keyword search was run for data_b64. Autopsy found one result inside a browser History artifact.
The preview contained data_b64=MHhLSEE=. The parameter name indicates that the value is Base64 encoded.
The value MHhLSEE= was copied as the first encoded password clue.
Figure 16. Opening the keyword hit list
Explanation and steps
Autopsy placed the result under Analysis Results then Keyword Hits then Single Literal Keyword Search then data_b64.
This view confirms that the data_b64 search had one hit. The source name was History which points to browser activity.
Finding this clue in web history shows that part of the password was left in a visited URL or internal portal link.
Figure 17. Reading the first encoded value
Explanation and steps
The detailed preview showed data_b64=MHhLSEE=&mode=preview.
Only the value after data_b64= is decoded. The value is MHhLSEE=.
Decoding MHhLSEE= from Base64 gives 0xKHA. This became the first part of the ZIP password.
Figure 18. Searching for the second password clue
Explanation and steps
A second keyword hit was found in ConsoleHost_history.txt. This file is PowerShell command history stored under the user profile in AppData Roaming Microsoft Windows PowerShell PSReadLine.
The text pane showed a PowerShell command using FromBase64String with the value TElMMjAwNCE=.
This is a strong clue because the user previously decoded a Base64 string. The value TElMMjAwNCE= was copied for decoding.
Figure 19. Decoding the second clue in CyberChef
Explanation and steps
CyberChef was used with the From Base64 operation. The input was TElMMjAwNCE= from the PowerShell history file.
The output was LIL2004!. This was the second part of the archive password.
The full password was created by joining 0xKHA from browser history with LIL2004! from PowerShell history. The final password was 0xKHALIL2004!.
Complete Investigation Flow
1. Create a new case in Autopsy and add DISK.dd as a disk image data source.
2. Wait for ingest analysis to identify file system entries deleted files and artifacts.
3. Open File Views then Deleted Files then File System.
4. Locate Possible_Flag_.zip which is marked as deleted and unallocated.
5. Extract Possible_Flag_.zip from Autopsy to a local export folder.
6. Open the ZIP archive and confirm that the internal files are password protected.
7. Search Autopsy for data_b64 and find MHhLSEE= in Chrome History.
8. Decode MHhLSEE= with CyberChef From Base64 to get 0xKHA.
9. Search for the PowerShell Base64 value TElMMjAwNCE= inside ConsoleHost_history.txt.
10. Decode TElMMjAwNCE= with CyberChef From Base64 to get LIL2004!.
11. Join the two decoded strings to form 0xKHALIL2004!.
12. Use the password to extract final_review_token and read the final flag.
Conclusion
The lost item was not an active visible document. It was a deleted encrypted ZIP archive recovered from the NTFS file system. The archive password was not guessed. It was reconstructed from two Base64 artifacts left in workstation history. This is why the solution depends on both deleted file recovery and user activity analysis.
Final flag: CrypteraCTF{Y0u_4r3_Th3_B3st_D1g1t4L_F0r3ns1cs}
![[Flagyard Training Labs] Technical Report: ViewOnce (Hard Web)](https://miro.medium.com/v2/resize:fit:1358/format:webp/1*Iwp7nwPEXTyM7hIIrQEQHw.png)
