2019 Unofficial Defcon DFIR CTF Writeup - Linux Forensics

When completing this portion of the CTF I relied upon Autopsy 4.12 heavily, using the CTF as an opportunity to practice and trial a different toolset/ approach. In general I was impressed, but I’m not an Autopsy user day to day and as such I was fumbling a fair bit. For the Linux portion of the challenge, in hindsight, I think mounting the image within a Linux distribution would make more sense. For that reason, in this writeup I have addressed how to solve the questions using SIFT.

You can mount the image under sift, using the ewfmount command:
sudo ewfmount /mnt/hgfs/Cases-ssd/Evidence/Adam\ Ferrante\ -\ Laptop-Deadbox/Horcrux/Horcrux.E01 /mnt/ewf
The new file object is named ewf1:

This presents the E01 as a raw file which can the be mounted with a loopback device. First, we need to establish where the partition of interest is located and to achieve this I use ‘mmls’:
mmls /mnt/ewf/ewf1
This provides the below output:

We can see that “Units are in 512-byte sectors” and that the start offset of the Linux partition is 75560960. Multiplying these together we get ‘38687211520’ which is the byte offset we will use for mounting the partition. First I created a directory to use as a mount point, with:
mkdir /mnt/linux_mount
Then using the mount command, we can mount the partition read only:
mount -o ro,loop,offset=38687210496 -t ext4 /mnt/ewf/ewf1 /mnt/linux_mount
Or not…

The error above can result from a number of things, however in this case it is because the filesystem is dirty. When mounting the drive it attempts to rectify the issue, which cannot be performed with a read only mount. We can overcome this issue by passing the ‘norecovery’ option when mounting:
mount -o ro,norecovery,loop,offset=38687211520 -t ext4 /mnt/ewf/ewf1 /mnt/linux_mount
This worked without error and if we 'ls' the new mountpoint we can see that we now have access to the mounted filesystem:

Now we have the filesystem mounted... on with the questions!

red star - 10 pts


What distribution of Linux is being used on this machine?


