Magnet Virtual Summit 2020 CTF – Memory Analysis Write-up

The Magnet Virtual Summit ran throughout May 2020 and included a CTF created in association with the Champlain College Digital Forensics Association. The CTF included Android, Apple iOS, Windows host, and Windows memory analysis challenges. Unfortunately I didn’t have as much time to spend on the CTF as I had hoped while the challenge was live so this write-up only covers the Windows memory analysis, as this is an area I have been focusing on recently.

The MVS is over and the CTF is no-longer available to the public, but the presentation videos are available to watch via the Magnet Forensics site.

Let’s get on with the analysis.

MD5: 224f93209cbea29e862890f30dfa762d
SHA1: 55f0d288c91296621e9d9f50a9d8ecf81d4e3148

01 – How’s Your Memory?

Which memory profile best fits the system?

This is generally the first thing you will need to work out when given a memory image to examine. We can use Volatility’s imageinfo or kdbgscan plugins to determine which profile best fits our image, I tend to use imageinfo. -f memdump.mem imageinfo

The imageinfo plugin gives us a number of suggestions, but the profile Win7SP1x64 seems a sensible choice.

Flag: Win7SP1x64

02 – Hash Slinging

What is the LM hash of the user’s account?

Now that we have determined which profile to use we can get on with the rest of the analysis. Volatility has a hashdump module which, unsurprisingly, dumps hashes from the SAM registry hive. -f memdump.mem --profile=Win7SP1x64 hashdump

The question doesn’t actually specify the username, but as there is only one user account other than the default Administrator and Guest accounts, we can be pretty sure the Warren account is the one we are after. NTLM hashes are stored in the format:

<username>:<rid>:<LM hash>:<NT hash>

As the question asks specifically for the LM hash, our flag is:

Flag: aad3b435b51404eeaad3b435b51404ee

03 – Cache Money

What is Warren’s Ignition Casino password? (Case Sensitive!!!!)

I found this question the hardest one in the section and undoubtedly spent the most time on it. I started by running the pstree plugin to get an overview of what processes were running when the memory image was captured. -f memdump.mem --profile=Win7SP1x64 pstree

The first process I looked into was WINWORD.EXE (PID: 3180) in the hope that the user had typed the password into a document, but unfortunately this was a red-herring. Next I moved on to the web browsers, starting with Chrome.

If allowed by the user, Chrome will store login details for websites so that they can be auto-filled on subsequent visits. The passwords themselves are encrypted, but even if we can’t decrypt them we might get something useful from the database. The first thing to do is use the filescan plugin to output a list of files and their offsets within the memory image. I expected to use this output a lot for later questions, so I redirected the Volatility output to a file to speed up searching later on. -f memdump.mem --profile=Win7SP1x64 filescan > filescan.txt

Chrome stores the login data in a SQLite database called Login Data under the user’s local profile. Using grep to filter the filescan output we can quickly find the database offset and extract it using the dumpfiles plugin.

grep -i '\\Device\\HarddiskVolume1\\Users\\Warren\\AppData\\Local\\Google\\Chrome\\User Data\\Default\\Login Data' filescan.txt -f memdump.mem --profile=Win7SP1x64 dumpfiles -Q 0x000000013fa8cf20 -D .

Now that we have extracted the Login Data database we can open it up in a SQLite browser and take a look.

Record 3 contains the data for the Ignition Casino website. We can clearly see the stored email address (warrenhamiltonfinance[@]gmail[.]com) but, as expected, the password is encrypted.


Having done some digging into Chrome’s password storage mechanism it is likely that they can be decrypted using data we have in the memory dump, however as I had limited time available I opted for the less elegant approach of running strings over the memory image and heavily relying on grep! We were able to confirm the email address that Warren used, giving us our first filter. Searching these lines for casino seems reasonable.

strings memdump.mem | grep -i '' | grep -i 'casino'

There we go! That looks enough like a password that it is worth submitting, and it turns out to be correct.

Flag: WHbigboy123

04 – Never Tell Me The Odds…

It seems like Warren may have let his addictions slip into his work life… Find the program in question, recover it from memory, and give the SHA1 hash

We need to find the Ignition Casino executable and calculate its SHA1 hash. There is nothing obviously related to Ignition Casino in the pstree output, but we can check the filescan output for clues.

grep -i 'casino' filescan.txt -f memdump.mem --profile=Win7SP1x64 dumpfiles -Q 0x000000013d5f4070 -D .
sha1sum file.None.0xfffffa80339f4650.img

