Magnet Weekly CTF: Question 7 Solution Walk-Through

Unlike the Fighting Irish, I don’t have a perfect record this year – but I’m still loving the game. I never did get to finish the week 6 challenge, but with week 7, I’m back in it.

Challenge 7 (Nov 16-23) Part 1, Domains and Such. What is the IP address of the HDFS primary node?

As I was gathering information about Linux forensics, I came across LinuxForensicsForNon-LinuxFolks from Hal Pomeranz. (Google it). It’s chock full of pointers on where to find particular artifacts as the correspond to their Windows counterparts, and as the title indicates it’s meant for novices to Linux.

To identify the IP address of a Linux host there are a few places to check. If the address is assigned statically it will be in /etc/hosts. If the address is assigned by DHCP there should be a reference in /var/lib/dhclient and/or /var/log/*.

Bringing up our evidence in the File System view in Magnet Axiom, we navigate to /etc/hosts.

We can see that the primary node has the IP assignment of 192.168.2.100. [Flag 1]

After not being able to finish the challenge the week before, I was so excited to get the flag I nearly (or did) miss the fact that this was a 3-part question. It was only later in the afternoon watching the video introducing the challenge that I realized it had multipe sections.

Part 2: Is the IP address on HDFS-Primary dynamically or statically assigned?

Based on the fact that the address was in the hosts file, that indicates that the address was assigned statically. [Flag 2]

Part 3: What is the interface name for the primary HDFS node?

For this answer we navigate to /etc/network/interfaces.

Previewing the content of the file we see that ens33 [Flag 3] is the name of the interface. Had we identified this file first we would have been able to surmise all 3 flags from the same source. As with all things forensics, there are many ways to get to the same information. Understanding how those compare and what the outliers are, is all part of the challenge.

That’s all for this week. Now I’m off to watch the next video so I can see what I missed in last weeks challenge.

Magnet Weekly CTF: Question 5 Solution Walk-Through

So for week 5 we started Ali Hadi’s Linux image, (farewell for now Android.) I’ve worked WITH Linux for years as my underlying operating system for forensics, but as the forensics target, not so much.

As the Magnet Training team is fond to say, “You don’t know what you don’t know.” That was certainly the feeling for me when I opened up the week 5 challenge.

Challenge 5 (Nov. 2-9) Had-A-Loop Around the Block: What is the original filename for block 1073741825?

I knew this had something to do with data architecture but not much else. I scoured the filesystem and find some references to block_1073741825, but nothing related to file associations.

Midway through the week, a hint was dropped. It cost 20 points but I knew that without a pointer in the right direction this was going to elude me.

The hint wound up being a link to a presentation from the DFIR Summit in 2016.

I watched this several (countless?) times. I think by the end after infinite repetitions my wife and cats were starting to grasp Hadoop. I’ll be looking out for other talks by Kevvie in the future.

There were 2 main takeaways for me that wound up getting me to the correct solution before the final bell tolled.

  1. hdfs-site.xml – this file will tell you where within the system the data resides.

So I parsed the .E01’s in Axiom (as Windows images) and found the hdfs-site.xml in the File system view.

I exported the file out and opened with VS Code. Lately I’ve been finding this just as useful if not more as Notepadd++ when dealing with text or xml files.

We’re looking for the namenode path, seen here as /usr/local/hadoop/hadoop2_data/hdfs/namenode…

This brings me to take-away #2 from the video.

The transaction logs, which capture the to and fro of files on the system, can be exported from it’s native format to a human-readable xml – when done with a utility on the Hadoop server.

Using the identified path information I exported the transaction logs via Axiom.

The video calls out the usage of OEV (Offline Edits Viewer).

OEV documentation

My next step was to get a Hadoop VM so that I could utilize the OEV tool.

After a pretty basic setup I transferred the exported edit logs via SCP to the VM. Once I had the transaction log files on the VM I used the OEV utility to convert to xml.

hdfs oev -I [edit_log_name] -o [export_name].xml -p XML

I then SCP’d the xml files back to my analysis machine and ran a search for the block number in VS Code on the file directory.

The block ID we’re looking for is shown as part of a file copy operation. If we drop back about 10 lines to <PATH> we see that the filename of the file was AptSource.

Another week down.

Another challenge completed.

Another (multiple) things learned that I didn’t know when I started.

Magnet CTF: Question 4 Solution Walk-Through

Challenge 4 (10/26-11/2) Animals That Never Forget

Chester likes to be organized with his busy schedule. Global Unique Identifiers change often, just like his schedule but sometimes Chester enjoys phishing. What was the original GUID for his phishing expedition?

Week 4 was definitely a brain-teaser for me. On my first attempt I was focused on the final part of the question. What was the original GUID for his phishing expedition?

The equivalent of a GUID for an email would be the message ID. In the case data we have, we can see a portion of the original phishing email delivery, but the message headers were not visible. As the data sample was also used at the Magnet User Summit, I checked the Google TakeOut data for the same account and voila – the message ID (email GUID) for the phishing email was: CACWSF2E=ghTTG2hx10GUh+WOf-GkORngZc+c7-BuY4R+cKUhGA@mail.gmail.com

WRONG

So I go back to the question and this time don’t ignore 75% of the verbiage. It’s there for a reason, right?

So we know that our subject, Chester, is meticulous. My first inspection was of the calendar data – but nothing presented as intersting. Looking at the Documents artifacts, we can see that the subject uses Evernote – and among the notes on his device is one called Phishy Phish Phish (at least is wasn’t titled “Evidence”).

If we follow the source link to \user213…-Evernote.db we see that Evernote is storing this content in a SQLite database.

If we examine the notes table we can see that each notebook entry has its own guid. Our Phishy Phish Phish message has the guid of c80ab339-7bec-4b33-8537-4f5a5bd3dd25.

Is that the answer? NO.

What was the original GUID for his phishing expedition?

So this is a GUID, but is it the original?

Looking at a number of developer articles for Evernote I learned that a note can be moved or copied to another notebook.

https://dev.evernote.com/doc/reference/NoteStore.html#Fn_NoteStore_listNotebooks

When that operation takes place it keeps track of this activity in the guid_updates table.

If we reference this table we can find our message, identified by the current guid (identified above) and see that there’s a column for old_guid which for the note in question is: 7605cc68-8ef3-4274-b6c2-4a9d26acabf1. 

Magnet CTF: Question 3 Solution Walk-Through

Challenge 3…Which exit did the device user pass by that could have been taken for Cargo?

In NJ it’s common to inquire where someone resides with the question “What exit?” I found it interesting that some of the test data examined as part of the CTF included artifacts that originated in New Jersey. Yup. I hail from the land of Bruce Springsteen and Bon Jovi and if you even mention Jersey Shore in the context of a reality show, please just… quietly go away.

Many types of forensic artifacts include metadata that ties that evidence to a particular location using GPS data. Maps and driving applications are among these, and commonly you can retrieve this data from photos and videos. (Note: a lot of services Facebook, Instagram, etc. – will have settings on whether or not they remove this data when media is shared.)

Selecting this view limits the presentation of artifacts to just those that include GPS data.

Reviewing the artifacts with GPS metadata there was nothing that immediately presented as a reference to exit or cargo

However, just like Transformers, within these artifacts there is more than meets the eye. In the screenshot above you’ll see that several files start with MVIMG_ . These files are Google Motion Photos, essentially the functional equivalent of Live Photos on iOS.

A few weeks back I saw a Magnet webinar: Mobile Artifact Comparison – Understanding the Similarities Between iOS and Android Data

Included in the comparison were both of these “live photo” types and B1n2h3x reference that previously she had carved out the MVIMG_ files and was able to isolate the key frame and the MP4 image (video) that comprised it.

If you’re not supplementing your Magnet course training with their free webinars you’re really missing out.

  • Using Axiom, I exported all the MVIMG_ files to a folder.
  • Next I utilized GoMoPho – Google motion photos video extractor https://github.com/cliveontoast/GoMoPho and ran it against the directory which split the MVIMG_ files into .jpg and .mp4
  • From there I loaded the videos into VLC.  They were only a few seconds long and played very fast. This is where the playback speed settings in VLC come in handy. Drop it back to the slowest it will play.

When initially previewed, MVIMG_20200307_120326.jpg presented what appeared as a view from the highway in winter. There are no immediate discernable landmarks in the photo.

However, when the extracted video is played, we get a few seconds visibility from the car on the highway, including passing the following sign:

Among the words on the sign we can read “Cargo” and the exit show at the bottom of the sign, F16.

PDF: magnetweeklyctf-write-up-3-1.pdf

Magnet CTF: Question 2 Solution Walk-Through

Challenge 2 (OCT 12-18) PIP Install: What domain was most recently viewed via an app that has picture-in-picture capability?

For the week 2 challenge, we’re using the same Android image we examined last week. From the question there’s two factors involved, application capability and application usage.

The first thing to understand is what applications on the device have PIP (Picture in Picture) capability.

Picture2

 

 

 

 

 

 

 

 

 

 

I reviewed the installed applications on the device looking for anything that could be PIP related. A screen recording application caught my attention (googled to understand capability), but this was not the ‘Droid (app) we’re looking for.

One of the Discord users shared this helpful link describing the capability and what applications featured PIP support.

How to enable & use Android Picture in Picture (PIP) Mode. List of apps supporting PIP mode

Back to the applications I tagged anything listed that showed up in the PIP article.

From here I proceeded to look at the Application Activity – Android.  One of the applications we can see recent activity for is Google Chrome. From the previously referenced article we know this app supports PIP.

Picture3

 

 

 

 

 

 

 

 

 

 

In the preview card we can see that it was captured that Chrome was used to visit a URL beginning with MallieSae.com. 

The artifact for this can be found at MUS_Android.tar\data\system_ce\0\snapshots\320.jpg

Answer: Google Chrome, an app that supports PIP, was recently used visit the domain malliesae.com

 

PDF: MagnetWeeklyCTF Write-Up 2.pdf

Magnet CTF: Question 1 Solution Walk-Through

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

Mobile Forensics is not my strongest area, and Android even less than iOS.  Based on my limited experience the first thing I started with was Google (“GTS”). Based on the question I supposed that the artifact would be DNS related.  Where on the device would that be set locally? To my delight I learned that on Android there is a local hosts file that is responsible for mapping IP’s to DNS (what do you know just like Windows and Linux).

Doing a Global Search for hosts there are a number of hits, but nothing for the hosts file itself.

UntitledImage

The first time I processed the Android image tar file I did it as

Mobile > Android > Load Evidence > Image

Using this format when I went to the file explorer view in Magnet, all that was visible was the tar file and I couldn’t navigate the directory structure.

I extracted the tar file (using 7zip) and then re-processed the evidence as

Mobile > Android > Load Evidence > Files and Folders

This yielded the same number of artifacts; however, it exposed the directory structure for browsing in File System view.

UntitledImage

In the File System view we can now run a search for hosts (be sure to enable subdirectory results if you’re not focusing on a particular path.

UntitledImage

In this case the hosts file can be found at /data/adb/modules/hosts/system/etc

UntitledImage

Looking at the preview we can see an additional entry for malliesae.com

UntitledImage

With the hosts file selected, scrolling to the right reveals the Created, Accessed and Modified times for this file.  Here we see that the file was modified 03/05/2020 05:50:18.

PDF: MagnetWeeklyCTF Write-Up 1.pdf