MITRE ATT&CK T1201 Password Policy Discovery: Spotting Enumeration Early

An attacker who knows your lockout threshold can spray passwords just below it indefinitely, and in most environments any authenticated account can read that threshold. MITRE ATT&CK T1201 Password Policy Discovery is a Discovery (TA0007) technique covering Windows, Linux, macOS, IaaS, Identity Provider, SaaS, Office Suite and Network Devices: adversaries read the password policy so their guessing and spraying fit inside it. ATT&CK's own example: if the lockout threshold is 6, the adversary does not check more than 3 or 4 passwords per account. You cannot hide the policy from authenticated users in most directories, so the defence is to make the information worth little and to notice who asks for it in unusual contexts. This guide covers the technique as ATT&CK v20 defines it, cases, the detection analytics, mitigations and testing. It is for detection engineers, identity teams and SOC analysts. For setting the policy itself, see the Password Policy Guide (NIST-aligned).

Key takeaways

• The policy is not a secret. Treat it as known to the attacker and design lockout, MFA and spray detection so that knowing it does not help.
• The query is noisy alone and useful in a chain. ATT&CK v20 frames detection as behaviour chains: a policy read followed by account enumeration, credential activity or authentication changes by the same principal.
• Context beats the command. A help desk console reading the domain policy is routine; a user workstation, a web server process or a newly created cloud principal doing it is not.
• Cloud and SaaS reads are logged. AWS records GetAccountPasswordPolicy in CloudTrail, and Entra ID and Microsoft 365 policy reads appear in audit logs, so the same chain logic applies to identity platforms.
• ATT&CK's one mitigation is about password filters. M1027 Password Policies asks you to ensure only valid password filter DLLs are registered, which protects the policy enforcement path rather than hiding it.

What T1201 covers

ATT&CK v20 describes adversaries accessing detailed information about the password policy used in an enterprise network or cloud environment, so they can build dictionary and brute force attacks that conform to it. The technique has no sub-techniques. Its sources span every place a policy lives:

Password policy discovery usually sits next to T1087 and T1069 Account and Permission Group Discovery: the attacker needs both the list of accounts and the rules for guessing them. The result feeds T1110 Brute Force, especially T1110.003 Password Spraying.

How adversaries have used it

ATT&CK v20 procedure examples show the technique is routine reconnaissance for state groups and criminal tooling alike:

• OilRig (G0049): used a script running the Net utility to find a domain's password policy, as FireEye reported in attacks on Middle East banks. See the OilRig Threat Actor Profile Guide.
• Turla (G0010): used Net account settings commands locally and against the domain, per ESET's May 2020 ComRAT research. See the Turla Threat Actor Profile.
• Operation CuckooBees (C0012): Cybereason reported in May 2022 that the actors used the same Net command as part of their reconnaissance.
• Chimera (G0114): NCC Group reported in January 2021 the group using the NtdsAudit utility to collect information about accounts and passwords.
• Kwampirs (S0236): malware that Symantec tied to the Orangeworm group in April 2018 collects password policy information through Net.
• Offensive frameworks: ATT&CK lists CrackMapExec (S0488) and PoshC2 (S0378) as able to enumerate password policies, which is why authorised red teams trigger the same detections.

The value of policy knowledge shows in low-and-slow spraying. In the Microsoft Midnight Blizzard Breach 2024, Microsoft said the actor compromised a legacy, non-production test tenant account without MFA through password spraying, targeting a limited number of accounts with few attempts to avoid detection and account blocks, through residential proxies. Microsoft did not say whether the actor read a policy first; the point is that a spray tuned to stay under lockout succeeds wherever MFA is missing.

What to detect and where

ATT&CK v20 detection strategy DET0161 is titled as cross-platform behaviour-chain analytics. Each analytic is a chain: a policy read, then an adjacent suspicious action by the same principal within a window.

NHI Mgmt Group recommends these practical adaptations:

• Scope by host role: as AN0455's HostRoleScope suggests, suppress on domain controllers and management servers and raise on user workstations, VDI and servers that run applications.
• Parent process matters: a policy query whose parent is a web server, database, office application or script host is high-signal regardless of user.
• Machine identities reading policy: an access key, service principal or service account that has never read the password policy and now does is a strong lead, because non-human identities have stable behaviour. Pair it with the IaaS chain: policy read then user creation is a common persistence path.
• Chain into authentication telemetry: join the policy read to failed sign-ins across many accounts within hours, which is the spray the read was for.
• Directory reads without commands: LDAP reads of domain policy attributes do not need any of the listed commands. Where you collect directory access auditing (4662 requires a SACL on the domain object) or LDAP query telemetry, include them. See the Active Directory Security Monitoring and Event IDs Guide.

Platform logging guides: AWS CloudTrail Guide, Entra ID Sign-In and Audit Log Detection Guide and Microsoft 365 Unified Audit Log Guide for Detection.

