No account lockouts does not mean no attack attempts

The help desk reports nothing unusual. Individual user accounts show only a few failed sign-ins. Only the combined view reveals that the same source has reached many different accounts within a given period. Monitoring that counts locked accounts alone misses this pattern.

Password spraying spreads attempts using a small number of common passwords across many identities. Defenders therefore need to understand the relationship between accounts, sources, authentication paths and time. A sensible account lockout policy remains part of the baseline; on its own, it provides neither complete detection nor reliable prevention.

The scope includes on-premises AD authentication and services that validate domain passwords, such as VPN, RD Gateway, web applications and federated access. In hybrid environments, establish whether a cloud service authenticates users itself or passes validation to on-premises components. Not every cloud authentication failure appears in a domain controller's Security log.

Target state: cover authentication paths and attribute findings

Document the protocol, identity source, responsible team, protective controls and available logs for each relevant entry point. Acceptance requires three verifiable outcomes:

  • Failed attempts across multiple accounts can be correlated centrally without counting forwarded duplicates more than once.
  • An alert identifies the affected identities, time window and authentication path, and explains how confidently the source can be attributed.
  • The operations team can investigate suspicious activity and apply targeted restrictions; ownership and escalation paths are agreed in advance.

Failures of an event source must also become visible. A quiet dashboard caused by interrupted forwarding is no evidence of security.

Enable the right telemetry first

Advanced audit policies are located under Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies. Use the English policy names when working across management environments in different languages.

The relevant domain controllers need success and failure auditing for Audit Kerberos Authentication Service and Audit Credential Validation. Success auditing for Audit User Account Management adds account lockout events. Relevant target systems also need success and failure auditing for Audit Logon. The setting Audit: Force audit policy subcategory settings ... to override audit policy category settings prevents older category settings from overriding the intended subcategories; verify that this setting is effective as well.

Roll out policies to a defined pilot scope first. Then include all relevant domain controllers, target systems and upstream services in collection. Security log capacity, forwarding latency, time synchronisation and retention must support the expected volume. Restrict access to account names, source addresses and sign-in histories to the responsible roles; do not collect passwords.

Check the effective local audit configuration with this read-only command in an administrative session:

auditpol.exe /get /category:*

The GPO report and the effective local settings should agree. A controlled test event must then actually arrive in the central system. A configured policy does not prove that collection works.

Interpret events by protocol and failure reason

Four events provide different parts of the picture:

  • 4771 on the domain controller: Kerberos pre-authentication failed. Failure code 0x18 is consistent with an incorrect password. Do not count other failure codes as password guessing indiscriminately. The client address helps attribute the source.
  • 4776 on the validating system: NTLM credentials were validated. For domain accounts, this system is a domain controller. Status 0xC000006A indicates an incorrect password; 0x0 indicates successful validation. The event contains a source workstation name, but no direct source IP address or target server information.
  • 4625 on the sign-in target: A sign-in failed. Logon type, authentication package, status and substatus provide context. Not every failure means an incorrect password; the completeness of source information varies with the authentication path.
  • 4740: An account was locked out. This event supports investigation, but is not required to suspect password spraying.

A gateway or intermediary service may appear as the source from the domain controller's perspective. Its logs must provide the link to the original connection. Workstation names and IP addresses are clues, not reliably unique device identities.

For success correlation, 4768 with Result Code 0x0 records successful Kerberos TGT issuance and 4624 records a successful sign-in on the target, for example. Event ID 4768 alone is not evidence of success. Successful 4776 credential validation does not establish that access to an application was completed. Standard Windows events also do not reveal which password was entered. Detection provides a reasoned suspicion of spraying, not proof that the same guessed password was reused.

Build correlation across accounts

SIEM processing can be broken down into manageable steps:

  1. Map events to common fields: UTC timestamp, domain or identity namespace, account, protocol, result, source indicator and target application. Map UPN and DOMAIN\User carefully; use available SIDs and keep accounts with the same name in different domains separate.
  2. Separate password failures from other causes. Deduplicate original events and forwarded copies. Link different events from the same authentication attempt where possible, so that one attempt is not artificially counted as several.
  3. Count both failed attempts and distinct affected accounts per source and authentication path. Combine short and longer time windows. Also investigate account and service patterns across multiple sources so that detection does not depend on a single IP address.
  4. Set thresholds using representative operational data. A shared VPN egress, a VDI farm and an individual client need different expectations. There is no universally reliable value for "accounts per minute".
  5. Enrich alerts with subsequent successes, privileged accounts and relevant endpoint and gateway findings. Explicitly include any uncertainty in source attribution.

