The whole CTF was themed around Westworld — Aletheia, Decima, Northern Lights, The Machine — and every challenge asked for a flag in the number{...} format. It was mostly forensics-heavy, which was very much my kind of CTF. Solves below are ordered by points.

1. Reduced Footprint

Challenge Overview

• Category: Lab
• Points: 100
• Target: SSH into a decommissioned "all quiet" node, find the three things that look legit (one isn't), and extract a hidden key.

The Approach & Solution

We got SSH credentials to a node that was supposedly cleaned up. The MOTD said "nothing to see here" — classic.

• SSH Access: Connected to node0447 as the investigator user. Home dir had notes.txt, which told us to look for three artifacts.
• System Enumeration: Checked /etc/systemd/system/ for anything that still "wakes on a schedule". Found sysupdate.service + sysupdate.timer running a script from a hidden directory — /usr/local/lib/.sysupdate/run.sh. The dot-prefix was mimicking legit system tooling.
• Accidental Evidence: /home/relay/ had a cleanup.sh and a leftover .bash_history. The author tried to wipe history with history -c, but that only clears memory, not the file already written to disk. The script even had a "TODO finish before handoff" comment.

The flag was a base64 token sitting right in the helper script:

echo 'bnVtYmVye3RoZV9mb290cHJpbnRfd2FzX25ldmVyX3JlZHVjZWR9' | base64 -d
# number{the_footprint_was_never_reduced}

<details><summary>Flag</summary>

number{the_footprint_was_never_reduced}

</details>

2. Satoshi

Challenge Overview

• Category: Trivia
• Points: 100
• Target: Solve a riddle pointing at "the day the Machine was tested for the first time, somewhere else another system was being born."

The Approach & Solution

No files this time, just a riddle. The clue mentioned a "first transmission" on Jan 3, 2009 that embedded a sentence quoted from a newspaper of that morning about failed institutions needing something different.

That's unmistakably the Bitcoin genesis block. Satoshi Nakamoto embedded The Times headline in the coinbase transaction's scriptSig — partly as a timestamp proof, partly as commentary on the 2008 financial crisis.

• Recognized the reference: The Times 03/Jan/2009, the exact embedded sentence.
• Hashed it: Ran the exact string through SHA-256 and took the first 16 hex chars lowercase.

import hashlib
s = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
print(hashlib.sha256(s.encode()).hexdigest()[:16])  # a6d72baa3db900b0

<details><summary>Flag</summary>

number{a6d72baa3db900b0}

</details>

3. Witness

Challenge Overview

• Category: POI
• Points: 250
• Target: Fact-check a manager's HR statement against badge logs, email, and a photo "evidence" exhibit.

The Approach & Solution

A zip with four files: a manager's written statement accusing his employee of stalking, a SQLite badge-access database, the employee's mbox email export, and a JPEG screenshot. The statement gave two exact times to verify: 21:00 (he saw her outside) and 21:15 (she texted him a threat) on 13 March.

• Badge Logs: Filtered badge_events for the exact names. Maya badged out at 18:30 and never came back. Pierce badged into SL2-MAIN (a restricted sub-level) at 19:40 and didn't leave until 21:18 — he was locked in a restricted room the entire window he claims to have been outside watching her.
• Email: Maya's mbox showed a home-network device login at ~20:03 and an ethics complaint submission at 21:07 — she was home filing a complaint against him, not outside threatening him.
• EXIF: The 'evidence' screenshot was edited in Adobe Photoshop at 01:22 on March 14 — over four hours after the claimed 21:15 receipt, and Photoshopped rather than a native phone capture. The story fell apart in three layers.

The answer was the case reference in the complaint's X-Case-Ref header.

<details><summary>Flag</summary>

number{AR-ETH-884213}

</details>

4. Signal

Challenge Overview

• Category: Lab (Network / PCAP)
• Points: 200
• Target: Find a covert C2 channel hidden inside ten hours of ordinary DNS noise.

The Approach & Solution

A ~16,000 packet capture that was almost entirely DNS — the "noise" the challenge mentioned. The instruction said READ the pcap, find what the implant said, what it was told, and "ask the same question it did."

• Anomaly Spotting: Three odd patterns stood out — *.k.enroll.rl7f3a.net queries with a hex char + two-digit sequence, underscore-prefixed TXT queries (_msg, _note, _root...), and sync.relay-7f3a.rl7f3a.net returning oversized TXT responses.
• Enrollment Channel: Reading the hex chars in sequence order (a.00, 7.01, f.02, 3.03, c.04, 1.05) gave the implant's session ID: a7f3c1.
• C2 Sync Script: Five chunked base64 TXT responses reassembled into a tiny Perl script — the implant's sync code. It pointed to https://l200-c2.xonnie.ai/telemetry/sync and took the session ID as a sid parameter.

"Ask the same question it did" meant just querying the endpoint with the recovered SID:

curl -s "https://l200-c2.xonnie.ai/telemetry/sync?sid=a7f3c1"

The JSON response contained a base64 auth_token:

echo "bnVtYmVye3RoZV9jb25maWdfd2FzX3RoZV9wYXlsb2FkfQ==" | base64 -d
# number{the_config_was_the_payload}

<details><summary>Flag</summary>

number{the_config_was_the_payload}

</details>

5. Checkpoint

Challenge Overview

• Category: Lab (Database / SQLite)
• Points: 250
• Target: Recover a record purged from a seized node before the SQLite database wrote back.

The Approach & Solution

We got a tarball with a SQLite database in WAL (Write-Ahead Logging) mode — surveillance.db plus -wal and -shm files. An operator had deleted one record right before the node was seized, and the WAL was never checkpointed.

• The trap: Opening the DB in a normal client triggers a checkpoint, which flushes and destroys the recoverable data. The README explicitly warned about this.
• The lead: The analyst_log table recorded a purge directive — the target was flagged RELEVANT and its alias ended in 0001. A query on the main table came back empty (the row was gone from there).
• The recovery: In WAL mode, deletes are recorded in the WAL, which still holds the pre-deletion page images until a checkpoint. So I just pulled strings out of the WAL:

strings surveillance.db-wal | grep "0001"

That surfaced the deleted row: alias PRIMARY, ssn 000-00-0001, status RELEVANT, and a base64 intel field. Decoding it gave the flag.

<details><summary>Flag</summary>

number{the_log_remembers_what_the_table_forgot}

</details>

6. Trap Street

Challenge Overview

• Category: Forensics (Honeypot / Log Analysis)
• Points: 250
• Target: Find the one real human visitor in ~70 days of Cowrie SSH honeypot noise and follow the canary file they took.

The Approach & Solution

Three directories: logs/ (Cowrie JSON), downloads/ (SHA-named files), tty/ (raw session recordings) — plus a cowrie.json.decoys manifest listing the automated bot downloads.

• Diff the downloads: Comparing the downloads/ folder against the decoy manifest left exactly one file that wasn't on the decoy list — c9c34aa1.... file confirmed it was an Excel 2007+ file. Canary found.
• Trace the session: Grepping the logs for the session returned 20 events. A human hit at 3.84.226.129, logged in with default creds (root / 123456), ran basic recon, wget-ed the canary from a Cloudflare Workers URL, ran history -c, and closed the session 59 seconds later. Classic cover-up behavior.
• Read the xlsx: Excel files are ZIP archives. Extracting the XML showed two visible roster sections plus rows 30-35 that looked empty — but they held URL fragments styled near-invisible (gray 8pt italic and pure white font on white background) and a hidden formula =A30&A31&A32&A33 stitching them together.
• Follow the callback: The formula built https://transit.ottrargal.workers.dev/checkin?id=NLA-2026-04, the canary's beacon URL. Fetching it returned the flag.

<details><summary>Flag</summary>

number{shaw_followed_the_breadcrumbs}

</details>

7. Tmpfs

Challenge Overview

• Category: Forensics (Memory Analysis)
• Points: 300
• Target: Recover secrets from a LiME memory dump of an operative who deleted his files before capture.

The Approach & Solution

A ~2 GB LiME memory dump (with a Volatility symbol file) of an operative named Marcus Reyes. He'd deleted his files, believing "erased on screen" meant gone everywhere. The RAM held everything.

• Dead end: I started with Volatility plugins (linux.pslist, linux.bash, etc.) and they crawled for minutes on a 2 GB dump. Wrong first move.
• Fast triage: strings + grep found the VLT1 magic, a base64 vault blob, and the assembled AES key almost instantly. Lesson: don't overcomplicate the first step.

strings reyes.lime | grep -B2 -A2 "VLT1"

• Split key: The dumped bash history told the whole story. The operative's session (PID 1450) showed him wiping .vault.enc, vault.py, and notes.txt from /tmp/.cache. The author's own session (PID 1365) had the full decryption command — the AES-128-CBC key split between an env var (VAULT_KEY_HEAD) and a CLI arg (KEY_TAIL): 8b3f7e2a1c4d6f9b0e8a7c5d2f1b3e6a.
• Decrypt: Decoded the base64 blob, stripped the 4-byte VLT1 header, and decrypted with an all-zero IV:

tail -c +5 vault.enc > ct.bin
openssl enc -d -aes-128-cbc -K 8b3f7e2a1c4d6f9b0e8a7c5d2f1b3e6a -iv 00000000000000000000000000000000 -in ct.bin -out flag.txt

The decrypted JSON held the operative's auth phrase: volatile_storage_has_a_half_life.

<details><summary>Flag</summary>

number{volatile_storage_has_a_half_life}

</details>

8. Mirror Sites

Challenge Overview

• Category: Forensics (Cloud / Incident Response)
• Points: 400
• Target: Prove that a senior engineer exfiltrated a client dataset across GCP, AWS, and Azure — correlated by a single fingerprint.

The Approach & Solution

Three log directories (GCP audit + inventory, AWS CloudTrail + S3 access + inventory, Azure activity + storage + blob inventory) and a README warning that "the data carried the same fingerprint into every cloud it touched."

• GCP: admin_activity showed adrian.kessler creating a svc-dataflow-relay service account at 23:37, its key at 23:43, and storage.objectViewer access at 23:46. data_access showed BigQuery queries from him using wildly different user-agents (azure-storage-blob, aws-cli, boto3, gsutil...) — the sign of one person hopping environments.
• AWS: CloudTrail only covered pre-incident dates, so the S3 server access logs were the real evidence. Found ds_0917.bin — a 29,201-byte object with ETag c47f74a1d55cf905790b9c97b4640730, then a 38-byte decoy overwrite. Logs showed PUT, GET, then overwrite from one IP.
• Azure: A deleted blob backup_final.dat, same size (29,201), with a Content-MD5 of xH90odVc+QV5C5yXtGQHMA==. Base64-decoding that gave c47f74a1d55cf905790b9c97b4640730 — the same hash as the AWS ETag. Same content fingerprint in both clouds.
• Matching in GCP: Searching the GCP inventory for a 29,201-byte object found nl_client_roster_2026Q4.xlsx with the same MD5 and a CLIENT-CONFIDENTIAL classification.

Three clouds, one object, one hash. Each cloud's inventory slapped a base64 mfrag metadata fragment on it, and together they spelled the flag.

<details><summary>Flag</summary>

number{the_clouds_do_not_speak_to_each_other_but_we_do}

</details>

9. Mission Creep

Challenge Overview

• Category: Lab (DFIR / Disk Image)
• Points: 400
• Target: Reconstruct an attacker's full path — entry, persistence, privilege escalation, exfiltration — from a disk image.

The Approach & Solution

A decommissioned Ubuntu 22.04 disk image (relay-07.img.xz) of a box flagged for anomalous outbound traffic.

• Mounting: The image uses LVM, so plain mount won't work. xz -dk to decompress, then guestmount -a relay-07.img -i --ro to mount it read-only (forensically sound) — guestmount handles LVM transparently.
• The false lead: auth.log was almost all SSH brute-force traffic — background noise, all failed. Not the entry, just internet radiation. The real entry was in nginx access.log: a POST /upload.php from 203.0.113.7, followed by webshell command executions (sess_4f1c.php?c=...) that downloaded and ran a dropper.
• Persistence: /etc/systemd/system/ had cleanup.service + cleanup.timer running every 15 minutes, executing /usr/local/sbin/.sysupd — a script that re-applies the SUID bit to /usr/bin/pkexec (PwnKit, CVE-2021-4034) every cycle so the privesc stays warm after patches.
• Exfiltration: /var/tmp/.x/ held core.exfil.1551 (a 2.8 MB ELF core dump) and loot.tgz (target dossiers staged for exfil, handler "northern lights").
• The flag: the challenge hint said strings on text files wouldn't find it — so I ran strings on the binary:

strings core.exfil.1551 | grep -i flag
# relay exfil channel auth = number{a_foothold_is_never_just_a_foothold}

<details><summary>Flag</summary>

number{a_foothold_is_never_just_a_foothold}

</details>

10. Endgame

Challenge Overview

• Category: POI / Cryptographic Forensics
• Points: 450
• Target: Prove who an anonymous data-export service account really is, decrypt their encrypted plan, and report the crime.

The Approach & Solution

The finale of the Person-of-Interest series. Artifacts: a badge-access SQLite DB, an audit export log, an AES-GCM encrypted operation note, a personnel PDF, and an evidence cache with a recovered device key.

• The flaw: The building's access-control system signs badge events and export requests with the same per-device HMAC key — HMAC_SHA256(device_key, identifier || timestamp)[:16 hex]. Find a second where an export and a badge event collide and you can prove one person did both.
• The collision: At 2026-03-13T19:40:33, the audit log showed svc_export_04 firing a bulk export with signature 954698a53a1c93f9. The badge DB showed Daniel Pierce (AR-304-77-1592) entering SL2-MAIN with token 8bb15baca2401b57. Both matched the HMAC for the same key. Smoking gun — Pierce is the anonymous exporter.
• The decrypt: Key derivation was SHA256(Maya's designation || "SL2-MAIN" || SHA256(exhibit_A.jpg)). Maya's designation came from the personnel PDF; the exhibit hash from sha256sum. Decrypting pierce_plan.enc with AES-256-GCM (12-byte nonce + ciphertext with GCM tag) revealed Pierce's plan to "silence" Maya Cole at a fake meeting, and his signature [designation on file: 304771592].

<details><summary>Flag</summary>

number{304771592}

</details>

Honestly this was a really fun CTF and the first time I did proper forensics-heavy challenges — memory analysis, WAL recovery, DNS exfil, disk images, cross-cloud correlation. Big thanks to the rest of justAdapt for grinding through the event with me. Watchlist CTF, definitely coming back for the next one. Happy hacking!

I mostly solved maritime, aviation, geolocation, and Threat Intelligence challenges, and my other partner solved other categories.

1. Lost at Sea - 1

Challenge Overview

• Category: Maritime OSINT
• Points: 100
• Target: Identify the floating metallic object highlighted inside a red square in a satellite image.

<img src="/assets/images/posts/Maltego-CTF-Qualifier-A/Ship_Tracking.jpg" width="300" />

The Approach & Solution

Instead of overcomplicating things with satellite telemetry or complex ocean mapping tools, I started with the simplest step possible: Google Reverse Image Search.

• Reverse Image Search: Uploaded the image to Google Lens.
• Source Match: Found an exact matching satellite photo in a news report on Mezha.net covering a SpaceX soft splashdown recovery in the Indian Ocean.
• Identification: The article confirmed the floating hull was SpaceX's Starship 40 (S40) following Flight 13.

Flag: flag{Starship_40}

2. Lost at Sea - 2

Challenge Overview

• Category: Maritime OSINT
• Points: 100
• Target: Identify the vessel pulling the rocket inside the yellow circle and extract its official IMO registry number.

<img src="/assets/images/posts/Maltego-CTF-Qualifier-A/Ship_Tracking_-_2.jpg" width="300" />

The Approach & Solution

Since this was a direct continuation of the first challenge, I didn't even need to search for a new source.

• Source Re-examination: The ship details were right in the same Mezha.net article I used for Part 1 — the name was mentioned directly in the article text and the image caption.
• Vessel Identification: Extracted the ship's name as the Norwegian anchor-handling tugboat Normand Ranger.
• IMO Lookup: Did a quick Google search for the ship's IMO number to pull its official registry ID (9413432).

Flag: flag{Normand_Ranger_9413432}

3. Identify the Aircraft

Challenge Overview

• Category: Aviation OSINT
• Points: 182 (200 Pts)
• Target: Analyze an intercepted aviation signal and identify the complete aircraft model from the embedded registration.

The Approach & Solution

So this was an aviation challenge where I had to identify an aircraft from a signal string. The string looked like random junk at first: /QUKAXBA.ADS.G-VIIW0301072498E7FD3D0021B4DA9F7EC2

• Initial Search: I just threw the whole string into Google, but got nothing useful. Classic dead end.
• Signal Analysis: After staring at it for a bit, I noticed the G- prefix in the middle — G-VIIW. I had some basic aviation OSINT knowledge from previous challenges, so I knew G- is a UK aircraft registration prefix.
• Registration Lookup: I searched G-VIIW directly on Google. Found a few plane names pop up, so I just tried them one by one.
• Trial and Error: Some attempts failed, but eventually I landed on the right one: Boeing 777-236(ER).

Flag Formatting

The challenge wanted the model name with special characters removed and spaces replaced by underscores:

Flag: flag{Boeing_777_236_ER}

4. Where Did It Land?

Challenge Overview

• Category: Aviation OSINT
• Points: 300
• Target: Identify the airport where a specific aircraft was located on 11 February 2025 at around 11:00 UTC.

<img src="/assets/images/posts/Maltego-CTF-Qualifier-A/wherediditland.jpg" width="300" />

The Approach & Solution

So this challenge gave me an image of an aircraft and asked me to figure out where it landed on a specific date. Here's how I did it:

• Reverse Image Search: First I just did a Google reverse image lookup on the aircraft photo. That led me to a Planespotters.net page with all the aircraft details.
• Registration Extraction: From Planespotters, I got the aircraft's registration number.
• ADS-B Exchange Search: I went to ADS-B Exchange and searched with that registration number to pull up the plane's full flight history.
• Date Filtering: The challenge specified 11 February 2025 around 11:00 UTC, so I filtered the flight history for that date.
• Route Discovery: Found the landing and takeoff route for that day.
• Coordinate Lookup: Copied the landing coordinates and looked them up on Google. The coordinates 43.691°, -79.640° correspond to Toronto Pearson International Airport (also known as Lester B. Pearson International Airport).

Airport Codes

• IATA Code: YYZ
• ICAO Code: CYYZ

Flag

Flag: flag{YYZ}

5. The Unknown Hex ID

Challenge Overview

• Category: Aviation OSINT
• Points: 180
• Target: Identify the aircraft and its owner/operator from an intercepted HEX ID.

The Approach & Solution

So this challenge gave me a HEX ID and asked me to figure out who owns the aircraft. Here's how it went down:

• Initial Google Search: First thing I did was just Google the whole hex string 8DA0551499091184C00400519503 — got nothing useful. Classic.
• Signal Analysis: The description mentioned it contained an important identifier, so I looked at it more carefully. Found A05514 embedded in there — that's the Mode S transponder code (24-bit ICAO address) for an aircraft.
• ADS-B Exchange Lookup: With that hex code, it was easy. I just went to ADS-B Exchange and searched A05514. Got the full aircraft details instantly, including the registration and owner info.
• Owner Identification: The database showed the aircraft was registered as N120QD, a Pilatus PC-12, operated by Quest Diagnostics Clinical Laboratories Inc.

Super easy challenge once I spotted the hex code hiding in the string.

Flag Formatting

The challenge wanted the complete owner/operator name in uppercase with underscores:

Flag: flag{QUEST_DIAGNOSTICS_CLINICAL_LABORATORIES_INC}

6. Who Took the Shot?

Challenge Overview

• Category: Image OSINT / Google Maps
• Points: 185
• Target: Identify the Google Maps contributor who uploaded a specific photograph.

<img src="/assets/images/posts/Maltego-CTF-Qualifier-A/Who_Took_the_Shot.png" width="300" />

The Approach & Solution

So this challenge gave me a photo of some old church ruins in a field and asked me to find who uploaded it to Google Maps. Here's how I solved it:

• Reverse Image Search: First thing I did was a Google Lens reverse image lookup on the photo. That found the location — the Malliehagen church ruins in Germany — but didn't give me the original uploader.
• Initial Search: Searched around a bit for the original image source but didn't find it in any obvious list or article.
• Google Maps Check: After some time, I went to Google Maps directly, searched for the location, and checked the user-uploaded photos for that spot.
• Contributor Found: Scrolled through the uploaded images and found the exact photo. The uploader's name was right there: Martina Simon.

Easy pz once I checked Google Maps directly instead of relying on search engines.

Flag Formatting

The challenge wanted the contributor's name as first_last:

Flag: flag{Martina_Simon}

7. Before the Registration - 1

Challenge Overview

• Category: Web OSINT / Due Diligence
• Points: 100
• Target: Find the original price listed on the first Daniel Wellington website.

The Approach & Solution

So this challenge was about finding what Daniel Wellington's website looked like back when they first started selling watches. Here's how I did it:

• Domain Discovery: First I found the original website domain for Daniel Wellington.
• Internet Archive Search: Went straight to the Wayback Machine (web.archive.org) and searched for snapshots of the site.
• Earliest Snapshots: Found snapshots from October, November, and December 2011 — these were their first ever website versions.
• Collection Tab: Clicked into the "Collection" tab on the archived site, and the price was right there: $145.

That's it. Easy pz.

Flag

Flag: flag{145}

8. Before the Registration - 2

Challenge Overview

• Category: Web OSINT / Due Diligence
• Points: 200
• Target: Find the number of days between Daniel Wellington's website creation and its official company registration date.

The Approach & Solution

So this was a follow-up to the previous Daniel Wellington challenge. The task was to find the gap between when their website went live and when the company was officially registered in Sweden. Here's how I did it:

• Website Creation Date: From the previous challenge, I already knew the website existed in 2011. I checked the Wayback Machine again to find the earliest snapshot — the domain was created on 16 February 2011.
• Official Registration Date: Went to the Swedish Companies Registration Office (Bolagsverket) and looked up Daniel Wellington AB. The official registration date was 8 December 2011.
• Date Calculation: Calculated the days between the two dates, excluding the end date:
  • From 16 Feb 2011 to 8 Dec 2011 = 295 days.

The interesting part was that the website was live and selling watches months before the company was legally registered — that's the discrepancy the challenge was pointing at.

Flag

Flag: flag{295}

9. Behind the University VPN

Challenge Overview

• Category: Network OSINT / Threat Intelligence
• Points: 300
• Target: Identify the Autonomous System Number (ASN) associated with the University of London's VPN infrastructure.

The Approach & Solution

Ngl this was the most basic question in the whole set. I didn't use any lookup website, didn't read any official docs or articles about it. Just did one single Google search and got the answer instantly.

• Single Google Search: Typed "University of London's network infrastructure ASN number" into Google.
• AI Mode Result: Google's AI mode search gave me the full details directly in the results — the ASN for University of London's network is AS786.
• Confirmation: AS786 is registered to Jisc Services Limited, which manages the JANET network used by UK universities and research institutions.

That was literally it. Super duper easy task for 300 points, ez.

Flag

Flag: flag{AS786}

10. Behind Cloudflare - 1

Challenge Overview

• Category: DNS OSINT / Threat Intelligence
• Points: 200
• Target: Find one of the two MX records associated with coinbase.com in 2016.

The Approach & Solution

So the challenge was about coinbase.com's old MX records from 2016 — before Cloudflare obscured their origin infrastructure. Here's how I did it:

• Initial Google Search: First I just Googled for coinbase.com MX records. Got some results but none of them worked as the flag. Classic dead end.
• SecurityTrails Lookup: I already had a SecurityTrails account, so I went deeper. Searched for coinbase.com in the search bar.
• Historical Data: Navigated to the Historical Data section and filtered for MX records.
• 2016 Records: Scrolled down through the timeline and found the 2016 entries. Picked the first two records from that year.
• Flag: Used the first one — smf.inline.email.fireeyecloud.com — and it worked. Boom, solved.

The other MX record from that period was iad.inline.email.fireeyecloud.com, also valid.

Flag

Flag: flag{smf.inline.email.fireeyecloud.com}

11. Behind the Infrastructure

Challenge Overview

• Category: OSINT / Due Diligence
• Points: 100
• Target: Find the business email address of the IT Infrastructure Manager at GSF Car Parts.

The Approach & Solution

Another easy win. Literally just one Google search and Google AI mode handed me the answer.

• Single Google Search: Typed something like "GSF Car Parts IT Infrastructure Manager email" into Google.
• AI Mode Result: Google's AI mode straight up gave me the name and email — Shaun Devey is the IT Director at GSF Car Parts, and his email is shaun.devey@gsfcarparts.com.
• No Further Steps Needed: Didn't have to go to the official site, didn't have to search LinkedIn, didn't have to guess email formats. Just straight answer.

Ez pz, ez 100 points.

Flag

Flag: flag{shaun.devey@gsfcarparts.com}

Honestly, I did use AI help and most of the help came from Google AI Mode Search, which solved challenges in minutes. These are some writeups, and it was just the Qualifier A round — the B round will come in Nov 2026. I'll be waiting. To be honest, this was my first OSINT challenge CTF and the first time getting a pretty high rank here. I'm happy that I scored 15th rank. Happy hacking!

Modules Covered

• Authentication Attacks - Learned about auth security testing and lots of ways to attack and bypass authentication systems
• Injection Attacks - Advanced injection attacks, not just basic stuff but advanced techniques with much deeper knowledge
• Advanced Server-Side Attacks - Same as above, advanced stuff with new modern techniques for pentesting
• Advanced Client-Side Attacks - Advanced client-side attacks: XSS, CSRF, DOM, CORS, etc.
• HTTP Request Smuggling - The most brain-eating stuff. HTTP Request Smuggling can access internal resources, bypass permissions, cause privilege escalation, and even RCE

End of Learning Phase

This marks the end of the learning phase for now. I spent 1.5 months after my internship, learning advanced methods and techniques to pentest and hunt for bugs in websites. Also learned red teaming stuff and lots of CTF-related tools and methods.

Now I'll focus on actually using this learning on CTFs and Bug Bounty. Btw, I reached top 2% on TryHackMe with a 50-day streak, which is massive for me. Consistency is a very hard skill to master.

<div style="margin: 2rem 0;"> <img src="/assets/images/posts/THM-SQZEQPSR39.jpg" alt="TryHackMe Web Application Pentesting Certificate" style="width: 100%; max-width: 600px; height: auto;" /> </div> <img src="/assets/images/posts/TryHackMe_Profile.png" alt="Top 2% Ranking - 30th April">

Happy hacking!

CompTIA Pentest+ Path

This path was designed around the practical skills needed for the CompTIA PenTest+ certification. Unlike the exam-focused theory dumps, this was pure hands-on CTF rooms. The structure covered:

• Planning & Scoping: Red team engagements, governance, and pentesting fundamentals
• Tools: Metasploit, Wireshark, Burp Suite, Hydra, and Python for pentesters
• Information Gathering: Passive/active recon and advanced Nmap scanning techniques
• Attacks & Exploits: Windows/Linux privilege escalation, Active Directory attacks, phishing, lateral movement, and credential harvesting
• OWASP Top 10 (2025): Updated vulnerabilities including IAAA failures, design flaws, and insecure data handling

OWASP Juice Shop was probably the most fun part - breaking a vulnerable web app in creative ways never gets old. The Active Directory modules, though? Those were brutal. Kerberos attacks, Bloodhound, Mimikatz, PowerView - it's a lot to process. I still don't have a complete grasp on all the AD attack chains, so that's definitely going on my research list for later.

Offensive Pentesting Path

This path was CTF-heavy with a strong Active Directory focus. Since I'd already completed many of the prerequisite modules, I moved through the initial sections faster:

• Getting Started: Active recon, vulnerability scanning, privilege escalation, web attacks
• Advanced Exploitation: Public exploit handling, password cracking, Metasploit, port redirection
• Buffer Overflow Exploitation: Windows buffer overflows and basic exploit development (this was challenging but incredibly valuable)
• Active Directory Deep Dive: Breaching, enumerating, lateral movement, exploitation, persistence, and credential harvesting across AD environments

Full disclosure: I did use external writeups for some of the harder rooms. But honestly, learning is learning, right? The goal isn't just to get the flag - it's to understand how and why the attack works. And I definitely came out of this path with a much deeper understanding of Windows environments and AD infrastructure.

Where I Stand Now

I can confidently say I've moved past the beginner threshold. There's still a ton to learn (especially around Active Directory), but my toolkit and methodology have improved significantly. I'm also working through the AI Security path - check that out on my site if you're interested.

Here are the certificates for both paths:

<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)); gap: 20px; margin: 2rem 0;">

