How to Write CTF Writeups That Teach Reasoning (Not Just Flags)

By Syed Zada Abrar · andraxpentester.in

A good CTF writeup is not a trophy case of flags. It is a teaching artifact: what you observed, why it mattered, and what you tried next. Flag dumps help the author feel finished; reasoning-first writeups help the next learner reproduce the thinking, not just the answer.

This guide covers how to write CTF writeups that stay ethical, respect platform rules, and connect cleanly to structured practice on andraxpentester.in—without spoiling live competitive rooms.

Why writeups fail (and why that matters)

Most weak writeups share the same shape:

1. Screenshot of a tool
2. Magical command
3. Flag in a code block
4. “GG”

That pattern trains copy-paste. It does not train hypothesis testing. Employers, mentors, and future-you care about the middle: how you narrowed the search space, what you ruled out, and how you recovered from a wrong turn.

Treat the writeup as a lab notebook you would hand to a junior teammate who has the same authorized target and the same rules of engagement—nothing more.

The core template: Observe → Why it mattered → Next step

Use this three-beat loop for every meaningful finding. Repeat it as many times as the challenge needs.

Observe

State the fact without interpretation.

• “HTTP response includes X-Powered-By: Express.”
• “Directory listing is enabled on /backup/.”
• “Binary prints gets() in the PLT.”

Prefer primary evidence: response headers, file names, error strings, process behavior you measured yourself.

Why it mattered

Connect the observation to a hypothesis or risk class in one or two sentences.

• Express fingerprint → likely Node stack; check for common misconfig patterns on this box.
• Open backup directory → possible source or credential residue in scope.
• gets → classic unsafe input path for a memory-corruption learning path in a retired pwn challenge.

If you cannot explain why it mattered, you are not ready to write the step yet—keep experimenting.

Next step

Write the smallest next action that tests the hypothesis.

• “Enumerate /backup/ for non-binary text artifacts.”
• “Diff config against a known-good Express default.”
• “Map input length vs crash in the debugger on the local copy.”

Avoid leaping to the flag. The next step should be falsifiable: you might learn you were wrong, and that belongs in the writeup too.

Mini example (fictional retired web room):

Observe: robots.txt disallows /old-admin/.
Why it mattered: Disallow entries often mark forgotten paths still reachable.
Next step: Request /old-admin/ and record status code + body length before fuzzing anything else.

Structure of a full writeup

Front matter (keep it short)

• Challenge name, platform, difficulty (as labeled)
• Status: retired / practice / your own lab—never “live ranked spoilers”
• Your goal for the reader (“follow the web enumeration chain,” not “get root in 10 minutes”)
• Tools used (version notes when behavior differs)

Body sections that scale

1. Recon summary — only signals that changed your plan
2. Path narrative — Observe / Why / Next repeated
3. Wrong turns — at least one; credibility lives here
4. Technique index — short list of reusable skills (SQLi detection thinking, JWT misconfiguration checklist, etc.)
5. References — docs, man pages, prior Andrax tutorials

What to omit

• Live CTF or in-progress competitive HTB/THM machine spoilers when the platform or event forbids them
• Credential dumps from real third-party systems
• Payload catalogues aimed at unauthorized use
• Flags for active seasonal or competitive boxes

When in doubt for HTB: wait until the box is retired (or explicitly allowlisted)—not merely expired—or write a technique article with a synthetic example.

Platform etiquette (non-negotiable)

Spoiler hygiene

• Put the flag behind a collapsible section or at the very end, clearly labeled.
• Title and social cards should not leak the path (“IDOR on invoice ID” is often enough without the flag).
• Separate “technique explainers” (/articles/) from “step-by-step labs” (/tutorials/) so search engines do not serve spoilers as the only hit.

Educator voice vs flag dump

Ask before publishing:

• Can a reader who never saw this box apply the same method to a different authorized target?
• Did I show how I validated assumptions?
• Did I name the skill (“forced browsing,” “certificate transparency pivoting,” “basic buffer overflow triage”) so it can link to a tutorial later?

