← Back to Writeups
CUSTOMMediumForensics

The flag is visible outside the windows

XESXOR9/2/20264 min read
#forensics#custom#medium#alternate_data_stream_recovery#archive_metadata_triage#credential_pivoting#image_cropping_and_ocr#ntfs_artifact_enumeration#ova_disk_extraction#password_reuse_analysis#windows

The flag is visible outside the windows

Platform: hackerlab | Category: Forensics | Type: Challenge | Difficulty: Medium | OS: Windows | Author: XESXOR | Date: 2026-04-05 | Status: Solved Techniques: alternate_data_stream_recovery, archive_metadata_triage, credential_pivoting, image_cropping_and_ocr, ntfs_artifact_enumeration, ova_disk_extraction, password_reuse_analysis

Summary

Task: a large ZIP archive hides a Windows 10 VirtualBox disk image containing many password-protected ZIP artifacts, often stored in NTFS Alternate Data Streams. Solution: enumerate the OVA/VMDK filesystem, pivot from recovered browser credentials to the long archive password, decrypt the ADS-backed archive from Windows/security/database, and crop the resulting image to read the flag.

The flag is visible outside the windows — Hackerlab

Description

The original organizer description was not preserved in the task directory.

English summary: the challenge provides a very large archive that turns out to be a Windows virtual machine image. The goal is to examine the disk offline, recover hidden artifacts, find the correct password chain, and extract the final flag image.

Short Challenge Summary

This was a forensic triage task centered on a Windows 10 VirtualBox image packed inside a ZIP. The intended path was not to boot the VM immediately, but to inspect the archive structure, extract the disk, enumerate NTFS artifacts, notice multiple password-protected ZIP files stored in Alternate Data Streams (ADS), and pivot from a recovered browser password dump to the final archive password. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Analysis

1. Initial reconnaissance

The first useful decision was to inspect the large challenge ZIP without fully extracting it first. That immediately showed the archive was just a container for one VM export:

  • za_oknami.ova

After unpacking the OVA, it contained:

  • za_oknami.ovf
  • za_oknami-disk001.vmdk
  • za_oknami.mf

The OVF metadata revealed the guest type right away:

  • VirtualBox appliance
  • Windows 10 x64 guest (Windows10_64)

Useful quick checks:

bash
# Inspect the outer archive before full extraction
7z l The_flag_is_visible_outside_the_windows.zip
‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

# Extract the OVA contents
7z x za_oknami.ova

# Read VM metadata
grep -n "Windows10_64\|Machine" za_oknami.ovf

2. Disk extraction and partition triage

The next step was to work with the virtual disk offline. The VMDK was extracted and converted/analyzed as a raw image, then partition layout was identified with SleuthKit.

Example workflow:

bash
qemu-img convert -O raw za_oknami-disk001.vmdk za_oknami.raw
mmls za_oknami.raw

From there, NTFS partitions were enumerated with SleuthKit tools such as fls, icat, and/or bulk recovery tooling. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

3. Filesystem artifact triage

Enumerating the Windows filesystem showed a recurring pattern: many suspicious ZIP files existed either directly as files or embedded in NTFS Alternate Data Streams. That was the key clue that the challenge was about hidden storage plus password reuse.

Important artifacts included:

  • not_qwe.zip:not_qwe
  • Users/Vanya/Pictures/flag.zip:haha_secret
  • Users/Vanya/3D Objects/flag2.zip:super_secret
  • Users/Vanya/AppData/Roaming/Yandex/bebebe.zip:bebe
  • Windows/security/database/brrr.zip:brrrrr ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Along with several other similar decoys.

Representative enumeration commands:

bash
# List filesystem entries from the NTFS partition
fls -r -p -o <offset> za_oknami.raw

# Recover interesting files by inode
icat -o <offset> za_oknami.raw <inode> > extracted.bin

4. Password triage and false leads

Several simple passwords worked on some of the recovered archives, which helped confirm that the hidden ZIPs were not random noise:

  • password worked for Vanya_brute_me.zip, kvakva_ads.bin, and yandex_browser_passwords_2023-08-03.zip
  • 12345 worked for some other archives
  • 123456 worked for Vanya_bebebe_ads.bin ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

Those recoveries produced extra images and decoy-style content, which were still useful because they established two things:

  1. the archives were intentionally meant to be cracked in layers;
  2. password reuse was likely part of the intended solution.

So these were not wasted efforts, but they were not the final flag path.

Solution

Step 1 — Recover the Yandex password export

One of the useful archives was the browser credential export:

  • yandex_browser_passwords_2023-08-03.zip
  • password: password ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

After extraction, it contained passwords.csv with an extremely long saved password for https://codeby.net/ and user vanya_super_hacker:

text
sdiowgjiowjfg98234ujg987234ujg987we9ojhfg98723jhfg98i2jh3q1g87iuh2387igh2387hg_FOR_THE_ARCHIVE

This was the critical pivot. The suffix _FOR_THE_ARCHIVE is a strong hint that this credential is not just background data, but the password for another protected artifact.

Step 2 — Use the long password on the brrr ADS archive

The most promising hidden archive was: ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

  • Windows/security/database/brrr.zip:brrrrr

Once that ADS content was extracted to a regular file (for example as brrr_ads.bin), the long password from passwords.csv successfully decrypted it.

Example:

bash
unzip -P 'sdiowgjiowjfg98234ujg987234ujg987we9ojhfg98723jhfg98i2jh3q1g87iuh2387igh2387hg_FOR_THE_ARCHIVE' brrr_ads.bin

That produced:

  • 11.jpg

Step 3 — Inspect the image carefully

11.jpg did contain the flag, but it was not immediately readable at normal scale. The text was small enough that simple viewing could miss it. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍

The final step was to:

  • crop the region with text,
  • enlarge it,
  • optionally run OCR to confirm ambiguous characters. ‍​‌‌​​​​‌​‌‌​​‌‌​​‌‌​​‌‌​​‌‌​​‌​​​​‌‌​​​​​‌‌​​‌‌​​‌‌​​‌​‌​‌‌​​‌​‌‍