Module 15 · Password Spraying Against AD in 2026

Last updated: April 29, 2026

Why this module exists. Brute force = trying many passwords against one account → triggers lockout. Spraying = trying one password against many accounts → stays under lockout thresholds. The result of spraying every Indian enterprise’s user list with “Password@2026” is, statistically, 2-5% success — sometimes including admins.

The math

Default AD account lockout: 5 wrong passwords in 30 minutes → 30-minute lockout. Spraying never trips this because each account gets one attempt.

Empirical hit rate against typical Indian enterprises (50K+ users, mixed knowledge-worker / factory-worker / contractor base):

2% of 50K = 1,000 accounts. Among them: at least one admin, at least one DBA, at least a few high-privilege application accounts.

Step 1: enumerate users

You need a username list. Sources:

• If you have any domain credential: net user /domain, LDAP get-aduser -filter *
• From outside, no creds: Kerberos AS-REQ brute force — Kerbrute will tell you which usernames exist (different KDC error for valid vs invalid users)
• OSINT: LinkedIn (firstname.lastname format usually matches), GitHub, leaked databases

# Kerbrute — fast, no lockout impact (just queries KDC)
kerbrute userenum -d corp.local --dc 192.168.56.10 names.txt

# Generate names from LinkedIn
linkedin2username -c "Acme Corp" -n
# Output: a.lastname, alastname, lastname.firstname patterns

Step 2: spray

# Kerbrute — recommended (uses Kerberos, low impact)
kerbrute passwordspray -d corp.local --dc 192.168.56.10 
  users.txt 'Password@2026'

# CrackMapExec / NetExec
nxc smb dc.corp.local -u users.txt -p 'Password@2026' 
  --continue-on-success

# Spray365 — distributed across multiple source IPs to dodge geo-detection
python spray365.py spray --execution-plan plan.json

Timing — why slow is fast

Modern detections (Microsoft Defender for Identity, Splunk) flag rapid sequential failed logons. Slow spraying:

• One attempt per user, with 30-second jitter between accounts.
• One spray per 24-48 hours per password.
• Random ordering.
• Distribute across multiple source IPs / attack infrastructure.

This stays under most baseline detections. The hit rate is the same (statistical, not timing-dependent).

Spraying Microsoft 365 / Entra ID

Same idea, different protocol. Tools like MSOLSpray, TREVORspray hit Entra’s authentication endpoints. Microsoft has improved detection (smart lockout, anomaly detection), but slow + distributed sprays still slip through.

Real-world cases

• Midnight Blizzard / Microsoft 2023-24 — initial access via password spraying against a legacy Microsoft tenant.
• Citrix 2019 — attackers used password spraying as initial access for the credential-leak incident.
• Many ransomware playbooks begin with a password spray phase before any other action.

Defender’s checklist

• Conditional Access on Entra ID with strict MFA. Password alone, even if correct, doesn’t get the attacker in.
• Smart lockout / fine-grained password policies — on-prem AD; lock out after N failures across any source.
• Banned password list — Microsoft’s Azure AD Password Protection extends to on-prem; bans common patterns like {Season}{Year}.
• Detection: SIEM rule for “failed logon (4625) for ≥10 different users from the same source within 1 hour”. This is the spraying signature.
• Honey accounts: create accounts with names like admin_test or backup_admin that should never log in. Any auth attempt = guaranteed-malicious.
• Disable legacy authentication on Entra. Spray attempts against legacy auth bypass conditional access policies designed for modern auth.
• Geographic anomaly detection — Defender for Identity, Cloud Apps. Failed logons from countries where you have no users.