Security Compass Internal CTF Write-Up

July 6, 2015

A link to the CTF discussed below:

Introduction

I thoroughly enjoyed the CTF organized by Stephen Hall for a recent Learning & Growth session at Security Compass. I was in awe of how some of my co-workers solved the challenges, and wanted to understand their mindset. So, I looked at one of the challenges no one had yet figured out and completed it successfully with the goal of logging the way I solved it to help anyone else curious on the thought process and for myself if I ever come across a similar problem.

The Write-up is broken down into three blocks:

  1. The Thought Process — The step-by-step write-up with screen shots and my general thought process
  2. The TLDR — Just the command line commands
  3. The Merits — Reasoning on why this challenge

I close the write-up with a Reference section; it contains links loosely related to the topic and just interesting stuff.

Thought Process and Walk Through

This write-up covers the Grab Bag: Forensic challenge. The challenge presents you with a zip file and a set of clues:

  • There are four things you need to get from this pcap in order to get the whole flag
  • Don’t forget to recycle because it saves the environment Those who don’t study history are destined to repeat it
  • Something on the desktop
  • I hear windbg can be used to extract password

What I got from this vague set of clues is that there are indeed four flags to find, however the file is not a PCAP.

You can extract the file in a Linux/BSD system or Windows or Mac; I used Kali Linux for this challenge and set up a virtual share to access the file from my Windows host system in Virtual Box.

I ran the unzip command on the command line to extract the contents of the file:

Image 1 — Using the unzip command

Image 1

unzip <filename>.zip



Once the file is extracted you will get a 2.1GB VMEM file. You can obtain more file information from your favorite search engine in conjunction with the File command native on Linux which provides three methods to obtain the file type, and depending on the first successful test lists the file type.

With use of the File command I found that the file is considered as just data.

Image 2 — Using the File command

Image 2

File <file_name>.vmem



This was not very helpful, so I resulted to searching online. I found info that vmem stands for “VMware virtual machine’s paging file”. So, I had obtained two pieces of information and seeing as this is a forensic challenge every bit of information I could extract would help directly or indirectly in some way.

I then knew it was a paging file; paging files are usually designed for memory management of a computer system. Basically, I was dealing with memory of a virtual machine created by a Vmware application. Checking the VMware page I found out that a VMEM file is “The virtual machine paging file, which backs up the guest main memory on the host file system. This file exists only when the virtual machine is running or if the virtual machine fails. It is stored in the working directory, so with context I basically had a virtual machine crash dump.

With that information I looked to applying the use of a tool I had heard quite a bit about: Volatility.

Image 3 — Volatility Logo

Image 3

Volatility is described as a cohesive framework (Collection of tools), which analyzes RAM dumps from 32–64-bit Windows, Linux, Mac, and Android systems. It was written in Python, with a scriptable API and the ability to add in various user=created plugins. It was designed by forensics and incident response, in association with malware experts.

The basic usage of Volatility would then be:



volatility -f <file name> — profile=<What type of memory dump is it> <plugin_name>



The first step was then determining what profile the Windows system was. This was obtained by running the Volatility plugin Imageinfo.

Image 4 — Obtaining system information

Image 4

Volatility imageinfo -f <filename>.vmem



When the Imageinfo plugin is run in Volatility, it attempts to determine the image / dump info based on the KDBG, which stands for Kernel Debugging.

Now I had an option of 4 possible profiles: Win7SP0x64, Win&SP1x64, Win2008R2SP0x64, or Win2008R2SP1x64. I eliminated the service pack 0 type profiles because it was stated in a lower section that the service pack was version 1. And, on a whim, I went with Windows 7 and was right.

Next, I tried to extract relevant information in relation to the challenge that the relevant information would be something related to passwords “I hear windbg can be used to extract password“.

I researched Windbg and passwords, which led me to tutorials about using Windbg and Mimikatz to obtain user passwords. Windbg is a multipurpose debugger for Microsoft Windows, and is distributed by Microsoft. It has the capabilities for x86, x64 and Kernel level debugging. Mimikatz is a tool created by Gentil Kiwi with the initial intention of learning C, but also has the capabilities of dumping plaintext passwords from memory utilizing Windows LSASS (Local Security Authority Subsystem Service).

Since I was already analyzing memory via Volatility, I wondered if I could just do everything in Volatility. It was possible to extract the SAM hashes from Volatility, but could I also dump the plain text information? I was lucky to discover that there was a Mimikatz plugin for Volatility which I obtained from https://github.com/dfirfpi/hotoloti . Once I downloaded the plugin, I copied the file to the two plugin locations in Volatility. (It might not be needed — but just to ensure it worked I moved it to both plugin locations).

Image 5 — Downloading Mimikatz plugin

Image 5

wget https://raw.githubusercontent.com/dfirfpi/hotoloti/master/volatility/mimikatz.py



Image 6 — Moving plugin to correct directories

Image 6

