Presented by: Ashwin (Microsoft Azure MVP)
Mimikatz is a credential dumper capable of obtaining plaintext Windows account logins and passwords, along with many other features that make it useful for testing the security of networks.
Source:
MITRE ATT&CK® Matrix for Enterprise
Now, let's see the details around the series of events associated with this software in chronological order, and how we can work to mitigate or detect these activities.
The Mimikatz credential dumper has been extended to include Skeleton Key domain controller authentication bypass functionality. The LSADUMP::ChangeNTLM and LSADUMP::SetNTLM modules can also manipulate the password hash of an account without knowing the clear text value.
Adversaries may manipulate accounts to maintain access to victim systems. Account manipulation may consist of any action that preserves adversary access to a compromised account, such as modifying credentials or permission groups. These actions could also include account activity designed to subvert security policies, such as performing iterative password updates to bypass password duration policies and preserve the life of compromised credentials. In order to create or manipulate accounts, the adversary must already have sufficient permissions on systems or the domain.
Multi-factor Authentication
Use multi-factor authentication for user and privileged accounts.
Network Segmentation
Configure access controls and firewalls to limit access to critical systems and domain controllers. Most cloud environments support separate virtual private cloud (VPC) instances that enable further segmentation of cloud systems.
Operating System Configuration
Protect domain controllers by ensuring proper security configuration for critical servers to limit access by potentially unnecessary protocols and services, such as SMB file sharing.
Privileged Account Management
Do not allow domain administrator accounts to be used for day-to-day operations that may expose them to potential adversaries on unprivileged systems.
Collect events that correlate with changes to account objects and/or permissions on systems and the domain, such as event IDs 4738, 4728 and 4670. Monitor for modification of accounts in correlation with other suspicious activity. Changes may occur at unusual times or from unusual systems. Especially flag events where the subject and target accounts differ or that include additional flags such as changing a password without knowledge of the old password.
Monitor for use of credentials at unusual times or to unusual systems or services. This may also correlate with other suspicious activity.
Monitor for unusual permissions changes that may indicate excessively broad permissions being granted to compromised accounts.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Modification
Changes made to a file, or its access permissions and attributes, typically to alter the contents of the targeted file (ex: Windows EID 4670 or Sysmon EID 2)
Group: Group Modification
Changes made to a group, such as membership, name, or permissions (ex: Windows EID 4728 or 4732, AWS IAM UpdateGroup)
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
User Account: User Account Modification
Changes made to an account, such as permissions and/or membership in specific groups (ex: Windows EID 4738 or /var/log access/authentication logs)
The Mimikatz credential dumper contains an implementation of an SSP.
Adversaries may abuse security support providers (SSPs) to execute DLLs when the system boots. Windows SSP DLLs are loaded into the Local Security Authority (LSA) process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs.
The SSP configuration is stored in two Registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.
Privileged Process Integrity
Windows 8.1, Windows Server 2012 R2, and later versions may make LSA run as a Protected Process Light (PPL) by setting the Registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL, which requires all SSP DLLs to be signed by Microsoft.
Monitor the Registry for changes to the SSP Registry keys. Monitor the LSA process for DLL loads. Windows 8.1 and Windows Server 2012 R2 may generate events when unsigned SSP DLLs try to load into the LSA by setting the Registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe with AuditLevel = 8.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Module: Module Load
Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)
Windows Registry: Windows Registry Key Modification
Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)
Mimikatz's MISC::AddSid module can appended any SID or user/group account to a user's SID-History. Mimikatz also utilizes SID-History Injection to expand the scope of other components such as generated Kerberos Golden Tickets and DCSync beyond a single domain.
Adversaries may use SID-History Injection to escalate privileges and bypass access controls. The Windows security identifier (SID) is a unique value that identifies a user or group account. SIDs are used by Windows security in both security descriptors and access tokens. An account can hold additional SIDs in the SID-History Active Directory attribute, allowing inter-operable account migration between domains (e.g., all values in SID-History are included in access tokens).
With Domain Administrator (or equivalent) rights, harvested or well-known SID values may be inserted into SID-History to enable impersonation of arbitrary users/groups such as Enterprise Administrators. This manipulation may result in elevated access to local resources and/or access to otherwise inaccessible domains via lateral movement techniques such as Remote Services, SMB/Windows Admin Shares, or Windows Remote Management.
Active Directory Configuration
Clean up SID-History attributes after legitimate account migration is complete.
Consider applying SID Filtering to interforest trusts, such as forest trusts and external trusts, to exclude SID-History from requests to access domain resources. SID Filtering ensures that any authentication requests over a trust only contain SIDs of security principals from the trusted domain (i.e preventing the trusted domain from claiming a user has membership in groups outside of the domain).
SID Filtering of forest trusts is enabled by default, but may have been disabled in some cases to allow a child domain to transitively access forest trusts. SID Filtering of external trusts is automatically enabled on all created external trusts using Server 2003 or later domain controllers. However note that SID Filtering is not automatically applied to legacy trusts or may have been deliberately disabled to allow inter-domain access to resources.
SID Filtering can be applied by:
Examine data in user's SID-History attributes using the PowerShell Get-ADUser cmdlet, especially users who have SID-History values from the same domain. Also monitor account management events on Domain Controllers for successful and failed changes to SID-History.
Monitor for Windows API calls to the DsAddSidHistory function.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Process: OS API Execution
Operating system function/method calls executed by a process
User Account: User Account Metadata
Contextual data about an account, which may include a username, user ID, environmental data, etc.
The Mimikatz credential dumper contains an implementation of an SSP.
Adversaries may abuse security support providers (SSPs) to execute DLLs when the system boots. Windows SSP DLLs are loaded into the Local Security Authority (LSA) process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs.
The SSP configuration is stored in two Registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.
Privileged Process Integrity
Windows 8.1, Windows Server 2012 R2, and later versions may make LSA run as a Protected Process Light (PPL) by setting the Registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL, which requires all SSP DLLs to be signed by Microsoft.
Monitor the Registry for changes to the SSP Registry keys. Monitor the LSA process for DLL loads. Windows 8.1 and Windows Server 2012 R2 may generate events when unsigned SSP DLLs try to load into the LSA by setting the Registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe with AuditLevel = 8.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Module: Module Load
Attaching a module into the memory of a process/program, typically to access shared resources/features provided by the module (ex: Sysmon EID 7)
Windows Registry: Windows Registry Key Modification
Changes made to a Registry Key and/or Key value (ex: Windows EID 4657 or Sysmon EID 13|14)
Mimikatz's MISC::AddSid module can appended any SID or user/group account to a user's SID-History. Mimikatz also utilizes SID-History Injection to expand the scope of other components such as generated Kerberos Golden Tickets and DCSync beyond a single domain.
Adversaries may use SID-History Injection to escalate privileges and bypass access controls. The Windows security identifier (SID) is a unique value that identifies a user or group account. SIDs are used by Windows security in both security descriptors and access tokens. An account can hold additional SIDs in the SID-History Active Directory attribute, allowing inter-operable account migration between domains (e.g., all values in SID-History are included in access tokens).
With Domain Administrator (or equivalent) rights, harvested or well-known SID values may be inserted into SID-History to enable impersonation of arbitrary users/groups such as Enterprise Administrators. This manipulation may result in elevated access to local resources and/or access to otherwise inaccessible domains via lateral movement techniques such as Remote Services, SMB/Windows Admin Shares, or Windows Remote Management.
Active Directory Configuration
Clean up SID-History attributes after legitimate account migration is complete.
Consider applying SID Filtering to interforest trusts, such as forest trusts and external trusts, to exclude SID-History from requests to access domain resources. SID Filtering ensures that any authentication requests over a trust only contain SIDs of security principals from the trusted domain (i.e preventing the trusted domain from claiming a user has membership in groups outside of the domain).
SID Filtering of forest trusts is enabled by default, but may have been disabled in some cases to allow a child domain to transitively access forest trusts. SID Filtering of external trusts is automatically enabled on all created external trusts using Server 2003 or later domain controllers. However note that SID Filtering is not automatically applied to legacy trusts or may have been deliberately disabled to allow inter-domain access to resources.
SID Filtering can be applied by:
Examine data in user's SID-History attributes using the PowerShell Get-ADUser cmdlet, especially users who have SID-History values from the same domain. Also monitor account management events on Domain Controllers for successful and failed changes to SID-History.
Monitor for Windows API calls to the DsAddSidHistory function.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Process: OS API Execution
Operating system function/method calls executed by a process
User Account: User Account Metadata
Contextual data about an account, which may include a username, user ID, environmental data, etc.
Mimikatz’s LSADUMP::DCShadow module can be used to make AD updates by temporarily setting a computer to be a DC.
Adversaries may register a rogue Domain Controller to enable manipulation of Active Directory data. DCShadow may be used to create a rogue Domain Controller (DC). DCShadow is a method of manipulating Active Directory (AD) data, including objects and schemas, by registering (or reusing an inactive registration) and simulating the behavior of a DC. Once registered, a rogue DC may be able to inject and replicate changes into AD infrastructure for any domain object, including credentials and keys.
Registering a rogue DC involves creating a new server and nTDSDSA objects in the Configuration partition of the AD schema, which requires Administrator privileges (either Domain or local to the DC) or the KRBTGT hash.
This technique may bypass system logging and security monitors such as security information and event management (SIEM) products (since actions taken on a rogue DC may not be reported to these sensors). The technique may also be used to alter and delete replication and other associated metadata to obstruct forensic analysis. Adversaries may also utilize this technique to perform SID-History Injection and/or manipulate AD objects (such as accounts, access control lists, schemas) to establish backdoors for Persistence.
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
Monitor and analyze network traffic associated with data replication (such as calls to DrsAddEntry, DrsReplicaAdd, and especially GetNCChanges) between DCs as well as to/from non DC hosts. DC replication will naturally take place every 15 minutes but can be triggered by an attacker or by legitimate urgent changes (ex: passwords). Also consider monitoring and alerting on the replication of AD objects (Audit Detailed Directory Service Replication Events 4928 and 4929).
Leverage AD directory synchronization (DirSync) to monitor changes to directory state using AD replication cookies.
Baseline and periodically analyze the Configuration partition of the AD schema and alert on creation of nTDSDSA objects.
Investigate usage of Kerberos Service Principal Names (SPNs), especially those associated with services (beginning with "GC/") by computers not present in the DC organizational unit (OU). The SPN associated with the Directory Replication Service (DRS) Remote Protocol interface (GUID E3514235–4B06–11D1-AB04–00C04FC2DCD2) can be set without logging. A rogue DC must authenticate as a service using these two SPNs for the replication process to successfully complete.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Object Creation
Initial construction of a new active directory object (ex: Windows EID 5137)
Active Directory: Active Directory Object Modification
Changes made to an active directory object (ex: Windows EID 5163 or 5136)
Network Traffic: Network Traffic Content
Logged network traffic data showing both protocol header and body values (ex: PCAP)
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Mimikatz's SEKURLSA::Pth module can impersonate a user, with only a password hash, to execute arbitrary commands.
Adversaries may "pass the hash" using stolen password hashes to move laterally within an environment, bypassing normal system access controls. Pass the hash (PtH) is a method of authenticating as a user without having access to the user's cleartext password. This method bypasses standard authentication steps that require a cleartext password, moving directly into the portion of the authentication that uses the password hash.
When performing PtH, valid password hashes for the account being used are captured using a Credential Access technique. Captured hashes are used with PtH to authenticate as that user. Once authenticated, PtH may be used to perform actions on local or remote systems.
Adversaries may also use stolen password hashes to "overpass the hash." Similar to PtH, this involves using a password hash to authenticate as a user but also uses the password hash to create a valid Kerberos ticket. This ticket can then be used to perform Pass the Ticket attacks.
Privileged Account Management
Limit credential overlap across systems to prevent the damage of credential compromise and reduce the adversary's ability to perform Lateral Movement between systems.
Update Software
Apply patch KB2871997 to Windows 7 and higher systems to limit the default access of accounts in the local administrator group.
User Account Control
Enable pass the hash mitigations to apply UAC restrictions to local accounts on network logon. The associated Registry key is located HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
Through GPO: Computer Configuration > [Policies] > Administrative Templates > SCM: Pass the Hash Mitigations: Apply UAC restrictions to local accounts on network logons.
User Account Management
Do not allow a domain user to be in the local administrator group on multiple systems.
Audit all logon and credential use events and review for discrepancies. Unusual remote logins that correlate with other suspicious activity (such as writing and executing binaries) may indicate malicious activity. NTLM LogonType 3 authentications that are not associated to a domain login and are not anonymous logins are suspicious.
Event ID 4768 and 4769 will also be generated on the Domain Controller when a user requests a new ticket granting ticket or service ticket. These events combined with the above activity may be indicative of an overpass the hash attempt.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Credential Request
A user requested active directory credentials, such as a ticket or token (ex: Windows EID 4769)
Logon Session: Logon Session Creation
Initial construction of a new user logon session (ex: Windows EID 4624, /var/log/utmp, or /var/log/wmtp)
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Mimikatz’s LSADUMP::DCSync and KERBEROS::PTT modules implement the three steps required to extract the krbtgt account hash and create/use Kerberos tickets.
Adversaries may "pass the ticket" using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Pass the ticket (PtT) is a method of authenticating to a system using Kerberos tickets without having access to an account's password. Kerberos authentication can be used as the first step to lateral movement to a remote system.
When preforming PtT, valid Kerberos tickets for Valid Accounts are captured by OS Credential Dumping. A user's service tickets or ticket granting ticket (TGT) may be obtained, depending on the level of access. A service ticket allows for access to a particular resource, whereas a TGT can be used to request service tickets from the Ticket Granting Service (TGS) to access any resource the user has privileges to access.
A Silver Ticket can be obtained for services that use Kerberos as an authentication mechanism and are used to generate tickets to access that particular resource and the system that hosts the resource (e.g., SharePoint).
A Golden Ticket can be obtained for the domain using the Key Distribution Service account KRBTGT account NTLM hash, which enables generation of TGTs for any account in Active Directory.
Adversaries may also create a valid Kerberos ticket using other user information, such as stolen password hashes or AES keys. For example, "overpassing the hash" involves using a NTLM password hash to authenticate as a user (i.e. Pass the Hash) while also using the password hash to create a valid Kerberos ticket.
Active Directory Configuration
To contain the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it. For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.
Password Policies
Ensure that local administrator accounts have complex, unique passwords.
Privileged Account Management
Limit domain admin account permissions to domain controllers and limited servers. Delegate other admin functions to separate accounts.
User Account Management
Do not allow a user to be a local administrator for multiple systems.
Audit all Kerberos authentication and credential use events and review for discrepancies. Unusual remote authentication events that correlate with other suspicious activity (such as writing and executing binaries) may indicate malicious activity.
Event ID 4769 is generated on the Domain Controller when using a golden ticket after the KRBTGT password has been reset twice, as mentioned in the mitigation section. The status code 0x1F indicates the action has failed due to "Integrity check on decrypted field failed" and indicates misuse by a previously invalidated golden ticket.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Credential Request
A user requested active directory credentials, such as a ticket or token (ex: Windows EID 4769)
Logon Session: Logon Session Creation
Initial construction of a new user logon session (ex: Windows EID 4624, /var/log/utmp, or /var/log/wmtp)
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from the LSASS Memory.
Adversaries may attempt to access credential material stored in the process memory of the Local Security Authority Subsystem Service (LSASS). After a user logs on, the system generates and stores a variety of credential materials in LSASS process memory. These credential materials can be harvested by an administrative user or SYSTEM and used to conduct Lateral Movement using Use Alternate Authentication Material.
As well as in-memory techniques, the LSASS process memory can be dumped from the target host and analyzed on a local system.
For example, on the target host use procdump:
Locally, mimikatz can be run using:
Built-in Windows tools such as comsvcs.dll can also be used:
Windows Security Support Provider (SSP) DLLs are loaded into LSSAS process at system start. Once loaded into the LSA, SSP DLLs have access to encrypted and plaintext passwords that are stored in Windows, such as any logged-on user's Domain password or smart card PINs. The SSP configuration is stored in two Registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages and HKLM\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages. An adversary may modify these Registry keys to add new SSPs, which will be loaded the next time the system boots, or when the AddSecurityPackage Windows API function is called.
The following SSPs can be used to access credentials:
Behavior Prevention on Endpoint
On Windows 10, enable Attack Surface Reduction (ASR) rules to secure LSASS and prevent credential stealing.
Credential Access Protection
With Windows 10, Microsoft implemented new protections called Credential Guard to protect the LSA secrets that can be used to obtain credentials through forms of credential dumping. It is not configured by default and has hardware and firmware system requirements. It also does not protect against all forms of credential dumping.
Operating System Configuration
Consider disabling or restricting NTLM. Consider disabling WDigest authentication.
Password Policies
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Privileged Account Management
Do not put user or admin domain accounts in the local administrator groups across systems unless they are tightly controlled, as this is often equivalent to having a local administrator account with the same password on all systems. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
Privileged Process Integrity
On Windows 8.1 and Windows Server 2012 R2, enable Protected Process Light for LSA.
User Training
Limit credential overlap across accounts and systems by training users and administrators not to use the same password for multiple accounts.
Monitor for unexpected processes interacting with LSASS.exe. Common credential dumpers such as Mimikatz access LSASS.exe by opening the process, locating the LSA secrets key, and decrypting the sections in memory where credential details are stored. Credential dumpers may also use methods for reflective Process Injection to reduce potential indicators of malicious activity.
On Windows 8.1 and Windows Server 2012 R2, monitor Windows Logs for LSASS.exe creation to verify that LSASS started as a protected process.
Monitor processes and command-line arguments for program execution that may be indicative of credential dumping. Remote access tools may contain built-in features or incorporate existing tools like Mimikatz. PowerShell scripts also exist that contain credential dumping functionality, such as PowerSploit's Invoke-Mimikatz module, which may require additional logging features to be configured in the operating system to collect necessary information for analysis.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Process: OS API Execution
Operating system function/method calls executed by a process
Process: Process Access
Opening of a process by another process, typically to read memory of the target process (ex: Sysmon EID 10)
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from the SAM table.
Adversaries may attempt to extract credential material from the Security Account Manager (SAM) database either through in-memory techniques or through the Windows Registry where the SAM database is stored. The SAM is a database file that contains local accounts for the host, typically those found with the net user command. Enumerating the SAM database requires SYSTEM level access.
A number of tools can be used to retrieve the SAM file through in-memory techniques:
Alternatively, the SAM can be extracted from the Registry with Reg:
Creddump7 can then be used to process the SAM database locally to retrieve hashes.
Notes: RID 500 account is the local, built-in administrator. RID 501 is the guest account.* User accounts start with a RID of 1,000+.
Operating System Configuration
Consider disabling or restricting NTLM.
Password Policies
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Privileged Account Management
Do not put user or admin domain accounts in the local administrator groups across systems unless they are tightly controlled, as this is often equivalent to having a local administrator account with the same password on all systems. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
User Training
Limit credential overlap across accounts and systems by training users and administrators not to use the same password for multiple accounts.
Hash dumpers open the Security Accounts Manager (SAM) on the local file system (%SystemRoot%/system32/config/SAM) or create a dump of the Registry SAM key to access stored account password hashes. Some hash dumpers will open the local file system as a device and parse to the SAM table to avoid file access defenses. Others will make an in-memory copy of the SAM table before reading hashes. Detection of compromised Valid Accounts in-use by adversaries may help as well.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Windows Registry: Windows Registry Key Access
Opening a Registry Key, typically to read the associated value (ex: Windows EID 4656)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from the LSA.
Adversaries with SYSTEM access to a host may attempt to access Local Security Authority (LSA) secrets, which can contain a variety of different credential materials, such as credentials for service accounts. LSA secrets are stored in the registry at HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets. LSA secrets can also be dumped from memory.
Reg can be used to extract from the Registry. Mimikatz can be used to extract secrets from memory.
Password Policies
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Privileged Account Management
Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
User Training
Limit credential overlap across accounts and systems by training users and administrators not to use the same password for multiple accounts.
Monitor processes and command-line arguments for program execution that may be indicative of credential dumping. Remote access tools may contain built-in features or incorporate existing tools like Mimikatz. PowerShell scripts also exist that contain credential dumping functionality, such as PowerSploit's Invoke-Mimikatz module, which may require additional logging features to be configured in the operating system to collect necessary information for analysis.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
Windows Registry: Windows Registry Key Access
Opening a Registry Key, typically to read the associated value (ex: Windows EID 4656)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from DCSync/NetSync.
Adversaries may attempt to access credentials and other sensitive information by abusing a Windows Domain Controller's application programming interface (API) to simulate the replication process from a remote domain controller using a technique called DCSync.
Members of the Administrators, Domain Admins, and Enterprise Admin groups or computer accounts on the domain controller are able to run DCSync to pull password data from Active Directory, which may include current and historical hashes of potentially useful accounts such as KRBTGT and Administrators. The hashes can then in turn be used to create a Golden Ticket for use in Pass the Ticket or change an account's password as noted in Account Manipulation.
DCSync functionality has been included in the "lsadump" module in Mimikatz. Lsadump also includes NetSync, which performs DCSync over a legacy replication protocol.
Active Directory Configuration
Manage the access control list for "Replicating Directory Changes" and other permissions associated with domain controller replication.
Password Policies
Ensure that local administrator accounts have complex, unique passwords across all systems on the network.
Privileged Account Management
Do not put user or admin domain accounts in the local administrator groups across systems unless they are tightly controlled, as this is often equivalent to having a local administrator account with the same password on all systems. Follow best practices for design and administration of an enterprise network to limit privileged account use across administrative tiers.
Monitor domain controller logs for replication requests and other unscheduled activity possibly associated with DCSync. Also monitor for network protocols and other replication requests from IPs not associated with known domain controllers.
Note: Domain controllers may not log replication requests originating from the default domain controller account.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Object Access
Opening of an active directory object, typically to collect/read its value (ex: Windows EID 4661)
Network Traffic: Network Traffic Content
Logged network traffic data showing both protocol header and body values (ex: PCAP)
Network Traffic: Network Traffic Flow
Summarized network packet data, with metrics, such as protocol headers and volume (ex: Netflow or Zeek http.log)
Mimikatz's CRYPTO::Extract module can extract keys by interacting with Windows cryptographic application programming interface (API) functions.
Adversaries may search for private key certificate files on compromised systems for insecurely stored credentials. Private cryptographic keys and certificates are used for authentication, encryption/decryption, and digital signatures. Common key and certificate file extensions include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc.
Adversaries may also look in common key directories, such as ~/.ssh for SSH keys on * nix-based systems or C:\Users\(username)\.ssh\ on Windows. These private keys can be used to authenticate to Remote Services like SSH or for use in decrypting other collected files such as email.
Adversary tools have been discovered that search compromised systems for file extensions relating to cryptographic keys and certificates.
Some private keys require a password or passphrase for operation, so an adversary may also use Input Capture for keylogging or attempt to Brute Force the passphrase off-line.
Audit
Ensure only authorized keys are allowed access to critical resources and audit access lists regularly.
Encrypt Sensitive Information
When possible, store keys on separate cryptographic hardware instead of on the local system.
Password Policies
Use strong passphrases for private keys to make cracking difficult.
Restrict File and Directory Permissions
Ensure permissions are properly set on folders containing sensitive private keys to prevent unintended access.
Monitor access to files and directories related to cryptographic keys and certificates as a means for potentially detecting access patterns that may indicate collection and exfiltration activity. Collect authentication logs and look for potentially abnormal activity that may indicate improper use of keys or certificates for remote authentication.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from the credential vault and DPAPI.
Adversaries may search for common password storage locations to obtain user credentials. Passwords are stored in several places on a system, depending on the operating system or application holding the credentials. There are also specific applications that store passwords to make it easier for users manage and maintain. Once credentials are obtained, they can be used to perform lateral movement and access restricted information.
Password Policies
The password for the user's login keychain can be changed from the user's login password. This increases the complexity for an adversary because they need to know an additional password.
Organizations may consider weighing the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is a significant concern, technical controls, policy, and user training may be used to prevent storage of credentials in improper locations.
Monitor system calls, file read events, and processes for suspicious activity that could indicate searching for a password or other activity related to performing keyword searches (e.g. password, pwd, login, store, secure, credentials, etc.) in process memory for credentials. File read events should be monitored surrounding known password storage applications.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Process: OS API Execution
Operating system function/method calls executed by a process
Process: Process Access
Opening of a process by another process, typically to read memory of the target process (ex: Sysmon EID 10)
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Mimikatz performs credential dumping to obtain account and password information useful in gaining access to additional systems and enterprise network resources. It contains functionality to acquire information about credentials in many ways, including from DPAPI.
Adversaries may acquire credentials from web browsers by reading files specific to the target browser. Web browsers commonly save credentials such as website usernames and passwords so that they do not need to be entered manually in the future. Web browsers typically store the credentials in an encrypted format within a credential store; however, methods exist to extract plaintext credentials from web browsers.
For example, on Windows systems, encrypted credentials may be obtained from Google Chrome by reading a database file, AppData\Local\Google\Chrome\User Data\Default\Login Data and executing a SQL query: SELECT action_url, username_value, password_value FROM logins;. The plaintext password can then be obtained by passing the encrypted credentials to the Windows API function CryptUnprotectData, which uses the victim’s cached logon credentials as the decryption key.
Adversaries have executed similar procedures for common web browsers such as FireFox, Safari, Edge, etc. Windows stores Internet Explorer and Microsoft Edge credentials in Credential Lockers managed by the Windows Credential Manager.
Adversaries may also acquire credentials by searching web browser process memory for patterns that commonly match credentials.
After acquiring credentials from web browsers, adversaries may attempt to recycle the credentials across different systems and/or accounts in order to expand access. This can result in significantly furthering an adversary's objective in cases where credentials gained from web browsers overlap with privileged accounts (e.g. domain administrator).
Password Policies
Organizations may consider weighing the risk of storing credentials in web browsers. If web browser credential disclosure is a significant concern, technical controls, policy, and user training may be used to prevent storage of credentials in web browsers.
Identify web browser files that contain credentials such as Google Chrome’s Login Data database file: AppData\Local\Google\Chrome\User Data\Default\Login Data. Monitor file read events of web browser files that contain credentials, especially when the reading process is unrelated to the subject web browser. Monitor process execution logs to include PowerShell Transcription focusing on those that perform a combination of behaviors including reading web browser process memory, utilizing regular expressions, and those that contain numerous keywords for common web applications (Gmail, Twitter, Office365, etc.).
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Process: OS API Execution
Operating system function/method calls executed by a process
Process: Process Access
Opening of a process by another process, typically to read memory of the target process (ex: Sysmon EID 10)
Mimikatz contains functionality to acquire credentials from the Windows Credential Manager.
Adversaries may acquire credentials from the Windows Credential Manager. The Credential Manager stores credentials for signing into websites, applications, and/or devices that request authentication through NTLM or Kerberos in Credential Lockers (previously known as Windows Vaults).
The Windows Credential Manager separates website credentials from application or network credentials in two lockers. As part of Credentials from Web Browsers, Internet Explorer and Microsoft Edge website credentials are managed by the Credential Manager and are stored in the Web Credentials locker. Application and network credentials are stored in the Windows Credentials locker.
Credential Lockers store credentials in encrypted .vcrd files, located under %Systemdrive%\Users\[Username]\AppData\Local\Microsoft\[Vault/Credentials]\. The encryption key can be found in a file named Policy.vpol, typically located in the same folder as the credentials.
Adversaries may list credentials managed by the Windows Credential Manager through several mechanisms. vaultcmd.exe is a native Windows executable that can be used to enumerate credentials stored in the Credential Locker through a command-line interface. Adversaries may gather credentials by reading files located inside of the Credential Lockers. Adversaries may also abuse Windows APIs such as CredEnumerateA to list credentials managed by the Credential Manager.
Adversaries may use password recovery tools to obtain plain text passwords from the Credential Manager.
Disable or Remove Feature or Program
Consider enabling the "Network access: Do not allow storage of passwords and credentials for network authentication" setting that will prevent network credentials from being stored by the Credential Manager.
Monitor process and command-line parameters of vaultcmd.exe for suspicious activity, such as listing credentials from the Windows Credentials locker (i.e., vaultcmd /listcreds:"Windows Credentials").
Consider monitoring API calls such as CredEnumerateA that may list credentials from the Windows Credential Manager.
Consider monitoring file reads to Vault locations, %Systemdrive%\Users\[Username]\AppData\Local\Microsoft\[Vault/Credentials]\, for suspicious activity.
Monitoring the following activities in your Organisation can help you detect this technique.
Command: Command Execution
Invoking a computer program directive to perform a specific task (ex: Windows EID 4688 of cmd.exe showing command-line parameters, ~/.bash_history, or ~/.zsh_history)
File: File Access
Opening a file, which makes the file contents available to the requestor (ex: Windows EID 4663)
Process: OS API Execution
Operating system function/method calls executed by a process
Process: Process Creation
Birth of a new running process (ex: Sysmon EID 1 or Windows EID 4688)
Mimikatz's kerberos module can create golden tickets.
Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT), also known as a golden ticket. Golden tickets enable adversaries to generate authentication material for any account in Active Directory.
Using a golden ticket, adversaries are then able to request ticket granting service (TGS) tickets, which enable access to specific resources. Golden tickets require adversaries to interact with the Key Distribution Center (KDC) in order to obtain TGS.
The KDC service runs all on domain controllers that are part of an Active Directory domain. KRBTGT is the Kerberos Key Distribution Center (KDC) service account and is responsible for encrypting and signing all Kerberos tickets. The KRBTGT password hash may be obtained using OS Credential Dumping and privileged access to a domain controller.
Active Directory Configuration
For containing the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it. For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.
Privileged Account Management
Limit domain admin account permissions to domain controllers and limited servers. Delegate other admin functions to separate accounts.
Monitor for anomalous Kerberos activity, such as malformed or blank fields in Windows logon/logoff events (Event ID 4624, 4672, 4634), RC4 encryption within TGTs, and TGS requests without preceding TGT requests.
Monitor the lifetime of TGT tickets for values that differ from the default domain duration.
Monitor for indications of Pass the Ticket being used to move laterally.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Credential Request
A user requested active directory credentials, such as a ticket or token (ex: Windows EID 4769)
Logon Session: Logon Session Metadata
Contextual data about a logon session, such as username, logon type, access tokens (security context, user SIDs, logon identifiers, and logon SID), and any activity associated within it
Mimikatz's kerberos module can create silver tickets.
Adversaries who have the password hash of a target service account (e.g. SharePoint, MSSQL) may forge Kerberos ticket granting service (TGS) tickets, also known as silver tickets. Kerberos TGS tickets are also known as service tickets.
Silver tickets are more limited in scope in than golden tickets in that they only enable adversaries to access a particular resource (e.g. MSSQL) and the system that hosts the resource; however, unlike golden tickets, adversaries with the ability to forge silver tickets are able to create TGS tickets without interacting with the Key Distribution Center (KDC), potentially making detection more difficult.
Password hashes for target services may be obtained using OS Credential Dumping or Kerberoasting.
Encrypt Sensitive Information
Enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible.
Password Policies
Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire.[5] Also consider using Group Managed Service Accounts or another third party product such as password vaulting.
Privileged Account Management
Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.
Monitor for anomalous Kerberos activity, such as malformed or blank fields in Windows logon/logoff events (Event ID 4624, 4634, 4672).
Monitor for unexpected processes interacting with lsass.exe. Common credential dumpers such as Mimikatz access the LSA Subsystem Service (LSASS) process by opening the process, locating the LSA secrets key, and decrypting the sections in memory where credential details, including Kerberos tickets, are stored.
Monitoring the following activities in your Organisation can help you detect this technique.
Logon Session: Logon Session Metadata
Contextual data about a logon session, such as username, logon type, access tokens (security context, user SIDs, logon identifiers, and logon SID), and any activity associated within it
Mimikatz's SEKURLSA::Pth module can impersonate a user, with only a password hash, to execute arbitrary commands.
Adversaries may "pass the hash" using stolen password hashes to move laterally within an environment, bypassing normal system access controls. Pass the hash (PtH) is a method of authenticating as a user without having access to the user's cleartext password. This method bypasses standard authentication steps that require a cleartext password, moving directly into the portion of the authentication that uses the password hash.
When performing PtH, valid password hashes for the account being used are captured using a Credential Access technique. Captured hashes are used with PtH to authenticate as that user. Once authenticated, PtH may be used to perform actions on local or remote systems.
Adversaries may also use stolen password hashes to "overpass the hash." Similar to PtH, this involves using a password hash to authenticate as a user but also uses the password hash to create a valid Kerberos ticket. This ticket can then be used to perform Pass the Ticket attacks.
Privileged Account Management
Limit credential overlap across systems to prevent the damage of credential compromise and reduce the adversary's ability to perform Lateral Movement between systems.
Update Software
Apply patch KB2871997 to Windows 7 and higher systems to limit the default access of accounts in the local administrator group.
User Account Control
Enable pass the hash mitigations to apply UAC restrictions to local accounts on network logon. The associated Registry key is located HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy.
Through GPO: Computer Configuration > [Policies] > Administrative Templates > SCM: Pass the Hash Mitigations: Apply UAC restrictions to local accounts on network logons.
User Account Management
Do not allow a domain user to be in the local administrator group on multiple systems.
Audit all logon and credential use events and review for discrepancies. Unusual remote logins that correlate with other suspicious activity (such as writing and executing binaries) may indicate malicious activity. NTLM LogonType 3 authentications that are not associated to a domain login and are not anonymous logins are suspicious.
Event ID 4768 and 4769 will also be generated on the Domain Controller when a user requests a new ticket granting ticket or service ticket. These events combined with the above activity may be indicative of an overpass the hash attempt.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Credential Request
A user requested active directory credentials, such as a ticket or token (ex: Windows EID 4769)
Logon Session: Logon Session Creation
Initial construction of a new user logon session (ex: Windows EID 4624, /var/log/utmp, or /var/log/wmtp)
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Mimikatz’s LSADUMP::DCSync and KERBEROS::PTT modules implement the three steps required to extract the krbtgt account hash and create/use Kerberos tickets.
Adversaries may "pass the ticket" using stolen Kerberos tickets to move laterally within an environment, bypassing normal system access controls. Pass the ticket (PtT) is a method of authenticating to a system using Kerberos tickets without having access to an account's password. Kerberos authentication can be used as the first step to lateral movement to a remote system.
When preforming PtT, valid Kerberos tickets for Valid Accounts are captured by OS Credential Dumping. A user's service tickets or ticket granting ticket (TGT) may be obtained, depending on the level of access. A service ticket allows for access to a particular resource, whereas a TGT can be used to request service tickets from the Ticket Granting Service (TGS) to access any resource the user has privileges to access.
A Silver Ticket can be obtained for services that use Kerberos as an authentication mechanism and are used to generate tickets to access that particular resource and the system that hosts the resource (e.g., SharePoint).
A Golden Ticket can be obtained for the domain using the Key Distribution Service account KRBTGT account NTLM hash, which enables generation of TGTs for any account in Active Directory.
Adversaries may also create a valid Kerberos ticket using other user information, such as stolen password hashes or AES keys. For example, "overpassing the hash" involves using a NTLM password hash to authenticate as a user (i.e. Pass the Hash) while also using the password hash to create a valid Kerberos ticket.
Active Directory Configuration
To contain the impact of a previously generated golden ticket, reset the built-in KRBTGT account password twice, which will invalidate any existing golden tickets that have been created with the KRBTGT hash and other Kerberos tickets derived from it. For each domain, change the KRBTGT account password once, force replication, and then change the password a second time. Consider rotating the KRBTGT account password every 180 days.
Password Policies
Ensure that local administrator accounts have complex, unique passwords.
Privileged Account Management
Limit domain admin account permissions to domain controllers and limited servers. Delegate other admin functions to separate accounts.
User Account Management
Do not allow a user to be a local administrator for multiple systems.
Audit all Kerberos authentication and credential use events and review for discrepancies. Unusual remote authentication events that correlate with other suspicious activity (such as writing and executing binaries) may indicate malicious activity.
Event ID 4769 is generated on the Domain Controller when using a golden ticket after the KRBTGT password has been reset twice, as mentioned in the mitigation section. The status code 0x1F indicates the action has failed due to "Integrity check on decrypted field failed" and indicates misuse by a previously invalidated golden ticket.
Monitoring the following activities in your Organisation can help you detect this technique.
Active Directory: Active Directory Credential Request
A user requested active directory credentials, such as a ticket or token (ex: Windows EID 4769)
Logon Session: Logon Session Creation
Initial construction of a new user logon session (ex: Windows EID 4624, /var/log/utmp, or /var/log/wmtp)
User Account: User Account Authentication
An attempt by a user to gain access to a network or computing resource, often by providing credentials (ex: Windows EID 4625 or /var/log/auth.log)
Copyright © 2022 AshwinPro