DFA/CCSC Spring 2020 CTF – Apple iOS Forensics with iLEAPP

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. I published my network traffic analysis write-ups earlier in the year, and after spending some more time on memory analysis, I decided to take a look at something different.

Over the last few months I have been seeing more and more chat about iLEAPP – the iOS Logs, Events, and Plists Parser – from Alexis Brignoni (with plugins and artefact definitions submitted by many others!), and wanted to set some time aside to play with it myself. I didn’t have any jailbroken iOS devices or fancy iOS acquisition kit to hand, but I remembered the iOS section of the Champlain College CTF and realised I could use that instead.

This post is nowhere near a full write-up of the iOS analysis section. Instead, think of it more as an illustration of what can be accomplished with iLEAPP and a spare hour on a Sunday afternoon! I used the CTF questions as a guide for the analysis, however if I couldn’t see a way to get the answer directly from iLEAPP I simply moved on to the next one. With that in mind, let’s go!

Installing iLEAPP (on Ubuntu 20.04 LTS)

The first thing to note is that iLEAPP requires at least Python 3.7.4 in order to run.

As far as possible, I like to use free or open-source tools when writing-up CTF challenges so that they are accessible for people without access to commercial tools. Purely out of habit I have been using an old copy of the SANS SIFT virtual machine based on Ubuntu 16.04 for most of my write-ups to this point. I recently took the time to setup a copy of the updated SIFT VM based on Ubuntu 18.04, but after fighting with multiple different versions of Python for a while, I gave up and built a new virtual machine with a default installation of Ubuntu 20.04 which (in my case, anyway) shipped with Python 3.8 and made the iLEAPP installation so much simpler!

The iLEAPP readme contains easy to follow installation instructions but does assume that Python pip is already present. I had to install pip for Python 3 using the Ubuntu apt package manager. I also had to install the git client, again, using apt.

sudo apt update && sudo install git python3-pip

Once the correct version of pip is installed the remaining steps are quite straightforward. First, clone the repository from Github:

git clone https://github.com/abrignoni/iLEAPP.git

We can handle almost all of the requirements with pip:

cd iLEAPP
pip install -r requirements.txt

As I am installing on linux I also need the python3-tk package to support the GUI; apt can take care of that for us:

sudo apt install python3-tk

Now that we have iLEAPP installed we can get on with the analysis!

Processing with iLEAPP

The iOS dump used in the CTF was distributed as a TAR archive:

MD5: 09683cf41534735ab1c24dbb898a3a4a
SHA1: 1211ed593e5111e45d04077ede3d0cd9728349b0

iLEAPP can process the dump directly from the TAR file, or as a directory structure after manual extraction. In this case I chose to process the TAR file directly, using all of the available modules (selected by default):

Processing took 1 minute 18 seconds to complete on my rather underpowered virtual machine…

…and produced a nice HTML report of the findings.

As my focus was on playing with iLEAPP rather than fully completing the CTF, I have only answered six of the 19 questions in the iOS analysis section:

01 – I’m just trying to do my iObeSt (50 points)

What ios version is this device on?

The first question was simple – using the Device Details tab in the Case Information section of the report.

One thing that stood out was that the iOS version was 9.3.5, which is a little outdated in 2020. According to the documentation, the current version of iLEAPP (version 1.6) supports iOS versions 11, 12, and 13. I’m not sure if this made any difference to the analysis that iLEAPP was able to perform.

flag<9.3.5>

03 – The Man, the Myth, the Legend (50 points)

Who is using the iPad? Include their first and last name.

Digging through the iLEAPP report I found the Calendar Identity Report which listed the display name and email address of our old friend Tim Apple.

flag<Tim Apple>

07 – High Fi! (150 points)

What is the name of the WiFi network this device connected to

Again, iLEAPP makes this very simple – the report extracts a list of known WiFi networks. In this case there is only one entry, an SSID named black lab.

flag<black lab>

12 – Let me in LET ME INNNNNN (200 points)

What app was used to jailbreak this device?

iLEAPP also gives us a nice list of installed applications:

