I was perusing through Twitter when I came across a tweet from John Hammond about a CTF being run in correlation with NahamCon. I don't really know much about reverse engineering or website exploitation but I was able to work through some the Forensics questions as well as some of the general warmup ones. Let's walk through these:
Blobber
This file is really... weird...
Evidence: blobber
We get an extensionless file so I opened it up in hex viewer HxD to take a peek at the header. We can see instantly that it appears to be a SQLite database.
Figure 1: blobber header in HxD
What I did next was open the file in DB Browser for SQLite. There was one table titled "blobber" that had three columns, "id", "name" and "data". The "name" column appears to have gibberish in terms of readable text. The "data" column was almost completely empty except for one, row with id 238.
Figure 2: blobber blob in DB Browser
Rightfully so, it was a blob, which can be exported out. Opening the blob file into HxD, I couldn't easily determine the file so I took to Google to search for the header based off the hex. Based off of AConvert it said it was most likely a zip container, so I used 7Zip to open it and we get another extension-less file inside.
Figure 3: Blob file contents in 7Zip
Dropping the file into HxD I can see this on shows a header with PNG inside it so I opened the file with MS Paint (what else haha) and it showed the flag of "flag{b93a6292f3491c8e2f6cdb3addb5f588}".
Figure 4: Zipped file from blob in MS Paint
Perfectly Disinfected
Ever had to deal with dirty files? No more! Our patented technology will make your files sparkling clean! Sample included.
Evidence: clean_document.pdf
We are provided a simple PDF file so first thing I did was open it (hoping for no viruses :P). Not much to work with there.
Figure 5: clean_document.pdf in Adobe Reader
Opening in HxD I can already see the answer appears to be embedded in the Title section of metadata.
Figure 6: clean_document.pdf in HxD
I ended up using MDViewer instead of Exiftool (because it didn't give me what I wanted) and saw the field and flag I was looking for. The flag was found in multiple fields but the answer we were looking for was "flag{b00acdc78749b378f8f4889f8243789304abe928}".
Figure 7: clean_document.pdf in MDViewer
Fetch
"Gretchen, stop trying to make fetch happen! It's not going to happen!" - Regina George
Evidence: fetch.7z
We are provided a 7Zip container which has a extension-less file "fetch" inside. Extracting and opening the file in HxD we get a header showing it as a WIM file. These are basically zip containers so we can use 7Zip again to open it and see the contents.
Figure 8: contents of "fetch" in 7Zip
From my experience this is a dump of the C:\Windows\Prefetch folder from a Windows system. Once extracted we can use Eric Zimmerman's PECmd to parse the prefetch files. Since we know the answer has the "flag{" format we can just search and get a hit on one row for wordpad.exe. If we expand the Files Loaded column we can scroll through and find the answer was "flag{97f33c9783c21df85d79d613b0b258bd}".
Figure 9: Answer from PECmd parsed prefetch files
Raided
The police raided a server belonging to a very 1337 hax0r that was used to stage attacks. Upon further investigation, this server turned out to be a jump server for the attacker to access more infrastructure.
A memory snapshot was taken of the machine. See if you can figure out what the attacker was doing and what other systems the hacker was accessing.
Evidence: dump-vmem.xz
I will be the first to say that memory forensics is not my specialty but when there's a will there's a way. Extracting the VMEM file from the zip I tried out some of my normal memory analysis tools such as Volatility but I couldn't get it to read the file properly. I pivoted to just using strings to pull out something I could view. Because of the wordage of jump server and the accessing of other systems, one of the first things that comes to mind is SSH.
I used bstrings by Eric Zimmerman as it's sometimes quicker. After dumping to a text file, we can search using NotePad++ to find some interesting things.
Figure 10: Searches for SSH via bstrings output
Here we get a session attempt using the key "id_ed25519" to logon as user "l33t" to IP 167.172.12.154. Now that we know they were connecting here we can continue onward to look for the key. Further down in the dump we can see an OpenSSH private key located in memory.
Figure 11: OpenSSH private key in memory
I had issues on Windows copying out this key to a usable file so I opened the whole memory image up in HxD to search for it and do it that way. I think because I was missing some characters via the text output from bstrings.
At offset 0x7609620 we see the key starts and it ends at offset 0x76097AE.
Figure 12: OpenSSH private key in HxD
Saving the section of data to it's own file, I changed the permissions, and then could use it with SSH to connect to the IP we found earlier.
Figure 13: SSH session with flag
As we can see the flag gets pushed back to us, the answer being "flag{654e9dc4c424e25423c19c5e64fffb27}".
Note: The IR section had 5 questions all from the same evidence file, which was a VM image of a Windows 10 computer.
IR #1
Can you find the hidden file on this VM?
Evidence: ir.zipPWD: 3766572f638355c5028b60ca641b6f0d
After downloading the file I unzipped it and realized it's a .OVA file, commonly used by VirtualBox or VMWare. What I realized is that it's just a container which houses the .VMDK file inside so what I did was extract the hard drive itself to analyze more easily with forensic tools. Because FTK Imager didn't like opening the VMDK itself, I first mounted the image with Arsenal Image Mounter then opened the logical drive in FTK Imager (what a nuisance).
I came across a folder called "hidden" at:
C:\Users\IEUser\Documents\hidden
Inside was a folder called "directory", and inside that was a simple text file called "Ransom note".
Figure 14: Ransom note.txt file in FTK Imager
I assumed this answer was for question 1 and it was, the flag was "flag{053692b87622817f361d8ef27482cc5c}".
IR #2
Can you figure out how the malware got onto the system?Evidence: ir.zipPWD: 3766572f638355c5028b60ca641b6f0d
While perusing the filesystem I found a powershell script in the Downloads folder, the contents of which appear to be encoding with something I've never seen before. I assumed this was a possible point of entry.
One of the first things I run after getting a system image like this is the EZ Tools parser in KAPE. It makes quick work of triaging a system fast from common Windows artifacts. Knowing the name of the potential file as "updates.ps1" I could look at the output of the MFT file and the $J file. In the MFT we can find the entry for "updates.ps1" and pivot a few entries above to see that it appears a similarly named file was located in an Attachments folder associated with the Windows Mail application.
Figure 15: updates.ps1 from MFTECmd report
Figure 16: updates[27].ps1 attachment sample
Going back to the MFT report, we can see right above the original .ps1 attachment is the path to the email itself, in .dat form.
Figure 17: Email .dat file path in MFTECmd report
Navigating to the path in FTK Imager (or any browsing tool), we can see the HTML formatted text of the file, including the answer of "flag{75f086f265fff161f81874c6e97dee0c}".
Figure 18: Contents of the original point of entry email
IR #3
Can you reverse the malware?
Evidence: ir.zipPWD: 3766572f638355c5028b60ca641b6f0d
Do I know what encoding the powershell script was using? Nope, not at all. Did I shortcut things a bit in how I got the answer? Possibly. After running the EZ Tools parser did a search across the results for "flag{" and hit on one in the EventLogs folder which makes sense. Event Logs will have entries for execution sometimes. In record number 134 we get warning for PowerShell execution as well as the payload details which contained our flag.
Figure 19: EventLogs entry for PowerShell execution
As we can see execution shows that the malware was encrypting files. We see the flag entry here was "flag{892a8921517dcecf90685d478aedf5e2}".
IR #4
Where is the data being exfiltrated? Please give the MD5 hash of the URL with the usual wrapper of flag{}.
Evidence: ir.zipPWD: 3766572f638355c5028b60ca641b6f0d
From the same EventLog payload we can see a URL that the data was exfiltrated to.
Figure 20: Exfiltration URL in EventLog payload
The URL was https://www.thepowershellhacker.com/exfiltration but they are looking for the MD5 so we can plug it into an online generator and get the answer of "flag{32c53185c3448169bae4dc894688d564}".
IR #5
Can you please recover our files?
Evidence: ir.zipPWD: 3766572f638355c5028b60ca641b6f0d
From navigating the file system prior, I saw a bunch of deleted and encrypted files on the user's Desktop folder.
Figure 21: Desktop deleted files
Luckily the deleted files could be recovered with a few clicks of the mouse. I exported all files and then did a quick search again for the flag format with a hit on one file, "NexGen Innovations.docx". We have to zoom in but we can see in the footer of page 2 of the file in super tiny font was the answer of "flag{593f1527d6b3b9e7da9bdc431772d32f}".
Figure 22: Footer of NexGen Innovations.docx
Figure 23: Zoom image of the footer of NexGen Innovations.docx