Mitigations

ATT&CK v20 maps one mitigation: M1027 Password Policies, with the guidance to ensure only valid password filters are registered. Filter DLLs must be present in the Windows installation directory (System32 by default) of a domain controller or local computer, with a matching entry in the LSA Notification Packages registry value. A rogue filter is itself a technique, T1556.002 Password Filter DLL, which captures passwords as they change. See MITRE ATT&CK T1556 Modify Authentication Process.

Because the policy cannot realistically be hidden, the controls that matter make it useless to the attacker. NHI Mgmt Group recommends:

Microsoft also documents that smart lockout tracks the last three bad password hashes, so re-entering the same wrong password does not increase the counter. That reduces user lockouts without helping a spray, which uses different passwords. Lockout tuning in detail is in the Account Lockout and Brute-Force Protection Guide.

Where identity fits

Non-human identities change this technique in two ways. First, they are attractive spray targets: service accounts with static passwords, often excluded from MFA and sometimes from lockout to avoid outages. An attacker who reads the policy and sees the threshold knows how many guesses each service account can absorb. Second, they are useful detection anchors: a service account, access key or service principal has a narrow, repeatable pattern of API calls, so a first-ever read of a password policy by one stands out more than the same read by a human administrator. Inventory service accounts, move them to managed or certificate credentials, and monitor them separately. See How to build a service account inventory from Active Directory.

Implementation sequence

1. Collect the logs AN0455 to AN0461 name for your platforms: Sysmon process creation and PowerShell script block logging on Windows, auditd on Linux, CloudTrail management events, Entra and Microsoft 365 audit logs, network device command accounting.
2. Build allow lists from 30 days of history: which accounts, hosts and applications read password policy routinely.
3. Deploy single-event detections in alert-only mode scoped to unusual host roles and parents, and review hits with the identity team.
4. Add chain correlations within the TimeWindow: policy read plus account enumeration, policy read plus user creation, policy read plus multi-account failed sign-ins.
5. Promote the chains to paging alerts; keep single reads as low-severity context for investigations.
6. Harden in parallel: verify registered password filters, confirm lockout ordering in hybrid estates, remove legacy authentication and move service accounts off passwords.

Small organisations without a SIEM can still get value from cloud-native alerts for password spray and from checking registered password filters during routine domain controller reviews. Large estates should treat the chains as part of a wider discovery detection pack alongside account and group discovery.

How to test

• Emulate the read: from an authorised test workstation, query the domain policy with standard tooling and confirm the event chain is logged and correlated.
• Emulate the chain: follow the read with a small, approved set of failed sign-ins against test accounts and confirm the combined alert fires.
• Cloud check: call GetAccountPasswordPolicy from a test principal not on the allow list and confirm the IaaS analytic triggers.
• Filter audit: list the LSA Notification Packages on every domain controller and confirm each entry is expected and signed.

Metrics

• Percentage of platforms in the table above whose policy-read events reach the SIEM.
• Number of password policy reads per week outside the allow list, and percentage triaged.
• Percentage of service accounts still authenticating with static passwords.
• Percentage of sign-in paths covered by MFA, including legacy and test tenants.
• Time from emulated read-plus-spray chain to SOC alert.

Common failure patterns

• Alerting on every query: help desk and posture tools generate constant reads, the alert is muted, and the real one is lost.
• Ignoring non-production tenants: the Midnight Blizzard foothold was a legacy test tenant account without MFA.
• Lockout thresholds that punish users and spare attackers: low thresholds without location awareness cause user lockouts while a slow spray stays underneath.
• Service accounts exempt from everything: no MFA, no lockout, never-expiring password.
• Never checking password filters: a rogue filter DLL survives for months because nobody reviews the registry value.

Framework mapping

Practitioner checklist

• Policy-read telemetry is collected for Windows, Linux, macOS, cloud, identity provider, SaaS and network devices you run.
• An allow list of routine readers exists and is reviewed.
• Chain detections join policy reads to account discovery, user creation and multi-account sign-in failures.
• Registered password filters on every domain controller are known and reviewed.
• MFA covers every sign-in path, including test and legacy tenants.
• Lockout is location-aware, and hybrid thresholds are ordered as the identity provider recommends.
• Banned password screening is on.
• Service accounts are inventoried and moving to managed or certificate credentials.

Standards and references

• MITRE ATT&CK: T1201 Password Policy Discovery
• MITRE ATT&CK: M1027 Password Policies
• Microsoft Learn: Protect user accounts from attacks with Microsoft Entra smart lockout
• AWS: IAM API Reference, GetAccountPasswordPolicy
• NIST: SP 800-63B Digital Identity Guidelines, Authentication and Authenticator Management
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ATT&CK Discovery Tactic (TA0007) Guide, Password Policy Template, Storm-0940 Password Spray Botnet Profile Guide and Active Directory and Entra ID Hardening Guide.