There are various ways to determine the distribution in use within a linux install/image. When looking at a dead image checking the contents of /etc/issue, /etc/*-version or /etc/*_version is the quickest and easiest.

A simple cat of /mnt/linux_mount/etc/*version or /mnt/linux_mount/etc/issue provides the following:

Throughout this process be careful to ensure you are targeting the mounted filesystem and not your analysis system's filesystem. I will normally navigate to the root of the target and work from there as my working directory, in this case using ‘cd /mnt/linux_mount’. Thereafter a path in the OS under analysis would be equivalent to that of being at the root of the system and we can presceed any paths with '.' to indicate that we should be starting from the current directory. the current director.e.g.:

cat ./var/log/apache2/access.log
Due to my working from the route of the mounted drive the command above will target '/mnt/linux_mount/var/log/apache2/access.log' on my analysis system.

Going back to the screenshot and the output of our commands, it looks like we are dealing with Kali.


abc123 - 10 pts


What is the MD5 hash of the apache access.log?


By default the apache access log is located at /var/log/apache2/access.log. So with a working directory of the root of the mounted fs, we can use:
md5sum ./var/log/apache2/access.log
Which provides the following:



Radiohead - No Surprises - 10 pts


It is believed that a credential dumping tool was downloaded? What is the file name of the download?


As a first step in familiarising myself with the image I reviewed the ‘/etc/passwd’ file in an effort to see what users were active and worthy of further investigation. With regard to this specific questions I was particularly interested to see which users had home directories as possible locations to have downloaded files to.

As is default in kali, the 'root' account is the only user account, and the home directory was at ‘/root’. A quick way of having an easy to review list of home directories in use is to use the following command:
cat ./etc/passwd | cut -d':' -f 6 | sort | uniq
Which results in this output:

Based on the above we will start with the ‘root’ user and it makes sense to check on the contents of the associated ‘Downloads’ folder:
ls -al ./root/Downloads/
Which results in the below:

Only one file, and it’s filename is sure does look like that of a well-known credential dumping tool.


super duper secret - 15 pts


There was a super secret file created, what is the absolute path?


Within the bash history for ‘root’ (/root/.bash_history) we see that someone piped the output of a cat command into ‘/root/Desktop/SuperSecretFile.txt’:


this is a hard one - 15 pts


What program used didyouthinkwedmakeiteasy.jpg during execution?


Still in the bash history we see ‘binwalk’ being used over didyouthinkwedmakeiteasy.jpg:


overachiever - 15 pts


What is the third goal from the checklist Karen created?


There is a file on the desktop for ‘root’ called ‘Checklist’, reviewing its content we see that it has three items:


attack helicopter - 20 pts


How many times was apache run?


We earlier reviewed the apache access log to calculate its hash, and the eagle eyed forensicators among us may have noticed that the hash was ‘d41d8cd98f00b204e9800998ecf8427e’ which is the MD5 associated with a 0 byte file.

Reviewing the log directory, we find the same to be true of the other logs:

Most notable is the error.log as this log is populated with entries upon apache starting. Assuming the log hasn’t been tampered with, it being empty is an indication that apache has not run.


oh no some1 call ic3 - 25 pts


It is believed this machine was used to attack another, what file proves this?


While spelunking through the image to get my bearings, I happened upon a screenshot within the home directory for ‘root’. This file is located at ‘/root/irZLAohL.jpeg’ and is reproduced below:

Notably this image contains a screenshot of a windows host, probably captured during a malicious remote access session. The filename was accepted as the flag. Further notable is that the screenshot includes the notepad window open with a flag which we had previously found in the Triage Memory questions. It’s all starting to fall into place…


scripters prevail - 25 pts


Within the Documents file path, it is believed that Karen was taunting a fellow computer expert through a bash script. Who was Karen taunting?


When reviewing bash history we saw various references to bash scripts:

Reviewing that excerpt we see that the user navigated to ‘Documents’, made a directory called ‘myfirsthack’, entered that directory and then created, modified, chmod’d and executed two scripts (hellworld.sh and firstscript), they then copied firstscript to firstscript_fixed and executed it. Lets see what they contain:

Not so interesting, and:

Nope, third time is a charm?:

Here we have a reference to a ‘Young’, lets give that a go! 


the who - 30 pts


A user su'd to root at 11:26 multiple times. Who was it?


su events are recorded in the auth log at ‘/var/log/auth.log’, we can quickly parse this for events at that time using the following:
cat ./var/log/auth.log | grep 11:26
This gives us the following output:

And we can see that user ‘postgres’ has multiple entries that minute stating “Successful su for postgres by root”.


/ - 30 pts
Based on the bash history, what is the current working directory?

Within the bash history, reviewing the last cd to an absolute path we see that the user changed directory to /root. Thereafter we can review the following cd commands to see what impact they would have on the current working directory.

Command Resultant Working Directory
cd /root /root
cd ../root /root
cd ../root/Documents/myfirsthack/../../Desktop/ /root/Desktop
cd ../Documents/myfirsthack/ /root/Documents/myfirsthack

So we see the final state is' /root/Documents/myfirsthack'



2019 Unofficial Defcon DFIR CTF Writeup - Memory Forensics

For the majority of this section I used Volatility 2.6 under Windows Subsystem for Linux (WSL). As an aside, I commonly use volatility in one of two ways. Most commonly I will run a number of common commands up front and as I progress I will run other less common commands, in each case I redirect the output of the command(s) to txt files which I can then manually review or cat/grep etc, thus reducing processing time that would arise from re-running commands. e.g:
vol.py -f [path_to_memory] --profile[profile] pslist >> [media-id]-pslist.txt
vol.py -f [path_to_memory] --profile[profile] psscan >> [media-id]-psscan.txt
vol.py -f [path_to_memory] --profile[profile] netscan >> [media-id]-netscan.txt
This approach means I can reuse output if later required in analysis. During CTFs and similar I quite often use quick and dirty commands piped to grep to narrow in on answers quickly where I don’t think I will rely upon analysis later. In such cases, a knowledge of the expected output from plugins in advance often means I can do away with the headers in output tables or I can include them with an or statement in grep e.g.:
vol.py -f [path_to_memory] --profile=[profile] pslist | grep -i 'offset\|notepad'
This requires knowledge of a unique string which can be found in the header of the output table for each plugin. In this case I know the pslist header containes ‘Offset’ and I am interested in the ‘notepad’ entry.

Grepping the output of volatility plugins is something memory forensics ninja Alissa Torres (@sibertor) covers in her SANS FOR526 class and it’s really sped up my analysis. There will be a mix of both techniques in the examples that follow.

get your volatility on – 5pts


What is the SHA1 hash of triage.mem?


No fancy tools needed here a simple sha1sum, in this case using WSL, gives us the answer.

sha1sum [path_to_file]


pr0file - 10 pts


What profile is the most appropriate for this machine? (ex: Win10x86_14393)


The first step in most volatility analysis is to use the ‘imageinfo’ plugin:
vol.py -f [path_to_memory] imageinfo

Reviewing the output, we can see that the plugin presents a few possible profiles, we also review the service pack level to confirm that we require an SP1 profile.

Combining that information, it is possible that a number of other profiles (e.g. Win2008R2SP1x64 or the other kernel variant profiles) would be correct, and it would likely have been possible to use any of them to confirm the exact OS by pulling registry hives from RAM. But in this case, and based on prior experience, I went with ‘Win7SP1x64’ and it was correct.


hey, write this down - 12 pts


What was the process ID of notepad.exe?


The 'pslist' command, known profile and a pipe to grep can get us this quickly:
vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile= Win7SP1x64 pslist | grep -i 'offset\|notepad'

The Process ID (PID) column shows for notepad the PID is 3032.


wscript can haz children - 14 pts


Name the child processes of wscript.exe.


The 'pstree' command shows the relationship between parent and children processes, sometimes where there are lots of processes child to a single parent it can be a bit confusing and alternatives like explicitly looking up the PID of the parent and seeing what processed have it as a Parent Process ID (PPID) using 'pslist' (or 'psscan') is the best approach.

In this case 'pstree', the known profile and a pipe to grep with context (-C) is a nice shortcut:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 pstree | grep wscript -C2

Executing this command results in the following output:

We can see the child process is UWkpjFjDzM.exe.


tcpip settings - 18 pts


What was the IP address of the machine at the time the RAM dump was created?


There are a couple of quick ways to skin this cat, but my preference is to use netscan output as it is commonly required later, I piped this to a text file with:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 netscan >> netscan.txt
Which provided the following output:

Per the above, there are multiple established connections which detail an IPv4 address of


intel - 18 pts


Based on the answer regarding to the infected PID, can you determine what the IP of the attacker was?


The infected process was the child process spawned from ‘wscript.exe’, ‘UWkpjFjDzM.exe’ or PID 3496.
We can re-review the netscan output written to netscan.txt with:
cat netscan.txt | grep -i 'offset\|UWkpjFjDzM'

Which outputs as below:

That process is associated with an established connection to '':


i <3 windows dependencies - 20 pts


What process name is VCRUNTIME140.dll associated with?


If you want to know something about loaded dlls, the 'dlllist' plugin is a good place to start. The output is verbose due to us not being able to focus on a single process in this question. The output is a repeating format with a header detailing process information and then a list of the associated dlls. In this case I used the following command to pass all lines which contain details of a process and also pass any instance of ‘VCRUNTIME140’:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 dlllist | grep -i 'pid\|VCRUNTIME140'
Therefor for the occurance of  VCRUNTIME140 we can review the proceeding line in the output and we can conclude that this was the associated process.

To my surprise there were 5 instances associated with different processes.

While I didn’t do this at the time, a tidier approach would be to use:
vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 dlllist | grep -i 'pid\|VCRUNTIME140' | grep -i VCRUNTIME140 -B1
This results in the following output:

Technically any of these would be a correct answer for “What process name is VCRUNTIME140.dll associated with?”, but OfficeClickToR.exe stood out as unique so I went with that first. From memory, I think I tried them all when that didn’t work, before realising that I had to drop the extension…


mal-ware-are-you - 20 pts


What is the md5 hash value the potential malware on the system?


As mentioned earlier, the potential malware is ‘UWkpjFjDzM.exe’ or PID 3496. We can dump this process to the current directory and hash it with a one liner. This is because we know the behaviour of the 'procdump' commend when it comes to naming dumped processes. We specify the output location and the filename will be ‘executable.[pid].exe’

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 procdump -p 3496 -D . && md5sum executable.3496.exe

My AV was unimpressed, but we managed to hash the file before it was quarantined:


lm-get bobs hash - 24 pts


What is the LM hash of bobs account?


There is a good guide to the required process here.

To answer this question, we need to use the hashdump plugin. However, this plugin needs to be provided with the virtual address of two hives, SAM and System. We retrieve this information with the hivelist plugin:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 hivelist

Resulting in the following output:

SYSTEM is at: 0xfffff8a000024010
SAM is at: 0xfffff8a000e66010

We can then use the hashdump command to dump the hashes:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 hashdump -y 0xfffff8a000024010 -s 0xfffff8a000e66010

The format of the resultant output is:

<Username>:<User ID>:<LM hash>:<NT hash>:<Comment>:<Home Dir>:

As such we are interested in the LM component, so ‘aad3b435b51404eeaad3b435b51404ee’, which happens to be the LM hash of a blank password.


vad the impaler - 25 pts


What protections does the VAD node at 0xfffffa800577ba10 have?


Information on VAD notes can be returned using the ‘vadinfo’ command. Running it on its own will result in a lot of output, easily piped to a txt file for subsequent review or narrowed down with a grep with context. The firs relevant line will be the one with the VAD note location and the next 10 lines will be more than enough to answer our question:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 vadinfo | grep '0xfffffa800577ba10' -A 10

This results in the following output:

And we can see the protection is ‘PAGE_READONLY’


more vads?! - 25 pts


What protections did the VAD starting at 0x00000000033c0000 and ending at 0x00000000033dffff have?


This time we are seeking the same information but based upon start location and end location. I actually just used the same command but substituted @ value for the start location. However, this approach actually returned multiple results. It was easy enough to distinguish which I was looking for from the mess but in short, I hadn’t noticed in the question that we were talking about a historical VAD hence “What protections did the VAD”.

A cleaner way to find exactly the right answer is as follows:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 vadinfo | grep '0x00000000033c0000' -A 3 | grep '0x00000000033dffff ' -A 3


vacation bible school - 25 pts


There was a VBS script run on the machine. What is the name of the script? (submit without file extension)


I expect there are a number of ways to answer this one, and I tried a few possibilities which didn’t get me to the answer. Ultimately the ‘cmdline’ solved it for me but it may not be the most elegant answer. If a VBS script had been executed via the command line then I would have expected there to be evidence here.

As it was a search for vbs entries within here actually identified that the process wscript.exe (PID 5116) had been executed with the command line detailed below:


thx microsoft - 25 pts


An application was run at 2019-03-07 23:06:58 UTC, what is the name of the program? (Include extension)


The shimcache is one of many handy ways to evidence process execution and there is a volatility plugin to parse it from memory, the following query immediately gave the process executed at that time:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 shimcache | grep '23:06:58'

Resulting in:

So we see that Skype executed at the time in question.


lightbulb moment - 35 pts


What was written in notepad.exe in the time of the memory dump?


There is a ‘notepad’ plugin for Volatility however it only supports XP/2003, so we have to do this manually. Fortunaltely being a common challenge there are a few handy guides out there, including the one located here.

Earlier in ‘hey, write this down’, we identified that the PID assoaicted with notepad.exe is 3032, as such we can dump the process memory with:

vol.py -f Adam\ Ferrante\ -\ Triage-Memory.mem --profile=Win7SP1x64 memdump -D dump -p 3032

We can then run strings over the dumped memory and as a first Hail Mary use grep to parse the output for any string containing ‘flag<’, just in case the challenge author has been kind.

And they have:

Note that the command used, per the guide linked above, is strings with the ‘-e l’ flag to set it to 16-bit littleendian, as this is how notepad stores content.


8675309 - 35 pts


What is the shortname of the file at file record 59045?


The ‘mftparser’ plugin is very useful and I had already run it while looking to solve some of the other challenges. Due to the volume of information returned, run time and how often the content gets returned to I piped the output of the command to a text file.

A search of the file for the string ‘59045’ had 2 results, one of which was the relevant one.

In the screenshot we can quickly see that the short filename associated with this record was ‘EMPLOY~1.XLS’.


whats-a-metasploit? - 50 pts


This box was exploited and is running meterpreter. What PID was infected?


This was a bit of a gimme. Earlier in ‘wscript can haz children’ we identified a malicious process and then in ‘intel’ we used netscan to see what it was communicating with. I noted at the time that it was communicating on port ‘4444’ which will be known to many as the default port for metasploit.

The PID associated with this process was ‘3496’ and lo and behold, it was accepted as the correct answer.


2019 Unofficial Defcon DFIR CTF Writeup - DFA Crypto Challenge


"On the homepage you will notice the Champlain College Digital Forensics Association's Logo. Can you decipher the hidden message?"

Full disclosure: I wasn’t a fan of this challenge and furthermore I would not have solved it without talking to the question author.

It became apparent that it was likely a multi-stage challenge with the flag string encoded in multiple ways, made more complicated by you not having feedback that the intermediate step had been correct. 

After trying all sorts of encoding methods and some guessed possible keys I ultimately reached out to the author of the question and asked: 
“is the string 'poqdckhn', (with additional work) all you need for the crypto challenge. Or does something else need to be derived from the image/file to use in conjunction?”
They confirmed that there were three steps and when I asked if I would know that the intermediate step had been correctly solved, I was informed that I would not. But I was assured:
“When the challenge was created, we thought of some common ciphers that we were taught in the classroom.” 
So I wasnt to expect anything too exotic/ complicated.

The Logo obviously contains a string of hexadecimal characters:

70 6F 71 64 63 6B 68 6E

These all fall within the ascii alphabet range and correspond to:


The kicker here is that you have to ROT13 (at least they didn’t use a less common ROT) the string, resulting in:


I tried various different cipher methods but ultimately determined that a Vigenère cipher was correct. I undertook an exercise to try and find possible keys early before this time and included the following list:
  • champlain
  • ccdfa (Champlain College Digital Forensics Association)
  • lcia (Leahy Center for Digital Investigatio)
  • audeamus (champlain college motto)
  • beaver (Chaplain College Mascot)

Throughout the process I used the fantastic tool CyberChef to allow me to quickly try different variations. My eventual recipe was as below:

Imagine my surprise (read moderate rage) when I found the flag had been under my nose all along. Using the key ‘champlain’, or specifically ‘champlai’ due to string length, resulted in the answer ‘audemus’. Due to the fact that the flag was Latin, to be honest I’m not sure I would have realised it was correct had I not previously researched the motto as a possible key.

2019 Unofficial DEFCON DFIR CTF Writeups


First a shout out to the Champlain College Digital Forensics Association (@champdfa) for putting together an awesome CTF and to David Cowen for making it public. For those who aren’t aware David has authored and run a number of awesome CTFs over the last few years, including an Unofficial DEFCON DFIR CTF released during the week of DEFCON. Each one of them has been great fun and an awesome learning experience.

This year, due to other commitments, he was hard pressed to design one from scratch. Fortunately CCDFA came to the rescue and David hosted the CTF based upon a dataset and questions which they had previously designed. Details of the CTF can be found here

I’ve never put together a CTF write-up before, but I have often benefited from those written by others. It's great as a learning tool and to help understand other people’s processes when solving these types of challenges. So here goes nothing.

If of interest to anyone, I had no access to my usual commercial tools during this CTF and as such the majority was solved using the following (some I have personal/home use licenses for):

  • FTK Imager ( - Until I noticed I was out of date and a bug was impeding progress!
  • FTK Imager ( - Much better
  • Autopsy (4.12)
  • Eric Zimmerman's tools (including KAPE)
  • Volatility 2.6
  • 7Zip
  • 010 Editor 8.0.1
  • Arsenal Image Mounter (3.0.64)
  • Passware Kit Standard (2019.3.2)
I'll be releasing the write-up as a single post per section of the CTF, these are:
  1. DFA Crypto Challenge
  2. Deadbox Forensics
  3. Linux Forensics
  4. Memory Forensics
  5. Triage VM Questions