Adversaries may patch the authentication process on a domain controller 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 controller 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]

ID: T1556.001

Sub-technique of: T1556

Tactics: Credential Access, Defense Evasion

Platforms: Windows

Permissions Required: Administrator

Data Sources: API monitoring, Authentication logs, DLL monitoring

Version: 1.0

Created: 11 February 2020

Last Modified: 26 August 2020

Version Permalink

Live Version

Procedure Examples

Name	Description
Chimera	Chimera's malware has altered the NTLM authentication program on domain controllers to allow Chimera to login without a valid credential.^[2]
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. ^[3] ^[4] 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. ^[5]
Privileged Process Integrity	Enabled features, such as Protected Process Light (PPL), for LSA.^[6]

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.^[7] 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).

Modify Authentication Process: Domain Controller Authentication

Other sub-techniques of Modify Authentication Process (4)

Procedure Examples

Mitigations

Detection

References