Overtimepog Greyhatcc Skills Cve Lookup

---
name: cve-lookup
description: Search, analyze, and correlate CVEs against target technology stacks with exploit availability assessment
---

# CVE Research and Analysis

## Usage
`/greyhatcc:cve <CVE-ID or product name or keyword>`

## Smart Input
`{{ARGUMENTS}}` is parsed automatically:
- **CVE ID** (CVE-2024-xxxx) → used for CVE lookup and exploit search
- **Finding ID** (FIND-001) → looked up in findings_log.md
- **Description** (free text) → used as search/filter query
- **File path** → read and analyzed directly
- **Empty** → error: "Usage: /greyhatcc:<skill> <identifier>"

No format specification needed — detect and proceed.


## Context Loading (MANDATORY)
Before executing this skill:
1. Load scope: `.greyhatcc/scope.json` — verify target is in scope, note exclusions
2. Load hunt state: `.greyhatcc/hunt-state.json` — check active phase, resume context
3. Load program files: `findings_log.md`, `tested.json`, `gadgets.json` — avoid duplicating work
4. Load memory: Check MEMORY.md for target-specific notes from previous sessions
5. Load recon: `tech_stack.md` — correlate CVEs with detected versions

## CVE Analysis Workflow

### Step 1: Search
- **By CVE ID**: Use MCP tool `greyhatcc_sec__cve_detail` for specific CVE
- **By product**: Use MCP tool `greyhatcc_sec__cve_search` with product name + version
- **By keyword**: Use MCP tool `greyhatcc_sec__cve_search` with vulnerability type

### Step 2: Enrich
For each CVE found:
- Get CVSS score and vector breakdown — understand each metric
- Search for exploits via `greyhatcc_sec__exploit_db_search`
- Search Shodan exploits via `greyhatcc_s__shodan_exploits_search`
- WebSearch for GitHub PoCs: `"CVE-YYYY-NNNNN" exploit PoC`
- Check for Nuclei templates: `"CVE-YYYY-NNNNN" nuclei template`

### Step 3: CVSS Interpretation

| CVSS Metric | Meaning for Testing |
|-------------|-------------------|
| AV:N (Network) | Exploitable remotely — highest priority |
| AV:A (Adjacent) | Needs network proximity — lower priority for remote testing |
| AC:L (Low) | No special conditions — straightforward exploitation |
| AC:H (High) | Needs specific config/timing — may not apply to target |
| PR:N (None) | No auth needed — can test unauthenticated |
| PR:L (Low) | Needs basic account — need test credentials |
| UI:N (None) | No user interaction — server-side exploitable |
| UI:R (Required) | Needs victim action — client-side attack |

### Step 4: Exploit Availability Check

| Availability Level | What It Means | Action |
|-------------------|---------------|--------|
| Public exploit on Exploit-DB | Ready to use or adapt | Download, test against target |
| Metasploit module exists | Automated exploitation | Use if in scope |
| GitHub PoC exists | May need adaptation | Review code, adapt for target |
| Nuclei template exists | Automated detection | Run nuclei with specific template |
| No public exploit | Theoretical only | NOTE: most programs reject "vulnerable library without working PoC" |
| Patch diff available | Can reverse-engineer exploit | Write custom PoC from patch analysis |

### Step 5: Version Correlation
Cross-reference detected versions from `recon/tech_stack.md`:
```
For each technology in tech_stack.md:
1. Extract exact version (e.g., "Apache 2.4.51")
2. Search CVEs for that product + version range
3. Check if detected version falls in affected range
4. If yes AND exploit available → HIGH priority testing target
5. If yes AND no exploit → add to gadgets as potential, low priority
```

### Step 6: Analyze
Delegate to `vuln-analyst` for deep analysis or `vuln-analyst-low` for quick assessment.

### Step 7: Output Format
```
## CVE-YYYY-NNNNN
**Severity**: CRITICAL (CVSS 9.8)
**Vector**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
**Description**: ...
**Affected**: Product X versions 1.0-2.3
**Target Version**: Product X 2.1 (detected in tech_stack.md)
**In Affected Range**: YES
**Exploits Available**: Yes - Exploit-DB #12345, Metasploit module, GitHub PoC
**Exploit Tested**: [YES/NO] — [result]
**Remediation**: Upgrade to version 2.4+
**Chain Potential**: [what this CVE provides if exploited: code_execution, file_read, etc.]
```

## State Updates
After completing this skill:
1. Update `tested.json` — record what was tested (asset + vuln class)
2. Update `gadgets.json` — add any informational findings with provides/requires tags for chaining
3. Update `findings_log.md` — log any confirmed findings with severity
4. Update hunt-state.json if in active hunt — set lastActivity timestamp