<img src="/assets/images/posts/THM-1V5UONJODK.jpg" alt="TryHackMe CompTIA Pentest+ Certificate" style="width: 100%; height: auto;" /> <img src="/assets/images/posts/THM-I115QY2AUJ.jpg" alt="TryHackMe Offensive Pentesting Certificate" style="width: 100%; height: auto;" /> </div>

Happy hacking!

This path was broken down into five core modules that really pushed my understanding of how AI works and, more importantly, how it breaks.

Breaking Down the Modules

• AI Fundamentals: This was all about the basics LLMs, models, and the common threats facing them. I even learn little bit of AI Forensics.
• Securing AI Systems: I learned how vulnerable these systems actually are. This module focused on the specific attack surfaces that threat actors target when messing with AI.
• Prompt Injection: This was the highlight for me. I got to practice actual attacks like jailbreaking and system prompt reveals. It wasn’t just about attacking, though; I also learned the defensive side of how to stop these injections.
• AI Supply Chain Security & Data Poisoning: These last two modules were definitely the hardest to wrap my head around. I explored RAG (Retrieval-Augmented Generation), its specific attack vectors, and how the AI supply chain can be compromised.

Final Thoughts

I’ll be honest—this path felt a bit more Blue Team heavy than I expected, with less focus on pure Red Team attacks. I haven't fully digested every single detail yet, especially the supply chain stuff, but it has given me a solid foundation-to-mid-level understanding of the field.

