Spotting password spraying and credential stuffing in your logs

Password spraying and credential stuffing both show up as a pile of failed sign-ins, but the shape of the pile differs, and so does the fix. If your only alert is "five failures on one account", you will miss both.

Three attacks, three shapes

The OWASP Credential Stuffing Prevention Cheat Sheet separates them like this:

OWASP says that in many cases the defences are the same, and that they also work against brute force.

What to look for in the logs

MITRE's detection strategy for password spraying is a high volume of authentication failures using one password, or a small set, across many user accounts within a time window. For credential stuffing it is multiple failures with distinct username/password pairs from a single IP address or session in a short window.

Attackers adapt to the obvious counters:

• Throttled spraying. MITRE describes APT28 tooling that made roughly four attempts per hour per targeted account over days or weeks. Quad7 activity used a single sign-in attempt within a 24-hour period, which eluded brute force detection thresholds. Per-account counters will not catch this.
• Distributed spraying. MITRE also notes that APT28 used a Kubernetes cluster for distributed, large-scale sprays. A count per source IP alone will miss that, because no single address fails often. Also count distinct accounts failing per time window across all sources, and break the same data down by ASN and user agent.
• Quieter protocols. Attackers may use LDAP and Kerberos attempts, which are less likely to trigger high-visibility events such as Windows "logon failure" event ID 4625, commonly triggered by failed SMB connections. Collect LDAP and Kerberos failures as well as 4625.

Attackers usually go for management services on common ports: SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) and web management interfaces on 80 and 443. They also target SSO, cloud applications using federated authentication, and externally facing email such as Office 365 and OWA.

Microsoft 365: use smart lockout properly

Microsoft Entra smart lockout is always on. By default it locks an account after 10 failed attempts in Azure Public tenants, or three in Azure US Government tenants. The first lockout lasts one minute and gets longer on later failures. Microsoft does not disclose the rate of increase.

• It tracks the last three bad password hashes, so repeating the same wrong password does not raise the counter. That stops a user's repeated typo from locking them out. It does little against a spray, where each account sees the password once.
• Familiar and unfamiliar locations have separate lockout counters, so an attacker from a new location can be locked out while the real user carries on.
• Custom values need Microsoft Entra ID P1 or higher. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator and go to Entra ID > Authentication methods > Password protection. There you set the Lockout threshold and the Lockout duration in seconds (default 60).
• Entra also blocks some sign-ins on IP traffic and behaviour signals by default and returns AADSTS50053 - IdsLocked, regardless of whether the password was valid. Treat the accounts that show this code as targeted, but do not read it as proof that the password was wrong or right.

Smart lockout does not guarantee a genuine user is never locked out. MITRE adds the other side: too strict a policy can create a denial of service, with every account in the attack locked out.

Hybrid setups

With pass-through authentication, the Entra threshold must be lower than the on-premises AD DS threshold, and the AD DS threshold should be at least two or three times higher. The Entra lockout duration must be longer than the AD DS one. Microsoft's example is a threshold of 10 against 20, and 120 seconds against 60. Entra duration is set in seconds and AD DS in minutes, so check the units.

Hash tracking is not available with pass-through authentication. To read your AD DS values, open Group Policy Management, edit the policy holding your lockout settings, and browse to Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.

Your own login page and exposed services

Lockout is a per-account control. Our reading is that a stuffing run which tries each account once or twice will often never reach the threshold, so do not treat it as your main defence. MITRE warns that stuffing can cause numerous failures and lockouts, but that depends on your policy. Its mitigations for both techniques add:

• Multi-factor authentication, enabled on externally facing services where possible.
• Conditional access policies that block logins from non-compliant devices or from outside defined organisation IP ranges.
• Blocking risky requests, such as those from anonymising services or proxies.
• Password policies based on NIST guidance.
• For stuffing, proactively resetting accounts known to appear in breached credentials, either at once or after you detect brute force attempts.

For a custom application, the OWASP Authentication Cheat Sheet has sections on protecting against automated attacks, CAPTCHA, and logging and monitoring.

Where to start

1. List every internet-facing login: Microsoft 365 or OWA, VPN, RDP, SSH, SSO and your own web forms. Close any management port that does not need to be open.
2. Check the smart lockout threshold and duration under Entra ID > Authentication methods > Password protection. With pass-through authentication, compare them with your AD DS lockout policy using the rules above.
3. Build two queries over your sign-in logs. The first counts distinct accounts with failed sign-ins per source IP per hour. The second ignores the source: it counts distinct failing accounts per time window overall, then splits by ASN and user agent. Alert on both, and keep AADSTS50053 as a separate view.
4. Turn on MFA for every externally facing service, then add conditional access rules for unmanaged devices and anonymising services.
5. Compare staff accounts against known breaches, for example with our breached password check, and reset any that match. If you lack the people to watch the logs daily, managed monitoring covers that gap.