RingZer0team CTF - Challenges 86, 87, and 88
Posted on Thu 13 July 2017 in Security
There are a bunch of fantastic Capture The Flag security challenges on RingZer0Team.com. I've been working through some of these for a wee while now, and with the New Zealand Cyber Security Challenge coming up again soon, I thought I'd get back into some of them.
Challenge 86 ("1/3 Do not waste the environment", under the Forsensic Challenges) is one of a series of challenges where you need to dig through some provided data to find the flag.
I started by downloading the 'forensic bundle', which was just a large zip file. The first challenge was to figure out the contents of that zip file. The file name was just a jumble of characters, and there was no extension. Running
file on it just returned the file type "Data"... not very enlightening, but
head uncovered the string "VBOX" in the file... okay, it's VirtualBox file.
Because I didn't have Virtualbox installed, I spent a bit of time digging through the actual Vbox file itself, trying to see if there's a flag already in there. I used
strings | egrep -i flag-...., to try to find any flags embedded in the file itself. I didn't find any flags, but I did discover that the computer name itself is "FLAG-PC". Very clever. :-|
Update, many hours later:
Okay this totally cooked my bacon. After hours of playing with VirtualBox and playing with files, I finally gave up and Googled the name of the downloaded file.
Turns out I was REALLY close. The flag IS embedded in the actual file itself, but the format is different for the first time. The correct grep string would have been
egrep -i '.?f.?l.?a.?g.?-'.
Real frustrated by how close I was, I'll have to expand my searches in the future. Hat-tip to @professormahi and his GitHub page.
Once I understood that, I also discovered the flag for challenge 87 ("2/3 Did you see my desktop?"), in the same manner.
I haven't managed to get the flag for Challenge 88 ("3/3 Suspicious Account Password") yet, but I do know what it is. I can see (by grepping for "Visited") a bunch of visits to http://www.forensicswiki.org/wiki/Tools:Memory_Imaging... this thing is a memory dump. That explains now why it doesn't work as a VirtualBox disk.
Next time I sit down here, I'll find visit Forensics Wiki, and start digging through the memory dump for the passwords.
I decided not to put this up as a separate post, because once I knew what I was looking at, it was pretty easy. Again though, I relied on @professormahi's work - but now thanks to him I have a little bit of experience with Volatility!
First, we get Volatility to scan the image and see what it's dealing with:
$ volatility -f vm.vmdk imageinfo Volatility Foundation Volatility Framework 2.6 INFO : volatility.debug : Determining profile based on KDBG search... Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86 AS Layer1 : IA32PagedMemory (Kernel AS) AS Layer2 : FileAddressSpace (/home/eric/Downloads/86/vm.vmdk) PAE type : No PAE DTB : 0x185000L KDBG : 0x82920be8L Number of Processors : 1 Image Type (Service Pack) : 0 KPCR for CPU 0 : 0x82921c00L KUSER_SHARED_DATA : 0xffdf0000L Image date and time : 2014-03-09 20:57:55 UTC+0000 Image local date and time : 2014-03-09 13:57:55 -0700
Now, knowing the profile that we need to use, we can use it to just... dump the password table:
$ volatility -f vm.vmdk --profile Win7SP1x86 hashdump Volatility Foundation Volatility Framework 2.6 Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0::: flag:1000:aad3b435b51404eeaad3b435b51404ee:3008c87294511142799dca1191e69a0f:::
And then, we grab that NTLM hash and pop it into an online NTLM decryptor service, and we're away!