Our grep search only gives us one hit, but it looks like a plausible location for the application to have been installed. Again, we can use the dumpfiles plugin to extract the executable, then calculate the SHA1 hash.

Flag: 3b7ca3bb8d4fb2b6c287d6a247efd7c457937a3e

05 – Compilation Station

When was IgnitionCasino.exe compiled? YYYY-MM-DD HH:MM:SS

Now that we have the executable, we move away from memory analysis for a little bit to examine the executable itself. There are number of different tools to examine PE files, but I have pev installed on my SIFT VM, and that is enough for what we need to find here. I used grep to clean-up the output.

pev file.None.0xfffffa80339f4650.img | grep 'Date/time stamp:'

We can see the compilation date and time. Converting it to the YY-MM-DD HH:MM:SS format required by the question, we get our final flag.

Flag: 2020-02-12 12:01:35

TufMups Network Forensics Challenge Write-up

Recently I was browsing the CTF section and found a nice network forensics challenge released by Andrew Swartwood in December 2017 called TufMups Undercover Operation.

We are given a PCAP to analyse, and the following briefing:

You’re an agent with a government law enforcement agency. You’ve been tracking a group of criminal hackers known as “TufMups”. This group either keeps a low profile, your agency’s capacity to run investigations on the internet is very poor, or some combination of those two factors. Up until two days ago you had an active relationship with an informant who went by the handle “K3anu”. As you walked into your office you received a package containing a flash drive, a printed screenshot (at the top of this blog post) and a very short note.
“Review this PCAP. It will all make sense. Woaaahhhh. – K3anu”
That package was the last you heard from K3anu.

Let’s download the PCAP and get started then.

01 – What is the start time of the PCAP (“Date and Time of Day” setting in Wireshark round to nearest second)?

After extracting the PCAP file and opening it in Wireshark, we can bring up the Summary window to find the start and end time of the capture. One thing I’m not sure about is the timezone – it’s not explicitly specified. My SIFT VM and Wireshark are both set to UTC so let’s assume that for now.

2017-12-10 22:43:17

02 – What is the end time of the PCAP (“Date and Time of Day” setting in Wireshark round to nearest second)?

The Summary screen also gives us the end time of the capture. Again, assuming UTC as no timezone is specified and that’s what I’m working with locally.

2017-12-10 23:25:19

03 – How many total packets were sent between the host and the hacker website IP?

Using the Endpoints screen we can quickly summarise the traffic sent between each IP address in the capture. We know from the provided screenshot that the server we are interested in has the IP address

By checking against our IP of interest we can see that 15,128 packets were exchanged.


04 – What is the hostname of the system the PCAP was recovered from? (all caps)

Hostnames aren’t always going to be available in PCAPs, at least not directly. In this case we can filter for DHCP traffic and examine any requests that have been captured.

We only have one DHCP request in our capture and it matches the IP address of our capturing system. Examining the packet details we find the hostname:


05 – What exact version of browser did K3anu use? (exact number only)

We can find the web browser user-agent string by filtering for HTTP requests made by K3anu’s system:

http and ip.src==

Examining a request gives us the following string:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

There are a few ways to decode this to find the browser version; I used CyberChef.

K3anu was using Chrome 63.0.3239.84


06 – What operating system did K3anu use? (Name and number only)

We already have the answer to this from Question 5:

Windows 10

07 – How many DNS queries in the PCAP received NXdomain responses?

We can filter for DNS packets where the Response Code is set to 3, indicating that the domain did not exist.

dns.flags.rcode == 3

5 responses

08 – What is the hidden message in the TufMups website? (decoded)

If the TufMups website were still online we could simply visit it and take a look. Unfortunately it was offline when I did this CTF but we can use our network forensics skills to find out what it looked like.

