CTF categories: the types of challenges you will meet

CTF categories are the skill areas challenges are grouped by. The core categories are web exploitation, cryptography, binary exploitation (pwn), reverse engineering, forensics, steganography and OSINT, plus miscellaneous for everything else. Larger and modern CTFs add programming (PPC), cloud, blockchain, hardware and radio, AI and machine learning, legal, and live king-of-the-hill or attack-defense targets. Each tests a distinct security skill.

Each category below covers what it tests, the key techniques, one worked example and the essential tools. Organizers can use the same structure when they create challenges for each category. New to all this? Start with what a CTF is, then work through this page, and keep the tools guide open alongside it for install commands. To practice, open Ouroboros CTF, an always-on, self-paced event, or follow the practice roadmap.

Web exploitation

What it tests: finding and exploiting vulnerabilities in web applications and APIs. Web is the largest category at most CTFs and the closest to real-world bug bounty and appsec work. Nearly every web bug comes down to the server trusting something it shouldn't: a user-supplied ID, a hidden form field, a client-side check, a URL or a file name.

Challenge shapes: a black-box challenge gives you only a URL, so you map every page, form and parameter before attacking. A white-box challenge ships the source, often with a Dockerfile, and you trace user input to wherever the flag lives. An admin-bot challenge has a "report this page" feature: a headless browser visits your link, the flag sits in its cookies, and you look for a client-side bug.

Key techniques: most web flags map to a class in the OWASP Top 10.

• Broken access control: an insecure direct object reference (IDOR) that leaks other users' data, hidden admin routes, and server-side request forgery (SSRF) that reaches an internal metadata endpoint.
• Injection: SQL injection on a login form, command injection in a "ping this host" tool, stored XSS used to steal an admin cookie, and server-side template injection (SSTI) that turns into remote code execution.
• Authentication failures: JWTs (readable in a JWT decoder) signed with a weak key or the none algorithm, weak password resets, and no rate limit on one-time codes.
• Misconfiguration and logic bugs: a leaked .git folder, a debug console left on, a negative quantity accepted by a shop, or two simultaneous requests that both pass a check meant for one.

Worked example: a challenge called "not-your-invoice" lets you sign up and view your own invoice at /invoice?id=1042. In Burp Repeater you change the ID to 1041, and the server returns someone else's invoice because it never checks who owns it. A short Python loop walks the IDs downward until the admin's first invoice shows the flag. The habit it teaches is the core of the category: anything the client sends can be changed, so change one thing at a time and watch the status code, response length and error text.

Essential tools:

• Browser developer tools, where many easy flags sit in the page source, cookies or network tab.
• Burp Suite (Community Edition is free) or ZAP, to intercept, edit and replay requests.
• curl and Python with requests, for exact requests and repetitive work.
• ffuf for content discovery and sqlmap for SQL injection. Read the rules first, because many events restrict heavy automated scanning.

Test only systems you have permission to attack. Probing a real website without authorization is illegal in most countries, including under India's Information Technology Act, 2000.

Cryptography

What it tests: breaking or exploiting weak cryptography. Challenges come in three layers. Encodings such as Base64 and hex have no key, so you only need to recognize and decode them. Classical ciphers such as Caesar and Vigenère have a key that is tiny or guessable. Modern crypto (AES, RSA, elliptic curves) falls only when someone used it wrong, so the flaw is the challenge, never the algorithm itself. Most medium challenges ship the script that encrypted the flag, so read every constant and ask why the author chose it.

Key techniques:

• Identification: Base64 uses letters, digits, + and / with optional = padding; hex uses only 0-9 and a-f; 32, 40 or 64 hex characters usually mean a hash. Paste an unknown hash into the CTF7 hash identifier, and decode Base64, hex or binary in the encoder and decoder.
• XOR: a single-byte key has only 256 options, a repeating key is Vigenère on bytes, and a key reused across two messages cancels out.
• RSA misconfigurations: a small modulus or primes that sit close together, a prime shared between keys, e = 3 with no padding, or a private exponent small enough for Wiener's attack.
• Block modes and randomness: AES in ECB mode leaking patterns, a padding oracle on CBC, nonce reuse in CTR or GCM, and keys seeded from the clock.

