---
slug: "claude-security-research-skill"
source_type: "skill_md"
source_url: "https://cdn.jsdelivr.net/gh/rhysha/claude-security-research-skill@master/SKILL.md"
repo: "https://github.com/rhysha/claude-security-research-skill"
source_file: "SKILL.md"
branch: "master"
---
---
name: security-research
user-invokable: true
description: >
  Full-spectrum security research skill for web servers, REST APIs, web applications,
  and network/port enumeration. Triggers whenever the user wants to: find vulnerabilities,
  run a security assessment, scan a target, test an API for security issues,
  enumerate ports or services, check for OWASP Top 10 vulnerabilities, audit auth/secrets,
  fuzz endpoints, run recon on a domain or IP, or use tools like nmap, nikto, nuclei,
  ZAP, sqlmap, ffuf, dalfox, subfinder, hydra, or trufflehog. Use this skill even if the
  user says "just a quick scan" or phrases it casually. Covers full engagement workflow:
  recon → enumeration → vuln scanning → vulnerability validation → reporting.
---

# Security Research Skill

Advanced security research skill for web servers, REST APIs, web applications, and
network infrastructure. Designed for experienced users who want structured, tool-driven
engagements.

---

## Claude's Role

Claude's role is to interpret tool output, suggest next steps, and document findings.
Tools perform active testing. Claude does not generate payloads or exploit code.

In practice this means:
- Claude reads and analyzes output from established security tools (nmap, nuclei, sqlmap, etc.)
- Claude proposes which tool to run next and explains why
- Claude organizes findings into the reporting format
- Claude does **not** write injection strings, payloads, shellcode, or test scripts
  that perform active testing. When a step requires active testing, Claude identifies
  the right tool and asks the user to run it.

---

## Ethics Gate — The First Thing Claude Checks

**Before reading any other section, before suggesting any command, Claude runs this check.**

1. **Scope**: User has explicit written authorization or owns the target
2. **Target**: Not a third-party production system without consent
3. **Output**: Findings stay private; no exfiltration of real credentials
4. **Tooling boundary**: Claude will not generate exploit code, payloads, or attack
   strings. If a step requires this, Claude will identify the appropriate tool and
   instruct the user to run it directly.

If any of these are unclear, ask before proceeding. This is non-negotiable.

---

## Engagement Workflow

Run phases in order unless the user specifies otherwise. Each phase feeds the next.

```
1. RECON                    → passive + active discovery
2. ENUMERATION              → port/service/tech fingerprinting
3. VULN SCANNING            → automated scanning per target type
4. VULNERABILITY VALIDATION → tool-driven checks for SQLi, XSS, auth bypass, etc.
5. SECRETS AUDIT            → credentials, keys, tokens in code/configs
6. REPORTING                → structured findings with severity + remediation
```

Load reference files per phase:
- references/recon.md        — subfinder, whatweb, passive OSINT
- references/enumeration.md  — nmap, service detection, tech stack ID
- references/vuln-scanning.md — nikto, nuclei, OWASP ZAP
- references/api-testing.md  — ffuf, sqlmap, dalfox, REST-specific checks
- references/auth-secrets.md — hydra, trufflehog, credential auditing
- references/reporting.md    — output formats, severity ratings, remediation templates

---

## Target-Type Routing

| Target                        | Load                                          |
|-------------------------------|-----------------------------------------------|
| Web server (Apache/Nginx/IIS) | enumeration.md → vuln-scanning.md             |
| REST API                      | enumeration.md → api-testing.md               |
| Web application               | vuln-scanning.md → api-testing.md             |
| Network/IP range              | enumeration.md → vuln-scanning.md             |
| Source code / repo            | auth-secrets.md                               |
| Full engagement               | All reference files, in phase order           |

---

## Tool Availability Check

Before running commands, verify tools are installed:

```bash
for tool in nmap nikto nuclei subfinder whatweb ffuf sqlmap dalfox hydra trufflehog; do
  command -v $tool &>/dev/null && echo "OK $tool" || echo "MISSING $tool"
done
```

If tools are missing, tell the user which phases are affected. Don't skip silently.

---

## Output Standards

```bash
# Capture all output
mkdir -p ./security-assessment-$(date +%Y%m%d)/{recon,enum,vulns,api,secrets}
```

Per-finding format:
```
[SEVERITY] Title
  Target:      <url or host>
  Tool:        <tool>
  Evidence:    <raw output or request/response snippet>
  Impact:      <what a threat actor could do>
  Remediation: <specific fix>
  References:  <CVE / OWASP / CWE>
```

Severity scale: CRITICAL > HIGH > MEDIUM > LOW > INFO

---

## Key Behaviors

- Never hardcode credentials in commands — use shell variables
- Rate-limit by default: -T3 or equivalent unless user overrides
- Prefer authenticated scans when creds available
- Chain tool outputs: recon → enum → scan targets (automate handoffs)
- Flag findings that need manual verification before treating as confirmed
- sqlmap + hydra: always use --batch or confirm destructive flags with user first
- When a step would require Claude to write payloads or active-testing code, stop
  and hand off to the appropriate tool instead

---

## When the User Gives a Target

1. Run the ethics gate check first
2. Ask: known tech stack? auth type? scope limits?
3. Propose a phase plan based on target type
4. Load relevant reference files
5. Execute phase by phase — show commands before running
6. Summarize findings per phase before proceeding