Skip to content
Skip to main content
Cyber Incidents & Offender Methods Technical Explainer

Does beaconing prove an attacker was actively controlling the device?

No. A beacon can be an automated check-in that receives no task, repeats old configuration or continues after an operator abandons the system.

Distinguish the control stages

Separate outbound request, server response, task delivery, command execution, result reporting and interactive control. Repeated requests support a configured channel; changing responses, decoded tasks or new local processes can support active tasking.

One task may trigger extensive automation, so resulting activity does not necessarily show a person remained present. Responsive, irregular commands that change after system output can support interactivity, but timing alone cannot.

Use metadata when content is unavailable

Preserve network data, endpoint process chains, malware configuration and decoded material where lawful and available. If encryption prevents content inspection, response sizes, timing and immediate process, file or account changes may support a cautious inference.

Repeated identical responses with no local effect may establish only automated contact. Keep that narrower conclusion visible in the timeline and reporting.

Key takeaway

Treat beaconing as evidence of an automated communication channel unless separate response and endpoint records demonstrate tasking or interactive control.

Reference: CIM-145Cyber Incidents & Offender Methods