Worked example: a 50-point warm-up called "Salad Bar" ships cipher.txt and the line "Julius left us a note, then protected it for the internet." The file holds only 0-9 and a-f, so the outer layer is hex:

$ xxd -r -p cipher.txt
FWI7{k3a_wk3q_f43v4u}
$ xxd -r -p cipher.txt | tr 'D-ZA-Cd-za-c' 'A-Za-z'
CTF7{h3x_th3n_c43s4r}

The decoded text has the shape of a flag, but against the known prefix CTF7{ every letter is three places ahead and the digit didn't move. With "Julius" as the hint, that is a Caesar shift of 3, and the second command shifts it back (the cipher toolkit tries every shift at once). Harder challenges stack more layers or swap Caesar for a repeating XOR key, but the loop stays the same: identify, decode, compare against the flag format, repeat.

Essential tools:

• CyberChef, whose Magic operation guesses layered encodings.
• Python with PyCryptodome, and pwntools for live oracle services.
• SageMath for number theory and RsaCtfTool for common RSA checks.

Binary exploitation (pwn)

What it tests: exploiting memory-corruption bugs in compiled programs to hijack execution, usually to pop a shell on a remote server. A typical challenge gives you a Linux binary to download, often with the server's exact libc and a Dockerfile, plus an address such as nc chal.example.lab 31337 where the same binary runs. Pwn is the most feared category and one of the most rewarding, because it teaches how software actually fails at the memory level.

Key techniques: experienced players think in primitives. An information leak reveals memory you shouldn't see, a write primitive changes memory you shouldn't touch, and control-flow hijacking redirects execution. Hard challenges chain a weak primitive into a stronger one.

• Bug classes: stack buffer overflows, off-by-one errors, format-string bugs, integer overflows that approve a huge copy, and heap bugs such as use-after-free and double free in the glibc allocator.
• Mitigations: ASLR and PIE randomize addresses, so you usually need a leak first. NX stops injected data running as code, which is why return-oriented programming (ROP) exists. A stack canary detects a straight overflow, and Full RELRO makes the library-function pointer table read-only.
• Reading the hints: authors rarely disable protections at random. A binary with no canary and no PIE is telling you where the intended path starts.

Worked example: a beginner challenge reads your name into a 64-byte stack buffer with gets(), and the binary contains an unused win() function that prints the flag. checksec shows no canary and no PIE, so addresses are fixed and an overflow goes undetected. In GDB you find how many bytes reach the saved return address, then a pwntools script sends that much padding followed by the address of win(). Make it reliable against a local copy run in the author's Dockerfile, then point it at the remote service, since local-versus-remote differences are the classic last-minute failure.

Essential tools:

• GDB with pwndbg or GEF for live register, stack and heap views.
• pwntools for exploit scripting against local processes and remote services.
• Ghidra to decompile the binary, and checksec to read its mitigations.
• ROPgadget or Ropper to find the instruction sequences ROP chains are built from.

Expect months, not weeks. Learn C, x86-64 registers and calling conventions before your first overflow, and expect the heap stage to be where progress slows.

Reverse engineering

What it tests: understanding what a compiled program does without its source code, then recovering a hidden flag or the logic that validates one. The file can be a Linux or Windows executable, an Android APK, a .NET assembly, compiled Python or a WebAssembly module. The flag is rarely stored as plain text. More often the program validates your input, builds the flag at runtime, or encodes a secret you must recover. Reversing is the analytical twin of pwn and essential to malware analysis.

Key techniques:

• Challenge families: crackmes that check a password or serial, input transformations compared against a constant, obfuscated or packed binaries (UPX is the common beginner packer), bytecode and managed code, and custom virtual machines with an instruction set the author invented.
• Static analysis: read strings, imports and decompiler output without running the program, renaming functions as you understand them. Most binaries are stripped, so you see names like FUN_00101189.
• Dynamic analysis: set breakpoints in a debugger and watch which values reach the comparison. Run challenge binaries only in a disposable VM.

Worked example: a crackme asks for a license key. Following references to the "Correct!" string leads to main, which a decompiler shows roughly like this once you rename a few variables:

int main(void) {
    char input[64];
    printf("Enter license key: ");
    fgets(input, sizeof(input), stdin);
    if (check(input) == 1)
        puts("Correct! That key is your flag.");
    else
        puts("Nope. Try again.");
    return 0;
}

The real work is check(). Say it XORs each character with a key and compares the result to a byte array: you form that theory statically, break at the comparison in GDB to confirm it with real values, then XOR the array with the key to invert it and test the result against the original program.

Essential tools:

• Ghidra (free, with a decompiler), IDA Free or radare2/Cutter.
• GDB on Linux or x64dbg on Windows, plus ltrace and strace for quick call traces.
• jadx for Android and ILSpy for .NET.
• The Z3 solver and angr, once you can solve a check by hand.

Forensics

What it tests: recovering evidence and hidden data from files, disk images, memory dumps and network captures. There is no live target: you analyze a download on your own machine. Forensics mirrors real digital forensics and incident response (DFIR) work and is very beginner-friendly. Many challenges are question-driven, such as "which process opened the outbound connection?", and you wrap the answer in the event's flag format.

It's usually split into these sub-types:

• File analysis: magic bytes decide the real file type, not the extension. A PNG starts with 89 50 4E 47 and a ZIP with 50 4B 03 04, so a renamed or corrupted file gives itself away in a hex editor. Hidden-media tricks have their own section below.
• File carving: recovering files by their signatures, such as a ZIP appended to a JPEG or deleted files in unallocated disk space.
• Network forensics: reconstructing sessions and extracting files or credentials from a .pcap in Wireshark, with a subnet calculator for reading address ranges.
• Memory forensics: analyzing a RAM dump with Volatility 3 plugins such as windows.pstree and windows.netscan to find processes, command lines and connections.
• Disk forensics: browsing a disk image, recovering deleted files and building a timeline from registry hives, logs and browser history.

Worked example: "Night shift" (300 points) hands you a capture from a file server that "sent something it shouldn't have last night". The protocol hierarchy shows far more DNS than a server normally sends, so you filter to the query names:

$ tshark -r capture.pcap -Y 'dns.qry.name contains "exfil-example.lab"' -T fields -e dns.qry.name
504b0304.exfil-example.lab   # 50 4B 03 04: a ZIP signature
14000000.exfil-example.lab
08000800.exfil-example.lab
…

The labels are hex and the first is the ZIP signature, so someone moved a file out inside DNS queries. Export the names in order, join and decode the hex, and you get a ZIP holding flag.txt. Noticing the odd one out solved it, not a clever tool.

Essential tools: Wireshark and tshark, Volatility 3, Autopsy, binwalk, ExifTool, file and a hex editor. Hash the original artifact and work only on copies.

Steganography

What it tests: finding data hidden inside something that looks ordinary, such as a photo, an audio clip or a block of text. Cryptography hides what a message says; steganography hides that a message exists at all. Some events file it under forensics, others give it a category of its own, and the hidden payload is often Base64 or XOR-encoded on top.

Key techniques:

• Images: a flag in an EXIF comment, a ZIP appended after the image's end marker, or a PNG whose header lists a smaller height than the real pixel data, cropping the flag out of view.
• Least-significant-bit (LSB) encoding: changing the last bit of a color value shifts it by at most 1, which nobody can see. A 1920 × 1080 image with 1 bit per channel holds about 777 KB. LSB doesn't survive JPEG compression, so JPEG challenges use steghide with a passphrase instead.
• Audio: text drawn in a spectrogram, Morse or tones, or LSB data in uncompressed WAV samples.
• Text: trailing spaces and tabs, or zero-width Unicode characters such as U+200B between visible letters. cat -A or a hex view shows both.

Worked example: run the cheap checks first, in a fixed order, before reaching for carrier-specific tools:

$ file challenge.png  # is it really a PNG?
$ exiftool challenge.png  # comments, authors, GPS, software
$ strings -n 8 challenge.png | grep -i ctf7
$ binwalk challenge.png  # anything glued on the end?
$ pngcheck -v challenge.png  # header and chunk sanity
$ zsteg -a challenge.png  # try many LSB combinations
$ steghide info photo.jpg  # is there a steghide payload?

If a passphrase prompt appears, go back to the description, the metadata and the file name before guessing. A fair challenge leaves the passphrase somewhere you can find it, and words like "look closer" or "listen closely" in the description usually point at the technique. Badly designed stego that needs the author's exact tool and password is why many players groan at the category.

Essential tools:

• ExifTool and binwalk for metadata and appended files.
• zsteg and Stegsolve for LSB and bit planes in PNG and BMP.
• steghide for passphrase-protected JPEG and WAV payloads.
• Sonic Visualiser or Audacity for spectrograms.

OSINT

What it tests: open-source intelligence, answering a question using only public sources: where a photo was taken, who runs an account, what a deleted page once said. OSINT needs no exploitation skills, so beginners often score their first flag here. In a well-run event every person and account involved is fictional and built by the organizers.

Key techniques:

• Geolocation: placing a photo from road markings, the side of the road traffic drives on, signage script, vegetation, architecture and shadows, narrowing from country to street before confirming in street-level imagery.
• Metadata: an author name in a PDF or GPS coordinates in EXIF become the next search.
• Public records and archives: old snapshots of a page, domain registration and DNS history, and commit history in public repositories.
• Username footprint: people reuse handles, avatars and bios, so one username often leads to accounts on several platforms.

Worked example: a medium challenge gives you one photo posted by a fictional persona. Its metadata holds a handle, the handle leads to a mock forum, a picture posted there shows a landmark you geolocate, and an archived snapshot of the persona's blog confirms the date the flag asks for. Each step should give a clear signal that you are on track. Verify every answer with a second source before you submit, and read the flag format rules on case and spelling, because OSINT answers are free text.

Essential tools:

• Search-engine operators and reverse image search (Google Lens, Bing Visual Search, Yandex Images, TinEye).
• Google Maps and Earth, OpenStreetMap and a sun-position calculator such as SunCalc for geolocation.
• The Wayback Machine and WHOIS or RDAP lookups for history.
• Sherlock for usernames, and ExifTool for metadata.

Miscellaneous

What it tests: everything that doesn't fit a neat box. "Misc" is a grab-bag where organizers put their most creative ideas, so expect the unexpected.

Typical challenges: scripting challenges (a server asking 500 timed math questions, which some events file under PPC), esoteric programming languages, QR and barcode puzzles, audio and DTMF decoding, Git repository archaeology, spreadsheet or regex puzzles, and "jail" escapes from restricted Python or shell sandboxes (pyjail).

Core techniques: automation with Python and pwntools, lateral thinking, and quickly building small tools. The one reliable skill is scripting anything you'd otherwise do by hand.

Essential tools: Python and pwntools, CyberChef, and whatever the specific puzzle demands.

Difficulty ladder: a one-off decode → automate an interactive service → escape a restricted sandbox → chain several obscure tricks under time pressure.

PPC (programming challenges)

What it tests: writing correct, fast code under time pressure. PPC, usually expanded as "professional programming and coding", is the CTF cousin of competitive programming. The security angle is light; the skill is turning a problem into a working script before the server's timer runs out.

Typical challenges: a network service that sends a maze and wants the shortest path within two seconds, repeated a hundred times; arithmetic or logic puzzles too large to solve by hand; a game you must beat by computing optimal moves; parsing a huge noisy data file to find one anomaly; constraint puzzles such as sudoku or nonograms delivered over a socket.

Core techniques: algorithms and data structures (graph search, dynamic programming, greedy methods), reading a protocol from a few sample exchanges, socket automation that handles timeouts and malformed lines, and picking an approach fast enough for the limit.

Essential tools: Python with sockets or pwntools for the connection, a faster language (C++, Rust or PyPy) when Python is too slow, and a constraint solver such as Z3 for logic puzzles.

Start practicing: many beginner CTFs include a scripting warm-up, so start with a CTF7 event or Ouroboros CTF.

Difficulty ladder: answer one question by hand → script ten rounds over a socket → solve a hundred timed rounds with an efficient algorithm → combine PPC with a crypto or reversing twist.

Cloud security

What it tests: misconfigurations and attack paths in cloud environments (AWS, Azure, GCP). As real infrastructure moved to the cloud, so did the challenges, and this category is growing fast at larger events.

Typical challenges: a public S3 bucket leaking secrets; over-permissive IAM roles that allow privilege escalation; exposed instance metadata (IMDS) reachable via SSRF; leaked access keys in a repo; a misconfigured serverless function or container.

Core techniques: cloud enumeration, understanding IAM policies and trust relationships, privilege-escalation paths, and metadata-service abuse. Real cloud security knowledge transfers directly here.

Essential tools: the AWS, Azure and gcloud CLIs, Pacu for AWS, and enumeration tools like ScoutSuite.

Start practicing: look for cloud tracks in live CTF7 events, and only ever test cloud accounts you own or have written permission to test.

Difficulty ladder: read a public bucket → pivot with a leaked key → escalate IAM privileges → chain a full cloud attack path to the flag.

Blockchain and smart contracts

What it tests: vulnerabilities in smart contracts and blockchain applications, almost always on an Ethereum-style EVM chain. This category rewards anyone curious about how decentralized code fails.

Typical challenges: draining a vulnerable contract via reentrancy; integer overflow or underflow; unprotected functions and access-control failures; logic bugs in a token or vault; reading "private" on-chain data that was never really private.

Core techniques: reading and writing Solidity, interacting with contracts via web3 libraries, tracing transactions, and applying known smart-contract attack patterns.

Essential tools: Foundry, Remix, Web3.py or ethers.js, and a testnet node.

Start practicing: look for smart-contract tracks in live CTF7 events, and work locally against test chains, never real funds.

Difficulty ladder: read on-chain storage → call an unprotected function → exploit reentrancy → chain a multi-contract DeFi attack.

Hardware and radio

What it tests: physical devices, embedded firmware and radio signals. Common at in-person CTFs and DEF CON-style villages, this category often needs equipment, though many challenges ship as captured data to analyze offline.

Typical challenges: analyzing firmware dumps; decoding UART, SPI or I2C protocols from logic-analyzer captures; demodulating a software-defined radio (SDR) recording; JTAG debugging; side-channel and glitching puzzles; decoding RF, RFID or IoT protocols.

Core techniques: firmware extraction and analysis, serial-protocol decoding, signal processing and demodulation, and reading electrical waveforms.

Essential tools: binwalk and firmware tools, logic analyzers, GNU Radio and an SDR such as an RTL-SDR, and a multimeter and bus tools for live hardware.

Difficulty ladder: extract strings from a firmware image → decode a UART capture → demodulate an SDR recording → perform a live side-channel or glitch attack.

AI and prompt injection

What it tests: security of AI and large language model (LLM) applications. This is the newest category, and it has grown quickly as LLMs entered production. Expect to see it at more and more events.

Typical challenges: extracting a hidden system prompt or secret via prompt injection; jailbreaking a guardrailed model; indirect injection through data the model reads; exploiting an LLM agent's tools or plugins to reach a flag. Attacks on classic machine-learning models are covered in the machine learning section below.

Core techniques: crafting adversarial prompts, bypassing content and output filters, exploiting the trust boundary between instructions and data, and abusing tool-use and retrieval in LLM agents.

Essential tools: creativity and a systematic prompt methodology, plus scripting to automate attempts against an API.

Start practicing: try AI tracks in live CTF7 events; the OWASP Top 10 for LLM Applications frames the risks.

Difficulty ladder: ask the model directly → bypass a simple output filter → defeat layered guardrails → exploit an agent's tools or an indirect injection chain.

Machine learning

What it tests: the security of machine-learning models and the pipelines around them, beyond chat-style LLMs. Where the AI category is mostly about manipulating a model with words, ML challenges ask you to reason about the model itself: its inputs, its training data and the files it ships in.

Typical challenges: nudging an image so a classifier mislabels it (an adversarial example); working out whether a record was part of a model's training set (membership inference); reconstructing a simple model by querying it (model extraction); finding the trigger that activates a backdoor in a poisoned model; recovering a flag encoded in a model's weights; spotting why an untrusted model file is unsafe to load.

Core techniques: understanding how a model turns input into a prediction, querying a model systematically and recording the results, basic linear algebra and statistics, and inspecting model files in a sandbox rather than loading them blindly.

Essential tools: Python with NumPy, scikit-learn and PyTorch or TensorFlow, plus Jupyter notebooks for experiments.

Where to read more: MITRE ATLAS catalogs real attack techniques against ML systems and is a good map of the category; the OWASP Machine Learning Security Top 10 frames the risks.

Difficulty ladder: read a flag out of model metadata → flip a simple classifier's output → infer training-set membership → find and trigger a hidden backdoor.

Legal

What it tests: knowledge of the laws, regulations and agreements that shape security work. It is the rarest category on this list, but it appears at events aimed at incident responders and CSIRTs.

Typical challenges: reading a fictional incident and identifying which reporting obligations apply, for example the deadline for reporting a given incident type under a national CERT's published directions; finding the clause in a scope document that puts a test out of bounds; naming the section of a statute that covers unauthorized access; spotting an open-source license violation in a project; deciding which data-protection regime applies to a breach. The answer, such as a section number or a deadline, is the flag.

Core techniques: reading primary sources rather than summaries, citing precisely, telling jurisdictions apart, and understanding scope and rules of engagement, the same documents that make CTFs and bug bounties legal in the first place.

Essential tools: official legislation databases such as India Code for the IT Act 2000 and the Digital Personal Data Protection Act 2023, EUR-Lex for the GDPR, and the published guidance of national CERTs.

Difficulty ladder: look up a single defined term → match an incident to the right obligation → reconcile two jurisdictions → work through a multi-step scenario with conflicting duties.

Legal challenges teach awareness, not legal advice. Our guide to CTFs vs bug bounties covers why authorization matters before you test anything outside a CTF.

King of the Hill and attack-defense as categories

What it tests: sustained offense and defense against live opponents, rather than a one-time solve. King of the Hill (KotH) and attack-defense (A/D) are normally whole competition formats, explained in our CTF formats guide. Some scoreboards also treat them as categories so they can sit on a mixed board.

How it looks on a board: a KotH tile points players at a shared "hill" machine, and points accrue for every interval a team holds it. An A/D tile gives each team its own copy of a vulnerable service, a vulnbox, scored every round on flags stolen, flags defended and whether a checker confirms the service still works. In both cases the score comes from a game engine, not from a single flag submission. Our guide to CTF scoring works through both models.

Core skills: fast enumeration, hardening and patching without breaking functionality, monitoring for intruders, automation that runs all event long, and team coordination.

Who it suits: intermediate and advanced teams, and conference crowds watching a live hill change hands. See how CTF7 runs managed King of the Hill and attack-defense events.

CTF categories at a glance

Use this table to decide where to start and to plan which categories your team needs to cover.

Which category should you start with?

Try all of them once, then specialize based on what you enjoy and your existing strengths:

• If you like puzzles and math: cryptography.
• If you like building and breaking apps: web exploitation, the most job-relevant category.
• If you like understanding how things work deep down: reverse engineering, then pwn.
• If you like investigation: forensics, steganography and OSINT.
• If you enjoy coding contests: PPC, then misc scripting challenges.
• If you work with the cloud, Web3, LLMs or ML models already: lean into cloud, blockchain, AI or machine learning.
• If you're heading toward incident response or GRC: try a legal round alongside forensics.

A strong team has at least one player for each category. Practice on Ouroboros CTF, build skills in War Zone operations (see pricing), then test yourself in live events. The practice roadmap sequences it all by category. If you're building a team, our guide on how to build a CTF team shows how to split categories between players. When you're ready to run your own competition, our guides on how to host a CTF and on competition formats will help you balance a challenge board across these categories.