What it is
What you may notice
-
Repeating, short network “check-ins” to odd domains/IPs (often over HTTPS or DNS)
-
Legit tools (PowerShell, PsExec) launched in strange ways
-
New services/scheduled tasks; security tools disabled or excluded
How it gets in
-
Phishing documents and fake installers
-
Exploited VPN/RDP or unpatched public apps
-
Stolen admin credentials from earlier malware
If you suspect Beacon (quick response)
-
Isolate the host from the network—don’t just kill the process.
-
Collect evidence first (memory, logs), then remove persistence (tasks/services).
-
Reset credentials from a clean admin box; rotate keys/tokens.
-
Hunt laterally—assume more than one foothold.
-
Engage your IR team; block C2 domains/IPs at the firewall/DNS.
Prevent it
-
Patch internet-facing systems; lock down or remove unused remote access.
-
Enforce MFA, least privilege, and admin “jump” workstations.
-
Monitor for beaconing patterns and unusual admin tool usage.
-
Use EDR with script logging (PowerShell, AMSI) and DNS filtering.
-
Train staff to spot phishing; test restores from offline backups.
Legitimate tool or intrusion?
Authorized use should match a written test scope, approved infrastructure, expected time window, and responsible operator. Beacon activity on an unexpected host or outside that scope should be handled as an incident. Process names and file hashes are weak evidence because operators can change payload format and network profiles.
Evidence and containment
- Isolate the host while preserving memory, process trees, network connections, and authentication logs.
- Identify the parent process, initial access path, privileges, and every account used from the device.
- Block confirmed infrastructure and hunt for the same behavior across endpoints and network telemetry.
- Rotate exposed credentials and review lateral movement, persistence, and data access.
Stopping one Beacon process does not remove another implant or backdoor. Compare its traffic with the broader command-and-control investigation checklist.