The com.saurik.Cydia package immediately stood out as one of the alternative App Stores commonly installed on jailbroken devices, but after some searching I found that the com.VN337S8MSJ.supplies.wall.phoenix package corresponds to the Phoenix Jailbreak for iOS 9.3.5 and 9.3.6

flag<phoenix>

18 – Interstellar Docking Scene Music (300 points)

Name one of the apps that were on this device’s dock. Provide them in bundle format: com.provider.appname

Going by the high number of CTF points awarded for this question one might expect the answer to be held in some obscure plist, but iLEAPP makes this easy!

The Apps per Screen report plots the position of each application icon in an easy to follow table, including those in the dock (icons bottom bar). We have four applications to choose from; I submitted the first one, which was accepted as a correct flag.

flag<com.apple.MobileSMS>

19 – Remind me later (300 points)

A reminder was made to get something, what was it?

Again, another 300-point question easily answered with iLEAPP.

The Calendar Items report lists two reminders; one to “go to bed before 5AM” and another to “get milk“. Easy!

flag<milk>

Summary

Again, this is not a complete write-up of the iOS analysis section of the Champlain College Spring 2020 CTF, and might not even be a complete representation of the current state of iLEAPP! Even so, I think this has shown how powerful a tool iLEAPP is for performing quick analysis of Apple iOS devices, and iLEAPP is regularly updated to support new analysis modules so I fully expect that its capabilities will improve further in future.

While the CTF has now formally closed meaning that no points will be assigned, the challenge site is still available and functioning as of October 2020 if you would like to download the images and have a go yourself. I was able to make quick progress with iLEAPP alone; the most recent version of the SANS Smartphone Forensics poster looks like a great help too for anything that iLEAPP might miss!

Memlabs Memory Forensics Challenges – Lab 3 Write-up

Memlabs is a set of six CTF-style memory forensics challenges released in January 2020 by @_abhiramkumar and Team bi0s. This write-up covers Lab 3 – The Evil’s Den. You can find the rest of my Memlabs write-ups here.

Before starting with the analysis I calculated the MD5 and SHA1 hashes of the memory dump

MD5: ce4e7adc4efbf719888d2c87256d1da3
SHA1: b70966fa50a5c5a9dc00c26c33a9096aee20f624

And determined the correct profile for Volatility:

vol.py -f MemoryDump_Lab3.raw imageinfo

The imageinfo plugin suggests a few profiles; I used Win7SP1x86_23418 to complete the analysis. To begin with, let’s check the running processes with pstree:

vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 pstree

There are two notepad.exe processes running (Pid: 3736 & 3432) but nothing else that immediately jumps out. Using the cmdlines plugin we may be able to see which files were opened.

vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 cmdline -p 3736,3432

That’s a bit more interesting now! Notepad was used to open two files – evilscript.py and vip.txt – let’s try to extract them:

vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 filescan > filescan.txt
grep -E '\\Desktop\\evilscript.py|\\Desktop\\vip.txt' filescan.txt
vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 dumpfiles -Q 0x000000003de1b5f0 -D . -n
vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 dumpfiles -Q 0x000000003e727e50 -D . -n

I used the filescan plugin to list all of the file objects (and their offsets) within the memory image, and redirected the output to a file. Using grep we get the offsets for the files (and also notice that evilscript.py is actually evilscript.py.py), then the dumpfiles plugin will extract the files to disk for analysis.

evilscript.py

import sys
import string

def xor(s):
  a = ''.join(chr(ord(i)^3) for i in s)
  return a

def encoder(x):
  return x.encode("base64")

if __name__ == "__main__":
  f = open("C:\\Users\\hello\\Desktop\\vip.txt", "w")
  arr = sys.argv[1]
  arr = encoder(xor(arr))
  f.write(arr)
  f.close()

vip.txt

am1gd2V4M20wXGs3b2U=

So, we have a Python script that works as follows:

  1. Take a string as a command-line argument
  2. Break that string down to its individual characters, and XOR each character with 3
  3. Encode the XOR’d string as Base64
  4. Write the Base64 encoded string to the file vip.txt

We could write another Python script to reverse these steps, but CyberChef is much easier!

Reversing the steps from evilscript.py, CyberChef spits out the first part of our flag:

