Magnet Weekly CTF – Week 2 – PIP Install

Magnet Forensics have announced a weekly CTF running from October 2020. A new challenge will be released each week on Monday, and the first few are based on an Android filesystem dump. You can find my other Magnet Weekly CTF write-ups here.

MD5: 3bb6abb3bf6d09e3e65d20efc7ec23b1
SHA1: 10cc6d43edae77e7a85b77b46a294fc8a05e731d

Week 1 was pretty straightforward. On to Week 2!

PIP Install (30 points)

What domain was most recently viewed via an app that has picture-in-picture capability?

In the last challenge I didn’t need to do any analysis or parsing of the data, simply read the timestamp of a particular file using FTK Imager. This time I needed to dig a little deeper and used Alexis Brignoni’s ALEAPP to parse the Android filesystem dump.

I have previously used iLEAPP to perform analysis of Apple iOS dumps; ALEAPP – the Android Logs Events And Protobuf Parser – works in much the same way, but for Android data. ALEAPP can process the dump directly from the TAR file. I simply started the GUI, set the input and output, and clicked Process.

A few seconds later I was presented with a nice HTML report of the analysis.

Given that the question asks about a domain being accessed, I guessed that the Chrome history would be a good place to start. I also found an article containing a list of Android applications which support the picture-in-picture featureChrome is listed. Another good sign.

Navigating to the Chrome History report and sorting by the most recent entry, we find the answer to the Week 2 question.

Flag

malliesae.com

Memlabs Memory Forensics Challenges – Lab 4 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 4 – Obsession. You can find the rest of my Memlabs write-ups here.

As usual I started by calculating hashes for the image…

MD5: d2bc2f671bcc9281de5f73993de04df3
SHA1: bf96e3f55a9d645cb50a0ccf3eed6c02ed37c4df

…and running the Volatility imageinfo plugin to determine which profile to use for the rest of the analysis.

vol.py -f MemoryDump_Lab4.raw imageinfo

Having chosen Win7SP1x64 from the suggested profiles, I next checked the running processes with the pstree plugin.

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

I briefly investigated the StikyNot.exe process but found nothing of interest. Let’s try the filescan plugin instead. I directed the output to a file, and used grep to filter the files in user profile directories, guessing that anything “very important” to the user would be stored there.

vol.py -f MemoryDump_Lab4.raw --profile=Win7SP1x64 filescan > filescan.txt
grep '\\Users\\' filescan.txt

Indeed, examining the filtered list we see a reference to Important.txt in a Desktop directory. My first approach was simply to run the dumpfiles plugin to recover the file from the memory image…

vol.py -f MemoryDump_Lab4.raw --profile=Win7SP1x64 dumpfiles -Q 0x000000003fc398d0 -D . -n

… but in this case no output was created.

We can’t extract the file directly but there is another place the data might be stored. On an NTFS partition, small files (up to a few hundred bytes) may be stored as resident in the $DATA attribute in the Master File Table (MFT). We can use the mftparser plugin to, well, parse the MFT, and use grep again to filter the relevant entry. The -C 20 argument in my grep command instructs grep to return the 20 lines above and below the matching line.

Looking at the $DATA attribute, we can see something that looks like the flag but broken up with whitespace characters; with CyberChef we can easily convert the raw bytes to text then remove these…

… leaving us with our flag to complete the challenge.

inctf{1_is_n0t_EQu4l_7o_2_bUt_th1s_d0s3nt_m4ke_s3ns3}

Magnet Weekly CTF – Week 1 – Mapping the Digits

Magnet Forensics have announced a weekly CTF running from October 2020. A new challenge will be released each week on Monday, and the first few are based on an Android filesystem dump.

MD5: 3bb6abb3bf6d09e3e65d20efc7ec23b1
SHA1: 10cc6d43edae77e7a85b77b46a294fc8a05e731d

Let’s go!

Mapping the Digits (20 points)

What time was the file that maps names to IP’s recently accessed?

(Please answer in this format in UTC: mm/dd/yyyy HH:MM:SS)

A pretty simple one to start with. On Linux-based systems (like Android) hostnames are mapped to IP addresses in the /etc/hosts file; find that file in the TAR archive and check the timestamp.

I opened the TAR archive up using FTK Imager, and navigated to the directory containing the hosts file:

/data/adb/modules/hosts/system/etc

There is only one timestamp, but it is worth noting that I have FTK Imager set to display dates in the common European format (day/month/year):

05/03/2020 05:50:18

So swap the day and month values to match the US format required by the question, and we have our first answer.

Flag

03/05/2020 05:50:18

As an aside, confusion around date and timestamps is exactly why we have ISO 8601.

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>