/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.