Protocol Exploitation Assessment

---
name: protocol-exploitation-assessment
description: "Assesses network protocol exploitation candidates while separating observed service behavior, advisory applicability, reproduced faults, demonstrated impact, authorization, disruption risk, telemetry, and coverage. Use when a banner, scanner result, packet trace, reset, legacy protocol, or suspected handshake weakness needs a defensible validation plan."
allowed-tools: Read Grep Glob
---

# Protocol exploitation assessment

A banner can identify a candidate. It cannot prove the running implementation,
patch state, vulnerable behavior, or security impact. Preserve each proof layer.

This skill plans and records assessment. It does not provide exploit commands,
payloads, credentials, poisoning, relay, coercion, replay, fuzz cases, or target
contact.

## When to Use

- A banner, scanner result, packet trace, reset, legacy protocol, or suspected handshake weakness needs a defensible validation plan.
- Use only within explicit authorization and the stated rules of engagement.

## When NOT to Use

- Do not treat this skill as permission to access, test, or change a target.
- Do not convert missing evidence into a clean result or a stronger claim.

## Workflow

1. Record exact targets, assessment window, disruption ceiling, signal ceiling or
   null, and written authorization by action class. Preserve approval gates and
   prohibitions separately.
2. Inventory each service from evidence. Keep transport reachability, protocol
   identity, implementation identity, version, configuration, and patch state as
   separate claims. Unknown stays null.
3. Store evidence provenance, trust, bounded or unknown time, subject, summary,
   and limitations. Historical notes and scanner labels remain low-trust context.
4. Classify candidates by protocol weakness family. Link advisories without
   equating a version-range match with applicability.
5. Separate candidate proof into: service observation, weakness evidence,
   reproduced behavior, and demonstrated impact. A socket reset needs independent
   service-health or crash evidence before it can prove a fault.
6. Define possible next actions by class, target, prerequisites, disruption,
   request count, expected telemetry, stop conditions, authorization, and cleanup.
7. Derive action state and candidate state. Recommend the lowest
   cost authorized action whose prerequisites are met and that adds evidence.
8. Mark a candidate finding-ready only after the weakness is demonstrated. Keep
   advisory matches and leads in the open-work ledger.
9. Cover service identity, implementation state, authentication, cryptography,
   state machine, input handling, disclosure, and telemetry/recovery for every
   service. Blocked and not-applicable work remains visible.

## Boundary with adjacent skills

- Use `network-recon` to discover hosts and services before assessing candidates.
- Use `protocol-traffic-analysis` to interpret supplied packet captures without
  active validation.
- Use `binary-fault-triage` for crash and binary-analysis depth after a
  reproducible protocol fault exists.
- Use `binary-fault-validation-readiness` to decide whether a confirmed fault has the
  prerequisites for exploit development.
- Use `findings-report` after this skill marks a candidate finding-ready.
- Use `detection-validate` when the objective is proving a detector rather than
  finding protocol weaknesses.

## Rationalizations to reject

- **"The version is in the affected range."** Vendors backport fixes and banners
  lie. This proves a match, not the running code's vulnerability.
- **"The connection reset, so the service crashed."** A peer, proxy, timeout, or
  parser rejection can reset one socket while the service stays healthy.
- **"The scanner says vulnerable."** Preserve the scanner output as a lead and
  inspect what evidence the check actually collected.
- **"A protocol is legacy, so exploitation is proven."** Legacy posture can be a
  real exposure without proving a particular attack path.
- **"Fuzzing is just another request."** Mutation campaigns have aggregate load
  and outage risk that require explicit authorization and recovery controls.
- **"No alert means the test was quiet."** Unknown sensor health and an unreviewed
  query window cannot support a detection conclusion.
- **"Production is the only realistic validation."** A faithful lab, build
  provenance, or configuration record may answer the question with less risk.