You spent six hours on a binary exploitation challenge, finally landed the shell at 2 a.m., and screenshotted the flag. Three weeks later, someone asks how you did it and your memory is fog. The exploit script still works, but the why — the chain of small realizations that got you there — is gone. This is the gap a writeup closes, and it’s why the first one you publish is worth more to your career than the next ten flags you capture.
A good CTF writeup does three things at once: it locks in your own learning, it teaches the next person who hits the same wall, and it becomes a portfolio artifact recruiters and CTF teams actually read. The mistake most first-time writers make is treating it as a solution dump — “here’s the payload, here’s the flag” — when the value is in the reasoning. This guide walks through how to structure, write, and publish a writeup that holds up technically and reads like something a human wrote.
Why Writeups Matter More Than the Solve
Solving a challenge proves you can do it once. Writing it up proves you understood it. The act of explaining forces you to fill gaps you papered over during the solve — the “I tried this and it worked, moving on” moments where you didn’t actually know why it worked. Putting that into prose surfaces the holes.
There’s also a community contract. Platforms like HackTheBox, TryHackMe, CTFtime, and event-specific archives are built on writeups. When a CTF ends and the organizers release the challenge files, the community fills in the explanations. If you’ve ever been stuck on a retired box and found a Medium post that unstuck you, you’ve benefited from that contract. Writeups are how you pay it forward, and they’re how you signal — to peers, hiring managers, and team captains — that you can communicate, not just exploit.
The career angle is real. Writeups are one of the few things a self-taught security practitioner can point to that demonstrate technical depth without an NDA in the way. A GitHub repo of clear, honest writeups beats a one-line “OSCP holder” bullet on a resume because it shows your thinking.
What to Solve Before You Write
The challenge you pick to write about matters less than how recently you solved it. Write while the pain is fresh — within 48 hours ideally, before your notes go cold. Choose challenges that taught you something specific: a new technique, an unfamiliar tool, a class of vulnerability you hadn’t seen exploited end-to-end.
Avoid writeups for challenges where you copy-pasted a public exploit and got the flag. There’s nothing to teach, and readers can smell it. The best first writeups come from beginner-to-intermediate boxes where you genuinely struggled — the struggle is the article.
Check the rules of the platform before publishing. HackTheBox prohibits writeups for active machines and only permits them once a box is retired. Most CTF events allow writeups freely after the competition closes, but some have embargo periods. Publishing a writeup for an active challenge gets your account suspended and your post taken down.
The Anatomy of a Writeup That Actually Teaches
Strong writeups follow a predictable shape, not because formula equals quality but because readers arrive with specific questions in a specific order. Disrupt the order and you lose them.
The teaching happens in sections 4 and 7. Sections 2, 3, 5, and 6 can be reproduced from notes; the analysis and lessons are where you have to think. If you find yourself with a thin section 4, you don’t yet understand the bug — go back to the source material before publishing.
Showing the Dead Ends Is the Point
Beginner writeups read like everything went perfectly. Real solves don’t. You ran gobuster with the wrong wordlist for forty minutes, you fuzzed a parameter that wasn’t injectable, you tried three reverse shell payloads before one fired through the egress filter. Include those.
Dead ends are where readers learn pattern recognition. A writeup that says “I noticed the response time was 4 seconds longer when the payload had a closing quote, which suggested blind SQL injection” teaches a heuristic. A writeup that jumps straight from “I found the login page” to “here is my sqlmap command” teaches nothing. The first writeup respects the reader; the second performs for them.
This doesn’t mean documenting every key press. Edit the dead ends down to the ones that taught you something or that another solver might also try. The signal is: would someone hitting this challenge for the first time benefit from knowing this path was wrong? If yes, include it.
Code, Commands, and Screenshots
Format every command and code block as actual inline code or fenced blocks — never as screenshots of a terminal. Screenshots aren’t searchable, can’t be copy-pasted, and break for readers using screen readers. Reserve screenshots for things only an image can convey: a rendered web page, a Burp Suite intercept showing GUI state, a Ghidra decompilation view, a network diagram.
When you do screenshot, crop tight. Full desktop captures with your browser bookmarks visible signal carelessness and sometimes leak personal info. Redact API keys, session tokens, and any private IPs you don’t want indexed. The flag itself is fine to show on retired challenges — that’s the whole point — but verify the platform’s rules first.
For exploit code, paste the working version with comments explaining the non-obvious parts. Don’t paste the version with three commented-out attempts and a print("test123") halfway down. Clean it up. If the script depends on a specific tool version, note it: pwntools 4.13, Python 3.11, Burp Suite Community 2025.10.
Where to Publish and How to Get Read
Your options sort into three buckets: personal blog, third-party platforms, and GitHub. Each has tradeoffs.
A personal blog on GitHub Pages, Hugo, Jekyll, or a self-hosted setup gives you full control, durable URLs, and a portfolio that doesn’t disappear if a platform shuts down. The downside is zero built-in audience — you have to drive traffic yourself, usually through Twitter/X, Mastodon, or the CTFtime writeups index. Medium and Dev.to trade control for discoverability; they’re easier to start but algorithmically dependent. CTFtime itself accepts writeup links and surfaces them by event, which is the highest-signal traffic source for competitive CTF writeups specifically.
GitHub repos work well for batched, reference-style writeups — a single repo of every box you’ve solved, organized by platform and difficulty. They’re also the format hiring managers expect to see linked from a resume. The format is constrained (markdown only, no fancy styling), which is usually a feature, not a bug.
Whichever you pick, commit to one. Five writeups in one place with consistent formatting beats fifteen scattered across three platforms.
Common Mistakes That Kill First Writeups
A few patterns sink otherwise solid posts:
The narrative-as-hero problem. “I expertly identified the vulnerability and quickly crafted the exploit.” Nobody believes it, and it makes the writeup useless to anyone who wants to learn. Be honest about confusion.
The unexplained payload. Posting a 40-line Python exploit with no inline comments and no walkthrough of the key sections. Readers will skim it, not learn from it. Annotate.
The missing prerequisites. Assuming the reader knows what an SUID binary is, or what GOT overwriting means, while writing a beginner-tagged post. Either define terms briefly or link to a source on first use. The earlier rule applies: one-sentence definition, then use freely.
The stale link problem. Pointing to a tutorial from 2017 about a tool that’s had three major versions since. Verify your references still resolve and still describe current behavior before you publish.
The over-redacted writeup. Blurring everything including the challenge name and the technique used because you read somewhere that opsec matters. If the challenge is retired and the platform allows writeups, the only things needing redaction are your personal info and any flag formats the platform asks you to obscure.
Frequently Asked Questions
Should I write up easy challenges or wait until I solve harder ones? Write the easy ones. The audience for “first SQL injection” writeups is enormous and underserved. Beginners search for beginner content. Save the hard-box writeups for when you can actually explain the techniques without hand-waving.
How long should a writeup be? Long enough to teach the solution and short enough that someone reads it. Most good writeups land between 1,500 and 3,000 words. If yours is hitting 6,000, you’re either explaining too much foundational material or covering more than one challenge.
Can I use AI to help write my writeup? For grammar, structure, and clarity passes — fine. For generating the technical content — no. Readers can tell, and getting a fact wrong because a model hallucinated it damages your credibility more than a clumsy sentence ever would. The thinking has to be yours.
Do I need permission to write up a challenge? For retired HackTheBox machines, completed CTF events, and TryHackMe rooms outside their active competitive seasons — generally no, but check the platform terms. For active machines, paid courses with NDAs (like OSCP exam machines), and private CTFs, the answer is no, sometimes career-endingly so. When in doubt, email the organizer.
Just Publish the First One
The first writeup is the hardest because you’re convinced it has to be perfect. It doesn’t. It has to be honest, technically accurate, and complete enough that someone hitting the same challenge could follow your reasoning. Your tenth writeup will be better than your first, and your twentieth will be better than your tenth — but only if you publish the first one.
Pick a challenge you solved this week. Open a markdown file. Use the section map above. Write the recon section first because it’s the easiest. Stop trying to make it good and try to make it honest. The good comes later.
