ctf-web

Routes authorized Web CTF challenges from observation to verified flag capture.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill ctf-web-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ctf-web
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/ctf-web
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill ctf-web-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Solving Web CTF challenges often devolves into random payload spraying with no record of what was tried or why. This Skill turns Web CTF solving into a disciplined, evidence-driven workflow: observe the target, route signals to the right attack technique, validate every hypothesis with controlled experiments, and converge on the flag with reproducible proof. ## Core Features & Use Cases - Signal-to-technique routing: Maps observed signals (JWT, SQLi hints, SSTI markers, file upload, SSRF, IDOR, GraphQL, WebSocket, and more) to the correct specialized hunting skill or knowledge base article, so you only pursue 1-2 shortest paths at a time. - Execution gating and scope control: Enforces PLAN_ONLY vs EXECUTE modes, scope binding, and authorization checks before any active request is sent to a target. - Structured evidence and flag validation: Separates INPUT, OBSERVED, HYPOTHESIS, CONFIRMED, and DEAD_END states, saves sanitized request/response evidence to case files, and only marks a challenge DONE when the flag is verified and reproducible. - Use Case: Given a CTF challenge URL with a login page and a JWT cookie, the Skill guides you to fingerprint the app, route the JWT signal to token-crypto analysis, run minimal true/false comparison probes, escalate to admin access, and document the full chain to the flag. ## Quick Start Give the agent your authorized CTF challenge URL, any provided credentials or source files, and the expected flag format, then ask it to solve the web challenge step by step with evidence.

Frequently Asked Questions about ctf-web

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I solve a Web CTF challenge step by step?

Start by observing the application through normal browser flow and low-cost HTTP requests, then map observed signals to one or two attack routes. Validate each hypothesis with minimal true/false comparison probes before escalating, and record evidence at every step until the flag is captured and verified.

What should I do first when given a CTF challenge URL?

First confirm the mode, target URL, flag format, scope, and allowed resources before sending any request. Then load the attack-network knowledge base, fingerprint the application, and identify the lowest-cost candidate locations where the flag might reside.

How is CTF web exploitation different from bug bounty testing?

CTF solving optimizes for the shortest verified path to a flag inside an authorized, scoped environment, while bug bounty work requires impact assessment and reporting standards for real targets. This Skill explicitly routes CTF tasks away from bug bounty methodology and never treats real targets as practice ranges.

When is it allowed to send active requests to the target?

Active requests are only sent in EXECUTE mode after the scope is bound, the target is confirmed reachable, and authorization is explicit. In the default PLAN_ONLY mode, the Skill only reads challenge materials and marks planned actions as PENDING without contacting the target.

What counts as a confirmed flag in a Web CTF?

A flag is confirmed only when it comes from the authorized target environment, the full request or command path to obtain it is documented, and at least one repeatable verification or raw response evidence exists. A confirmed vulnerability without the flag keeps the status at CONTINUE, not DONE.

What should I do when stuck on a web challenge with no progress?

Return to normal requests to verify methods, cookies, CSRF tokens, and real parameter names, then compare client-side display against server responses. Limit each hypothesis to two meaningful variants, record failures as dead ends, and switch to the lowest-cost adjacent node in the attack network.