cp mimikatz.py /usr/lib/python2.7/dist-packages/volatility/plugins/cp mimikatz.py /usr/share/pyshared/volatility/plugins/



A quick note: if you are missing any Python modules for the Mimikatz plugin you can install a program called PIP which installs Python modules with the command:



apt-get install pip



And from there just install any modules required for Python



pip install <module_name>



Once the module was moved and working, I ran the plugin to obtain the password and the third flag respectively.

Image 7 — Obtaining Flag 3

Image 7

Volatility -f <file_name>.vmem — profile=<Known_Profile_of_Image> mimikatz



So with that, I got the third flag and satisfied the hint given.

Moving on to the next hint I looked at “Those who don’t study history are destined to repeat it”.

When I thought of that I got the sense of the terminal command line history. So I investigated how does one refer to history with Volatility? I found a plugin called Console which finds the commands that the attacker typed into cmd.exe or executed via backdoors. By searching the memory of conhost.exe (the system process that deals with non-GUI programs, i.e. terminals), and scans for console information.

Image 8 — Obtaining Flag 4

Image 8
Image 8.5

Volatility -f <file_name>.vmem — profile=<Known_Profile_of_image> consoles



At this point, I had two of the four flags. For the other two flags the clues were more hard disk related, which seemed to look past the utility of Volatility. I applied the use of the Strings command with Grep for the final two flags.

I started with the first flag, “Don’t forget to recycle cause it saves the environment.”

I checked out most of the popular plugins in Volatility and figured that nothing really describes how to obtain the environmental variables, so I considered just running Strings and checking.

Image 9 — Obtaining Flag 1

Image 9

Strings <file_name>.vmem | grep -C 2 “flag1{*”



I used the option “-C” Just to gain some context of where the flag was set and in this case it was stored where environmental variables are being stored, hence the clue associated with it. This works because the VMEM file also contains all the information required to recreate that instance or snapshot of the VM which includes what the current environmental variables were at the time.

So with that logic, I attempted the same thing for clue number 2, “Something on the desktop“.

Image 10 — Obtaining Flag 2

Image 10

Strings <file_name>.vmem | grep -C 2 “flag2{*”



It appeared the information about what files are stored on the hard disk came from the MFT (Master File Table) in the NTFS (New Technology File System) standard which Windows natively uses.

So with that final flag found I combined all flags for the final submission of:

PinkFluffyUnicorns-GoRoundAndRound-TheRainCameAndWashedTheSpiderOut-HmmmChocolateRaisins

Short Version — The TLDR

Unzip the file



unzip <filename>.zip



Utilize the already installed memory forensic tool Volatility and determine the possible image profiles



Volatility imageinfo -f <filename>.vmem



Obtain Flag 4 By using the Consoles plugin for Volatility



Volatility -f <file_name>.vmem — profile=<Known_Profile_of_Image> consoles



Obtain Flag 3 by using the Mimikatz plugin for Volatility *Mimikatz plugin not natively on Volatility refer to references section for link.



Volatility -f <file_name>.vmem — profile=<Known_Profile_of_image> mimikatz



Obtain Flag 2 by running strings and grepping for “flag2{*”



Strings <file_name>.vmem | grep -C 2 “flag2{*”



Obtain Flag 1 by running strings and grepping for “flag1{*”



Strings <file_name>.vmem | grep -C 2 “flag1{*”

Merits of this Challenge

This challenge allowed me to experience a simple memory dump challenge and extract flag related information. But you can obtain various amounts of information such as Registry details, running processes, SAM hash dumps, User names, system information, command line history, and active connections at the time of the crash/memory dump, etc. Being able to analyze a virtual memory dump can be helpful in any scenario where you have access to the backups of virtual machine snapshots, or memory dumps for hosts on the network, or access to volatile memory.

References:

https://github.com/volatilityfoundation/volatility/wiki — Main wiki for Volatility providing various information

http://blog.gentilkiwi.com/mimikatz — Main blog for the creator of Mimikatz

http://blog.digital-forensics.it/2014/03/mimikatz-offline-addendum_28.html — Blog of the person who made the Mimikatz plugin for Volatility

http://downloads.volatilityfoundation.org/releases/2.4/CheatSheet_v2.4.pdf — Cheat Sheet for Volatility

https://www.ethicalhacker.net/features/root/using-cold-boot-attacks-forensic-techniques-penetration-tests — Article describing the merits of memory forensics for penetration testing in a cold boot attack.

Previous Article
Women In Tech: Opheliar Chan
Women In Tech: Opheliar Chan

Opheliar Chan This blog series allows us to get to know multiple women in the Security and Technology Indus...

Next Article
Understanding Strengths and Limitations of Static Analysis Security Testing (SAST)
Understanding Strengths and Limitations of Static Analysis Security Testing (SAST)

The Strengths and Limitations that Result from Usage Many organizations invest in Static Analysis Security ...

×

Schedule a live demo

First Name
Last Name
Company Name
!
Thank you!
Error - something went wrong!