inctf{0n3_h4lf

Now we have the first part of the flag, but we still need to find the second. None of the other running processes look particularly interesting, but the challenge description specifically mentions that steghide is required.

Steghide is a steganography program that is able to hide data in various kinds of image and audio files.

Using grep and my saved filescan output I filtered for common image file extensions, and spotted the following after searching for JPEG files:

grep -E '.jpg$|.jpeg$' filescan.txt | head
vol.py -f MemoryDump_Lab3.raw --profile=Win7SP1x86_23418 dumpfiles -Q 0x0000000004f34148 -D . -n

After extracting suspision1.jpeg:

We can feed it into steghide to check for any hidden data. Presumably the first part of the flag is the password…

steghide extract -sf suspision1.jpeg
cat secret\ text

And there we go, the second part of our flag.

_1s_n0t_3n0ugh}

Put them together, and we have completed the challenge!

inctf{0n3_h4lf_1s_n0t_3n0ugh}

Memlabs Memory Forensics Challenges – Lab 2 Write-up

Memlabs is a set of six CTF-style memory forensics challenges released in January 2020 by @_abhiramkumar and Team bi0s. I completed and published my write-up of Lab 1 in February 2020, but skipped the rest of the challenges due to the general wild-goose-chase approach of simply running Volatility plugins and searching the output for interesting strings.

That was until I saw Jessica Hyde mention the Memlabs challenges on Twitter during the SANS DFIR Summit, and noticed that they had been updated to include some context about why the analysis was needed. With my main complaint from Lab 1 taken care of I jumped back in, starting with Lab 2 – A New World.

As usual, I started by confirming the MD5 and SHA1 hashes of the memory image…

MD5: ddb337936a75153822baed718851716b
SHA1: 3ee71b2507e6b5b15bb2e5f97bf809ef7c85d810

And by determining the correct profile for Volatility using the imageinfo plugin:

vol.py -f MemoryDump_Lab2.raw imageinfo

The output gives us a number of suggestions; Win7SP1x64 will do for now.

The challenge contains three flags, but the order is not important. I am presenting this write-up in the order that I found the flags – Stage 3, Stage 2, then Stage 1.

Stage 3

The challenge description mentions that web browsers and password managers. Checking the running processes with the pstree plugin shows that Chrome and the KeePass password manager were running when the dump was made. Let’s start with Chrome.

vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 pstree

The filescan plugin will produce a list of all of the file objects within the memory dump; it can take some time to run so I redirected the output to a file to speed up grep searches later on.

vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 filescan > filescan.txt
head filescan.txt

Using grep to search for the location of the Chrome History file we can find and extract the database for analysis using the dumpfiles plugin.

grep '\\Chrome\\User Data\\Default\\History' filescan.txt
vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fcfb1d0 -D .

The History file is a SQLite database which we can explore with the sqlite3 command-line tool, or with a GUI application such as DB Browser for SQLite.

Browsing the database we see that the MEGA file-sharing website was visited; let’s check that out.

The directory title – MemLab_Lab2_Stage3 – is promising but the ZIP file is password protected.

Fortunately we already know the flags from Lab 1, and CyberChef can easily calculate the SHA1 hash:

6045dd90029719a039fd2d2ebcca718439dd100a

The password is accepted and Important.png is extracted, giving us our first flag (actually for Stage 3, but nevermind).

flag{oK_So_Now_St4g3_3_is_DoNE!!}

Stage 2

We have investigated the browser history, now let’s take a look at KeePass. We know the KeePass Process ID (3008) from the pstree output earlier. By checking the command-line associated with the KeePass process using the cmdline plugin we can find the location of the KeePass database file, then extract it from the memory dump in the same way as the Chrome History file.

vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 cmdline -p 3008
grep '\\Users\\SmartNet\\Secrets\\Hidden.kdbx' filescan.txt
vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fb112a0 -D .

After installing KeePassX on my SIFT VM, I can open the file but require a password before I can actually view any of the contents.

I got lucky with grep searches over the saved filescan output from earlier and was able to extract a file named Password.png

grep -i 'password' filescan.txt
vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fce1c70 -D .

Opening the extracted PNG file, we see the following:

The lower right-hand corner of the image contains the following text:

Psst!! password is P4SSw0rd_123

After entering the newly acquired password into KeePassX, we can browse the stored credentials and find the flag for Stage 2.

flag{w0w_th1s_1s_Th3_SeC0nD_ST4g3_!!}

Stage 1

While working on Stage 2 I ran the cmdscan plugin along with cmdline. The cmdscan plugin didn’t return anything related to KeePass, but it did show some unusual output from a cmd.exe shell.

vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 cmdscan

The challenge description emphasises that the owner of the system is an environmental activist; pulling out the environment variables for this process (2068) with the envvars plugin gives us the following:

vol.py -f MemoryDump_Lab2.raw --profile=Win7SP1x64 envars -p 2068

The environment variable NEW_TMP contains what appears to be a base64 string:

ZmxhZ3t3M2xjMG0zX1QwXyRUNGczXyFfT2ZfTDRCXzJ9

Going back to CyberChef, we can decode this with ease and return our final flag for Lab 2.

flag{w3lc0m3_T0_$T4g3_!_Of_L4B_2}

DFA/CCSC Spring 2020 CTF – Wireshark – https.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the https PCAP file.

MD5: c634a81223887075a4972e086e6849c4
SHA1: 5df0d28254eae799634d37d81b78f6c148c5f573

01 – Some secret sauce (200 points)

What has been added to web interaction with web01.fruitinc.xyz?

Before we can start answering questions we need to decrypt the encrypted traffic. Wireshark allows us to decrypt TLS traffic by supplying the Pre-Master Secret helpfully provided in the secret-sauce.txt file that was included with the challenge PCAPs.

After decrypting the traffic we can filter for traffic to the web server in question:

http.host == "web01.fruitinc.xyz"