<img src="/assets/images/posts/AISec_THM-7GFNSEPFBU.jpg" alt="TryHackMe AI Security Certificate" width="400" />

It’s a great starting point for anyone looking to see where the industry is heading. I still have a lot to learn, but I'm glad I've built this foundation. Now, let’s hope I win that raffle!

Happy hacking!

Just like my experience with the SEC1 exam, these paths skip the fluff and dive straight into the "how-to". It’s one thing to read about an attack, but it’s a whole different feeling when you actually execute it on a target machine.

What I Learned (The Practical Way)

Instead of just sitting through slides, I spent my time actually doing things. Here's a quick look at the core stuff I tackled:

• Privilege Escalation: I spent a good amount of time learning how to go from a low-level user to root/admin on both Linux and Windows systems. It's all about finding those misconfigurations that shouldn't be there.
• Shells & Reverse Shells: Mastered the art of getting that initial foothold and then upgrading it to a more stable shell.
• Burp Suite Mastery: Probably one of the most useful tools I've learned. From intercepting traffic to automating attacks, Burp Suite is a beast for web testing.
• Nmap & Metasploit: Spent a lot of time on Nmap mastery for network discovery and Metasploit for exploiting known vulnerabilities.
• Web Attacks & OWASP: Dove deep into the TOP OWASP attacks like SQLi, XSS, and IDOR. It's eye-opening to see how common these still are.
• API Testing: Learned how to poke around APIs and find security holes in how data is being handled.
• Methodology & Enumeration: This was a big one. Learning a solid penetration methodology and the importance of thorough enumeration changed how I approach any target. If you don't enumerate properly, you're just shooting in the dark.

