I can't remember my password! (dfchallenge.org CTF Write-Up)

This is a write-up of a CTF from dfchallenge.org called "I can't remember my password...T_T"

I pursued quite a few dead ends but I've left many of these in because I think they give some context to my thought processes. As well as being a really good challenge digging into NTFS artefacts it also forced me to find alternatives to some of the licenced tools I would usually use but don't have access to at the moment.

There is a short TLDR right at the bottom if you're in a hurry! 😜

The scenario:

"Michael uses USB to save the file that records password of VPN service that can access to company’s server. One day, he accidentally deleted the folder where the password file was saved on business travel, and he became unable to access the company VPN. Recover the deleted password file on USB and find out the VPN password."

The data:

• system.L01 (MD5: 4ac03fcddce09e122a682da5a3d09fdd)
• usb.dd (MD5: 4431d5f9e51d6d55f5f58dfe92d42348)

The tools I used (on my Windows 10 laptop):

• Certutil -hashfile md5
• AXIOM 4.0.0 (with a 30 day trial licence)
• FTK
• Regripper & RegEdit
• WinHex &HxD
• MFTDump
• INDXParse
• NTFS $LogFile Parser
• Windows Programming Calculator

I started by confirming the hashes of the evidence items using certutil, both were good:

Then I processed both items in AXIOM. I had some trouble with System.L01- although artifacts were parsed and were viewable I wasn't able to view file content. AXIOM thought it had lost the source and no amount of re-pointing it helped:


Some initial observations

• System.L01 is a Windows 10 Pro system set to Korea Standard Time (UTC+9).
• usb.dd is NTFS formatted. This is a bit odd for a USB drive- I'd usually expect it to be FAT32 since this is more widely compatible between different systems.

Lets try to find the password file

It seems unlikely that a user would forget their VPN password if it was the same as their Windows login password but since lots of people re-use passwords it was worth checking just in case....

Michael’s Windows account password is “test1234” (inferred from NTLM hash: 3B1B47E42E0463276E3DED6CEF349F93). A full keyword search for “test1234” across both media items produced no results so I set this aside while looking into other things.

To see which files had been recently accessed FTK imager was used to extract Michael’s NTUSER.dat and it was parsed with RegRipper to seek recent file usage but none was found:


I had expected to see entries here so to corroborate that there are actually no subkeys I would usually use the built-in registry viewers in X-Ways or AXIOM (both unavilable right now). This time I loaded Michael’s NTUSER.dat using RegEdit on my own machine and verified that the RecentDocs key was empty:


I then reviewed alternative places where indications of file access can be found such as Edge History, LNK files and jump lists. Edge History indicates that “E:\Documents\Cr3d3nti@ls.docx” was accessed:

I focussed my attention on Cr3d3nti@ls.docx

No file with this name has been recovered by AXIOM’s parsing of the file system or carving for known file types (which includes docx). USB.dd/$LogFile recorded the deletion of this file:


I used the timeline view in AXIOM to see that at the same time as the docx was accessed the following temp files were also created:

• System.L01\Users\Michael\AppData\Local\Temp\CVR49B7.tmp.cvr (this still exists but with size 0B)
• System.L01\Users\Michael\AppData\Local\Microsoft\Windows\INetCache\Content.Word\~WRS{61067635-2D2A-4772-93FD-24D933F6188A}.tmp and others of the same type (this still exists with size 2048 B)

