One Attempt per Account, and an EDR That Is Watching
Day 4 of a covert internal assessment at a 900-person insurer. You have a foothold on FIN-WS-114 from an approved macro document. Your C2 beacon was quarantined by the EDR after roughly four minutes; the macro persistence survived and you can re-run it, but every run raises a fresh alert to the SOC. Password policy, per the client's documentation: five failed attempts triggers a 30-minute lockout, counted per account. From an unauthenticated LDAP query you have 312 usernames following the first.last convention. The ROE prohibits denial of service, requires you to stop if you detect a SOC response, and permits credential attacks "in a controlled manner." A senior consultant proposes spraying "Spring2024!" against all 312 accounts in one pass.
1. Evaluate the proposed single-pass spray against all 312 accounts.
Read the worked answer
It is technically lockout-safe and operationally reckless - approve the technique, reject the execution.
Reasoning: One attempt per account stays under the five-attempt threshold, so the policy is not the constraint. The constraints are the ROE's "controlled manner" and the stop-on-SOC-response clause. 312 authentication attempts inside a short window is a textbook spray signature: Windows will log a burst of 4625s across many accounts, SIEM correlation will fire, and the SOC will respond - at which point the ROE obliges you to stop, so the noisy pass costs you the rest of the engagement for one password guess. It also generates helpdesk tickets from users who mistype later, which is a real-world disruption you were told to avoid.
Action: Narrow the target set to accounts with a plausible seasonal-password habit and the highest value (helpdesk, IT, finance approvers), spray one or two candidates at a low rate over an agreed window, and keep a timestamped spray log that proves you never exceeded the threshold. Halt on the first lockout or SOC alert.
2. The senior consultant wants to re-run the macro to re-establish the beacon. How do you decide?
Read the worked answer
Weigh detection cost against objective, not persistence against convenience.
Reasoning: Each run is a guaranteed, attributable alert. You already know the EDR catches this payload, so re-running is not an experiment - it is a repeated signal that trains the SOC on your tradecraft. The ROE's stop condition is keyed to SOC response, so repeated alerts may end the engagement. The question is what the beacon buys you: if the objective is domain admin and the workstation offers no path, persistence on FIN-WS-114 is worth little. If it does offer a path, get in and out rather than keeping a resident implant.
Action: Do not re-run the same payload. Confirm whether the SOC has actually engaged (ticket, isolation, password reset wave) via the deconfliction channel before proceeding. If continued access is needed, prefer living-off-the-land execution with signed binaries and existing administrative tooling, and time the activity against the client's stated detection windows. Document every alert you generated - the white team will compare notes at debrief.
3. What stop condition would you agree with the client before continuing, and why is it needed here?
Read the worked answer
A concrete, observable tripwire rather than a judgment call made under pressure.
Reasoning: "Stop if you detect a SOC response" is unworkable as written, because a covert test is designed so that the SOC's first move is invisible to you. Without a defined signal, the tester either ignores real responses (breaking the ROE and possibly disrupting the business) or stops on ambiguous noise (wasting the engagement). The ambiguity is the risk; resolving it in advance is the mitigation.
Action: Agree in writing on a deconfliction channel and a named white-team contact, and on what counts as a response: a host isolated by EDR, credentials reset mid-test, an out-of-band call from the client, or a specified alert count threshold. State that reaching any of these triggers a pause and a call, not an automatic end. Include the EDR alert volume you have already generated so the client can confirm the SOC saw it and chose not to act.