Skill redlog pentest

redlog-pentest

You are running under a RedLog project. RedLog is a tamper-evident audit log for offensive security work. Two planes: hooks record (every Bash command is already captured passively via a PostToolUse hook — that's the logging), and MCP operates the app (assert identity, confirm scope, mark findings, anchor the chain). Your job through this skill is the control-plane part: use MCP for what the hooks can't do, and never re-log over MCP what a hook already captured.

Install once: copy this file to ~/.claude/skills/redlog-pentest.md (or .claude/skills/redlog-pentest.md inside a project).

---

Prerequisites — hooks first

Set these up in this order. The hook is what actually guarantees capture; the MCP server only adds the agent-initiated actions on top.

1. RedLog is running (Electron app open, a project selected).
2. PostToolUse hook installed (Settings ▸ Hooks ▸ Claude Code — one click). This is the priority. It passively logs every Bash command whether or not you remember to — the one thing an audit log cannot afford to miss.
3. MCP server registered (once, per host) — for operating the app. RedLog hosts MCP over HTTP, so it's live whenever the app is open. Set it up in Settings ▸ Team & Integrations ▸ MCP Server, then:

   claude mcp add --transport http redlog http://127.0.0.1:6660/mcp --header "Authorization: Bearer <mcp-token>"
   

If the hook is missing, say so — capture is degraded and you must not rely on MCP to make up for it (you will miss commands). If only the MCP server is missing, hooks still capture everything; you just lose markers and scope checks. Either way, tell the operator once and continue rather than blocking work.

Rule of thumb for the whole session: if a hook can capture it, let the hook capture it — never log it again over MCP. Use MCP only for what no hook can do (identity, scope decisions, findings, loot scans, chain anchoring, and non-shell observations).

---

Session start (always, first turn)

Call these in this order. If any of them errors, tell the operator and stop calling RedLog tools for the rest of the session — do NOT retry silently.

1. redlog_whoami — confirms which operator token you inherited. If the returned operator.name is not who the human said they are, warn them: someone else's token is loaded.
2. redlog_status — check IP safety (ip.ipSafety === "exposed" means VPN is off; ask before doing anything network-touching), event count baseline, and violation count.
3. redlog_scope — memorize targets and excludeTargets. If the list is empty, warn: "No scope configured. RedLog will not flag out-of-scope activity." Ask the operator to define scope before recon.

Print a one-line summary of these three to the user, e.g.

Operator: guan (primary) · VPN: safe · Scope: *.example.com, 10.0.0.0/24 · 1247 events, 0 violations.

---

During the engagement

Every Bash command

The hook already logs it. Do not call redlog_log_event for shell commands you ran through Bash — that produces a duplicate.

Every finding worth writing home about

Call redlog_mark with a clear title, one-paragraph notes, correct severity, and the target. Do this in real time, not at the end:

redlog_mark({
  title: "Reflected XSS in /search?q=",
  notes: "Payload: <svg onload=alert(1)>. WAF strips <script> but not <svg>. Persistent across sessions. Auth not required.",
  severity: "high",
  target: "www.example.com"
})

Severity guide (use these, don't hedge):

• critical — RCE, ATO, full DB access
• high — auth bypass, stored XSS, IDOR on sensitive data
• medium — reflected XSS, open redirect, info disclosure
• low — misconfiguration, verbose errors, missing headers
• info — phase change, environment note, decision log

Bookmark endpoints you want to return to

redlog_quickmark({ title: "Admin panel", url: "https://admin.example.com/login", note: "creds tried: guest:guest fail" })

Scan raw output for secrets before pasting it back to the user

Any time a tool dumps a config file, response body, JWT, or process env, run it through the detector first:

redlog_loot_scan({ text: "<paste raw output here>" })

Findings auto-become loot events on the timeline.

Screenshot on demand

redlog_screenshot({})

Log something the shell hook can't see

Non-Bash actions (browser fills, GUI clicks, external tool output you paste in):

redlog_log_event({
  agent_type: "agent",
  data: { subtype: "manual_observation", note: "Admin UI accepts empty CSRF token" },
  target: "admin.example.com"
})

---

Scope violations

If a command you're about to run touches something not in scope.targets (or hits excludeTargets): stop and ask. Do not just log a mark — you need explicit confirmation before running out-of-scope actions. Then log the exchange:

redlog_mark({
  title: "Operator authorised probe of api-staging.example.com",
  notes: "Not in original scope. Confirmed in-chat 2026-07-28.",
  severity: "info",
  target: "api-staging.example.com"
})

---

Session end (always, last turn)

Before you sign off, in this order:

1. redlog_chain_status — confirm the chain length grew this session.
2. redlog_chain_anchor_now — submit the current chain head to OpenTimestamps calendars right now, so anything from this session is timestamped in-session (don't rely only on the hourly loop).
3. Print the returned anchor status. If status === "failed" or "partial", tell the operator to re-run redlog_chain_anchor_now later when network is better.

---

Handoff to a teammate

If someone else is taking over the session on their own machine:

1. Open RedLog ▸ Settings ▸ General ▸ Operator Tokens ▸ Add operator — give the teammate their own token.
2. Show the token once — copy it, don't screenshot it.
3. Teammate puts it in ~/.redlog/api-token on their machine (overwrite existing) and re-launches whatever hooks they use.
4. From that moment on, every event they generate is attributed to their operator id — mixing you and them in the same timeline is exactly what audit logs are for.

Do not share the primary operator's token. It rotates every session anyway.

---

What to avoid

• Do not call redlog_log_event for commands the Bash hook already logs — check the hook's subtype: claude_code_bash events first.
• Do not try to change operator_id inside data — it's overridden server-side from your token.
• Do not paste API tokens, session cookies, or SSH keys into redlog_log_event.data unredacted. Run through redlog_loot_scan first; it will detect and store them separately with proper markers.
• Do not anchor the chain more than once every few minutes — calendars are shared public infrastructure.
• Do not decide something is "out of scope, so we won't test it" without a marker. Log the decision so the client's report shows exactly what you refused and why.

---

Reference

• HTTP API + tool schemas: docs/agent-integration.md
• Operator token lifecycle: docs/operators.md
• Evidence chain + OTS verification: docs/audit-trail.md