Despite hopes of recovering cached file content, online research suggests that “~WRS*.tmp” files are used for moving data in an out of memory and are only judged to be of use while the application is active. (https://www.forensicfocus.com/Forums/viewtopic/t=12047/)

On the USB, the MFT Record Number 49 corresponds to the “Documents” folder, which we can see is also deleted:




$MFT Parsing Attempts:

I would usually try to use X-Ways FILE record templates but since I can't do that at the moment I did some Googling and found MFTDump:

Cr3d3nti@ls.docx is not listed but the “Documents” directory with MFT ID 49 is:

We can also see the other files that were in the Documents folder:

It looks like the $MFT isn't helping me very much.....Since the USB is, somewhat unusually NTFS, I suspect NTFS artifacts may well be the key to this so what are some other places NTFS might have information about deleted files?

The $I30 file, in each directory, contains information about the child objects of that directory.


Looking at the $I30 from the "Documents" folder we can see “.C.R...D.3.N.~.1...D.O.C “ which looks notable given that the short name for our file of interest is “CR3D3N~1.DOC”:


INDX files can be read by EnCase (licensed), X-Ways templates (licenced) or OSForensics (my trial has expired). Alternatively, there is a python 2.7 script here to save the day! https://github.com/williballenthin/INDXParse

From this output we can see the physical and logical size of our file of interest:

As well as modified, accessed, changed and created times:

.....but it hasn't gotten me any closer to actually finding the file!

What are some other NTFS artifacts that could help me?

Alternate data streams (ADS)- In NTFS files have an attribute $Data. The primary data stream will usually just contain the contents of the file while an alternate data stream is a way of adding metadata to a file. ADS could also be a potential hiding place for a password. However, only the following files have been noted as containing ADS (MFTDump output):

Resident files- Resident files are small enough (<900 B) to be stored in the $MFT in their entirety. Even a relatively empty docx file, such as a document recovered from usb.dd containing only “testtesttest” is 12KB and so would be too big to be stored as a resident file.

Can I find this file, or fragments of it, with some shrewd keyword searching?

The data I’m interested in is likely to be text in the body of the document and, if so, would be in “[docx file].zip\document\document.xml” e.g. for the “testtesttest” file from the USB:

I could search for "<w:t>" and "</w:t> but ZIP files are compressed so this content will not be available in plain text for keyword searching. The whole file needs to be found to allow proper decompression of the zip archive.

I then spent some time manually carving docx files from usb.dd using WinHex using the headers and footers described in this article: https://www.forensicfocus.com/Forums/viewtopic/t=4679/

I did have some success with this....

....but all it really confirmed was that I'm not better at carving that AXIOM!

What are some other ways to see what was in a Word document?

Thumbnails - Is there a thumbnail of the document contents? thumbcache_2560.db does contain large thumbnails of a couple of documents, but not the password file.

Autosaves - Is there an autosaved copy of the word document? I looked for *.asd across both media items but there were no matches.

Time to step away from the computer for a big cup of tea and take stock of what I know:

• If the docx was still fully intact and contiguous AXIOM should have carved it.
• If the $MFT entry for the docx file was still intact it would be listed in the file system view and in the MFTdump output.
• A zip file won't decompress unless complete so the file must be intact and not partially overwritten.
• If it can't be carved using headers and footers it must be fragmented i.e. not contigous.
• So I'm dealing with a fragmented file no longer referenced by the $MFT.

Bingo! In order to read a fragmented file we need.......DATA RUNS! Tea always helps.

Data Runs

Data runs point to the offset and length of each fragment of a file. Data runs are stored in the $MFT but since the $MFT entry for this file has been removed we can also look in $LogFile. The $LogFile is a journal for NTFS transactions to allow the system to complete or un-do interrupted transactions to prevent data corruption. It needs to know where the data is in order to complete these changes. Data runs can be parsed from $LogFile using “NTFS $LogFile Parser 2.0.0.48”:

We can see that Cr3d3nti@ls.docx had the $MFT number 11338, is non-resident and not compressed. It’s data runs are given as:

320104BF3E04229B01D8BD0000000000FFFFFFFF82794711

At this point I wished I had access to the NTFS notes I frantically scribbled during the excellet X-Ways File Systems training course. Thankfully this website came to the rescue: http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/concepts/data_runs.html

This thread also contains a good explanation of data runs: https://www.forensicfocus.com/forums/general/ntfs-mft-analysis-identifying-cluster-run/#post-6572997

Interpreting the data runs:

32 | 01 04 | BF 3E 04 || 22 | 9B 01 | D8 BD || 00 (end marker) 00 00 00 00 FF FF FF FF 82 79 47 11

Run one:

• Header = 32 --> 3 byte offset, 2 byte length
• Length= 01 04
• Offset= BF 3E 04
• Summary: 0401 (260) clusters starting at logical cluster number (LCN) 043EBF (278,207)

Run two:

• Header = 22 --> 2 byte offset, 2 byte length
• Length = 9B 01
• Offest = D8 BD (relative to 043EBF (278,207))
• Summary = 019B (1025) clusters starting at LCN [043EBF (278,207) + BDD8 (-16936)] = 3FC97 (261,271)

We also need to know the cluster size, shown here in FTK as 4096:

Locate first fragment

• Starting location: Multiply cluster size by first cluster address: 4096 * 278,207 = 1,139,535,872 (43EBF000)
• If we go to this offset we see the recognizable "PK" header of a docx file- reassuring!
  

• The first data run has a length of 1025 clusters (1025 * 4096 = 4,198,400 bytes)
• End pont = Starting point + (length-1) = 1,139,535,872 + 4,198,399 = 1,143,734,271
  

So we mark this as the end of the block and carve this section out and paste into a new file using WinHex:

Locate second fragment

• Interpreting the relative offset in the second data run (the negative number means that the second cluster is actually located before the first one):

• Starting point= 261,271 * 4096 = 1070166016
• Length = 411 clusters = 411 * 4096 = 1,683,456 bytes
• End point = start + (length -1) = 1070166016 + 1,683,455= 1071849471

Great news- this fragment of data appears to contain the end of a word document:

I pasted this into my new file, after the first fragment and saved it with a .docx file extension.

Hooray!



A nice final check is that the size of this file I've carved matches with the physical size of CR3D3N~1.DOC recovered from $I30 indicating that the data run calculations were correct:

My carved file:


$I30 output:



It's best practice not to carve beyond the end of the file to avoid mistakenly including any data that may be in slack space (even though it might not affect whether the file opens correctly in this particular situation).

TLDR:

• Win 10 computer and NTFS USB
• Access to Cr3d3nti@ls.docx seen in Edge History of computer
• This docx is deleted, was not carved and no longer has an $MFT record
• Data runs found in $LogFile
• 2 fragments recovered and recombined to open the word document
• The docx contains an image of the VPN password