CTF OSINT Write-up — Sakura Room (Expanded & In-depth)

I recently jumped into the Sakura Room, a CTF built by the OSINT Dojo. The puzzle asked me to use a variety of open-source intelligence techniques to identify an attacker, their crypto activity, and travel/home details. This document is a thorough, step-by-step write-up of the investigation — what I did, why it worked, how I verified it, and lessons learned.

Table of contents

1. Overview & goal
2. Tools, environment & important notes
3. High-level methodology (pivoting & evidence chaining)
4. Detailed walkthrough (Flags 1–5)

• Flag 1: Username (metadata analysis)
• Flag 2: Email & real name (PGP and social pivots)
• Flag 3: Cryptocurrency (repo → blockchain analysis)
• Flag 4: Dark-web paste → Wi-Fi OSINT (geolocation)
• Flag 5: Travel & home (reverse-image, flight clues)

1. Evidence, validation & reproducibility checklist
2. Ethics, legality & responsible disclosure
3. Post-investigation notes, mitigation, and lessons learned
4. Appendix: command cheat-sheet, helpful links, and checklists

1) Overview & goals

Room name: Sakura Room (OSINT Dojo)

Primary objective: Collect a set of discreet flags by chaining OSINT pivots across an image, a GitHub account, PGP artifacts, blockchain records, social media, and Wi‑Fi geolocation.

What I delivered: a complete narrative that ties together the username, email, real name, cryptocurrency holdings and activity, home city, airport/layover info, and the lake visible in a flight photo.

2) Tools, environment & important notes

Core tools used (local & web):

• exiftool (metadata extraction)
• gpg (PGP key inspection)
• curl / wget (raw file retrieval)
• git / GitHub web UI (repo browsing & commit history)
• web browser (Etherscan, WiGLE, TinEye, Google Images, Yandex)
• binwalk, strings, steghide (when looking for hidden content)
• text utilities: grep, sed, jq

Environment: I performed all actions from my local testing machine in a legal CTF environment. Do not attempt to apply these techniques to real people or live systems without explicit authorization.

Important: This write-up focuses on OSINT methods — passive collection and correlation of publicly available information. Avoid any intrusive techniques or operational security lapses.

3) High-level methodology (pivoting & evidence chaining)

A productive OSINT workflow is iterative and pivot-based. My general approach in this room was:

1. Identify a seed (the downloadable file from the website).
2. Extract all implicit data (metadata, hidden files, strings) from that seed.
3. Pivot outward from every useful artifact (username → GitHub/Twitter; PGP key → email; image content → reverse-image search; SSID → WiGLE).
4. Corroborate each pivot with at least one independent source (commit history, blockchain explorer tagging, additional social posts, WiGLE entries).
5. Document every command and screenshot for reproducibility

This produces an evidence chain: each fact is supported by a traceable artifact and at least one corroborating source.

4) Detailed walkthrough (Flags 1–5)

Flag 1 — Finding the username (metadata analysis)

Objective: Extract the username from the downloadable file.

What I did:

1. Downloaded the file with get <URL> (or curl -O <URL>/wget).
2. Suspicious that the file might contain metadata, I ran exiftool:

exiftool -a -u -g1 image.jpg

exiftool -a -u -g1 image.jpg

Why this works: Many image editors, phone cameras, and even some automated upload tools inject metadata fields (e.g., Artist, UserComment, Software, XMP fields). CTF creators often hide clues in these fields because users tend to overlook metadata.

What to look for:

• Artist, By-line, Creator, UserComment, Software, Description, XMP blocks.
• Any long strings, base64 blobs, or ASCII that look like usernames or URLs.

If nothing obvious appears:

• Use strings image.jpg | less to find embedded readable text.
• Try binwalk -e image.jpg to search for embedded files.
• Try steghide or zsteg (if the contest allows stego challenges).

Result: SakuraSnowAngelAiko found in metadata.

Notes and verification:

• Capture a screenshot of the exiftool output and note the exact field name that contains the username (e.g., UserComment).
• Save a copy of the original image and checksums (sha256sum) to ensure reproducibility.

Flag 2 — Email & real name (PGP & social pivots)

Objective: Use the username to find an email address (PGP key) and the attacker's real name from social media.

2.1 Email from PGP key (GitHub pivot)

Steps:

1. Google the username SakuraSnowAngelAiko and find the GitHub account.
2. Browse the repository and locate a folder named like pgp<key> (or find a .asc file). Often CTF creators deliberately place a PGP/public-key block in a repo.
3. Download the key file (raw view) or copy the ASCII armored key.
4. Inspect the key with GPG:

# show the key's UIDs and subkeys without importing to keyring
gpg --show-keys attacker_pubkey.asc
# or import temporarily to inspect
gpg --import attacker_pubkey.asc
gpg --list-keys --with-colons

# show the key's UIDs and subkeys without importing to keyring
gpg --show-keys attacker_pubkey.asc
# or import temporarily to inspect
gpg --import attacker_pubkey.asc
gpg --list-keys --with-colons