By filtering on HTTP traffic between K3anu’s system and the TufMups server, and following the HTTP Stream (#2879), we can see the HTML source including an interesting comment.


From the character set this looks like base64, but decoding it only gives us:


Maybe it is encrypted rather as well as encoded. CyberChef has a collection of cipher functions that we can try, including an XOR Brute Force module. By default the module will attempt single-byte keys and display the output.

CyberChef for the win.

ftp creds are p1ggy / ripgonzo

09 – What is the key to decode the secret message in the TufMups website?

From our work on Question 8 we know the key:


10 – How did K3anu get access to the file? (lowercase, just protocol)

The hidden message in the TufMups website mentions FTP credentials, so that is a good starting point. We can filter on FTP traffic, and follow the TCP Stream (#4075) for easier reading.

We can see that two files were downloaded to K3anu’s machine – decrypttool.exe and Those are probably worth remembering for later.


11 – What’s the nickname of the operator on the IRC channel?

Similarly, we can filter on IRC traffic and follow the TCP Stream (#2930) for easier reading.

IRC operators typically have @ before their nickname so they can be identified.


12 – What is the 1st operation needed to decode the IRC users “secure” comms? (just the format name)

Scrolling through the IRC chat between K3anu and the TufMups we see a few messages that stand out. With context from the questions, there are four steps required to make them legible.

The first message is:


From the character set (and because it’s almost always the first thing I try) let’s assume base64 encoding.


13 – What is the 2nd operation needed to decode the IRC users “secure” comms? (just the format name)

Our result from Question 12 looks like Hex encoding, but the character set has been shifted. Using CyberChef we can easily apply rot13.


14 – What is the 3rd operation needed to decode the IRC users “secure” comms? (just the format name)

From here CyberChef actually does the work for us, and suggests that applying the From Hex then From Morse Code operations will give us human-readable output.

Let’s try it!


15 – What is the 4th and final operation needed to decode the IRC users “secure” comms? (2 words lowercase)

morse code

Now that we know the required steps we can decode the remaining “secure” messages in the captured IRC chat.


It’s not looking good for K3anu!

16 – What is the password to decrypt the zip file that was downloaded by K3anu?

The TufMups have given K3anu a test – decrypt a file from their FTP server. In Question 10 we saw K3anu download two files from the TufMups FTP server; we need to extract them from the PCAP.

Filter on ftp-data to show the file transfer traffic, then follow the TCP Stream for the ZIP file (#4079)

Select the Raw radio button and Save As. We have our ZIP file, but we need a password to open it.

There are a few tools capable of cracking ZIP passwords; my goto is John The Ripper.

First, we use the zip2john utility to extract the hashed password from the ZIP.

zip2john ~/tufmups/ > ~/tufmups/

Then, use John with the RockYou wordlist to crack the extracted hash.

john --wordlist=/opt/wordlists/rockyou.txt ~/tufmups/

It doesn’t take John very long to churn through the wordlist and find a match:


17 – How many total rows of “fullz” are represented in the file?

After extracting the ZIP file we are presented with a CSV – tufmups_fullz_dec17.csv

We can check the number of lines in the file with a simple bash command

wc -l tufmups_fullz_dec17.csv
head -n 1 tufmups_fullz_dec17.csv

Subtracting one row to account for the column headers, we have 13377 rows of “fullz”.


18 – How many people in the fullz are named Joshua, have a MasterCard, and use an OS X system?

This can be solved with a bit more command-line work; using grep to filter only the characteristics we are looking for, and wc to count the matching rows.

cat tufmups_fullz_dec17.csv | grep -i "joshua" | grep -i "mastercard" | grep -i "os x" | wc -l


19 – From the previous question (people named Joshua) – what is the most expensive car new in this filtered list?

Modifying the command from Question 18 slightly, we can get a list of cars by filtering out the “Vehicle” column (column 37).

cat tufmups_fullz_dec17.csv | grep -i "joshua" | grep -i "mastercard" | grep -i "os x" | cut -d "," -f 37

After a bit of Googling I found the answer:

2006 Pagani Zonda

20 – What IP and port does the executable connect to? ip:port

Remember K3anu downloaded decrypttool.exe from the FTP server as well as the ZIP file? And how the TufMups were going to feed some false data to confirm their suspicions? We’re getting back to that now.

Using the same technique as for Question 16, we can extract decrypttool.exe from the PCAP (TCP Stream #4077)

There are a few ways to tackle this now that we have the binary. If you have a Windows VM set up for malware analysis you could just execute the binary and track its activity. Instead, I calculated the MD5 hash (20422a060c5f8ee5e2c3ba3329de514f) and searched a public online sandbox for a quick win.

md5sum decrypttool.exe

It’s important to note that I searched for the hash of the binary. In general I do not upload potentially malicious binaries to a public sandbox. It may not make a huge difference in a CTF, but in a real-world incident response uploading a potentially malicious binary can tip-off an attacker that they have been detected. In this case, the binary had already been uploaded to the sandbox on 17 December 2017 – roughly 12 days before the CTF was posted online – and the resulting analysis including details of a network connection was available for inspection.

22 – What was used to compile the malicious executable?

This one took me quite a bit longer than I expected and I ended up taking a guess. Given the numerous references to Python in the Dropped Files section of the sandbox analysis, and in the output of the strings utility, I guessed PyInstaller.


23 – What executable did K3anu likely use to download files from the remote server? (exactly as written in source material)

We know that the TufMups found out about K3anu’s real identity, and that K3anu downloaded an executable that connects back to the TufMups server on an unusual port. Let’s see if there is anything in the PCAP to shed light on what the TufMups found.

Filter for traffic on the IP address and source used by the TufMups binary.

ip.addr == && tcp.port == 1234

Follow the TCP Stream (#4082) for easier reading. Our malicious binary is acting as a reverse shell into K3anu’s machine!

Reading through the stream we can see a list of running processes. Based on the process names, the only dedicated FTP client is WinSCP.exe


24 – What is the host system’s exact BIOS version?

We can use the same TCP Stream (#4082) to answer the next few questions as well. The output of the systeminfo command lists the exact BIOS version.

innotek GmbH VirtualBox, 12/1/2006

25 – What is the filename of the first file taken from K3anu’s computer?

We can see two files being exfiltrated back to the TufMups server; is the first of the two…


26 – What is the filename of the second file taken from K3anu’s computer?

…and the second is


27 – What utility was used to steal the files from K3anu’s computer?

The files were transferred using ncat.


28 – What destination port was used to steal the files from K3anu’s computer?

The ncat connection was established to port 1235.


29 – What is the password to decrypt the file stolen from K3anu’s computer? (it’s lowercase)

There were two ZIP files transferred from K3anu’s machine – and – extract them both from the PCAP using the same technique as Question 16 and Question 20.

I started with – which didn’t require a password – and contained two images of airports. The Comment field in the EXIF data gave a clue…

My guess was that the IATA airport codes for the respective images would lead to the password for, but I don’t have time for OSINT. Let’s try cracking the password first.

Same procedure as Question 16. First run zip2john to extract the hash, then john itself to perform the cracking.

zip2john ~/tufmups/ > ~/tufmups/
john --wordlist=/opt/wordlists/rockyou.txt ~/tufmups/

Using the RockYou wordlist once again, it doesn’t take long to crack the password hash.


30 – What is K3anu’s real identity?

The file contains three images. Once again, the EXIF data reveals more clues about K3anu’s identity. Examining constantine2.gif give us the following.

My true identity is constantine, eternal enemy of Kermit the frog AKA k3rm17 of TufMups.

31 – What city is K3anu likely to be in?

This time it’s the EXIF data from constantine3.jpg that is of use to us.

Generally the TufMups have their enemies shipped to 42.226391, -8.899541

I guess we have to do a little bit of OSINT after all. Plugging the coordinates into Google Maps give us the following location:

The city isn’t immediately obvious, but with a bit of digging the closest city appears to be Pontevedra, Spain.


32 – What is K3anu’s likely status? (lowercase)

The EXIF data from Constantine1.jpg gives us our answer.

If you've found this I'm already dead, killed by the vicious muppets of TufMups.

33 – What is the address of the restaurant closest to where K3anu is likely to be? (exactly as reported by Google maps)

Back to Google Maps.

Camino C5 Illas Cies, 8, Vigo, Pontevedra, Spain

34 – The hacker left a message for law enforcement on K3anu’s system, what was it? (message only)

Reading to the end of the traffic sent by decrypttool.exe (TCP Stream #4082) we can see the final message left for the investigators.

yeah good luck finding this guy cops, great job picking an informant.. real winner with his grilled cheese

Woaaahhhh, indeed.

OtterCTF 2018 – Network Challenges – Otter Leak Write-up

OtterCTF dates from December 2018 and includes reverse engineering, steganography, network traffic, and more traditional forensics challenges. This write-up covers the network forensics portion. I have previously written-up the memory forensics section, and the Birdman’s Data and Look At Me network challenges. The whole CTF is available to play as of the publication of this post.

I managed to complete three of the four challenges in the network traffic section of the CTF. This post is a write-up of the Otter Leak challenge.

We start off by downloading the PCAP. The MD5 and SHA1 hashes are:

MD5: d0ab559c54fffe713fd13e9b0f7174df
SHA1: 35a934a665497c111ad572299840f002476cff81

Opening the PCAP file with Wireshark, we can check the Protocol Hierarchy to get a quick summary of the kind of traffic we are working with.

We can see some SSH traffic, but more interesting at the moment is the SMBv2 traffic which is often used to transfer files. We could use a tool like Network Miner to extract any file objects from the PCAP, but Wireshark gives us the means to do this as well.

Checking the Export SMB Objects window, we can see a large number of files with names suggesting they are images, but with a file size of only 1 byte. Let’s export them all to a new directory and see what we have.

We can use the cat command to print the content of all our 1-byte files to the terminal…

cat export/%5cotter-under-water.jpg.638x0_q80_crop-smart*

…giving us the following output:


Our output has the = padding suggesting we might be dealing with base64 encoding. Let’s see what CyberChef makes of this.

Running the From Base64 operation gives us something that looks like Morse Code.

-- ----- .-. ..... . --- - --... ...-- .-. .. -. -... -.... ....-

We could try to decipher this by hand, or we can use CyberChef’s From Morse Code operation to do it for us.

And just like, out pops our plaintext leaked data and our flag.



OtterCTF 2018 – Network Challenges – Look At Me Write-up

OtterCTF dates from December 2018 and includes reverse engineering, steganography, network traffic, and more traditional forensics challenges. This write-up covers the network forensics portion. I have previously written-up the memory forensics section, and the Birdman’s Data network challenge. The whole CTF is available to play as of the publication of this post.

I managed to complete three of the four challenges in the network traffic section of the CTF. This post is a write-up of the Look At Me challenge.

We start by downloading the challenge PCAP and calculating hashes for reference.

MD5: d7dbb2394596594b438ab3110ace3408
SHA1: fc16f0636a7f141b8b17e0e7a38b776dd5c21c82

Opening up the PCAP in Wireshark, the first thing is that we are not working with TCP/IP traffic; instead this appears to be USB data from a Wacom CTL-471 drawing tablet. After some Google searching I found a write-up of a 2017 BITSCTF challenge featuring USB traffic from a Wacom CTL-460 tablet, which was a huge help in solving this challenge.

With the help of The Blog Post I realised that the packets containing the Leftover Capture Data we need could be filtered within Wireshark based on the Frame Length

((usb.transfer_type == 0x01) && (frame.len == 37))

Then extract to a separate PCAP with tshark for further processing.

tshark -r look_at_me.pcap -w filtered.pcap -Y '((usb.transfer_type == 0x01) && (frame.len == 37))'

The data we need is a representation of the X/Y coordinates of the pen on the drawing tablet, and the Z value representing the pressure of the pen. Using the packet in the screenshot above as an example:


02:f0 - Header
82:0a - X
ba:05 - Y
00:08 - Z (Pressure)
00    - Padding?

This data is contained within the usb.capdata field; we can use tshark again to extract this to a text file and discard the rest of the PCAP.

tshark -r filtered.pcap -T fields -e usb.capdata -Y usb.capdata > usb.capdata.txt

The next thing to do was to use awk (shamelessly lifted from The Blog Post) to convert these raw hex values to little-endian X/Y and Z coordinates.

awk -F: '{x=$3$4;y=$5$6}{z=$7}$1=="02"{print x,y,z}' usb.capdata.txt >

After installing the pwntools Python library and running a small Python script “inspired” by The Blog Post, we have the coordinates in a format suitable to be plotted as an image using Gnuplot.

from pwn import *

for line in open('').readlines():
  coord = line.strip().split(' ')
  x = int(coord[0],16)
  y = int(coord[1],16)
  z = int(coord[2],16)

  if z > 0:
    print u16(struct.pack(">H",x)),u16(struct.pack(">H",y))

We feed our newly converted coordinates into Gnuplot

And out pops an image!

After exporting to a PNG file, we can flip it for easier reading.

convert -flip flag.png flag-flipped.png

There we go! Submit the flag and claim the points, thanks in large part to The Blog Post.


Next up in my OtterCTF series, Otter Leak.

13Cubed Mini Memory CTF Write-up

At the beginning of March 2020 Richard Davis published a small memory forensics CTF challenge to his 13Cubed Youtube channel, with four questions and the generous prize of a Nintendo Switch Lite for a randomly selected entrant with all four correct flags. Well, I didn’t win, but I did have a lot of fun digging into the memory image. And as Richard has published his official solution I thought I’d show my working as well.

We start off as usual by downloading the memory dump and calculating some hashes.

MD5: f3cc405eaf4e63cb9c4b4986c86a7016
SHA1: 7d2b7802b87da03c5e96f159d0bc7ba29896a07c

Before we can dig any deeper into the image we need to tell Volatility which profile to use by running the imageinfo plugin. -f memdump.mem imageinfo

We are offered a few possibilities but Win10x64_17134 seems sensible enough for now. On with the challenge!

Flag 1

Find the running rogue (malicious) process. The flag is the MD5 hash of its PID.

There are a few different plugins which will show us information about processes; my favourite is pstree as it makes spotting parent/child relationships much easier. -f memdump.mem --profile=Win10x64_17134 pstree

We have a lot of running processes! Things get more interesting after scrolling down a bit further.

There are a number of processes named svchost.exe running under explorer.exe – this should never happen with a legitimate svchost.exe process! Let’s dig a bit deeper with pstree, using grep to show the column headers, and filter out the svchost.exe processes with a Parent Process ID of 4824 (explorer.exe) -f memdump.mem --profile=Win10x64_17134 pstree | grep -E "^Name|svchost" | grep -E "^Name|4824"

The question specified a running process; 8560 looks a likely candidate given it is the only one that has any threads attached, but let’s use the psscan plugin to confirm. -f memdump.mem --profile=Win10x64_17134 psscan | grep -E "^Offset|svchost" | grep -E "^Offset|4824"

As the screenshot above shows, all the candidate process have an exit time except for 8560, suggesting it is our running rogue process. Calculate the MD5 hash of the PID and we have our first flag.

echo -n 8560 | md5sum

Flag 2

Find the running rogue (malicious) process and dump its memory to disk. You’ll find the 32 character flag within that process’s memory.

We start by dumping the memory of our rogue process to disk, and extracting the human-readable strings. -f memdump.mem --profile=Win10x64_17134 memdump -p 8560 -D .
strings memdump.mem > 8560.dmp.strings

Easy so far. Unfortunately our output file contains almost 24 million lines (23,912,252 to be exact). We know the flag is 32 characters long, so let’s run strings again and specify that only lines with 32 characters or more should be extracted, then run those through sort and uniq to remove any duplicates.

strings -n 32 8560.dmp.strings | sort | uniq > 8560.dmp.strings.32

That’s a big reduction but still leaves 491,446 lines to search through. Sadly, with no idea what the flag looked like, I wasn’t able to find a more elegant way of filtering it out so resorted to paging through the file using less until I found something interesting.

"contents": "da391kdasdaadsssssss t.h.e. M2ExOTY5N2YyOTA5NWJjMjg5YTk2ZTQ1MDQ2Nzk2ODA=",

The last part of the string is longer than 32 characters, and looks like base64; let’s decode it and find the second flag.

echo -n M2ExOTY5N2YyOTA5NWJjMjg5YTk2ZTQ1MDQ2Nzk2ODA= | base64 -d

Flag 3

What is the MAC address of this machine’s default gateway? The flag is the MD5 hash of that MAC address in uppercase with dashes (-) as delimiters. Example: 01-00-A4-FB-AF-C2.

This question incorporates a bit of Windows host-based forensics knowledge. Details of the host’s network connections are held in the SOFTWARE registry hive, under the following key:

Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged

We can use Volatility to query the registry hives in memory using the printkey plugin; by default printkey will search through all available registry hives in the memory image, but we can be a bit more precise and use the hivelist plugin to find the address of the SOFTWARE hive rather than brute-forcing it. -f memdump.mem --profile=Win10x64_17134 hivelist

The hivelist plugin completes and tells us the virtual address of the SOFTWARE hive is 0xffffd38985eb3000. Now to use printkey to query the registry itself. The network data sits under a randomly generated sub-key; we will need to determine that before getting the data we are after. -f memdump.mem --profile=Win10x64_17134 printkey -o "0xffffd38985eb3000" -K "Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged"

Luckily there is only one sub-key, making the task easier.


Running printkey again with our newly discovered path gives us our network data. -f memdump.mem --profile=Win10x64_17134 printkey -o "0xffffd38985eb3000" -K "Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged\010103000F0000F0080000000F0000F0E3E937A4D0CD0A314266D2986CB7DED5D8B43B828FEEDCEFFD6DE7141DC1D15D"

The MAC address of the default gateway is at the bottom of the output under DefaultGatewayMac. The question asks for the answer as the MD5 hash of the upper-case MAC address, with dashes as delimiters. Sounds like a task for CyberChef!

There we go. Flag three:


Flag 4

Find the full path of the browser cache created when an analyst visited The path will begin with “Users\.” Convert the path to uppercase. The flag is the MD5 hash of that string.

This one was relatively straightforward. We need to find a filepath created when was visited in a web browser. The question tells us that the path begins with “Users\” and we can assume that it contains the string “13cubed” as well. I first tried the filescan plugin to check for relevant file objects in memory, but this did not give me any meaningful results.

I tried again using the mftparser plugin which, perhaps obviously, parses the Master File Table combined with grep to filter on the string “13cubed -f memdump.mem --profile=Win10x64_17134 mftparser | grep -i "13cubed"

This gives two results, one HTML file and one PNG image. As we are looking for a web browser artefact I went with the path of the HTML file:


We need to convert this to upper-case and calculate the MD5 hash to get the flag; back to CyberChef.

Final flag – done.


I didn’t win the Nintendo Switch but had a huge amount of fun working through the challenge, especially working on registry analysis via the memory image. I would encourage anyone reading this who wants to improve their forensics and incident response skills to subscribe to the 13Cubed Youtube channel, and I hope that Richard finds the time to put more challenges together in the future!

Security Blue Team VIP CTF #1 – “Switching Teams” Write-up

The first CTF created by Security Blue Team was initially for subscribers only, but was made available to the public for a short time at the end of February 2020. While it covered network traffic analysis, password cracking, steganography, forensics, and some general knowledge challenges I didn’t have as much time as I would have liked to spend, so concentrated on the aspects that were most interesting to me personally.

This write-up covers the second of three password cracking challenges – Switching Teams. You can find the rest of my write-ups for Security Blue Team VIP CTF #1 here.

This time we have a password-protected ZIP archive name, and a dictionary file named SuperSecret.txt. We start by extracting the password hash from the archive using the zip2john utility.


This archive contains a mix of plaintext and password-protected files. To make sure we get the correct password, we can specify which file we are interested in with the -o flag. The archive contains a file called John/Flag1.txt which sounds like something we are interested in.

With the following command we can extract the correct password hash to a file.

zip2john -o John/Flag1.txt > flag1.hash
cat flag1.hash

So now we have a file containing our hash, and a file containing our wordlist. We could use a brute-force attack as suggested in the question, but let’s use what we are given first. Let’s feed both files to John.

john --wordlist=SuperSecret.txt flag1.hash

Almost immediately John returns our password – a1b2c3d4 – but we’re not done yet. Our flag is inside the password-protected archive, so let’s extract it (supplying our cracked password when prompted) and take a look.

cat John/Flag1.txt

There we go. Now we have our flag.


The final password cracking challenge – Jumbled – involved setting a mask and was more suited to a different password-cracking tool, hashcat. I was unable to get hashcat to run correctly on my SIFT virtual machine, and so as I had limited time for this CTF, I decided to skip it and move on to other challenges instead.

Security Blue Team VIP CTF #1 – “Weekpass” Write-up

The first CTF created by Security Blue Team was initially for subscribers only, but was made available to the public for a short time at the end of February 2020. While it covered network traffic analysis, password cracking, steganography, forensics, and some general knowledge challenges I didn’t have as much time as I would have liked to spend, so concentrated on the aspects that were most interesting to me personally.

This write-up covers the first of three password cracking challenges – Weekpass. You can find the rest of my write-ups for Security Blue Team VIP CTF #1 here.

We are provided with two files – passwd and shadow – which contain the user account details and password hash. For this challenge we will combine the two files, and use John The Ripper to crack the hash.

To combine the files we use a utility bundled with John called unshadow

unshadow passwd shadow > weekpass.hash
cat weekpass.hash

Now that we have our hash in a format that John can use, we need to find a wordlist or dictionary; the list of approximately 14.3 million plaintext passwords from the 2009 RockYou breach is still a good starting point a decade onwards. The list is included with Kali linux or can be downloaded from the internet. As I am using the SANS SIFT virtual machine, I downloaded the list and passed it to John via the following command.

john --wordlist=rockyou.txt weekpass.hash

After a couple of minutes work (a downside of cracking passwords on virtual machines) John has found a match – welcome01 – and we have our flag.


Next up in the password cracking category, Switching Teams.

Security Blue Team VIP CTF #1 – “Twin” Write-up

The first CTF created by Security Blue Team was initially for subscribers only, but was made available to the public for a short time at the end of February 2020. While it covered network traffic analysis, password cracking, steganography, forensics, and some general knowledge challenges I didn’t have as much time as I would have liked to spend, so concentrated on the aspects that were most interesting to me personally.

Of the five “general knowledge” questions, four were multiple choice. This write-up covers the one general knowledge challenge which required a bit of command-line work – Twin. You can find the rest of my write-ups for Security Blue Team VIP CTF #1 here.

After downloading and extracting the archive we are indeed presented with 4400 files, totalling 88000 lines.

ls | wc -l
cat * | wc -l

Still, we can find the duplicate line by chaining together a few Linux command-line tools: cat, sort, and uniq. First we cat all 4400 files out, and sort all 88000 files into alphabetical order. Then use uniq with the -c flag to count the occurrences of each line. This should be 1 in every case except for our flag. Next use sort again, this time with the -n and -r flags so that we sort in numerical order, which is then reversed so that our duplicate line appears at the top of the list. Optionally, use head to restrict the output to the first 10 lines.

cat * | sort | uniq -c | sort -nr | head

2 VXZ5eWdiY1BHU3tnajFhNV9wNGFfYTNpM2VfbzNfZjNjNGU0NzNxfQ==

Given the == at the end of the line, the output looks like base64. Let’s feed it to CyberChef and see what we can do.


The From Base64 operation gave us human-readable text, but we still don’t have our flag in the correct format. It looks like a substitution cipher, so let’s try the Rot13 function.

That’s much better. We have our flag!


Security Blue Team VIP CTF #1 – Sneaky Transmission Write-up

The first CTF created by Security Blue Team was initially for subscribers only, but was made available to the public for a short time at the end of February 2020. While it covered network traffic analysis, password cracking, steganography, forensics, and some general knowledge challenges I didn’t have as much time as I would have liked to spend, so concentrated on the aspects that were most interesting to me personally.

This write-up covers the network analysis challenge – Sneaky Transmission. You can find the rest of my write-ups for Security Blue Team VIP CTF #1 here.

After downloading the PCAP file we can open it in Wireshark to see what we are working with. While the question refers to a DoS attack, and to the possibility of a photo, all we see in the PCAP is ICMP traffic.

Nothing here is obviously an image, but the TTL values of the IMCP requests look a bit strange. Using the following Display Filter we can examine them more easily.

icmp.type == 8

The TTL value changes with each packet, which might be an indication of a covert channel; one byte per packet perhaps? We can easily extract the TTL values using tshark and redirect them to a file.

tshark -r sneaky_transmission.pcapng -Y "icmp.type == 8" -Tfields -e ip.ttl

The data will be much easier to work with if we output it to a file.

tshark -r sneaky_transmission.pcapng -Y "icmp.type == 8" -Tfields -e ip.ttl > ttl.txt

We now have a file containing what we think might be individual bytes, one-per-line, which we need to turn into something more intelligible. One of my favourite tools for playing with data like this is CyberChef, so let’s load our ttl.txt file as input and see what we can make from it.

First, let’s convert From Decimal back to the raw bytes.

That looks a lot like the “magic bytes” at the start of a JPEG file! CyberChef can render that as an image.

And there we are. We have our sneaky transmission, just as the question hinted at.


OtterCTF 2018 – Network Challenges – Birdman’s Data Write-up

OtterCTF dates from December 2018 and includes reverse engineering, steganography, network traffic, and more traditional forensics challenges. I have written-up the memory forensics section in a previous post. The whole CTF is available to play online as of March 2020.

This series of write-ups will cover the three challenges I was able to complete out of the four available in the network analysis section of the CTF, starting with a write-up of the Birdman’s Data challenge.

We start by downloading the PCAP containing the challenge data, and calculating some hashes.

MD5: 67157597613fc288fe8dbce910707a2f
SHA1: ae7d7060bab931c6241e18aacbeb03a61a744c10

When examining a PCAP I like to start by checking the Conversations and Protocol Hierarchy to get an idea of what kind of traffic we are dealing with.

We can see some HTTP traffic in the Protocol Hierarchy so let’s look into that.

This looks like plaintext HTTP traffic to an online text encryption service. We can follow the HTTP stream to get some more details of what is being sent and received, including the parameters used by the encryption service.

As we examine the HTTP stream further we find two parameters named key


And a third parameter named ciphertext.


Assuming that the first key parameter is the Key, and the second is the IV, we can use the online service to decrypt the ciphertext.

It worked! Out pops the plaintext message. But we’re not done yet, we still need to extract the flag.

The layout of the text is a little bit odd; looking at the first characters of the first four lines seems to spell CTF{… With a bit of command-line work we can clean this up.

cat plaintext.txt | cut -c 1 | tr -d '\n'

There we go! Now we can submit our flag and claim the points.


Next up in my OtterCTF series, Look At Me.