Beacon
A beacon is the periodic check-in traffic sent from a compromised host to attacker infrastructure to collect commands. In red team operations the timing is the tradecraft: the interval, the random variation applied to it and the periods of silence are what decide whether the pattern is visible to a defender.
The model is pull rather than push. Nothing listens on the compromised host; it reaches out on a schedule, asks for work, executes it and returns the result. That direction of travel is what lets it work from inside a network with no inbound access, and it is why the traffic has to look like ordinary outbound traffic to survive.
Three settings do most of the work. The interval sets how long a defender waits between opportunities to see it. Jitter randomises that interval by a percentage so the callbacks stop landing on a clean multiple, which is the single characteristic that automated detection engineering keys on most reliably. A sleep or dormant period holds the implant silent for hours or days, trading responsiveness for the chance that a review window closes without it.
One naming warning for anyone reading a report: Beacon is also the proper name of the implant shipped with a specific commercial adversary simulation product, so the word can mean either the generic behaviour or that particular payload depending on the sentence. When we use it as a proper noun we say so. On an engagement the useful outcome is not that the callback succeeded but at which interval it became visible, which is the measurement that improves command and control detection, and it comes out of the red team work where callback tradecraft is tuned against the client’s own detection.