What to look for:

• UID lines that contain Name <email>
• Key creation date & fingerprint (useful for attribution and later verification)

Result: SakuraSnowAngel83@protonmail.com discovered as the email in the PGP UID.

Validation:

• Cross-check the email appearing in commit metadata (git log --pretty=fuller) when possible.
• If email appears elsewhere (e.g., contact files, other repos), capture those instances.

2.2 Real name from Twitter

Steps:

1. Search for the username on Twitter.
2. Inspect the profile page (bio, display name, linked websites) and public tweets for real-name mentions.

Result: Aiko Abe listed as the profile name on Twitter.

Notes:

• Twitter display names are user-controlled and not definitive proof of identity — but combined with other artifacts they strengthen the attribution.
• Capture profile screenshots (bio, pinned tweets) as evidence.

Flag 3 — Cryptocurrency details (repo → blockchain analysis)

Objective: Find the cryptocurrency they own, the wallet address, the mining pool they used, and currency exchange details.

Approach:

1. Use the GitHub repo pivot (files/commits) to find any wallet address or crypto-related link.
2. Extract the wallet address from the commit history or files.
3. Use a blockchain explorer (Etherscan) to analyze the address and related transactions.

Key steps & commands:

• From GitHub web UI: open file → History to see when wallet strings were added. Use raw file link to copy the address precisely (avoid OCR mistakes).
• On Etherscan (web): paste the wallet address into the search bar.

What to inspect on Etherscan:

• Overview: current balance and token holdings (ERC-20).
• Transactions: list of outgoing & incoming txs.
• Internal Txns: payouts or contract interactions (useful for mining pool payouts).
• Token Transfers: look for USDT transfers to see exchanges into Tether.
• Contract events / input data: sometimes pools include identifiable patterns in input data.

Identifying mining pool payments:

• Mining pools often consolidate payouts; some pool addresses are tagged by Etherscan as ethermine or f2pool. Look for a tagged address or repeated small incoming payouts with large consolidated outgoing transfers.
• If unsure, follow the txs backward — see which incoming address repeatedly sends small amounts that aggregate in a single wallet.

Date-specific check:

• To confirm whether the attacker received payments from Ethermine on January 23, 2021 UTC, filter Etherscan by date (or scan the tx list and check timestamps). The explorer lists timestamps in UTC — match those to the date in question.

Exchange detection (ETH → USDT):

• Look at Token Transfers for USDT (Tether) entries.
• For decentralized swaps (Uniswap/1inch), inspect transaction input logs or look for interactions with token swap contracts. For centralized exchanges, you may see withdrawals to known exchange addresses (tagged on Etherscan).

Result (from the room):

• Cryptocurrency: Ethereum (ETH)
• Wallet address: (extracted from repo) — place as <wallet_address_here> in this doc.
• Mining pool: Ethermine (identified by repeated mining payouts and/or Etherscan tags)
• Currency exchanged: Tether (USDT)

Validation & evidence:

• Screenshot of the Etherscan address page showing transactions and tags.

• Note the tx IDs (TxHash) of specific payments (especially any on January 23, 2021 UTC) and include them in the report.

Flag 4 — Dark web paste & Wi-Fi OSINT (geolocation)

Objective: Using clues from a screenshot (MD5 hash + partial paste URL + SSID) to find the attacker's home location.

Steps & rationale:

The tweet screenshot included the word DeepPASTE and half a URL — suggesting a paste service on the dark web. The MD5 hash in the screenshot was likely part of the paste URL.

1. The paste itself was offline, but the screenshot contained an SSID: DK1F-G.
2. I used WiGLE (wiGLE.net) to search for that SSID. WiGLE aggregates wardriving records that map SSID → BSSID → location (lat/long).

Results from WiGLE (as found in the room):

• BSSID: 84:AF:EC:34:FC:F8
• Location: Hirosaki, Japan → used as the home city flag.

Important caveats:

• SSID names are not unique — the same SSID string can appear elsewhere. BSSID (MAC) is unique to the access point, so prefer BSSID over SSID when possible.
• WiGLE data comes from volunteer wardrives. Look for lastSeen timestamps and multiple sightings to increase confidence.
• Corroborate with other cues (tweets with location tags, photos of local landmarks, language/timezone in posts).

Conclusion: The combined evidence pointed to Hirosaki as the attacker's home city.

Flag 5 — Home & Travel OSINT (image/geospatial analysis)

Objective: Determine the attacker's nearest airports, last layover, lake visible in an inflight photo, and their home city.

By combining reverse-image searching, useing Ai ,metadata inspection, visual landmark matching, and flight-timeline analysis, the following were identified and validated:

• Nearest airport (DC): DCA (confidence: Medium/High)
• Last layover airport: HND — Haneda Airport, Tokyo (confidence: Medium)
• Lake on final flight photo: Lake Inawashiro (confidence: High)
• Home city: Hirosaki (confidence: High)

These findings, together with the other flags, completed the profile assembled in the Sakura Room CTF.