Beacon on a Developer Laptop During a Red Team Window
EDR on DEV-WS-014, a developer laptop in the platform engineering subnet 10.30.8.0/24, records rundll32.exe spawned by outlook.exe at 02:14 on a Saturday, followed by a TLS session every 60 seconds with roughly 15% jitter to a domain resolving to 185.199.x.x, a hosting range with a poor reputation. The JA3 fingerprint matches a known Cobalt Strike malleable profile published last year. A red team engagement is active: the rules of engagement authorise 10.30.8.0/24 on weekdays between 08:00 and 18:00, and the agreed asset list names DEV-WS-011, DEV-WS-012 and DEV-WS-013. The red team lead is unreachable until Monday. Two other hosts, DEV-WS-019 and DEV-WS-021, resolve the same domain but show no matching process chain. The CISO wants the laptop reimaged immediately.
1. Weigh the conflicting signals and state precisely what you can and cannot conclude at this point.
Read the worked answer
Two hypotheses fit parts of the evidence and neither fits all of it.
Sanctioned red team: the subnet is authorised, the beacon shape and the JA3 match are consistent with a commercial C2 framework, and jitter is a deliberate evasion technique a red team would configure. Against it: the host is not on the agreed asset list, the timing is 02:14 Saturday against a weekday 08:00–18:00 window, and the initial access vector is an Outlook-spawned rundll32 - red teams rarely phish the client's own staff outside the agreed window without deconfliction, and a two-host deviation from an asset list is a bigger deviation than a single typo.
Actual intrusion: a macro or COM-hijack chain from Outlook to rundll32 is a textbook loader, the destination has poor reputation, and two other hosts touch the same domain.
What you can conclude: an unauthorised C2-shaped channel is running on a corporate endpoint outside every declared parameter. What you cannot conclude: attribution. The JA3 fingerprint is a published hash - it identifies a tool, not a team, and any copycat or commodity loader using the same profile produces the same match. You also cannot conclude the other two hosts are compromised; a DNS resolution with no process chain may be a browser prefetch or a resolver cache artifact.
The only defensible position at this point is 'probable unauthorised compromise, red team involvement plausible but unconfirmed' - and proceed as though it is real while deconflicting in parallel.
2. What verification steps would you run in the next 30 minutes that could actually change the disposition?
Read the worked answer
Only steps whose outcome flips the decision are worth the 30 minutes.
- Deconfliction channel, not the lead's phone. Red teams leave a duty contact and a shared log or ticketing channel precisely for this. Check whether a deconfliction request or notification was filed for DEV-WS-014 or for an out-of-window test; check the red team's shared drive or ticket queue for a scope amendment. A 30-second check here is worth more than an hour of analysis.
- DNS resolver logs for the other two hosts. Did they merely resolve, or did they connect and send bytes? A connection with payload turns two hosts into a scope question; a bare resolution does not.
- The Outlook message itself. Sender domain, external versus internal origin, attachment hash and whether that hash appears on any other endpoint. An external phish points away from red team; an internally sent message with a signed red team artefact points toward it.
- The rundll32 command line and loaded module path. A DLL in %APPDATA% or %TEMP% with no signature and fleet-wide prevalence of one is not a sanctioned tool deployment.
- Whether the host is domain-joined and recently rebuilt, and whether the beacon's TLS certificate names a domain consistent with the red team's declared infrastructure.
Anything else - full disk forensics, malware reverse engineering - can wait until the machine is contained.
3. The CISO orders an immediate reimage. Explain why that is the wrong first move and give the containment you would argue for instead.
Read the worked answer
Reimaging destroys the only evidence that answers the questions the CISO will ask next week: how the host was compromised, what the beacon was configured to do, and whether it spread.
- Root cause lost. The Outlook message, the dropper, and the injected code all live in memory and in the user profile. After a reimage you cannot tell a red team implant from a loader that also stole credentials.
- Scope lost. The beacon configuration contains its C2 list and often a tasking history. Without it, the other two hosts remain unresolvable ambiguity, and 'we reimaged the one machine' becomes an unsupportable assurance claim.
- Attribution lost. If this is the red team operating outside its agreed parameters, the reimage removes the evidence of that too, and the organisation loses the ability to hold anyone to the rules of engagement.
Argue for: EDR network containment on DEV-WS-014 immediately - it stops the channel while preserving memory. Block the domain at egress and on the resolver, and sinkhole it to catch any further lookups from the fleet. Preserve volatile data with a memory capture before anything else touches the host. Keep the machine powered and isolated pending the Monday deconfliction call, and escalate the scope deviation to whoever owns the red team contract, not only to the SOC. Reimage later, deliberately, with the image taken first.