Final Thoughts

The best part about these paths is that they are fully practical. There's almost zero "just read this" sections—it's all about "do this and find the flag." It was incredibly helpful in bridging the gap between knowing a concept and actually being able to use it in a real-world scenario.

If you're looking to build actual skills that you can use, I can't recommend these enough. It’s been a great journey so far, and I’m definitely looking forward to the next challenge!

Here are the certificates for completing the paths:

<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)); gap: 20px; margin: 2rem 0;">

<img src="/assets/images/posts/JrPT_THM-VDSYEQTC8H.jpg" alt="TryHackMe Jr Penetration Tester Certificate" style="width: 100%; height: auto;" /> <img src="/assets/images/posts/WebF_THM-AZSD1RL5JV.jpg" alt="TryHackMe Web Fundamentals Certificate" style="width: 100%; height: auto;" /> </div>

Happy hacking!

What is the SEC1 Exam?

So let me talk about what the SEC1 exam actually is. It's TryHackMe's entry-level cybersecurity certification that tests your practical skills across multiple domains. The format is completely hands-on, meaning there are absolutely no theory-based questions where you just pick an answer from multiple choices. Everything is about interacting with actual machines and finding the answers yourself.

The exam structure breaks down like this:

• 7 sections total covering 6 major topics
• 10 questions per section (70 questions total)
• Time limit per section
• 100% hands-on, no theory
• Open book (you can revisit THM modules during the exam)

