# BTLO: Meta

# **BTLO Meta Challenge: A Hands-On Image Metadata Investigation**

I recently completed the **Meta** challenge on Blue Team Labs Online, a digital-forensics exercise focused on image metadata analysis using an Ubuntu virtual machine.

The lab involved examining two provided image files and answering four investigation questions:

*   What camera model was used?
    
*   When was the image taken?
    
*   What comment was embedded in the first image?
    
*   Where could the criminal be located?
    

While the lab was short, it reinforced an important DFIR principle: successful investigations are not just about knowing commands. They require a methodical process, the ability to validate evidence, and the flexibility to change direction when the initial approach does not produce an answer.

## **Starting the investigation**

The investigation began by downloading the challenge files and attempting to extract them in Ubuntu. The initial extraction attempt failed because the default `unzip` utility did not support the ZIP format used by the challenge file. The error returned this:

`need PK compat. v5.1 (can do v4.6)`

Instead of assuming the archive was corrupt, I treated the message as a compatibility issue. I switched to 7-Zip, which successfully extracted the challenge files and gave me access to the two images.

This was a useful reminder that troubleshooting is part of digital forensics. Before analyzing evidence, an analyst first needs to ensure the evidence is accessible and handled correctly.

## **Examining image metadata**

Once the images were available, I used ExifTool to inspect the metadata in the first image:

`exiftool uploaded_1.JPG`

EXIF metadata can contain useful information about an image, including the camera used to take it, timestamps, descriptive fields, embedded comments, and, in some cases, GPS coordinates. Using ExifTool, I was able to identify the camera model and review the timestamp information associated with the photo.

One key field was `Date/Time Original`. This field is particularly valuable because it generally represents when the camera captured the photograph, rather than when the file was later modified, copied, or processed.

I also reviewed metadata fields such as:

`Comment   User Comment   Image Description`

These fields can contain notes or hidden context that is not immediately visible when simply opening an image. In this case, reviewing them helped locate the embedded comment required by the challenge.

## **Investigating the location clue**

The final question required identifying where the criminal could be located. My first instinct was to look for GPS metadata in the second image:

`exiftool uploaded_2.png | grep -i gps`

The command returned no useful GPS information. At that point, it would have been easy to conclude that there was no location evidence in the file. Instead, I expanded the investigation by reviewing the full metadata output:

`exiftool uploaded_2.png`

When the metadata did not provide a direct answer, I opened the image itself:

`xdg-open uploaded_2.png`

That was the turning point in the investigation. The second image contained a visual clue that helped answer the location question. The evidence was not stored in EXIF metadata—it was visible in the image content.

This reinforced the importance of examining both **metadata and the actual artifact**. In real investigations, relying only on one source of evidence can lead to missed context or incorrect conclusions.

## **Challenges and lessons learned**

This lab included several small obstacles that made the exercise more realistic.

*   The challenge ZIP file could not be extracted with Ubuntu’s default `unzip` utility, requiring a switch to 7-Zip.
    
*   Multiple timestamps were present in the image metadata, requiring careful consideration of which field represented the actual capture time.
    
*   A GPS metadata search did not return useful results, so the investigation had to shift from metadata analysis to visual image analysis.
    
*   A few false leads reinforced the importance of verifying what the evidence actually supports before reaching a conclusion.
    

The biggest lesson was that a dead end is not necessarily the end of an investigation. It may simply mean that the evidence needs to be approached from a different angle.

## **Key takeaway**

This challenge followed a simple but realistic forensic workflow:

`Extract → Examine → Identify relevant metadata → Interpret evidence → Hit a dead end → Adjust the investigation → Continue`

The lab provided practical experience with Ubuntu/Linux, command-line troubleshooting, ExifTool, EXIF metadata, timestamps, file extraction, command filtering, image analysis, and investigative thinking.

For me, the value of this exercise was not only finding the answers. It was learning how to adapt when the obvious approach did not work. That mindset is critical for DFIR and SOC work, where the evidence may be incomplete, misleading, or located somewhere unexpected.

I am continuing to build my hands-on experience through Blue Team Labs Online and other defensive-security labs, with a focus on digital forensics, incident response, log analysis, and SOC analyst workflows.