How T1201 password policy discovery shows up before an intrusion escalates
A SOC lead who sees a suspicious account inside the environment should assume the account may be trying to learn the lockout threshold, lockout duration and complexity rules before it tries anything else. T1201 Password Policy Discovery is the technique where an adversary reads those settings so it can choose how many guesses to make and how slowly to make them. The useful question for the SOC is not only whether the account is malicious, but whether it has already queried the domain or local password policy and, if so, what it did next. At a high level, password policy knowledge lets an adversary plan password guessing and password spraying without tripping account lockout. If the lockout threshold is known, guesses can be spread across accounts and time windows so that no single account exceeds the limit. If complexity rules are known, candidate passwords can be shaped to pass validation. In ATT&CK, this step sits under the Discovery tactic (TA0007), which MITRE describes as the point where the adversary is trying to figure out the environment. It usually appears alongside account and group enumeration, which is why it often shows up in the same window as other discovery activity.
For the detection team, the practical decision is which hosts and identity sources should be treated as high value for policy queries. Domain controllers, administrative workstations and any server that can read directory policy are the first places to examine. Confirm with your identity and platform owners which built-in tools and administrative scripts legitimately read password policy in your environment, so that the baseline is written down before alerts are tuned. The targeted version for these pages is ATT&CK v20.0, and detection mappings should name that version because technique names, data components and mappings can change between releases. Confirm the current technique and analytic wording in the ATT&CK site and the STIX data for v20.0 before you publish a rule set.
Which telemetry reveals password policy queries on each platform
This table maps the data components relevant to T1201 (Process Creation, Command Execution and User Account Metadata) to the audit sources on Windows, Linux, macOS and IaaS, with the signal to look for and an open-source collector for each. Read each row as a starting point, then confirm the audit configuration in your own environment before relying on it, because default logging rarely captures these queries.
| Platform | Audit source to confirm | Signal to look for | Open-source collector |
|---|---|---|---|
| Windows | Process creation auditing with command line capture, plus Sysmon-style process logging | Execution of net accounts or equivalent policy query tools, and Group Policy or local security policy reads by non-administrative accounts | Wazuh agent forwarding Security and Sysmon event channels to the Wazuh manager |
| Linux | Auditd rules on execution of account and PAM policy tools, and reads of PAM and login.defs configuration files | Policy-related command execution by an account that does not normally administer the host, followed by no change to configuration | Auditd forwarded through the Wazuh agent, with Velociraptor for targeted collection |
| macOS | Unified logging and endpoint process telemetry, confirmed against your MDM and EDR configuration | Invocation of password policy or account policy utilities by a standard user session, outside managed scripts | Wazuh agent for log forwarding, Velociraptor for host hunts on process history |
| IaaS identity and directory | Cloud audit logs for identity policy reads, such as directory or identity provider policy API calls, where the provider exposes them | Read operations on password or authentication policy objects from unexpected principals or source addresses | Cloud audit log forwarding into Security Onion or Wazuh, using the provider's log export feature |
| Identity provider (self-hosted) | Administrative audit events for policy view actions, if the product records them | Repeated policy view events from one account across several tenants or realms within a short window | Log forwarding into Wazuh with a custom decoder for the product's audit format |
| Domain controller | Directory service access auditing on policy objects, scoped to avoid excessive volume | Queries against the default domain password policy object by accounts outside the administration group | Wazuh agent on domain controllers, with Sigma rules converted for the Wazuh analysis engine |
| Network and remote access | Authentication gateway or VPN logs that show which accounts reached policy or directory services | Policy reads that follow a new remote session from an unfamiliar source | Zeek or Suricata sensors in Security Onion for correlation, where protocol visibility allows |
| Items to confirm in your environment | Which audit policies are enabled, retention periods, log volume limits, and whether your MDM or EDR already captures command lines | Whether the platform records policy read actions at all, since some do not | Agent versions, decoder and rule versions, and whether you map detections to the ATT&CK version you target |
Detection logic for password policy queries, and where it breaks
The four ideas below look for the same behavior from different angles: someone reading the password policy, then acting on what they learned. Each one trades sensitivity against noise, so every card names the threshold to tune, the baseline to build first, and the routine work that will trigger it.
Account-scoped burst of policy reads
Alert when a non-administrative session runs several policy-reading queries in a short window, such as listing domain or local password settings, lockout thresholds, or complexity requirements. Tune the window and count per account, not per host, so one account cannot hide its reads across machines. Build a baseline of which service accounts, monitoring agents and onboarding tools legitimately read policy each day. The main false positives are password management tools, compliance scanners and IT scripts that run on a schedule, so exclude them by named account and parent process rather than by broad allowlisting.
Policy reads followed by authentication failures
Correlate a policy read with failed logons from the same account or source within a bounded period, since an actor who learns the lockout threshold may then probe just below it. Set the correlation window from your own lockout policy, and confirm the threshold with your identity platform before writing the rule. Help desk workflows are the most common source of this pattern: a user who mistypes a password after a reset, or a technician testing a new policy, produces the same sequence. Route matches to a triage queue with the help desk ticket system so analysts can confirm the change context quickly.
Cloud directory policy reads from unusual identities
In IaaS and identity provider logs, flag reads of directory password policy or authentication method settings by identities that do not normally administer identity configuration. The useful signal is the identity and its location, not the read itself, so compare each caller against a baseline of administrator roles, source addresses and working hours. Expect false positives from identity governance tools, cloud posture management scanners and new automation pipelines during rollout. Confirm which audit event names your provider emits for policy reads, because these differ between platforms and change between versions.
File access to policy configuration
On Linux and macOS hosts, monitor reads of files that store password quality, aging or lockout settings, and on Windows hosts monitor access to exported policy or security template files. Restrict the detection to processes outside configuration management and package tooling, then set a threshold on repeated reads by the same process over a short period. Configuration management agents, hardening baselines and audit tools read these files routinely, so record their process paths and signing details in the baseline before enabling alerts. File access auditing is costly on busy hosts, so confirm the volume with a pilot before widening scope.
How to confirm the T1201 detection fires in a lab
This sequence proves, in a private range, that a benign policy-reading activity on a test host produces telemetry, a Sigma match and a SIEM alert that the team can trace end to end. It also leaves a dated record that supports tuning and version control of the rule.
Agree scope and rules of engagement
The security lead, the detection engineer and the owner of the cyber range agree in writing which test hosts, accounts and telemetry sources are in scope, which activity is benign and permitted, when the exercise runs, and who can stop it. Production identity systems and live domain policy stay out of scope. The exercise is done when the signed scope note names the test host, the test account, the telemetry sources expected to log the activity and the rollback owner. Confirm the rules with your own change process and with DeployOpen if the range is run as a fixed-scope engagement.
Prepare the test host and baseline
The range engineer builds a dedicated test host and a non-privileged test account, confirms that the Wazuh agent or other collector, Sysmon or auditd equivalent, and the SIEM ingestion pipeline are healthy, and records a baseline of the logs for a quiet period. The baseline shows what normal policy-related activity looks like on the host, so later noise can be separated from the exercise. The step is complete when the baseline is saved with timestamps and the collector health checks are green.
Emulate a benign policy-reading activity
A named operator runs the agreed, benign activity that reads the local or domain password policy on the test host, using only the actions listed in the approved test plan. The operator records the start and end time, the test account and the host name in the exercise log at the moment each action is taken. No payloads or evasion are used. The step is done when the log entry matches the actions performed, so the detection can later be compared against a known event.
Confirm each telemetry source logs the activity
The detection engineer checks each telemetry source named in the plan, such as Process Creation and Command Execution events from endpoint sensors and the relevant identity or audit records, and confirms that the exercise event appears with the expected host, account and process fields. Gaps are logged as findings, for example a missing field or a source that is not forwarded. The step is complete when every expected source either shows the event or has a recorded reason for its absence.
Check the Sigma rule and SIEM alert
The detection engineer runs the Sigma rule against the collected events, confirms that it matches the exercise activity and not the baseline, and then verifies that the SIEM rule or Wazuh rule derived from it raised an alert with the expected severity and fields. Matches are checked against the event IDs and command lines recorded in the log, not against assumptions. The step is complete when the match result and the alert ID are recorded side by side with the exercise log.
Record timestamps, host, account and alert latency
The analyst compares the operator timestamp, the event timestamp, the rule match time and the alert creation time, and records the difference between each. The record also lists the host, the account, the rule version and the ATT&CK version the rule targets. Latency that exceeds the agreed expectation becomes a tuning item. The step is done when one reviewed record exists for the exercise, stored where auditors and the detection team can read it.
Tune, re-run and version the rule
After tuning, such as narrowing a noisy field or adjusting ingestion, the detection engineer re-runs the same approved plan on the same test host and compares the new record with the baseline. The rule is versioned in source control with a header that names the ATT&CK version it targets, and the change is linked to the exercise record. ATT&CK releases can rename, deprecate or revoke techniques, so the mapping is rechecked against the ATT&CK version in use before each new release is adopted. Confirm the mapping against the ATT&CK updates pages and the Enterprise STIX bundle for the version in use.
How detection strategies and data components map to T1201
Before you tune anything for T1201, confirm which ATT&CK version your detection mapping targets. ATT&CK v18, released October 28, 2025, replaced the detections that used to sit on technique pages with detection strategies, each identified by a DET ID, and analytics that describe how a strategy is implemented. It also made major updates to data components, identified by DC IDs, and deprecated some data sources. A rule that cites a technique ID alone cannot show which strategy or data component it was built from, so record the DET and DC IDs alongside each Sigma rule or Wazuh decoder. Releases after v18, including v19 on April 28, 2026 and v20 on October 13, 2026, can rename or revoke content, so the version string belongs in the rule metadata too.
Across Discovery techniques, the data components most often referenced by detection strategies are Process Creation (DC0032) and Command Execution (DC0064). For T1201, expect the relevant strategy to lean on these two components, which means your endpoint and command-line telemetry is the first thing to validate. Before you tune thresholds or suppression lists, open the T1201 entry in the enterprise-attack 20.0 STIX bundle and check the detection strategies, analytics and data component references it actually carries. Do not assume the mapping matches an older export or a community rule pack. Ask your detection engineering lead to record the bundle version and the exact DC IDs used, so an auditor or a later upgrade can trace each alert back to a documented source. The MITRE ATT&CK updates page lists the release notes you should review before any mapping change.
Preventive controls that limit what policy discovery reveals
These controls reduce what T1201 reveals before an adversary reads it, and they work together. Policy content should be readable only by accounts that need it, policy reads should be logged, and default settings should be verified after each update. Each card names a control, explains why it matters for password policy discovery, and lists what to confirm with the platform owner.
Password Policies mitigation
The Password Policies mitigation is the control most directly aimed at what T1201 exposes: the length, complexity, lockout and history settings an adversary would otherwise read first. This page does not state its ATT&CK ID, so confirm it on the T1201 technique page for the ATT&CK version you target. Check that the enforced policy matches what the identity platform actually applies, including per-group overrides, because a weak override can undo a strong default.
User Account Management
User Account Management limits which accounts can read directory policy and account metadata in the first place. Review standard user groups for rights that reveal domain or tenant password settings, and confirm that service accounts and low-privilege users cannot query them through default permissions. Treat this as an access question, because a policy any standard user can read is effectively published inside the environment. Ask the platform owner which built-in groups grant read access to policy objects and whether those grants changed during the last hardening pass.
Audit of policy reads
Audit ensures that policy queries leave a trace you can detect. Confirm that the platform records successful and failed reads of policy objects, and that those records reach your SIEM, such as Wazuh or Security Onion, with enough detail to show the querying account and host. Policy reads alone are noisy, so pair them with Process Creation and Command Execution telemetry on endpoints. Ask the platform owner which audit subcategories are enabled and how long records are retained.
Operating System Configuration baseline
Operating System Configuration covers the default settings on hosts and identity services that decide how much policy detail is exposed. On Windows, Linux and macOS, review which remote management paths, shell utilities and directory query interfaces ordinary users can reach. Tighten these defaults in a documented baseline and verify them after each patch cycle, since updates can restore default settings. Ask the platform owner for the baseline document and the evidence that each setting is still applied.
Cloud and identity policy visibility
Where T1201 covers cloud identity platforms, the same question applies to the identity provider and IaaS accounts that hold password settings. Review which roles can read tenant-wide authentication policy, and confirm that read-only and auditor roles do not inherit administrative visibility. Export the effective policy on a schedule and compare it with the approved baseline, so drift appears before an adversary finds it. Ask the vendor which roles can see tenant authentication settings by default.
Triage steps when a T1201 alert fires
The first decision on a T1201 alert is whether the discovery activity came from a legitimate actor. Confirm the source account and session before anything else. Identify the account name, the host or client it authenticated from, the authentication method, and the session identifier tied to the activity. On Windows, that means the logon session and the account that launched the process. On Linux and macOS, it means the user context of the shell or process and any sudo or SSH session that spawned it. On IaaS or identity platforms, it means the principal, the console or API client, and the source address. Then check whether the activity matches a known workflow: a scheduled audit, a configuration management run, a monitoring agent or a service account used by an approved tool. Ask the owning team for the change ticket or runbook entry. If no owner can explain the account or the host, treat the alert as suspicious until proven otherwise.
Next, widen the view to the authentication and activity history for the same account and source. Look for failed logons, lockout events, password reset requests or changes to the password policy around the time of the alert. A sequence of policy reads followed by repeated authentication attempts, or a spike in lockouts, changes the risk picture. Then check what came after: other Discovery techniques such as account or group enumeration, or any credential access activity from the same session. Our readers should confirm which of these events their environment logs at all, since a password policy query on one platform may leave no trace on another. Based on what you find, decide on containment. For a suspicious session, revoke it and force reauthentication. For an account with unclear ownership, disable it temporarily and review its recent changes. Preserve evidence first: export the relevant event logs, the process and command records, the authentication history, and the host's current state before rebooting or reimaging. Escalate to incident response when the account has privileged rights, when discovery is followed by credential access or lateral movement, or when the owner cannot confirm the activity within your agreed triage window.
Rehearsing T1201 detection in a private cyber range
The Windows range should mirror your production domain structure: a domain controller, a member workstation, a file server and a Wazuh or Security Onion collector that receives Windows event and Sysmon-style process telemetry. Planned injects are policy reads performed by a benign test identity that has no privileged rights, so the exercise tests detection, not exploitation. Confirm with your platform team exactly which event sources are enabled on the domain controller before the exercise starts, because policy-read activity is often visible only when the relevant audit settings are on.
- Topology: One isolated domain with a test user, a workstation and the log pipeline. No connection to production identity.
- Injects: Scheduled policy-reading activity from the test identity at known times, with the expected host and account recorded in advance.
- Detection goal: An alert in the agreed window that names the correct host, the correct test account and the time of activity.
- Response goal: A triage record showing the analyst's decision, a containment choice (for example, disabling the test account) and a lessons-learned entry.
- Check: Whether the rule fired on the intended event, and whether any false positives came from legitimate administration.
Linux and macOS hosts expose policy information through local configuration files and command-line utilities, so the range needs endpoints with auditing that captures process creation and command execution. Use a benign test account and a planned sequence of policy-reading actions, recorded by the exercise lead. Ask your endpoint team which audit framework and log forwarding agent they run, since coverage differs between distributions and macOS releases.
- Topology: One Linux host and one macOS host joined to the same log pipeline, with separate test accounts and no privileged sudo rights.
- Injects: Timed reads of local policy settings by the test account, logged in a shared exercise sheet with the host name and time.
- Detection goal: Process creation or command execution events that reach the SIEM and map to the detection rule, with the host and user fields populated correctly.
- Response goal: A triage note, an approved containment step on the test account, and a record of any gaps in host logging.
- Check: Whether events from both platforms carry the same field names, so one correlation rule can serve both.
An IaaS tenant creates policy-related signals in identity and control-plane logs rather than on the host. In a range, use a non-production tenant with a test identity that holds only read access to identity and policy settings. Confirm with the cloud provider which audit logs are available at your subscription level and how long they are retained, because these details vary by service and plan.
- Topology: A dedicated test tenant or project with a test identity, an identity provider configuration and a log export into the same SIEM used for endpoints.
- Injects: Planned reads of identity policy settings by the test identity, scheduled and logged by the exercise lead.
- Detection goal: A control-plane or identity log event in the agreed window that names the correct identity, source address and policy resource.
- Response goal: A triage record that separates the test activity from production noise, a containment decision on the test identity and a lessons-learned entry on log gaps.
- Check: Whether the cloud log export arrives within the window you agreed, since delayed ingestion can make a correct rule look broken.
Questions detection engineers ask about T1201
How do we separate password manager reads from adversary password policy discovery?
Judge each read by its context, since the command alone rarely settles the question. Password managers, endpoint agents and browser extensions read policy settings on a schedule, usually from a known parent process, a known service account and a predictable path. Build an allowlist from your own estate by recording which processes, accounts and hosts perform these reads during a baseline period you define. Then alert when the same read comes from an interactive session, an unexpected parent process, a host outside the expected population, or an account that has just signed in from an unfamiliar location. Because a policy read is low severity on its own, pair the rule with a follow-on signal such as account or group enumeration within a short window. Give every allowlist entry an owner and a review date so exceptions do not become permanent blind spots.
Can password policy reads be logged on each platform we run?
Logging depends on the platform and on what you have enabled, so confirm it per platform. On Windows, process creation auditing with command line capture is the usual starting point, alongside the audit settings for account management. On Linux and macOS, the answer depends on whether your audit framework, process accounting or endpoint telemetry records executed commands and reads of policy configuration files. For directory and cloud identity, policy is usually exposed through administrative APIs whose audit logs record the calling principal, which can give a clearer caller record than endpoint logs in some estates. Validate each platform by performing an authorized policy read on a test host and checking what reaches your collector. Map the results to the Process Creation and Command Execution data components in ATT&CK, and record every gap as a named finding with an owner.
How often should we re-validate T1201 detections after an ATT&CK release?
Re-validate whenever you move to a new ATT&CK version, and after any change to your logging pipeline or endpoint agents. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Releases can rename, deprecate or revoke techniques, and v18 replaced technique-level detections with detection strategies and analytics, so a rule written against an older mapping may need its references updated even when its logic still works. Record the ATT&CK version each rule targets in its metadata, then review the ATT&CK updates page at each release. Your own review cadence is a decision for your governance team. Confirm it against your change management policy and your assessment obligations.
How should we monitor cloud identity policy APIs for T1201 activity?
Ingest the audit logs from your identity provider and cloud control plane, then alert on policy-read calls made by principals outside your administrative baseline. The useful fields are the caller, the source address, the API operation, the result and the time, and these should be normalized into the same schema as your endpoint events. Correlate policy reads with sign-in events, since a read that follows an unusual authentication is more informative than the read alone. Confirm which policy-related events your provider records, which log tiers include them, and how long they are retained, because some of these logs are off by default or kept for shorter periods than endpoint logs. Test the rule by running an authorized read from a known administrative account and from a non-administrative test account, then confirm both produce the expected records.
What evidence do auditors expect for password policy discovery monitoring?
Auditors and certification bodies decide what evidence is sufficient, and DeployOpen prepares the systems, controls and records for their review without issuing audit reports or attestations. Typical evidence includes the written detection rule with its ATT&CK version, the data sources it depends on, and the alert samples produced during testing. Add the allowlist with owners and review dates, the records of each validation run in your cyber range, and the runbook showing how responders triage a hit. Map the controls you rely on to the ATT&CK mitigation named Password Policies and to the relevant control IDs in the framework your auditor uses. Keep log retention settings and access records for the monitoring system itself, since reviewers often ask whether the evidence can be trusted.
Can our own security team run T1201 detections without outside help?
A team can run these detections in-house if it has the telemetry, detection engineering time and a test environment that matches production closely enough to validate results. The main requirements are an owner for the rule lifecycle, access to the endpoint and identity logs, and a repeatable way to test changes before they reach production. Gaps usually appear in cloud identity logging and in the review of allowlists, which tend to drift without a named owner. DeployOpen can take on part of this work under a fixed scope agreed in writing before work starts, covering implementation, testing, cyber range exercises or training, and ongoing support can be added as a retainer. Ask any provider to state which of these items it will deliver and which remain with your team.
What does a cyber range exercise for password policy discovery prove?
A cyber range exercise shows that the detection path works end to end in a controlled environment. It confirms that an authorized policy read on a lab host produces the expected events, that those events reach your collector and SIEM, that the rule fires, and that responders follow the runbook to a documented outcome. It does not prove that every variant of password policy discovery will be caught, and it does not replace continuous testing or review after each ATT&CK release. Define the success criteria before the exercise, including which fields must appear in each record and what the expected alert severity is. Record the results with timestamps and keep them with the rule, so the exercise can be repeated and compared over time.
How DeployOpen builds T1201 detections and range exercises
DeployOpen works on T1201 Password policy discovery as a fixed-scope engagement inside your own environment. We map the telemetry you already collect to the detection logic, test it in a private cyber range, and leave you with documented, repeatable detections your team can run and maintain.
How we scope
- Confirm which platforms are in scope for T1201, such as Windows, Linux, macOS and IaaS accounts.
- Inventory the Process Creation, Command Execution and User Account Metadata sources already reaching your SIEM.
- Record the ATT&CK version the detection mapping targets, so later releases do not silently change coverage.
How we build
- Write detection logic for password policy queries in open formats, such as Sigma rules, and map it to Wazuh or Security Onion.
- Test log parsing and field normalization so policy enumeration commands are reliably recognized across hosts.
- Document the expected false positives, such as legitimate administrative audits, and the tuning used to handle them.
How we hand over
- Deliver rule files, data source requirements, and a validation runbook your analysts can rerun after changes.
- Rehearse the detection in a private cyber range with scripted T1201 activity and record the alert results.
- Provide a response playbook covering triage, scoping of the account involved, and review of the affected password policy settings.
How we support
- Ongoing support, upgrades and continuous testing of the T1201 detections are available as a retainer.
- Revisit mappings when MITRE releases a new ATT&CK version that renames or deprecates related content.
- Confirm with your team which mitigations, such as Password Policies, are enforced and how their evidence is retained.
