/covert-channel-assessment

name: covert-channel-assessment
description: "Assesses covert-channel and data-egress exposure, then plans or records bounded purple-team validation with synthetic data. Use when evaluating DNS, web, cloud, ICMP, tunnel, timing, steganographic, or dead-drop paths without turning a plausible route into a claim of successful exfiltration."
allowed-tools: Read Grep Glob

Covert channel assessment

A permitted protocol is not a working covert channel. A working channel is not automatically undetected. Keep route feasibility, execution proof, detection outcome, and data custody as separate claims.

This skill assesses supplied evidence and bounded synthetic tests. It does not provide payloads, encodings, tunneling commands, evasion settings, C2 design, pivoting, persistence, credential use, third-party abuse, or authority to move real data.

When to Use

• Evaluating DNS, web, cloud, ICMP, tunnel, timing, steganographic, or dead-drop paths without turning a plausible route into a claim of successful exfiltration.
• 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 the written authorization, exact sources, assessment window, approved receivers, synthetic marker hash, byte and duration ceilings, prohibited data, services, and actions. Receiver ownership and authorization are different facts. 2. Inventory evidence with source, locator, honest time precision, and integrity hash for copied artifacts. Use null time fields when the source supplies no observation time; the assessment window is not evidence time. Preserve unknowns; do not invent throughput, queries, alerts, endpoints, accounts, transfer times, or successful delivery. 3. For every source, assess all eight approved channel families. Keep a family unknown or blocked when evidence is absent or testing is prohibited. 4. Treat `plausible` as a route hypothesis. Use `validated` only after an authorized test records the approved marker, receiver, exact bounded times, observed bytes, source evidence, and receiver-side delivery evidence. 5. Describe capacity as `unknown`, `estimated`, or `measured`. Only an executed test can produce measured throughput. Baselines describe normal traffic, not covert channel capacity. 6. Inventory telemetry by source, health, retained fields, window, and limitation. Packet counts do not prove payload inspection; process telemetry does not prove delivery; a detection rule does not prove an alert fired. 7. Predeclare a detection check for every planned or executed test. `not-detected` requires healthy telemetry queried across the entire test window. An absent alert without that evidence is `inconclusive`. 8. Enforce byte and duration ceilings per test and in aggregate per source. Keep blocked or prohibited paths visible; do not force a transfer to complete coverage. 9. Track marker creation, source staging, receiver storage, retention, and destruction for every planned or executed test. A synthetic marker still has a custody trail. 10. Link medium-or-higher channels to an owned response: validate safely, improve telemetry, tighten egress, or accept the documented risk.

Interpretation rules

• An allowed port proves a route control state, not delivery, throughput, or stealth.
• Encryption protects content. It can increase entropy and does not erase volume,

timing, destination, process, or policy observables.

• A normal-volume test can validate content or rule coverage. It cannot prove that a

larger transfer would blend into the baseline.

• A blocked path can be a successful control result without becoming a validated

channel.

• Receiver logs prove delivery only for the receiver, marker, source, and window they

identify. They do not prove endpoint cleanup.

• Detection requires an alert or documented analytic result. Visibility means the

telemetry existed; the two are not interchangeable.

• A `not-detected` result is a real gap only when the expected telemetry was healthy

and fully queried. Otherwise the result is inconclusive.

Boundary with adjacent skills

• Use `protocol-traffic-analysis` to interpret supplied captures without transmitting.
• Use `detection-validate` for the broader ATT&CK technique coverage map.
• Use `detection-engineering` to build or tune the detector itself.
• Command-and-control architecture design is outside this collection; this skill

owns bounded channel exposure and detection validation only.

• Use `opsec-planning` for a red-team operation's full artifact and detection-risk plan.
• Use `findings-report` for final finding prose.

Rationalizations to reject

• **"Port 443 is open, so HTTPS exfiltration works."** A route still depends on the

proxy, allowlist, receiver, authentication, content controls, and actual delivery.

• **"No alert fired, so the channel is covert."** Without healthy telemetry and a

complete query, silence is an unknown observation.

• **"The file is synthetic, so the transfer limits do not matter."** The exercise can

still disrupt systems, trigger incidents, or teach the wrong control conclusion.

• **"Encryption makes the transfer invisible."** Metadata, volume, timing, process,

destination, and policy observables remain.

• **"We should try every channel to prove coverage."** Blocked and prohibited paths

are honest results; execution must stay inside the rules of engagement.

• **"A receiver log proves cleanup."** Delivery, source deletion, receiver deletion,

and retention are separate evidence.

• **"A complete record authorizes the test."** It validates the record. Written authority

and the operator govern execution.