RingZer0team CTF - Challenges 86, 87, and 88

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.

Update two

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!