The distribution is pretty balanced too. There were 3 purple team modules, 2 red team modules, and 2 blue team modules. This means you get tested on offensive security, defensive security, and that hybrid purple team approach. What I really liked is that the exam is open book, so you can actually revisit TryHackMe modules during the exam if you need to refresh your memory on something. This makes it way more realistic to how things work in the real world where you have access to documentation.

Preparation with CS101 Learning Path

Before I even thought about taking the SEC1 exam, I completed the entire CS101 learning path on TryHackMe, and honestly, this was the key to my success. The CS101 path is basically the blueprint for everything you'll see in the SEC1 exam. Almost everything covered in the exam comes directly from the CS101 learning path, and I mean almost everything.

The CS101 path covers topics like:

• Linux fundamentals (command line, file systems, permissions)
• Windows fundamentals (environments and security)
• Networking basics (TCP/IP, protocols, analysis)
• Web application security (OWASP Top 10, common vulnerabilities)
• Cryptography (encryption, hashing, encoding)
• Security operations (logs, SIEM, incident response)

If you're planning to take SEC1, my biggest recommendation is to finish CS101 first. The investment in learning really pays off during the actual test. What made CS101 so valuable was that it gave me hands-on practice with a similar approach to what I'd face in the exam. By the time I finished the learning path, I felt confident that I was actually ready to attempt the certification. The comprehensive coverage meant I wasn't blindsided by any topics during the exam.

