T1556.002: Password Filter DLL
Adversaries may register malicious password filter dynamic link libraries (DLLs) into the authentication process to acquire user credentials as they are validated.
Windows password filters are password policy enforcement mechanisms for both domain and local accounts. Filters are implemented as DLLs containing a method to validate potential passwords against password policies. Filter DLLs can be positioned on local computers for local accounts and/or domain controllers for domain accounts. Before registering new passwords in the Security Accounts Manager (SAM), the Local Security Authority (LSA) requests validation from each registered filter. Any potential changes cannot take effect until every registered filter acknowledges validation.
Adversaries can register malicious password filters to harvest credentials from local computers and/or entire domains. To perform proper validation, filters must receive plain-text credentials from the LSA. A malicious password filter would receive these plain-text credentials every time a password request is made.[1]
Analyst context for executives and security teams
Password Filter DLL abuse is a Windows authentication-process risk: a malicious filter can receive plain-text credentials when password changes are validated. The highest business concern is placement on domain controllers, where the behavior can affect domain accounts rather than a single workstation. This makes it relevant to identity resilience, privileged access protection, incident response scoping, and audit evidence around who can modify authentication components.
Executive priority
Treat this as a tier-zero identity control issue for Windows environments. Leaders should ask whether domain controllers and other sensitive Windows systems have an approved baseline for password filter DLLs, whether changes are monitored, and whether incident response plans account for possible credential exposure after unauthorized authentication-process modification. Budget and control priorities should favor hardened operating system configuration, change control, and evidence collection around authentication components over relying on password policy alone.
Technical view
This sub-technique applies to Windows and sits under Modify Authentication Process across defense impairment, persistence, and credential access. SOC and IR teams should validate visibility into registered password filter DLLs on local computers and especially domain controllers, compare them against an approved baseline, and investigate unauthorized or unexpected additions. Because ATT&CK provides no official detection text for this object, detection engineering should use the related DET0472 strategy, Detect Malicious Password Filter DLL Registration, as the relationship-driven starting point and tune for legitimate enterprise password policy filters to reduce false positives.
Likely telemetry
- Windows operating system configuration state showing registered password filter DLLs
- Domain controller and sensitive Windows host configuration baselines
- File inventory or integrity evidence for authentication-related DLL locations
- Change-management records for approved password policy or authentication components
- Security monitoring or EDR evidence of changes to LSA/SAM authentication-related configuration
Detection direction
- Prioritize domain controllers because a malicious filter there may receive credentials for domain password changes.
- Build or validate detections for unauthorized password filter DLL registration using DET0472 as the supplied ATT&CK detection strategy relationship.
- Maintain an allowlist or baseline of approved password filters and alert on additions, removals, or path changes.
- Tune carefully for legitimate password policy enforcement products or internally developed filters; unexpected does not automatically mean malicious.
- Correlate authentication-process configuration changes with administrative activity and change tickets.
Mitigation priorities
- Apply Operating System Configuration hardening as identified by mitigation M1028, with emphasis on reducing unauthorized changes to Windows authentication components.
- Restrict and review administrative access capable of modifying password filter configuration on domain controllers and sensitive Windows hosts.
- Document approved password filters and require change control for additions or updates.
- Use configuration baselines and integrity monitoring so defenders can prove whether authentication-process components changed.
- If an unauthorized filter is confirmed, handle response as a potential credential exposure event and use local evidence to decide credential reset, containment, and domain controller recovery actions.
Analyst notes and limits
ATT&CK relates this sub-technique to historical use by Strider, OilRig, MirrorFace, and Remsec, which supports threat-informed prioritization but does not by itself indicate current activity in any environment. The revoked T1174 relationship indicates this behavior was previously represented as its own technique and is now T1556.002 under Modify Authentication Process.
The official ATT&CK object does not provide detection text, procedure details, or guaranteed telemetry sources. The guidance above is derived from the supplied description, Windows platform scope, tactics, DET0472 detection-strategy relationship, and M1028 mitigation relationship. Local architecture, logging, EDR coverage, and approved password filter usage are required to determine actual exposure and detection quality.
Password Filter DLL
Adversaries may register malicious password filter dynamic link libraries (DLLs) into the authentication process to acquire user credentials as they are validated.
Windows password filters are password policy enforcement mechanisms for both domain and local accounts. Filters are implemented as DLLs containing a method to validate potential passwords against password policies. Filter DLLs can be positioned on local computers for local accounts and/or domain controllers for domain accounts. Before registering new passwords in the Security Accounts Manager (SAM), the Local Security Authority (LSA) requests validation from each registered filter. Any potential changes cannot take effect until every registered filter acknowledges validation.
Adversaries can register malicious password filters to harvest credentials from local computers and/or entire domains. To perform proper validation, filters must receive plain-text credentials from the LSA. A malicious password filter would receive these plain-text credentials every time a password request is made.[1]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1556 | Modify Authentication Process | This object subtechnique of Modify Authentication Process. |
| Enterprise | T1174 | Password Filter DLL | Password Filter DLL revoked by this object. |
Groups, software, and campaigns
G0049: OilRig
OilRig is a suspected Iranian threat group that has targeted Middle Eastern and international victims since at least 2014. The group has targeted a variety of sectors, including financial, government, energy, chemical, and telecommunications. It appears the group carries out supply chain attacks, leveraging the trust relationship between organizations to attack their primary targets. The group works on behalf of the Iranian government based on infrastructure details that contain references to Iran, use of Iranian infrastructure, and targeting that aligns with nation-state interests.[1][2][3][4][5][6][7]
G0041: Strider
G1054: MirrorFace
MirrorFace is a People's Republic of China (PRC)-aligned cyberespionage actor believed to be a subgroup under the menuPass umbrella based on targeting, tools, and infrastructure overlaps. MirrorFace has been active since at least 2019, at first exclusively targeting Japanese organizations across the media, defense, diplomatic, financial, manufacturing, and academic sectors. Subsequent MirrorFace operations included targets in Central Europe and featured use of LODEINFO, HiddenFace, and UPPERCUT malware.[1][2][3][4][5][6]
S0125: Remsec
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 3.0 | Current bundle | 72984c554be9… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Carnal Ownage Password Filters Sept 2013
Fuller, R. (2013, September 11). Stealing passwords every time they change. Retrieved November 21, 2017.
Open source URL -
[2]
mitre-attack T1556.002Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.