Enable custom banned passwords
Overview
Section titled “Overview”Organizations that don’t populate and enforce the custom banned password list expose themselves to a systematic attack chain where threat actors exploit predictable organizational password patterns. These threat actors typically start with reconnaissance phases, where they gather open-source intelligence (OSINT) from websites, social media, and public records to identify likely password components. With this knowledge, they launch password spray attacks that test organization-specific password variations across multiple user accounts, staying under lockout thresholds to avoid detection. Without the protection the custom banned password list offers, employees often add familiar organizational terms to their passwords, like locations, product names, and industry terms, creating consistent attack vectors.
The custom banned password list helps organizations plug this critical gap to prevent easily guessed passwords that could lead to initial access and subsequent lateral movement within the environment.
Remediation
Section titled “Remediation”Run it
Section titled “Run it”The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
Install-Module ZeroTrustAssessment -Scope CurrentUserConnect-MaesterInvoke-Maester -Pack ZTA -SkipBuiltInLeave out -SkipBuiltIn to run Maester’s own checks in the same run.
About this check
| Severity | Low |
| Effort to fix | Low |
| Impact on users | Low |
| Pillar | Identity |
| Category | Access control |
| Product | Entra ID |
| Feature | Password protection |
| Area | Authentication |
| ATT&CK | T1110.003 Password Spraying |
| Licence | P1 |
| Tenant | Workforce, External |
Product, feature, area and ATT&CK are Maester’s: the assessment does not record them, so Maester keeps them in the pack’s taxonomy.json.
A Microsoft check, part of the Zero Trust Assessment pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, MIT licence.