Protocol Exploitation Assessment

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.