Password spraying
In credential attacks, password spraying tries a small number of likely passwords against a very large number of accounts, instead of many passwords against one account. It is designed to stay below lockout thresholds, and it is the technique that most reliably produces a first foothold in a cloud tenant.
How it works
The attacker collects usernames, which is rarely difficult since corporate address formats are predictable and staff lists are public, then chooses passwords that follow the patterns a policy encourages: a season and a year, the company name with a number, a local football team, the classic keyboard walk. One password is attempted against every account, then the attacker waits out the lockout observation window and tries the next.
From each account’s point of view there is a single failed sign-in, which trips nothing. From the tenant’s point of view there is a burst of failures across thousands of accounts from a small number of sources, which is trivially detectable if anybody is looking at that view. Attackers who care distribute the source addresses to remove that signal too.
What goes wrong
The control everyone has is the wrong one. Account lockout counts per account and this technique never reaches the threshold. Rate limiting by source address is defeated by distribution. What detects it is a tenant-level view of authentication failures correlated by password attempt, source and time, and that view is usually not built because the tooling is oriented around individual accounts.
The bigger gap is protocol coverage. Legacy authentication endpoints in a mail platform accept a username and password without ever invoking modern policy, so a tenant with strong conditional access can be sprayed successfully through an old protocol that was left enabled for one device in a warehouse. This is the single most common finding we report in a Microsoft 365 review.
Third, the accounts that fall are not the ones anybody protected. Shared mailboxes, test accounts, service accounts with interactive sign-in enabled, and accounts excluded from the second factor policy for operational reasons are where the successes come from.
Where this shows up in an audit
We run it with the client’s agreement, at a rate agreed in advance, and we report three things: which accounts succeeded, which protocol accepted the sign-in, and whether anybody noticed. The third is usually the finding. We also record which accounts were excluded from policy, since that list explains the results. The recommendation is phishing-resistant credentials for everyone rather than better passwords, plus disabling the legacy paths. This is part of how we test tenant sign-in exposure the way an attacker does.