- Home
- Techniques
- Enterprise
- Modify Authentication Process
- Domain Controller Authentication
Modify Authentication Process: Domain Controller Authentication
Other sub-techniques of Modify Authentication Process (3)
| ID | Name |
|---|---|
| T1556.001 | Domain Controller Authentication |
| T1556.002 | Password Filter DLL |
| T1556.003 | Pluggable Authentication Modules |
Adversaries may patch the authentication process on a domain control to bypass the typical authentication mechanisms and enable access to accounts.
Malware may be used to inject false credentials into the authentication process on a domain control with the intent of creating a backdoor used to access any user’s account and/or credentials (ex: Skeleton Key). Skeleton key works through a patch on an enterprise domain controller authentication process (LSASS) with credentials that adversaries may use to bypass the standard authentication system. Once patched, an adversary can use the injected password to successfully authenticate as any domain user account (until the the skeleton key is erased from memory by a reboot of the domain controller). Authenticated access may enable unfettered access to hosts and/or resources within single-factor authentication environments.[1]
Procedure Examples
| Name | Description |
|---|---|
| Skeleton Key |
Skeleton Key is used to patch an enterprise domain controller authentication process with a backdoor password. It allows adversaries to bypass the standard authentication system to use a defined password for all accounts authenticating to that domain controller.[1] |
Mitigations
| Mitigation | Description |
|---|---|
| Multi-factor Authentication |
Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining control of valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs. |
| Privileged Account Management |
Audit domain and local accounts as well as their permission levels routinely to look for situations that could allow an adversary to gain wide access by obtaining credentials of a privileged account. [2] [3] These audits should also include if default accounts have been enabled, or if new local accounts are created that have not be authorized. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers. [4] |
| Privileged Process Integrity |
Enabled features, such as Protected Process Light (PPL), for LSA.[5] |
Detection
Monitor for calls to OpenProcess that can be used to manipulate lsass.exe running on a domain controller as well as for malicious modifications to functions exported from authentication-related system DLLs (such as cryptdll.dll and samsrv.dll).[1]
Configure robust, consistent account activity audit policies across the enterprise and with externally accessible services.[6] Look for suspicious account behavior across systems that share accounts, either user, admin, or service accounts. Examples: one account logged into multiple systems simultaneously; multiple accounts logged into the same machine simultaneously; accounts logged in at odd times or outside of business hours. Activity may be from interactive login sessions or process ownership from accounts being used to execute binaries on a remote system as a particular account. Correlate other security systems with login information (e.g. a user has an active login session but has not entered the building or does not have VPN access).