Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.jaspervanzeir.be/llms.txt

Use this file to discover all available pages before exploring further.

For this challenge, we were provided with a file named usb_image.E01. The brief mentioned that a USB drop attack had taken place, meaning someone had presumably left a USB stick behind in the hope that an unsuspecting victim would plug it in and open it. My objectives were:
  • Discover what was actually on the USB.
  • Identify the possible owner of the USB.

​
Enumeration & Initial Triage

I started by checking what kind of file I was dealing with: 
file usb_image.E01
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fnx Wo7lox Wfo78t Rp WFR4%2F1
A .E01 is a forensic copy of a USB stick or hard drive. So this wasn’t the USB itself, but a packaged image of it. I created a directory to mount the E01 into: 
mkdir ~/ewf_mount
Then I mounted the E01: 
ewfmount usb_image.E01 ~/ewf_mount
And inspected the contents: 
ls -lh ~/ewf_mount
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fk43g Kewb A0qm2ij Ss FJV%2F2
I could see the real content of the USB now exposed as ewf1. To list the files on the USB itself, I used fls: 
fls -r ~/ewf_mount/ewf1
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fsp9vo Ot3ed7p1ytvdc Rb%2f3
Several interesting files immediately stood out: 
HUGE_LEAK.ps1
HUGE_LEAK.lnk.lnk
sleeping_sound.url
maynotbeuseless.odt
mydoc

​
Extracting the Files

To pull these files out of the image, I used icat. The trick with fls output is that each entry has a number on the left (e.g., HUGE_LEAK.lnk.lnk showed as 41-128-7, where 41 is the inode number to feed icat). I went back to my challenge4 directory, created a new extracted folder, and dumped the files into it: 
icat ~/challenge4/ewf_mount/ewf1 41 > HUGE_LEAK.lnk.lnk
icat ~/challenge4/ewf_mount/ewf1 38 > HUGE_LEAK.ps1
icat ~/challenge4/ewf_mount/ewf1 40 > maynotbeuseless.odt
icat ~/challenge4/ewf_mount/ewf1 39 > sleeping_sound.url
icat ~/challenge4/ewf_mount/ewf1 42 > mydoc
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2f Uj5bz7ihk O7uhhjcst Pm%2f4
A quick ls -lh confirmed the files were not empty, so I had plenty of material to investigate.

​
Inspecting Each File

​
HUGE_LEAK.ps1

First up was the PowerShell script: 
strings HUGE_LEAK.ps1
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fpm5bzzhj E Tv Oo4m Y4as Z%2F5
Nothing suspicious here. Just a YouTube link to a video explaining why Finland doesn’t exist. Interesting (as a joke), but not what I was looking for.

​
sleeping_sound.url

Next, the .url shortcut: 
strings sleeping_sound.url
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fcb Wua M43W Os600a Jc L Et%2f6
Another YouTube link, this time pointing to the National Anthem of the USSR. More interesting given the goal was to gather information about the USB owner, but still not enough to identify anyone. I kept digging.

​
maynotbeuseless.odt

An .odt file is basically an OpenOffice / LibreOffice document, which is really just a ZIP archive containing text and images. I extracted it: 
mkdir odt_extract
unzip maynotbeuseless.odt -d odt_extract
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fxq WQFS Udjx9w Ew5zx4rj%2f7
Immediately, content.xml, meta.xml, and Pictures jumped out as the places worth poking around in. Unfortunately, content.xml was a dead end. It just contained the sentence THIS INDEED SOUNDS USELESS.
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fer Eg3pz Warl LF5VYG Zy Z%2F8
Next, I moved on to meta.xml:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2f Wrt JK Nx54un Es NVJXWYT%2F9
This one was more useful: I could see the creator was a user named SMO, along with the creation date and last-modified date. Then I checked the Pictures folder and opened the image inside it: 
xdg-open 100002010000029F000002A1F1E7A836.png
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fa0z Qc Lseati Ysj6gq Y Bf%2f10
An image popped up:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2f Zq4uu L91Q Kiy Ld Bbj Nb D%2F11
This was very interesting, possibly exactly what I was looking for. But there were still files left to inspect, so I kept going. This was already a big find. Finally, I checked Thumbnails. This is normally just the icon assigned to the .odt document, but I wanted to be thorough. You never know.
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fy PL Em Ij Nyavgdndq HR Ih%2f12
As expected, just the document with the photo and the title from content.xml.

​
mydoc