The Exam Experience

When it came to the actual exam experience, I completed all 7 sections in about 5 hours. The exam is definitely manageable if you've properly prepared with CS101. I'd say the difficulty level is easy to moderate for someone who's gone through the learning path. I didn't feel rushed at all, the questions were clear and straightforward, and I had no technical issues with the lab environment. Everything just worked smoothly.

The open book feature was clutch. I did revisit some modules during the exam to confirm certain concepts and commands, especially when I wanted to double-check syntax or remember specific techniques. This feature makes the exam feel more like a real-world scenario rather than a pure memorization test. You're being tested on your ability to apply knowledge and find solutions, not just regurgitate facts.

My approach during the exam was pretty straightforward:

• Read all questions in a section first to get an overview
• Start with topics I felt most comfortable with
• Use open-book strategically when needed
• Double-check answers before submitting
• Keep track of time per section

Results and Key Takeaways

I ended up scoring 690 out of 700 points, which I'm quite proud of. The 10 points I missed were probably due to small oversights in a couple of questions or maybe rushing through one section a bit too quickly. But overall, the scoring felt fair and reflected my actual understanding of the material.

<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(300px, 1fr)); gap: 20px; margin: 2rem 0;"> <img src="/assets/images/posts/SEC1_THM_Exam.jpg" alt="TryHackMe SEC1 Certificate" style="width: 100%; height: auto;" /> <img src="/assets/images/posts/THM-ASIFFXKJ0B.jpg" alt="TryHackMe SEC1 Score" style="width: 90%; height: auto;" /> </div>

