| name | tinybrain-ctf |
| description | Work a CTF challenge or other authorized security-learning exercise while tracking reconnaissance, hypotheses, payloads, and the path to the flag in TinyBrain — so you never lose a working payload, repeat a dead end, or forget what you already enumerated. Use this skill when the TinyBrain MCP tools are available AND you are solving a CTF, working a practice/retired box (HTB, picoCTF, a crackme, a deliberately-vulnerable app like Juice Shop or DVWA), or the user says "let's do this CTF", "solve this challenge", "capture the flag", or "work this box". Builds on the using-tinybrain skill. |
CTF and security-learning workflow with TinyBrain
CTFs and practice boxes are authorized, sandboxed learning. They're also exactly the kind of
multi-stage, easy-to-lose-track-of work TinyBrain is built for: lots of enumeration, many
hypotheses, payloads you'll want again, and a winning path worth remembering for the writeup.
Read the using-tinybrain skill first for the core loop. This skill adds CTF-specific habits.
Workflow
-
One session per challenge/box. create_session with task_type: "penetration_test"
(boxes) or "general" (puzzle-style challenges), named for the challenge. If you're
resuming, get_context_summary first to reload what you've enumerated and tried.
-
Log reconnaissance as you go. Open ports, services, versions, endpoints, interesting
files — each a create_memory, category: "context" or finding, tagged with the host
and service. This is the map you'll keep returning to; storing it once beats re-scanning.
-
Track hypotheses as first-class TODOs. "Login form might be SQLi", "that uploader
probably allows a webshell" — store as category: "hypothesis" at low-to-mid confidence.
As you test them, update_memory to bump confidence and flip toward vulnerability (it
worked) or note it as a dead end (it didn't). This is what stops you from re-trying the same
idea an hour later.
-
Never lose a working payload. The moment a payload, request, or command does something
useful, store it category: "payload" (or exploit) with the exact text in content and
high confidence. Link it exploits → the vulnerability it leverages. CTF flags are often
one tweaked payload away from the last one — keep them.
-
Capture the chain. When step B depends on what step A gave you (creds from one service
unlocking another, an LFI enabling log poisoning), link the memories with depends_on or
causes. The chain of links is your eventual writeup of how the box fell.
-
Store the flag and the path. When you get a flag, store it (category: "evidence",
high priority) and make sure it's linked back through the exploit chain that produced it.
Before you enumerate again, search
The classic CTF time-sink is re-enumerating something you already mapped. Before re-scanning a
host or re-poking an endpoint, search_memories by host/service tag. get_related_entries
from your current foothold to see what you already linked to it.
Track stage progress for multi-stage boxes
For boxes with clear phases (recon → foothold → privesc → root), use
create_task_progress / update_task_progress so resuming is instant: you can see you're at
"privesc, 60%, trying the SUID binary" without re-reading every note.
Writeup at the end
Ask TinyBrain to reconstruct the solve: get_context_summary for the arc, then traverse the
flag's relationships backward (get_related_entries) to recover recon → hypothesis → payload
→ exploit → flag in order. A clean writeup falls out of a well-linked graph.
Keep it in the authorized lane
This skill is for CTFs, retired/practice boxes, and deliberately-vulnerable training apps —
targets you're explicitly permitted to attack. If a request shifts toward a real,
non-consented target, stop and say so; that's outside what this skill (or TinyBrain) is for.