The last file was mydoc, with no extension at all. I asked Kali what it thought: 
file mydoc
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fsb Xd Cyr I4uzpz D2BF Pks%2f13
To dig deeper, I also checked the bytes: 
xxd -l 32 mydoc
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2f6v CUITN Nn In8v Ork Jk JW%2F14
Something stood out. The file started with: 
50 4e 47 0d 0a 1a 0a
This looked like a PNG image. But a normal PNG begins with: 
89 50 4e 47 0d 0a 1a 0a
The first byte, 89, was missing. Files have fixed starting bytes called magic bytes. A PNG must start with 89 PNG. Because the first byte was gone, Kali didn’t recognize it correctly as an image. I added the missing byte back: 
printf '\x89' | cat - mydoc > mydoc_fixed.png
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fm Xg Vfx3i52m1lg U3oxnh%2f15
Gotcha. When I ran xdg-open mydoc_fixed.png, I got:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fq Wyk Ffo XU Dhl5f0itf Gh%2f16
A passport request form. The user’s details were unfortunately too blurry to read, but I already had the face photo from the earlier ODT find. I was close, but the image wasn’t legible.

​
Hunting for Hidden Files with Binwalk

Since the visible PNG wasn’t readable, I went looking for hidden files inside mydoc using binwalk: 
binwalk mydoc
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fb E6w9c Um Gfh1ejkwz T Nq%2f17
Sure enough, there were interesting embedded files, including a content.xml and another .png worth examining. There was effectively another ODT/ZIP structure hidden inside mydoc. I made sure to run binwalk on the original mydoc, not on mydoc_fixed.png. When I added the 0x89 byte to fix the PNG, I may have shifted or corrupted the embedded hidden files. The unmodified mydoc was the only reliable source for carving. To actually extract the embedded data: 
binwalk -e mydoc
This created a new directory:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2f Wbc9c Naus D Mg ZV Ifg T Zf%2f18
Inside, I could see a ZIP archive had been pulled out of mydoc:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fyz2e2p I An Ysdz8cp W6gm%2f19
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fa8o Xdwe M Rx Ka3o Hi Jzqx%2f20
The ZIP was missing bytes and was corrupt. But earlier in the binwalk output, I had already seen:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fqhnc A3w H Rbe1i9mr5c Le%2f21
0x3EBF Zip archive data, name: Pictures/1000020100000418000003A0509F1AF7.png
So I knew there was a PNG inside the ZIP, and I wanted to view it. To find the exact offset where the PNG started: 
grep -abo $'\x89PNG' 3A3E.zip
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2ftc Il O2ku Ah1a9lo RNAP7%2F22
The output was: 
1228:�PNG
That meant the PNG started at position 1228. From there, I could carve the image out: 
tail -c +1229 3A3E.zip > passport.png
Why 1229 and not 1228? Because grep counts from 0, but tail -c counts from 1. So:
  • grep says 1228
  • tail needs 1228 + 1 = 1229
The command essentially says: “take everything from where the PNG begins and save it as passport.png”.
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fzyf8c Lt8s KSZ Cd Dkk V34%2F23
Opening the result with xdg-open passport.png:
Https Files Gitbook Com V0 B Gitbook X Prod Appspot Com O Spaces%2fwf Uhrqei Mz Jnppiwss2r%2fuploads%2fj AGB Yk7f Xj2n788p Ml WR%2F24
Now I could clearly read the passport request form, with all the owner details. Identified Owner: Anastasia Petrova 
Surname: Petrova
Given Names: Anastasia
Nationality: Prussian
Date of Birth: 07 February 1989
Place of Birth: Königsveil Province
Sex: F
Height: 172 cm
Eye Color: Azure

​
Tools Used

  • file: To determine the initial file type of usb_image.E01 and mydoc.
  • ewfmount (ewf-tools): To mount the E01 forensic image as a readable volume.
  • The Sleuth Kit (fls, icat): To list the files inside the USB image and extract them by inode number.
  • strings: To pull readable text out of the PowerShell script and URL shortcut.
  • unzip: To unpack the .odt document as a ZIP archive.
  • xxd: To inspect the raw bytes of mydoc and identify the missing PNG magic byte.
  • binwalk: To detect and extract files hidden inside mydoc.
  • grep & tail: To locate the exact offset of the embedded PNG and carve it out of the corrupt ZIP.

​
Summary

  • Key Steps: I mounted an E01 forensic image, listed and extracted the files on the USB with fls and icat, and inspected each one. The .odt document gave me a photo and a creator (SMO), while a file named mydoc turned out to be a PNG missing its first magic byte. After patching it I got a blurry passport form, so I ran binwalk on the original mydoc to find a hidden ZIP, then carved the embedded PNG out by hand to reveal the passport details of Anastasia Petrova.
  • What I Learned: This challenge was a great walkthrough of a forensic USB-image workflow, using ewfmount and the Sleuth Kit to work with E01 images, recognizing PNG magic bytes, and carving files out of a corrupt ZIP container using grep and tail instead of relying on unzip. Hidden data layers can survive even when the outer container is brokenCrucial Mistakes/Takeaways: The biggest pitfall I had to avoid was running binwalk on mydoc_fixed.png instead of the original mydoc. Patching the missing 0x89 byte was necessary to view the first image, but it shifts every byte that follows, which would have corrupted or hidden the embedded ZIP. Always carve from the untouched original whenever you’ve already modified bytes earlier in the chain.