SlipItIn/.github/skills/security-specialist/steering/attack-paths.md

Attack Path Tracing

Purpose

Map the exploitation path for a confirmed or suspected vulnerability. Starts from a finding, traces backward to entry point and forward to impact. Produces a realistic severity assessment based on actual exploitability — not theoretical worst-case.

When to Use

• A finding from steering/full-scan.md or steering/discovery.md needs severity validation
• Triaging whether a vulnerability is actually reachable
• Building proof-of-concept narratives for critical findings
• Disputing or confirming a severity rating

Step 1: Start from the Finding

Document the vulnerability anchor:

• What: The vulnerable code (file, line, function)
• Class: Injection, auth bypass, IDOR, SSRF, path traversal, etc.
• Primitive: What the attacker gains if this fires (read arbitrary data, execute code, escalate privilege)

Step 2: Trace Entry Point → Vulnerability

Work backward. How does attacker-controlled input reach the vulnerable code?

Map the chain:

Entry Point (HTTP route, message queue, CLI arg)
  → Input processing (parsing, deserialization)
    → Validation (what checks exist between entry and sink)
      → Intermediate transforms (encoding, type conversion, mapping)
        → Vulnerable code (the sink)

At each hop, document:

• What data flows through
• What transformations or filters apply
• Whether the attacker retains control over the data

If a hop breaks the chain (e.g., input is cast to integer before reaching SQL query), the path is dead. Document why and downgrade.

Step 3: Identify Prerequisites

What must be true for the attack to work?

Factor	Questions
Authentication	Does the attacker need a valid session? What role?
Network position	Must they be on the internet, internal network, localhost?
Application state	Does a specific condition need to exist (feature flag, data in DB)?
Race condition	Is timing critical? How tight is the window?
User interaction	Does a victim need to click/visit something?
Chaining	Does this require another vulnerability to be exploitable first?

Each prerequisite reduces exploitability. Stack them honestly.

Step 4: Map Impact Forward

From the vulnerable code, what happens when it fires?

Vulnerable code triggers
  → Immediate effect (SQL executes, file reads, command runs)
    → Data accessed/modified (what exactly)
      → Lateral movement possible? (pivot to other services, escalate)
        → Final impact (data breach, RCE, account takeover, DoS)

Be specific about impact scope:

• Single user's data vs. all users
• Read-only vs. read-write
• Contained to one service vs. cross-service pivot
• Persistent vs. one-shot

Step 5: Check Existing Mitigations

Before finalizing severity, verify what's already blocking this path:

• WAF/rate limiting — does it catch this payload pattern?
• Framework protections — auto-escaping, parameterized queries, CSRF tokens
• Network policy — is the target service isolated?
• Monitoring/alerting — would exploitation trigger alerts?
• Input validation upstream — is there a check we missed?

If mitigations exist, document them and assess residual risk. A mitigated path is still a finding (defense in depth matters), but severity drops.

Step 6: Assign Severity

Use this matrix — exploitability × impact:

	Critical Impact	High Impact	Medium Impact	Low Impact
Easy to exploit (unauth, no prereqs)	Critical	High	Medium	Low
Moderate (auth required, simple chain)	High	High	Medium	Low
Difficult (multi-step chain, race, internal network)	High	Medium	Low	Info
Very difficult (requires prior RCE, admin, physical)	Medium	Low	Info	Info

Impact levels:

• Critical — RCE, full data breach, complete auth bypass
• High — significant data exposure, privilege escalation, account takeover
• Medium — limited data leak, single-user impact, partial bypass
• Low — information disclosure, minor integrity issue

Step 7: Document the Path

Output format:

## Attack Path: <Title>

**Finding Reference:** <link to finding in scan DB>
**Final Severity:** <Critical/High/Medium/Low/Info>

### Chain

1. Attacker sends [specific input] to [entry point]
2. Input passes through [component] where [transform happens]
3. Reaches [vulnerable code] at [file:line]
4. Triggers [primitive] resulting in [immediate effect]
5. Attacker gains [final impact]

### Prerequisites
- [List each requirement]

### Mitigations Present
- [List what partially blocks this]

### Mitigations Absent
- [List what should exist but doesn't]

### Evidence
[Code snippets, data flow diagram, or PoC outline]

Step 8: Recommend Action

Based on the path analysis:

• Critical/High with easy exploit → Fix immediately, consider if already exploited
• Medium → Fix in next sprint, add detection
• Low/Info → Track, fix opportunistically
• Mitigated but structurally present → Harden, don't ignore. Mitigations fail.

Notes

• Real severity comes from the PATH, not the pattern. SQLi behind three auth gates and only reaching a public data table is not critical.
• Conversely, a "low-severity" IDOR that leaks all customer records is critical regardless of what the textbook says about IDORs.
• If you can't trace a complete path from entry to impact, the finding might be theoretical. Say so explicitly rather than inflating.
• Attack paths compound. Two medium findings that chain into a critical outcome should be reported as critical.