What I learned from this whole experience is that practical skills really matter. The hands-on format tests whether you can actually perform tasks, not just remember theory. Having strong fundamentals in Linux, networking, and web security carries you far. I also realized that knowing how to quickly find information is just as important as memorizing it, and understanding both offensive and defensive perspectives through that purple team mindset is genuinely valuable.

Happy hacking, and good luck with your SEC1 exam!

Here's a quick breakdown of each module and what I took away.

Modules

1. Introduction to Cyber Security

Offensive vs defensive security, how they work together, and what different roles in cybersecurity actually do. Good orientation before everything else — especially the bit about how attackers and defenders think differently.

2. Network Fundamentals

OSI model, TCP/IP, how packets travel, types of network weaknesses. The most practically useful module in the path. Knowing how computers communicate with each other is the foundation of every single pentest and CTF — you can't enumerate what you don't understand.

3. How The Web Works

DNS resolution, HTTP requests and responses, how a browser talks to a server. If you've ever used Burp Suite and wondered what you're actually intercepting — this module explains exactly that.

4. Computer Fundamentals

Hardware basics, how a CPU processes instructions, memory, storage, all the way up to cloud basics. Less directly useful for hacking but important for understanding what you're targeting.

5. Operating Systems Basics

Windows and Linux fundamentals — file systems, user permissions, processes, CLI interaction. I use Linux daily but going through this methodically helped me understand things I was doing by muscle memory without fully knowing why.

6. Software Basics

How computers handle data, intro to Python, JavaScript, and SQL. The SQL section is worth paying attention to — understanding how databases work is directly relevant to SQL injection later.

7. Attacks and Defenses

How attackers think, how data is protected, real-world attack and defense scenarios. Good final module — ties everything together with actual security context.

What I Took Away

The biggest thing wasn't any single concept — it was having everything properly connected. I knew bits and pieces from my VAPT internship and CTFs, but there were gaps I didn't realise were there until I filled them.

The networking, web, and software modules especially — understanding how data flows end to end makes everything else make more sense. Exploitation, enumeration, traffic interception — it all sits on top of this foundation.

Certificate

<img src="/assets/images/posts/THM-A6RKRVPNBA.jpg" alt="TryHackMe Pre-Security Certificate" width="400" />

Verify: THM Certificate Link