Spraying Into an Unknown Lockout Policy

In order of preference, and none of them involve discovering the threshold by locking out staff:

1. Ask. Email the engagement contact now, not Monday. 'We require the account lockout threshold, observation window, and counter reset window in writing before any credential testing. If unavailable, please provision one disposable test account and authorise us to lock it.' This is a two-minute request and it is the only zero-risk option.
2. Try reading it legitimately. net accounts /domain from the domain-joined workstation works with a domain logon context; a local admin token usually will not. Attempt it once - it is a read, not an attack - and record the failure rather than working around it.
3. Empirical, on a designated account only. With written approval, take the client's test account and fail authentication until it locks, counting attempts. Record the number, ask them to unlock it, then apply that threshold company-wide minus a safety margin. Costs one test account and one helpdesk ticket.
4. Never infer the threshold from the real 300. The first you would know is 15 staff locked out on a Monday morning, which is both a production incident and an unauthorised availability impact under most RoEs.

If the client cannot answer before the window, postpone the spray and use the two hours on the six workstations and the local admin password.

One password, all users, spaced so no single account can ever see a second attempt inside the observation window.

Constraints and arithmetic:

• 300 users, 120-minute window. A safe rate is one attempt per user per 30 minutes, so one full pass maximum - 300 attempts over two hours is 2.5 per minute, comfortably under any WAF/IPS threshold and far under the lockout risk.
• Implementation: single-threaded, fixed or randomised delay of 20-30 seconds between attempts, shuffle the username list so you are not hitting one department in sequence (helpdesk notices clusters).
• One password only. Spraying two passwords in one window doubles the failure count per account and breaks the safety margin. 'Spring2024!' also matches the seasonality of the 'Winter2023!' password you already hold, which is the whole hypothesis.
• Log every attempt: timestamp, username, result code. You need this to prove what you did if helpdesk gets a report.
• Hard stop conditions: any 'account locked out' response, any authentication anomaly, or 01:45 arrived - stop, do not finish the list.
• Prioritise order: the 300 names, but front-load accounts whose naming convention and role suggest service or shared use - those are the ones most likely to carry a weak shared password.

Stop the spray immediately, then treat it as an incident you caused, because you did.

• Cease all authentication attempts. Not 'pause and resume with a different list' - stop.
• Preserve the log: which account, what time, how many attempts it received from you, and the exact response string. If the count is below the stated threshold, either the policy is different from what you were told or someone else was failing on that account - that distinction matters and only your log can show it.
• Notify the engagement contact now, even out of hours, with the username and timestamps, and request an unlock. The cost of a locked service account at 01:40 on Sunday is an outage on Monday; the cost of staying quiet is a lost engagement and a client who cannot trust your logs.
• Re-derive the policy empirically with the client's test account before any second attempt, rather than assuming the stated threshold was wrong in a convenient direction.
• Report it. A section titled 'Lockout incident during credential testing - cause, containment, client notification at 01:41' is a professional deliverable. A section that omits it, and which the client discovers from event 4740 logs, is a finding against you.
• If the window is still open and the client confirms the policy, a single remaining pass at a wider spacing is defensible - but not tonight, and not without their written go-ahead.