Run a rule in observation mode first. Classify false positives and maintain narrowly scoped exceptions with an owner and expiry date. Excluding an entire proxy or all service accounts creates a blind spot precisely where many identities converge.

Reduce exposure at the actual entry points

Password length and blocklists reduce the likelihood that common passwords or passwords related to the organisation will work. Microsoft Entra Password Protection for on-premises AD checks passwords during changes and resets. It does not retrospectively scan existing passwords. Consistent enforcement requires coverage of all domain controllers that process these changes. Audit mode, a pilot and then Enforced mode are separate steps; continue monitoring agent and policy health.

Apply MFA to every supported entry point, preferably using phishing-resistant methods. An Entra ID Conditional Access policy does not automatically protect all on-premises Kerberos, NTLM or LDAP authentication. Close unused password-based entry points, check for direct paths that bypass controls, and keep privileged identities out of ordinary user access paths. Gateway rate limits must account for shared sources so that one suspicious client does not block the entire workforce.

Entra Smart Lockout and AD account lockout have different scopes. With pass-through authentication, deliberately coordinate cloud and AD thresholds, including lockout duration. Do not give service accounts blanket monitoring exceptions; replace static passwords with managed identities or gMSAs where the application supports them.

Respond without causing an authentication outage

First inspect raw events, source attribution and affected accounts. Stale service credentials can produce a similar pattern of failures. Restrict a suspicious connection at the responsible gateway or isolate a confirmed compromised endpoint once the evidence and ownership support that action. An aggregate failure count does not justify automatically locking every affected user account.

Confirmation that an unauthorised party has supplied a correct password is enough to trigger the incident process, even if MFA prevents subsequent access. Secure affected accounts, reset passwords in a controlled manner, address relevant sessions and tokens, and investigate possible follow-on activity. Password compromise and successful application access are different findings. A password reset does not immediately terminate every Kerberos ticket or application session. Sign-out, blocking and restoration of access must suit the services actually affected.

For the pilot, the operations plan needs a way to disable a faulty automated response and a reachable owner. Event collection remains active.

Advantages: earlier signals and targeted response

  • Patterns across accounts become visible before large numbers of account lockouts are needed.
  • The inventory exposes unprotected authentication paths and missing log sources.
  • Protocol and source context support targeted intervention and help avoid unnecessary lockouts.
  • Metrics such as detection latency, source coverage and reviewed false positives make operational performance measurable.

Disadvantages and limits: ongoing effort and incomplete certainty

  • Central collection, retention and investigation incur storage, licensing and operational costs.
  • Shared gateways, stale service passwords and incomplete client information make it harder to distinguish attacks from operational faults.
  • Slow attempts or attempts distributed across many sources can still evade rules. Strong password controls and protected entry points remain necessary.
  • An alert proves neither which passwords were used nor that a compromise succeeded. The absence of an alert does not prove the absence of attacks.
  • Overly aggressive automated responses can cause service disruption themselves. Response rules need separate tests and acceptance criteria.

Validate with synthetic events and a test account

Test detection logic using labelled synthetic events in a test environment: failures across many accounts, stale credentials for one service, a shared gateway address, success following failures and collector failure. Record both expected alerts and cases that should deliberately produce no alert.

An approved, non-privileged test identity with a controlled failed and successful sign-in is sufficient to validate the complete delivery path. Agree the number and timing of attempts in advance and respect existing lockout policies. There is no need to test guessed passwords against production user accounts. Synthetic testing evaluates correlation; the small functional test evaluates the path from event source to display.

Project checklist for reliable operation

  • Inventory on-premises, external and hybrid AD authentication paths and their owners.
  • Document protocols, validating systems and the actual scope of MFA protection.
  • Verify effective audit subcategories on domain controllers and target systems.
  • Make relevant domain controller, target system and gateway events available centrally.
  • Configure time synchronisation, retention, role permissions and source health monitoring.
  • Normalise account names, failure codes and source indicators in a traceable manner.
  • Account for duplicates and authentication attempts recorded in multiple events.
  • Evaluate distinct accounts, multiple time windows and distributed sources.
  • Distinguish successful credential validation from actual application access.
  • Keep exceptions narrow, time-limited and assigned to an owner.
  • Review password protection, MFA and unnecessary authentication paths separately.
  • Agree the response plan, including sessions, tickets and restoration of access.
  • Complete acceptance testing with synthetic cases and a controlled functional test.
  • Regularly review false positives, detection latency and collector outages.