Cisco 350-201 CBRCOR study materials
Cisco 350-201 CBRCOR study resources

Beaconing Developer Workstation and a Shared Build Server

Cisco 350-201 CBRCOR · Put your knowledge to work in context.

All case studies

Beaconing Developer Workstation and a Shared Build Server

At 11:40, Zeek and proxy logs show workstation 10.20.4.77 making HTTPS POSTs every 63 seconds with about 1.2 KB of jittered payload to a domain registered 11 days ago. EDR reports node.exe, which is signed and expected on developer machines, spawning powershell.exe -enc with a base64 command line; the parent process is a scheduled task created at 02:10. The user is on PTO and last logged in interactively two days ago. The workstation has local admin and access to a shared build server. Proxy logs show three other workstations contacting the same domain, but only one with regular beaconing. The SOC has full packet capture at the perimeter for 72 hours, EDR telemetry, and NetFlow, but no DHCP logs. The team must decide whether to block the domain at the proxy and whether to isolate the workstation.

1. State two competing hypotheses and the evidence that would distinguish them.

Read the worked answer

Hypothesis A: malicious command-and-control. The 63-second interval, jitter, small POST size, recently registered domain, scheduled task at 02:10, and encoded PowerShell fit beaconing. The user being on PTO weakens a legitimate interactive explanation.

Hypothesis B: developer tooling or an update check. Node.js applications sometimes spawn PowerShell for build scripts, and a scheduled task can be legitimate. A small periodic POST to a new domain could be telemetry from a package or internal test.

Distinguishing evidence: decode the base64 command line and inspect its behavior; check the scheduled task author, creation time, and action; examine the parent process tree for node.exe; review TLS SNI and certificate details in the 72-hour packet capture; compare payloads across beacons for structure; and check whether the other three workstations show the same scheduled task or command line. If the decoded command downloads or executes code, Hypothesis A strengthens. If it invokes a known internal build utility and the domain resolves to a corporate service, Hypothesis B is more likely.

2. Would you block the domain at the proxy immediately? Explain the trade-offs.

Read the worked answer

Not as the first action without preserving evidence. A proxy block can stop exfiltration and limit other hosts, but it also tips the attacker, who may rotate domains or switch to a backup channel. It can also break the packet capture if the block is applied before the 72-hour window is exported.

A reasoned sequence is: export and hash the relevant packet capture, isolate 10.20.4.77 with EDR network containment rather than shutdown, then apply a proxy block with full logging and a sinkhole response if possible. Keep the block scoped and time-limited. Because three other workstations contacted the domain, blocking at the proxy protects them while the team determines whether they are benign or additional victims. If the domain is shared with a legitimate service, blocking causes an outage; verify TLS certificate and SNI first. The trade-off is containment speed versus intelligence value, and in this case the regular beaconing and PTO user justify containment after a quick evidence snapshot.

3. What containment order for the workstation and build server, and what evidence should be preserved?

Read the worked answer

Contain the workstation first by EDR network isolation, not power-off, because it is the active beaconing host and its memory holds the injected process and scheduled-task context. Capture memory, the scheduled task XML, the decoded PowerShell command, and the EDR process tree. Then check the build server for sessions or artifacts from the workstation before isolating it; the build server is higher impact and should not be taken offline blindly.

If the workstation has credentials or SSH keys used against the build server, rotate those credentials and review build logs for unauthorized jobs or artifacts. Preserve perimeter packet capture for the workstation IP, Zeek logs, proxy logs, NetFlow, and EDR telemetry. Export before containment changes traffic. After containment, examine the other three workstations with the same domain in proxy logs and compare scheduled tasks and command lines. Document each action with timestamps so the sequence of containment and evidence collection is defensible.