How should command-and-control evidence be reported?¶
The practical answer¶
Command-and-control evidence should be reported by separating communication, tasking, execution and attribution.
The key evidential caution¶
The dangerous assumption is that contact with known malicious infrastructure proves full remote control by a named offender.
It does not.
A defensible report should state:
Key points¶
- which device or process communicated
- which destination was involved
- when communication occurred
- whether it repeated
- whether responses were received
- whether tasking was identified
- what local activity followed
- what attribution evidence exists
- what remains uncertain
Use precise language.
“The process made repeated connections to…” is different from “the offender controlled the device through…”
“The infrastructure had previously been associated with…” is different from “that group operated the server in this incident.”
Explain shared hosting, encryption, missing content and logging gaps where relevant.
Evidential limits¶
Do not treat threat-intelligence labels as direct evidence of personal identity.
Where the evidence supports only beaconing or attempted contact, say so.
Where commands and results are evidenced, state that clearly.
Practical interpretation¶
Where several conclusions rely on the same network event, avoid presenting them as independent corroboration. A threat-intelligence match, product alert and incident-ticket entry may all derive from one connection. The report should make that evidential dependency visible.
State whether the conclusion is based on content, metadata, resulting behaviour or intelligence association. Those are different evidential foundations and should not be presented as though they carry identical weight.
Confidence should follow the strongest supported layer rather than the most dramatic label.
Operational takeaway¶
Report command and control in layers, distinguishing network contact, automated beaconing, tasking, execution and offender attribution.