If the answer is “they still need my exact commands in order,” rewrite toward reasoning.

Linking techniques to Andrax labs and tutorials

Writeups on andraxpentester.in should point learners into structured practice—not strand them on a single room.

Skill names to practice next (link to the tutorials hub when a dedicated page exists):

• Enumeration mindset → web recon checklist
• Privilege escalation thinking → Linux privilege escalation methodology
• Forensics note-taking → DFIR triage notes
• Broader methodology essays → /articles/
• Hands-on practice hub → /tutorials/

In meta/SEO drafts, /labs/ may appear as a synonym for hands-on paths; in body copy, keep the public URL path as /tutorials/.

When you reference a technique, one sentence should say what the tutorial will let them practice under authorization—not how to attack random hosts.

Internal-link cluster (Rank): Point related writeups into existing Kali / lab-setup tutorials on andraxpentester.in (already impressing in GSC). Prefer /tutorials/ Kali install and fundamentals pieces over inventing new hubs. Do not conflate Andrax Pentester with Android “ANDRAX” — that disambiguation article is a separate P0 post-RESUME brief.

Optional sample outline (THM / HTB-style retired room)

Use this skeleton; fill only for retired or explicitly writeup-allowed content.

# <Room name> — reasoning writeup (retired)

## Scope and etiquette
- Platform, retire status, date you solved it
- What you will not spoil for active siblings

## Attack surface map (5–10 lines)
- Hosts, ports, obvious services
- What you deliberately ignored and why

## Path 1 — Initial foothold
### Finding A
- Observe:
- Why it mattered:
- Next step:
### Finding B
- …

## Path 2 — Privilege / deeper objective
- Same loop
- Include one failed hypothesis

## Technique index
- Skill → link to /tutorials/ or /articles/ when those pages exist
- Skill → link to the tutorials hub: /tutorials/

## Flag (spoiler)
<details><summary>Reveal</summary>
…
</details>

## See also

- Practice next on the tutorials hub: [/tutorials/](/tutorials/)
- Not looking for Android ANDRAX? [/articles/andrax-pentester-vs-android-andrax](/articles/andrax-pentester-vs-android-andrax)

## Sources
- Official docs, man pages, prior writeups you learned from (credit them)

Customize section names to the room type (web, pwn, forensics, cloud). Keep the loop identical so readers build muscle memory.

Practical checklist before you hit publish

• Box/event is eligible for public writeups
• Every major step has Observe / Why / Next
• At least one wrong turn documented
• Flags collapsed or end-loaded
• No live competitive spoilers
• Techniques linked to the tutorials hub or /articles/ when those pages exist
• Tone is defensive and educational—no “pwn random sites” framing
• Spelling pass; commands are complete enough to reproduce in the same lab
• You would be comfortable with a hiring manager reading it

A note on originality and citation

Reasoning-first does not mean reinventing known techniques. Cite prior writeups, documentation, and course material you leaned on. Summarize; do not paste large copyrighted challenge text or other authors’ full writeups. Your value is the decision tree, not a mirror of someone else’s narrative.

Closing

CTF writeups become a personal methodology archive when you write them as arguments, not answer keys. Observe carefully, explain why the signal mattered, choose the smallest next test, and leave a trail other learners can follow on authorized platforms. That is how andraxpentester.in stays an educator brand instead of a flag warehouse.

Sources

1. Hack The Box Help Center — writeups and retired machine guidance (check current policy before publishing): https://help.hackthebox.com/
2. TryHackMe — room and community guidelines (follow room-specific rules): https://tryhackme.com/
3. CTFtime — event pages and organizer rules for spoiler timing: https://ctftime.org/
4. OWASP Web Security Testing Guide — structured testing mindset useful for web CTF narratives: https://owasp.org/www-project-web-security-testing-guide/
5. andraxpentester.in tutorials hub (hands-on path): https://andraxpentester.in/tutorials/