This filter only shows us packets specifically containing the HTTP request headers, but by selecting the Follow HTTP Stream option (Stream #27) we can more easily read the exchange between the client and server, including the flag inserted into the server response headers.

flag<y2*Lg4cHe@Ps>

02 – A sneak peak (300 points)

What is the name of the photo that is viewed in slack?

I’m not familiar with how Slack operates on the network level, but checking for HTTP requests containing “slack” in the host header field seemed a sensible start.

http.host contains "slack"

There are two GET requests referring to JPEG files, entering the first one gives our flag. Out of curiosity I also exported the image using the Export Objects function, which would also have shown the filenames.

flag<get_a_new_phone_today__720.jpg>

03 – Someone needs a change (400 points)

What is the email of someone who needs to change their password?

I actually found the answer to this question by chance while working on Question 4. I while reviewing the HTTP2 traffic I noticed one transfer of urlencoded-form data going to a different server; examining the packet (Frame #4758) I found the user details.

urlencoded-form

flag<Jim.Tomato@fruitinc.xyz>

04 – That’s not good (400 points)

What is the username and password to login to fw01.fruitinc.xyz?

Format flag<username:password>

I prefer to use Wireshark with the DNS resolution option disabled, so my first task for this question was to confirm the IP address of the host. There are a few ways of doing this; I first checked for DNS responses:

dns.resp.name == "fw01.fruitinc.xyz"

After confirming the host IP address I started filtering its traffic. There was no HTTP traffic; instead we are looking at HTTP2 which complicated things slightly. Not being familiar with HTTP2 I ended up examining the exchanges between the client and server manually, accidentally answering Question 3 in the process!

ip.addr == 192.168.2.1 && http2

After some digging I realised that the actual content of the POST request was contained in the DATA packet following the request HEADERS; in this case Frame #937 contained the login details.

flag<admin:Ac5R4D9iyqD5bSh>

05 – What changed? (600 points)

A service is assigned to an interface. What is the interface and what is the service?

Format: flag<interface:service>

There was nothing very elegant about the way I solved this question! Filtering the HTTP2 traffic in the same way as in the previous question:

ip.addr == 192.168.2.1 && http2

I had assumed that I would be able to identify the service being assigned to the interface by examining POST requests, as per Question 4. Instead, after failing to find any neat and tidy POST requests, I resorted to guesswork and manual review of the HTML returned in Frame #1113. The HTML was returned in response to a request for the services_ntpd.php page and contained multiple references to NTP, so I guessed that NTP was the service in question. The HTML body contained references to the WAN and LAN interfaces, and specified that the LAN option was selected:

\t\t<option value="wan">WAN</option><option value="lan" selected>LAN</option>\n

Arrange these into the format requested, and we have our final flag:

flag<LAN:NTP>

DFA/CCSC Spring 2020 CTF – Wireshark – network.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the network PCAP file.

MD5: d6d5d77b88d73ae4299094a6888226a2
SHA1: fc5ba6363a3ed27e17d9c117a92f1a1395b90f98

01 – Please give (50 points)

What is the IP address that is requested by the DHCP client?

After answering the DHCP questions, we know that we can use the following Display Filter to isolate DHCP Request packets:

bootp.option.dhcp == 3

Examining the packet details we find the Requested IP Address field.

flag<192.168.20.11>

02 – Tick Tock (50 points)

What is the NTP server IPv6 address?

Using a simple Display Filter to isolate NTP traffic using IPv6…

ntp && ipv6

…we can see the IPv6 address of the NTP server.

flag<2003:51:6012:110::dcf7:123>

03 – Who has authority (100 points)

What is the authoritative name server for the domain that is being queried?

Only need one

The details of the authoritative name servers can be found in the DNS Response packets. We can filter them out as follows:

dns.flags.response == 1

The Authoritative nameservers field contains the details we are after.

webernetz.net: type NS, class IN, ns ns2.hans.hosteurope.de
webernetz.net: type NS, class IN, ns ns1.hans.hosteurope.de

We only need to submit one:

flag<ns1.hans.hosteurope.de>

04 – How am I talking? (150 points)

What is the port for CDP for CCNP-LAB-S2?

The Cisco Discovery Protocol is used to share information about other directly connected Cisco equipment, such as the operating system version, IP address, and Port ID. The Wireshark wiki has a nice overview of CDP, including a Display Filter reference that we can use to filter out the packets we need based on the Device ID provided in the question.

cdp.deviceid contains CCNP-LAB-S2

Examining the packet we find the Port ID field containing our answer:

flag<GigabitEthernet0/2>

05 – Who changed (150 points)

What is the number of the first VLAN to have a topology change occur?

This time we are looking at Spanning Tree Protocol, which I am not familiar with at all! As usual the Wireshark wiki STP page has enough information for us to identify a Display Filter that will isolate Topology Changes (TC).

stp.flags.tc==1

We are looking for the first VLAN to have a Topology Change, so checking the first filtered packet first makes sense. The Originating VLAN field contains the old VLAN ID which is our flag:

flag<20>

06 – How cool are you (200 points)

What is the IOS version running on CCNP-LAB-S2?

We can answer this using the filter from Question 4:

cdp.deviceid contains CCNP-LAB-S2

The Software Version field contains the full version string:

IOS (tm) C2950 Software (C2950-I6K2L2Q4-M), Version 12.1(22)EA14, RELEASE SOFTWARE (fc1)

However the flag only requires the version number itself:

flag<12.1(22)EA14>

07 – Please talk (200 points)

How many Router solicitations were sent?

You only get 3 attempts.

In ICMP, Router Solicitation messages are Type 10; in ICMPv6 they are Type 133. Filter the PCAP to identify both, and count the number of packets returned.

icmpv6.type == 133

flag<3>

08 – Virtual Sharing (200 points)

What is the virtual IP address used for hsrp group 121?

Hot Standby Router Protocol is another Cisco protocol that I am not familiar with. The Wireshark HSRP Display Filter reference proved useful here, specifying a simple filter by group.

hsrp2.group == 121

Examining the first packet returned by the filter, we find the Virtual IP Address field containing our flag:

flag<192.168.121.1>

09 – Who is root (200 points)

What is the MAC address for the root bridge for VLAN 60?

Format: flag<XX:XX:XX:XX:XX:XX>

Back to Spanning Tree Protocol for this question. Examining the STP display filter reference again, we find that we can filter the traffic by VLAN ID:

stp.pvst.origvlan == 60

The packet contains a Bridge Identifier field, but what we are after is the MAC address under the Root Identifier field. While writing this I noticed that I left the MAC address in lower-case despite the flag format specifying upper-case; it was still accepted.

flag<00:21:1b:ae:31:80>

10 – Who is sharing (200 points)

What are the shared networks being advertised by 192.168.10.1 and 192.168.20.1?

If necessary, format lower to higher networks, separated by a semicolon.

This question is related to the Routing Information Protocol, and took a bit of guesswork due to my limited understanding of the protocol. The question specified that we are looking for networks advertised by 192.168.10.1 and 192.168.20.1 so adding those to the Display Filter seemed a sensible starting point.

rip && ((ip.addr==192.168.10.1) or (ip.addr == 192.168.20.1))

Examining the filtered traffic we find that the following networks are advertised:

0.0.0.0/0
192.168.10.0/24
192.168.20.0/24
192.168.30.0/24
192.168.121.0/24

After some trial and error, I ruled out 192.168.10.0/24 and 192.168.20.0/24 as these are the networks our traffic is originating from, and ended up with the following which was accepted as the flag.

flag<0.0.0.0/0;192.168.30.0/24;192.168.121.0/24>

11 – Working together (200 points)

What is the actor state when the actor is “00:0a:8a:a1:5a:80”?

Relying on Google for help, I found that the “actor state” referred to in the question was likely part of the Link Aggregation Control Protocol, and after consulting the LACP display filter reference, I was able to find traffic relating to our specified MAC address:

lacp.actor.sysid == 00:0A:8A:A1:5A:80

Find the Actor State field in the packet and we have our flag:

flag<0x3d>

12 – How are you controlled (250 points)

What is the management address of CCNP-LAB-S2?

Once again we are back to Cisco Discovery Protocol, specifically device CCNP-LAB-S2.

cdp.deviceid contains CCNP-LAB-S2

The flag is the IP address listed in the Management Addresses field.

flag<192.168.121.20>

13 – Sharing is caring (250 points)

What is the interface being reported on in the first SNMP query?

Simple Network Management Protocol is used to monitor and manage network devices. Queries are made using strings of numbers known as Object IDs (OID) which can be translated into something more easily readable but that wasn’t necessary in this case. We can filter the SNMP traffic and examine the first response packet:

snmp

We can see the result of the query in the first field under the Variable-Bindings section:

1.3.6.1.2.1.31.1.1.1.1.2: 4661302f31

The first part is the OID, and the second is the response. I first tried entering the response as the flag but it was not accepted, leading me to think it was somehow encoded. Time for CyberChef!

A simple From Hex operation and we have something that looks like a network interface identifier. This time, the flag was accepted!

flag<Fa0/1>

14 – Last update (500 points)

When was the NVRAM config last updated?

Format: flag<HH:MM:SS mm/dd/yyyy>

NVRAM is where configuration details for switches, routers, and other network appliances are stored so that they can survive a reboot. I guessed we were looking for a timestamp inside a packet, or for a newly updated device configuration transferred over an unencrypted protocol. As the question does not specify which device received an update, or which protocols might have been used, I opted to use Wireshark’s search function to look for any occurrence of “nvram” in the packet bytes.

The search finds the first hit in Packet #3770 which is part of a Trivial File Transfer Protocol session; TFTP is often used to modify configuration files on network devices, so this makes sense.

Following the UDP Stream (#54) shows us the content of the configuration file, including the last update time:

! NVRAM config last updated at 21:02:36 UTC Fri Mar 3 2017 by weberjoh

Modify the timestamp to fit the specified format and we have our flag.

flag<21:02:36 03/03/2017>

15 – Some Authentication (500 points)

What is the IP of the radius server?

The PCAP file does not contain any RADIUS traffic, but perhaps the configuration file we extracted in Question 14 contains our answer.

There we go!

flag<2001:DB8::1812>

16 – Some more sharing (500 points)

What IPv6 prefixes are being advertised that will be used by clients?

If necessary, format lower to higher networks, separated by a semicolon.

This question is similar to Question 10, but this time we are looking at the RIPng protocol, using the following filter:

ripng

As with Question 10, there are multiple prefixes listed, and I don’t understand the protocol. After some trial and error I found that the following combination was accepted as the correct answer.

flag<2003:51:6012:121::/64;2003:51:6012:122::/64>

DFA/CCSC Spring 2020 CTF – Wireshark – dns.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the dns PCAP file.

MD5: 8663f79d064047f32c9d90791316fce1
SHA1: bda5cafbce553fc6c6fad6b5c300ed65570be2fb

01 – Some good ol fashion txt (50 points)

What is the response for the lookup for flag.fruitinc.xyz?

Wireshark has a comprehensive list of built-in Display Filters for working with DNS traffic. In this case we can use the following filter to isolate packets relating to the DNS response to queries for the specified domain:

dns.resp.name == "flag.fruitinc.xyz"

 

Examining the Answers section of the Packet Details we find a TXT record containing the flag.

flag<ACOOLDNSFLAG>

02 – I have the answers (75 points)

Which root server responds to the query?

Format: flag<hostname>

This question is relatively simple but required some digging through the PCAP to answer. The first DNS response in the PCAP contains a list of the DNS Root Servers.

In the next request, the Root Server is queried for the relevant Top Level Domain DNS server. Following that, a request is made to the TLD Server for the Authoritative Name Server, and then ultimately for the domain itself. We need to determine which Root Server responded during this sequence.

Checking the IP address of the Root Server, we find that our query was answered by 192.203.230.10, which has the hostname e.root-servers.net.

flag<e.root-servers.net>

DFA/CCSC Spring 2020 CTF – Wireshark – dhcp.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the dhcp PCAP file.

MD5: 166d1b3b82e23bbca694391b97d728e0
SHA1: 837ede0bb272c4a10163934e68320549a5c40498

01 – I will assit (50 points)

What IP address is requested by the client?

Wireshark does not have a built-in Display Filter specifically for DHCP traffic, but it does have one for the underlying protocol BOOTP.

bootp

As there are only five DHCP packets in the capture we could simply read through them all to answer the questions, but let’s try to be a bit more specific with Wireshark. Reading the Wireshark wiki DHCP page and the BOOTP Display Filter Reference we find that we can filter on the BOOTP option type to filter only DHCP Requests.

bootp.option.dhcp == 3

This Display Filter returns a single packet containing the DHCP request, including the Requested IP Address field.

flag<192.168.2.244>

02 – Shark01 (50 points)

What is the transaction ID for the DHCP release?

Using the Wireshark wiki and documentation from Question 1, we can filter the DHCP Release with the following Display Filter:

bootp.option.dhcp == 7

Examining the packet details we find the Transaction ID field.

flag<0x9f8fa557>

03 – Who speaks (50 points)

What is the MAC address of the client?

Format: flag<XX:XX:XX:XX:XX:XX>

Moving back to the DHCP Request from Question 1, we can simply examine the packet details and read the Client MAC Address field.

bootp.option.dhcp == 3

flag<00:0C:29:82:F5:94>

DFA/CCSC Spring 2020 CTF – Wireshark – smb.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the smb PCAP file.

MD5: 049cf5868027662393de6e15fd8322de
SHA1: af75d7b34e6476e6fc76c6ac3586f153c697ece7

01 – I am groot (50 points)

What is the tree that is being browsed?

The Wireshark wiki contains a good overview of the SMB2 protocol, including a very helpful list of Opcodes. We can isolate the Tree Connect request packets using the following filter to specify Opcode 0x03:

smb2.cmd == 3

Although there is a Tree Connect request to the IPC$ share in packet 124, the share that ends up being browsed is \public.

flag<\\192.168.2.10\public>

02 – Yellow Brick Road (50 points)

What is the path of the file that is opened?

Consulting the list of SMB2 Opcodes, we find that file Read requests are signified by Opcode 0x08, and apply the following filter:

smb2.cmd == 8

Examining the first packet to contain a Read request (Packet 342), we see that the requested file path is HelloWorld\TradeSecrets.txt

flag<HelloWorld\TradeSecrets.txt>

03 – Uh uh uh (75 points)

What is the hex status code when the user SAMBA\jtomato logs in?

Again, consulting the Wireshark wiki we find that the Session Setup operations are signified by Opcode 0x01; filtered as below:

smb2.cmd == 1

We can see the user SAMBA\jtomato attempt to login in Packet 75. Packet 76 shows the corresponding LOGIN FAILURE, with the hex status code 0xc000006d.

flag<0xc000006d>

04 – According to all known laws of aviation (100 points)

There is a nice simple flag in the file that was accessed.

Wireshark allows us to easily export SMB Objects using a graphical interface.

Wireshark has identified the TradeSecrets.txt file referenced in Question 2, allowing us to extract it from the PCAP; now to find the hidden flag, we can use grep. As we know the flag format we have a good starting point, instructing grep to output progressively more characters until the full flag is revealed.

grep -i -o -P "flag<.{0,20}" %5cHelloWorld%5cTradeSecrets.txt

flag<OneSuperDuperSecret>

 

DFA/CCSC Spring 2020 CTF – Wireshark – shell.pcapng Write-up

In May 2020 the Champlain College Digital Forensics Association, in collaboration with the Champlain Cyber Security Club, released their Spring 2020 DFIR CTF including Windows, MacOS, and Apple iOS images, as well as network traffic analysis, OSINT, and reversing challenges. This series of write-ups covers the network forensics section. As the questions were split over multiple PCAP files (shell, smb, dhcp, network, dns, and https), I have decided to split my write-ups by PCAP for ease of reading.

This write-up covers the questions relating to the shell PCAP file.

MD5: 0a8bad815f3207285628cae0432bb76d
SHA1: 760696c53e3a5fb9c4467096feb32095c604a227

01 – A second listener (50 points)

What is the port for the second shell?

Opening up the PCAP we can see the first packet contains the beginning of a connection to a remote host listening on TCP port 4444, which is the default port for many Metasploit shell payloads. Examining the TCP Stream (Stream #0) we can follow the exchange more easily, showing the commands that were issued.

The TCP stream shows that netcat was installed via the APT package management system, then netcat was used to listen on port 9999:

jtomato@ns01:~$ echo "*umR@Q%4V&RC" | sudo -S nc -nvlp 9999 < /etc/passwd

Based on the netcat command and its associated output we can see that the /etc/passwd file was exfiltrated from the host, but for now, all we need is the port number for the netcat shell.

flag<9999>

02 – Listening (50 points)

What port is the reverse shell listening on?

This was the connection initiated in the first packet in the capture, using the distinctive port 4444.

flag<4444>

03 – Exif (75 points)

What file is added to the second shell?

Again, based on our work answering Question 1, we already have the answer to this: /etc/passwd

flag</etc/passwd>

04 – How recent (75 points)

What version of netcat is installed?

Once more TCP Stream #0 contains the answer to this question.

The output from the APT package manager gives us the version of the netcat package that was installed.

flag<1.10-41.1>

05 – A very secure authication method (100 points)

What password is used to elevate the shell?

Following the TCP Stream we can see that a password was echo’d into the shell and piped to the sudo command, elevating privileges when updating the APT database.

flag<*umR@Q%4V&RC>

06 – What version pt. 2 (100 points)

What is the OS version name of the target system?

Again, the output from the APT update command gives us our answer: Ubuntu 18.04 LTS, codenamed Bionic Beaver.

flag<bionic>

07 – Who is using me (150 points)

How many users are on the target system?

This question required a little bit more work. The /etc/passwd file contains details of the user accounts on the host; before we can count them we need to extract a copy of the file. We know that the file was exfiltrated using a netcat listener on TCP port 9999. Filtering this traffic and following the associated TCP Stream (Stream #6), we can see the /etc/passwd file.

tcp.port == 9999

After saving the raw content of the TCP Stream to a text file we can use the Bash wc utility to count the number of lines, or we could just count them directly in the Wireshark window.

wc -l passwd

flag<31>

 

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.

vol.py -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.

vol.py -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.

vol.py -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.

vol.py -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
vol.py -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.

763130335e48e70e4dcc9512f02f3e25e174dace6ef49afa1ca6103326faf4cd624e4579647548d40f04

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 'warrenhamiltonfinance@gmail.com' | 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
vol.py -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