CCSM Elite R82 study materials
CCSM Elite R82 study resources

03:40 Beaconing: Containment, Evidence and Backups

CCSM Elite R82 · Put your knowledge to work in context.

All case studies

03:40 Beaconing: Containment, Evidence and Backups

At 03:40 the EDR platform raises three related detections across a 2,400-endpoint estate: a signed-but-unusual binary beaconing to a rare external address every 60 seconds on a file server, on a domain controller, and on an engineering workstation. NetFlow shows 4.2 GB outbound to that address in the last six hours. The backup service account has interactive logon events on two of the three hosts, and that account is used for the nightly backup to an on-premises NAS that is joined to the domain. The NAS has no immutable or offline copy and was last restore-tested 11 months ago. Three manufacturing plants run at an average downtime cost of $40,000 per hour, and the CEO is on the bridge insisting production stays up. The incident-response retainer activates in six hours. Sixty percent of IT staff are remote, and the VPN concentrator logs into the same SIEM the attacker may have touched.

1. Containment decision: in what order do you act in the first 60 minutes, and do you stop production?

Read the worked answer

Assume domain admin is already lost - a compromised domain controller plus interactive use of a privileged service account justifies it - and act in an order that reflects that.

  1. Open the bridge and start the clock. IR lead, IT operations, plant engineering, legal, communications. Six hours to the retainer is a long time; do not spend them discovering nobody has the vendor's after-hours number.
  2. Contain identity before hosts. Disable the backup service account, force logoff, rotate its credential and everything it could read. If the domain controller is genuinely compromised, plan the krbtgt double reset and DSRM password change. That is containment, not evidence destruction, and it is the highest-value action available at 04:00.
  3. Isolate the three hosts through EDR network containment, not by pulling cables. Containment keeps the agent and process tree alive for triage and preserves memory. If the engineering workstation drives plant tooling, confirm the dependency with the plant lead first and quarantine the VLAN instead.
  4. Block the destination at egress and hunt the same beacon signature across all 2,400 endpoints and in DNS and proxy logs.

Production: do not stop the plants on heartbeat alone, and do not keep them running on reassurance. The test is dependency - which plant systems authenticate to the domain, and can they run for four hours without it? Get that answer in writing from plant engineering on the bridge. Stop production if evidence shows the attacker has reached the manufacturing segment, or if identity containment will break plant authentication.

What not to do: mass-reset 6,200 user passwords before you know the entry vector. You will lose the ability to distinguish the attacker's logons from the noise of the reset.

2. What evidence do you preserve, in what order, given the attacker may hold domain admin and the SIEM is suspect?

Read the worked answer

Preserve most-volatile first, and preserve before you change state.

  1. Memory from the three hosts - via EDR capture or a forensic tool - before isolation completes and absolutely before any reboot. Process trees, injected code and in-memory credentials exist nowhere else.
  2. Live network state: connection tables, DNS cache, ARP. EDR containment preserves these if you capture first, so capture first.
  3. Telemetry exported off the estate: full EDR feed, proxy and NetFlow records, VPN concentrator logs - copied to storage you control, not to the domain-joined SIEM. Take the raw feed, not dashboard screenshots.
  4. Domain controller artefacts: security event log, NTDS.dit with SYSTEM and SECURITY hives, SYSVOL, and the recent history of admin-group and GPO changes. Assume the attacker read them; you still need the baseline.
  5. Chain of custody: hashes, collector identity, timestamps and storage location. If this ends in regulatory inquiry or litigation, the record of who touched what matters as much as the artefacts.

Handling the constraint: capturing full memory from three hosts may take longer than the CEO wants. Do it for the domain controller and the file server regardless; for the workstation, an EDR process-and-memory snapshot may be enough. Document what you chose not to capture and why - that decision will be reviewed afterwards.

Do not reimage a host to clean it before capture, and do not let an IR vendor overwrite the EDR telemetry source before it has been exported. Tell the vendor explicitly that logs are evidence and must be preserved in place.

3. Can you rely on the domain-joined NAS for recovery? Describe the restore sequence and what you tell the CEO.

Read the worked answer

No. Treat every backup as potentially encrypted or poisoned until verified from a clean host. The NAS is domain-joined, the backup credential is the service account seen in interactive use on compromised hosts, and the set has never been restore-tested. The attacker had motive, means and six hours or more.

Sequence:

  1. Protect what exists. Remove the backup account's rights, rotate credentials, take the NAS off the domain or block its management path, snapshot it if the platform allows, and suspend scheduled jobs so the last known-good set is not overwritten.
  2. Verify before restoring. Mount a copy in an isolated environment from a clean management host and scan the restored data. Check backup catalogue integrity and the age of the last successful full backup - if the attacker was resident for days, the most recent 'good' set may already contain persistence.
  3. Rebuild, do not clean. Domain controllers from known-good media with krbtgt reset, then file servers, then endpoints in order of plant criticality. Restore data into the rebuilt estate, not the other way round.
  4. Time-box a real test. The 11-month-old restore test proves nothing about full-estate recovery. Restore the top three business-critical systems on the bridge and publish the measured recovery time.

To the CEO: recovery time for the estate is currently unknown because the backup environment is inside the compromised trust boundary and untested. That is a business risk with a cost per hour attached, and it needs a decision now - accept an extended outage, or authorise restoring from a verified subset with a documented data-loss window.

Findings afterwards: an immutable or offline copy, separate credentials outside the domain, and a restore test in the SLA with evidence.