Overview

Initially, my aim with this post was to dig into Mimikatz in greater detail. I had used its more common functions during CRTO and OSCP, but had never explored its more exotic features in any depth. Mimikatz is an enormous tool, so I focused on the lsadump and sekurlsa functions, as they are commonly used for dumping credentials.

I also wanted to focus on providing detail on how this can be detected and monitored, as Mimikatz leverages a number of legitimate features of Windows, which can make it difficult to prevent. All of the work in this article has been performed by a number of excellent researchers – I have simply pulled it together into this article!

As an introduction to Mimikatz and credential providers, I found this blog to be a useful introduction. Initially, I will cover a few new features I uncovered which grabbed my attention. Then I will go through each of the functions, covering what they do, how they can be leveraged and how to defend against it. Finally, I will cover some recommendations to defend against password reuse, and to prevent Mimikatz from gathering credentials.

Interesting Stuff

DCShadow

The lsadump::dcshadow module allows for an attacker with Domain Admin permissions to more stealthily modify settings on any user of their choice. This means an account could have a single property changed to backdoor it, without being as noisy as performing an attack such as DCSync.

Decrypt ‘Isolated’ Credentials

Using sekurlsa::bootkey, we can decrypt blobs which are protected by an isolated LSA process (i.e. behind Credential Guard). With access to the physical memory of a machine, it is possible for Mimikatz to recover the necessary information to decrypt these protected blobs.

Inter-Realm Tickets

With Domain Admin privileges, we can dump the forest trust keys with Mimikatz which we can use to create a forged trust ticket. This will allow us to leverage an alternative high-level persistence mechanism to golden tickets without using the krbtgt account. (Link)

mimilib.dll

This little file can be used to register a custom SSP (Security Support Provider). If this is added to the registry, it will then log any credentials used to access the machine in plaintext, even if Credential Guard is enabled. This default method is well signatured, but I had not come across custom SSPs before. (Link 1, Link 2)

Pass The PRT

“A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10 or newer, Windows Server 2016 and later versions, iOS, and Android devices. It is a JSON Web Token (JWT) specially issued to Microsoft first party token brokers to enable single sign-on (SSO) across the applications used on those devices” – Microsoft

Using the sekurlsa::cloudap module, we can dump the PRT for a machine. With some DPAPI magic, we can then generate cookies for an account for up to 14 days. This allows us to interact with Azure as the compromised user, without needing access to the compromised device. (Link)

The Hacker Tools

This is a site I have seen several people mention, but I had never used it much until now. It is a really handy reference for the various functions which Mimikatz supports. Here are links to the lsadump and sekurlsa pages – thanks Charlie Bromberg!

lsadump::

backupkeys

Overview

The lsadump::backupkeys function allows for the Domain Controller backup DPAPI keys to be dumped

Attacking

This requires Domain Admin privilege and can only be performed against a DC.

Exploiting this means we can export the backup DPAPI keys. This can be done using Mimikatz or using DSInternals (Get-BootKey, Get-ADDBackupKey and Save-DPAPIBlob cmdlets) in this order.

We can then decrypt DPAPI secrets for all users, including decrypting these secrets off the target machine.

Prevention/Detection

This attack is hard to defend against as to leverage this, an attacker has to already have a Domain Admin level of permission. Therefore, limiting access to Tier 0/DC’s is likely the best route.

cache

Overview

lsadump::cache will load cached domain credentials from the registry, these credentials are cached in case the device is unable to connect to a DC, when these values will be used to authenticate the user.

These cached credentials can be found at registry keys HKEY_LOCAL_MACHINE\SECURITY\Cache\NL$1 through to NL$10.

Attacking

This attack requires elevated privileges.

The recovered hashes can be cracked with hashcat, if the hash is transformed into the format “$DCC2$10240#USERNAME#HASH” and mode 2100 is used.

Prevention/Detection

The caching of domain credentials can be restricted via Group Policy. Under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options and set the value for ‘Interactive logon: Number of previous logons to cache (in case domain controller is not available)‘ to 0.

Alternatively, the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon can be set to 0. By default Windows 10 and Server 2016 cache the 10 most recent passwords (i.e. The Winlogon value is set to 10)

changentlm

Overview

lsadump::changentlm allows the password of a user to be changed with an NTLM hash or a plaintext password.

Attacking

This requires access to the users current NTLM hash.

In particular, this technique can be very handy if we have a hash, but need to authenticate with a cleartext platform (Such as Sharepoint/OWA). It allows us to set a known password for an account, then revert it back to the original hash (If we have obtained the hash via DCSync or other means).

Despite these two benefits, there are a couple of key drawbacks. It can only be used once per day and it will not update password on client apps (Such as Outlook on their mobile), so could tip them off.

Prevention/Detection

This activity generates event ID 4723, which has odd characteristics of the subject and target being different users. This should be unusual, as the target should be the only person resetting their password. If an admin does a password reset, it generates event ID 4724

The new password will get added to the password history, which can help correlate events. Additionally, enabling Azure Conditional Access policies to force MFA or restrict logons to trusted network segments can provide another layer of security, although this can be bypassed by the Pass-The-PRT attack (via sekurlsa::cloudap)

dcshadow

Overview

Using lsadump::dcshadow, an attacker can modify any parameter on any user. With some forethought, an attacker could more stealthily backdoor accounts and gain persistence than other better known methods of leveraging Domain Admin permissions.

Attacking

This requires Domain Admin privilege.

As mentioned above, we can modify any permission on any user. There is also a very good technical deep dive on this technique.

Prevention/Detection

There are a few ways of detecting this activity, first we can investigate Event ID 4929 (Detailed Directory Service Replication) from non-DC hosts. Additionally, EID 4662 can be monitored for a rapid creation and deletion of a DC object

Moving away from Event IDs, we can monitor for computers which have an RPC service with a GUID of E3514235–4B06–11D1-AB04–00C04FC2DCD2 exposed, as this should be DC specific. This GUID also features in a characteristic SPN which can be fingerprinted.

dcsync

Overview

One of the classic Active Directory attacks, lsadump::dcsync allows us to perform a DCSync attack. By leveraging the MS-DRSR (Directory Replication Service Remote) protocol, this attack will effectively turn the compromised device into another DC, allowing it to replicate credential material from the other legitimate DC’s.

Attacking

As mentioned above, we can perform the DCSync attack. This requires both the Replicating Directory Changes and Replicating Directory Changes All ACEs. Typically this is limited to DA, EA and DC groups, but it can be mistakenly granted to other users or groups in AD.

DCSync can allow us to compromise the KRBTGT account, allowing golden ticket attacks to be performed, as well as other attacks.

Prevention/Detection

The easiest way of preventing this attack is to improve the security of your AD environment using an attack path auditing solution such as BloodHound. This tool has support for the 2 required permissions (GetChanges and GetChangesAll), as well as having a pre-built query to identify users with these permissions.

Should it not be possible to remediate these permissions in your environment, then you can monitor the network for MS-DRSR traffic coming from non-DC computers, but it is ultimately a far worse solution than preventing the attack in the first place.

lsa

Overview

lsadump::lsa will interact with the LSA server (lsass.exe) in order to dump credentials for a specific user.

Attacking

This function gives us 2 options for interacting with the LSA server, we can either patch it with /patch and return NTLM hashes although this is not recommended. Alternatively we can inject into the lsass.exe process with /inject. We can specify an individual user with the /name or /id parameters.

Prevention/Detection

Follow the defensive recommendations at the end of this post, in particular the guidance on hardening LSASS.

mbc

Overview

I couldn’t find any blogs relating to this, but I believe this function will reveal the MachineBoundCertificate for a given device. This certificate can be generated by Credential Guard.

Attacking

N/A – No publicly known attacks (yet…)

Prevention/Detection

I couldn’t find any articles relating to preventing this behaviour, but there is a good article on confirming that values within msDS-KeyCredentialLink are legitimate. CredentialGuard (And by extension MachineBoundCertificates) can populate this field.

netsync

Overview

lsadump::netsync leverages the Microsoft Netlogon Remote Protocol (MS-NRPC) to allow an attacker to request an NTLM hash for a machine account. This is similar to DCSync, but only for machine accounts. TrustedSec have done an excellent guide to this technique.

Attacking

In order to perform this attack, we need to obtain the NTLM hash of the DC machine account.

After leveraging netsync, we can then create silver tickets as the machine account of our choice.

Prevention/Detection

TrustedSec’s blog post has some good detection measures.

The patch for ZeroLogon (CVE-2020-1472) looks to prevent this attack, unless specific settings are disabled to allow ‘dangerous’ activity.

packages

Overview

This function shows the various credential packages available to Mimikatz

Attacking

N/A – This just shows information about Mimikatz

Prevention/Detection

N/A – This just shows information about Mimikatz

postzerologon

Overview

Following ZeroLogon exploitation, this will change the machine account to a known value.

Attacking

Targeted machine account will have its password set to ‘Waza1234/Waza1234/Waza1234/‘

Prevention/Detection

Follow Microsoft’s guidance on patching via KB4557222

rpdata

Overview

N/A – Unknown function

Attacking

N/A – Unknown function

Prevention/Detection

N/A – Unknown function

sam

Overview

Running lsadump::sam will dump the hashes stored within the local SAM registry hive

Attacking

This requires elevated privileges to the machine and is covered under T1003.002.

It can be performed remotely by dumping the SAM and SYSTEM hives using tooling such as reg save and running Mimikatz off the target.

Prevention/Detection

To thwart this style of attack, using strong, unique passwords can help to prevent credential re-use, should a computer become compromised.

We can detect this attack by enabling ‘Audit Object Access‘. This can be done via Local Security Policy under the following path: Security Settings\Local Policies\Audit Policy\Audit object access. This can also be done via group policy at the following path: Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy\Audit object access

Following this, you then need to enable audit policies for the relevant registry keys, such as the SAM and SECURITY hives. This will generate EID 4656 events which can then be detected. This can be extremely noisy though, so will require further tuning.

secrets

Overview

Running lsadump::secrets will dump the hashes stored within the local SECURITY registry hive

Attacking

This requires elevated privileges to the machine and is covered under T1003.004.

It can be performed remotely by dumping the SECURITY and SYSTEM hives using tooling such as reg save and running Mimikatz off the target.

Prevention/Detection

To thwart this style of attack, using strong, unique passwords can help to prevent credential re-use, should a computer become compromised.

We can detect this attack by enabling ‘Audit Object Access‘. This can be done via Local Security Policy under the following path: Security Settings\Local Policies\Audit Policy\Audit object access.

This can also be done via group policy at the following path: Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy\Audit object access

Following this, you then need to enable audit policies for the relevant registry keys, such as the SAM and SECURITY hives. This will generate event ID 4656 events which can then be detected. This can be extremely noisy though, so will require further tuning.

setntlm

Overview

Leveraging lsadump::setntlm will allow us to change the password of an account via the command line, should we have sufficient privileges.

Attacking

This function requires us to have ‘privileged access’ over the account. For example if we have compromised an account with a ForceChangePassword permission over another account. A benefit of this method is that it doesn’t require us to know the current or previous password

Prevention/Detection

This technique will generate event ID 4738. The new password will get added to the password history, which can help correlate events. Additionally, enabling Azure Conditional Access policies to force MFA or restrict logons to trusted network segments can provide another layer of security, although this can be bypassed by the Pass-The-PRT attack (via sekurlsa::cloudap)

trust

Overview

We can use lsadump::trust to patch LSASS in order to obtain the forest trust keys, which can allow us to forge inter-realm tickets.

Attacking

We can forge an inter-realm ticket, allowing DA in Domain A to move laterally into Domain B, should they share a bi-directional trust (Link 1 and Link 2). Additionally, there is an interesting blog by XPN looking at cracking these keys.

Prevention/Detection

Follow the guidance at the end of the post on identifying attack paths to critical assets such as Domain Controllers and Domain Admins.

zerologon

Overview

lsadump::zerologon performs the ZeroLogon attack.

Attacking

This will set the password of the computer account on the targeted domain controller to a blank string.

Prevention/Detection

Follow Microsoft’s guidance on patching via KB4557222

sekurlsa::

backupkeys

Overview

sekurlsa::backupkeys shows the GUIDs of the DPAPI backup keys on a DC. This is very similar to the lsadump::backupkeys command which will also automatically gather the value of the keys and the location of them on disk.

Attacking

This will reveal the GUID values of the backup DPAPI keys, which can then be exported and leveraged to decrypt secrets on any domain-joined machine, as covered in the attacking section of lsadump::backupkeys.

Prevention/Detection

N/A – See lsadump::backupkeys.

bootkey

Overview

I was unable to find a comprehensive post on sekurlsa::bootkey, so had to do quite a bit of digging to uncover it. Based on a tweet by Benjamin Delpy, we can use this function with the /raw parameter to decrypt ‘LSA Isolated’ (aka Credential Guard-protected) credentials, if we are able to obtain the ‘SecureKey.pdb’ file. From some comments on that post, it appears this might be possible against VMWare hosts.

Attacking

Benjamin Delpy has produced a video which demonstrates how to perform this attack. I am planning on digging into this technique at a later date, but for now I will use the screenshots from Benjamin Delpy’s video. Below we can see the output of sekurlsa::logonpasswords before sekurlsa::bootkey is run:

A minidump of LSASS is then taken and loaded into Mimikatz. The bootkey command is then run passing in the .vmem file of a virtual machine. It appears as if this technique will work if we have access to the physical memory of a machine.

Following this, we can now obtain the cleartext password which is ‘protected’ by Credential Guard.

Prevention/Detection

Follow the defensive recommendations at the end of this post, in particular the guidance on hardening LSASS.

Protecting credentials in Credential Guard is still a good step to take in order to secure credentials, this technique doesn’t fundamentally change that guidance! 

cloudap

Overview

sekurlsa::cloudap will reveal the Primary Refresh Token (PRT) for an Azure-joined or hybrid Azure-joined device. This PRT file will allow us to generate PRT cookies, which in turn will allow us to impersonate the user to Azure from an attacker controlled device.

Attacking

In short, this allows us to perform the Pass-The-PRT Attack. Joe Stocker summarises this attack really well: “This allows the attacker to sign in as the user, even if their device is not Intune compliant or Hybrid Azure AD joined”.

To perform this attack, we will need to have local admin access to the machine in question, but we will not need to compromise anything such as the TMP, as the information we need (PRT and derived key) are found in LSASS.

Prevention/Detection

Follow the defensive recommendations at the end of this post, in particular the guidance on hardening LSASS.

credman

Overview

sekurlsa::credman will interact with Credential Manager (credman), to uncover credentials.

Attacking

We can enumerate stored credentials with vaultcmd, although this didn’t reveal all the entries on my system in practise.

Additionally, we can backup the CredMan files to export them off a target system, but this does require GUI access.

Prevention/Detection

The best way of preventing this is preventing Credential Manager from caching passwords in the first place. I was unable to find a method of being more granular than a straight allow or deny of Credential Manager.

Backing up all the credentials from Credential Manager will create Event ID 5376.

dpapi

Overview

sekurlsa::dpapi will dump DPAPI user master keys from LSASS. These SHA1 hash of the password is cached by LSASS following the initial logon. This SHA1 value is used by DPAPI to decrypt the encrypted blobs.

Attacking

We can use this function to reveal the masterkeys for each user. These keys are then used to decrypt DPAPI-protected credentials, which can be performed with the dpapi:: module in Mimikatz.

Prevention/Detection

From Harmj0ys post, he states it is very difficult to prevent this attack.

Follow the defensive recommendations at the end of this post to harden LSASS.

dpapisystem

Overview

sekurlsa::dpapisystem will obtain the DPAPI system master keys from the SYSTEM and SECURITY registry hives.

Attacking

We can use this function to reveal the System master key. This key are then used to decrypt DPAPI-protected credentials, which can be performed with the dpapi:: module in Mimikatz.

Prevention/Detection

From Harmj0ys post, he states it is very difficult to prevent this attack.

Follow the defensive recommendations at the end of this post to harden LSASS.

ekeys

Overview

sekurlsa::ekeys will dump any kerberos tickets (i.e. all key types) from LSASS. This is very similar to the triage command in Rubeus, but with key differences under the hood. Rubeus will leverage the LsaCallAuthenticationPackage API call, whereas Mimikatz parses LSASS.

Both have different pros and cons, but the sekurlsa::ekeys command is likely to be the less OPSEC-safe option due to interacting with LSASS.

Attacking

We can perform many attacks with a valid hash of a user, in particular pass-the-hash or overpass-the-hash. We can use Rubeus to obtain a valid TGT using a hash with asktgt and the /rc4 or /aes256 flags. Using the sekurlsa::ekeys command, we will be able to find the AES256 hash for the user, which is more normal for an environment and might be more OPSEC-safe.

Prevention/Detection

If the hashes are used via overpass-the-hash, then the difference in encryption strength can be detectable if we were to use the RC4 hash instead of an AES256 hash.

Follow the defensive recommendations at the end of this post to harden LSASS.

kerberos

Overview

I believe sekurlsa::kerberos lists credentials cached by the Kerberos SSP following a successful authentication to the network. This appears to be separate to the Kerberos tickets which are also cached and obtainable through Rubeus’s triage command, or sekurlsa::tickets within Mimikatz.

Attacking

We can perform many attacks with a valid hash of a user, in particular pass-the-hash or overpass-the-hash.

Prevention/Detection

Follow the defensive recommendations at the end of this post to harden LSASS.

krbtgt

Overview

sekurlsa::krbtgt obtains the password hash of the krbtgt account from a domain controller.

Attacking

Compromising the KRBTGT account can be used to perform golden ticket attacks

Prevention/Detection

Follow the guidance at the end of the post on identifying attack paths to critical assets such as Domain Controllers and Domain Admins.

livessp

Overview

sekurlsa::livessp gathers data from the LiveSSP SSP, this was introduced in Windows 8 when signing in with a Live account.

Attacking

We can perform many attacks with a valid hash of a user, in particular pass-the-hash or overpass-the-hash.

Prevention/Detection

From GentilKiwi’s post, which refers to this post, we can likely remove LiveSSP from the authorised credential providers without too much impact.

KB2871997 appears to introduce the capability to prevent caching LiveSSP credentials for members of the Protected Users group.

logonpasswords

Overview

sekurlsa::logonpasswords is the classic mode of running Mimikatz, returns credentials from all supported credential providers and SSPs.

Attacking

N/A – The various SSPs and credential providers are covered in this guide.

Prevention/Detection

Follow the defensive recommendations at the end of this post to harden LSASS.

minidump

Overview

sekurlsa::minidump instructs Mimikatz to parse a memory dump of LSASS and not to interact with lsass.exe on the machine. This has the advantage of not having to interact with LSASS multiple times if you are going to perform multiple queries.

Attacking

In order to obtain a memory dump of a process, there are various ways for dumping processes in Windows, though they will require admin privileges.

Common methods include using ProcDump.exe, Task Manager or rundll32 with comsvcs.

Prevention/Detection

N/A – This is Mimikatz functionality and can be performed off the host.

msv

Overview

sekurlsa::msv shows credentials from the MSV1_0 credential package, which typically handles “Interactive logons, batch logons, and service logons“

Attacking

This is another credential provider which Mimikatz can parse. There are some interesting blogs which dig into this provider in greater detail.

Prevention/Detection

From Benjamin Delpy’s post, we need to retain MSV1_0 in order for the computer to work properly, so we will have to harden LSASS instead to prevent these secrets from being stolen. 

process

Overview

Following the usage of sekurlsa::minidump, sekurlsa::process will switch back to interacting with lsass.exe on the machine, rather than leveraging the data from the dumped file.

Attacking

N/A – This is Mimikatz functionality

Prevention/Detection

N/A – This is Mimikatz functionality

pth

Overview

sekurlsa::pth allows us to perform pass-the-hash attacks in Mimikatz, as well as spawning a process as a given user.

Attacking

This will allow us to spawn a process of our choice as a given user if we have the hash of their password.

There are also some specific criteria around which params are needed, as covered here.

It might be easiest to spawn a bogus program using this technique, then use steal_token in Cobalt Strike to leverage the access token of this process created via PTH.

Prevention/Detection

Generally EID 4624 with LogonType 9, but this blog covers some more detection settings which can help.

ssp

Overview

sekurlsa::ssp will gather data from SSP’s (Security Support Provider). Applications can implement their own third-party SSPs to handle authentication if SSO isn’t an option. Benjamin Delpy’s blog mentions that applications with third-party accounts might legitimately leverage this functionality.

Attacking

As an attacker, we can leverage this in three ways. We can simply use sekurlsa::ssp to read credentials gathered by pre-existing SSPs. Using misc::memssp, we can register a new SSP, which will log passwords in plaintext, but will not persist over a reboot and will require injecting into LSASS which is obviously not ideal. Finally, using mimilib.dll, we can create a more persistent method for leveraging SSPs, but it does require dropping a DLL to disk.

Prevention/Detection

Look for the existence of log files such as C:\Windows\System32\kiwissp.log or C:\Windows\System32\mimilsa.log, which will show the credentials potentially gathered by an attacker. Although if this is seen, then it is likely too late. 

Follow the defensive recommendations at the end of this post to harden LSASS, although remember that this is a Credential Guard bypass, therefore PPL will have to be enabled to prevent this attack from being successful.

tickets

Overview

sekurlsa::tickets lists all the Kerberos tickets from the system.

Attacking

Functionally, I believe this is similar to Rubeus’s triage command. Both require elevated access to view tickets from other users.

Tickets are valid for 10 hours, but can be renewed for up to 7 days. This can be leveraged using Pass-The-Ticket, which is covered by many other blogs.

Prevention/Detection

Follow the defensive recommendations at the end of this post to harden LSASS.

There is the potential to detect by matching users who are logged on compared to the kerberos tickets in memory. This seems quite complex and might be hard to implement at scale, even if it is effective.

Defender for Identity is able to detect suspected pass-the-ticket activity through external ID 2018.

trust

Overview

We can use sekurlsa::trust to obtain the forest trust keys, which can allow us to forge inter-realm tickets.

Attacking

We can forge an inter-realm ticket, allowing DA in Domain A to move laterally into Domain B, should they share a bi-directional trust (Link 1 and Link 2). Additionally, there is an interesting blog by XPN looking at cracking these keys

Prevention/Detection

Follow the guidance at the end of the post on identifying attack paths to critical assets such as Domain Controllers and Domain Admins.

tspkg

Overview

The sekurlsa::tspkg function will list credentials from the ‘Terminal Services’ authentication provider, which is more commonly known as TsPkg. This has close relations to TSSSP (Terminal Services SSP), which is the SSP which then leverages TsPKG to manage passwords.

Attacking

This is caused by a series of non-default settings being enabled. These relate to enabling a semi-SSO mode in RDP, where NLA is used. We need these settings to be enabled, and an authorised server (or a wildcard) to be set in the Computer Configuration\Administrative Templates\System\Credentials Delegation field of a GPO.

Prevention/Detection

The infamous KB2871997 introduces the capability to prevent plaintext caching of this SSP, but it is not enabled by default!

wdigest

Overview

sekurlsa::wdigest lists credentials from the Digest SSP, better known as wdigest.dll or WDigest.

Attacking

Hashes recovered from WDigest can be leveraged using standard pass-the-hash (T1550.002) or overpass-the-hash methodology.

Prevention/Detection

KB2871997 introduces the capability to prevent plaintext caching of Wdigest. Be warned, as it is installed by not enabled by default on Win8.1 and 2012 R2!

To enable this, install the patch for Windows 7/Windows 8/Server 2008 R2/Server 2012. Then ensure the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest entry has the UseLogonCredential property set to 0.

If this is set to 1, then it will not protect the machine at all (i.e. Wdigest will cache in plaintext). If the UseLogonCredential entry doesn’t exist, then it will again cache in plaintext on older OS’s.

This is a very complex patch, so refer to the KB2871997 article or an article by StealthBits which breaks down these considerations.

Defensive Advice

The sections below will cover some defensive guidance to help protect a device against the various Mimikatz functions above from being possible.

Hardening LSASS

This section will cover some recommendations for enhancing the security of LSASS. Due to it being commonly targeted by attackers, it makes sense to secure this as best as possible.

Enable PPL (Protected Process Light)

Enabling PPL (M1025) will effectively mean that even administrative users are unable to interact with LSASS via tools such as Mimikatz (As PPL will prevent an attacker for successfully invoking the OpenProcess API call to interact with LSASS, even if they have SeDebugPrivilege).

With this enabled, it will force an attacker to resort to other methods to bypass PPL, which open up more opportunities to detect them. Common examples of bypassing PPL typically rely on loading a custom driver, such as Mimikatz’ own mimidrv driver.

To enable PPL on an individual computer, we can do this by opening the HKLM\SYSTEM\CurrentControlSet\Control\Lsa key and adding the DWORD value “RunAsPPL“, setting its value to 1 and restarting. This can also be done via group policy

Enable Credential Guard

We can enable Credential Guard (M1043) to run ‘LSASS’ within its own heavily-restricted virtual environment, this isolated ‘version’ of LSASS is known as LSAIso. LSASS still runs on the computer, but talks to LSAIso in order to handle and monitor authentication requests. This monitoring limits the ability for an attacker to interact with the credentials within LSASS, as they are now isolated.

We can enable Credential Guard via group policy, InTune or on the local machine

As covered in sekurlsa::ssp, a well known bypass of this is to register a custom SSP, which will then capture any subsequent credentials in plaintext.

Enable Attack Surface Reduction (ASR) Rules

Should you be enrolled in a compatible plan, enabling ASR rules can help to monitor and prevent malicious access to LSASS. This includes attacks such as Pass-The-PRT (sekurlsa::cloudap), which was able to still work even with Credential Guard enabled.

The following PowerShell command will enable the rule in blocking mode:

Add-MpPreference -AttackSurfaceReductionRules_Ids 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -AttackSurfaceReductionRules_Actions Enabled

To enable it in audit mode, use -AttackSurfaceReductionRules_Actions AuditMode instead. With ASR enabled, this will generate event ID’s 1121 (Block mode) and 1122 (Audit mode) within the Windows Defender/Operational log

Restricting Local Admin Rights

Preventing users (and attackers) from obtaining administrative privileges in the first place will also add another layer of defence. Whilst there are a number of ways of escalating privileges, it introduces more opportunities to catch an attacker.

Reducing Credential Reuse

The age old advice of not re-using credentials still works today. A predictable or weak naming scheme is trivially exploitable by an attacker and can lead to widespread access across the environment. Using strong, unique passwords helps to prevent this.

Assess AD Attack Paths

Using a tool such as BloodHound, we can assess an Active Directory environment to identify ‘attack paths’ which an attacker might leverage. The BloodHound Enterprise site has a good introduction to this topic, but all of the concepts can be performed using the free version.

By removing attack paths within your environment, you can effectively prevent an attacker from directly escalating their privilege within Active Directory. If an attacker is able to gain permissions such as Domain Administrator, they are able to perform a number of highly powerful attacks and will be extremely difficult to fully remove from the environment.

Attack paths can also be created when privileged accounts log into other computers. Therefore limiting the computers which powerful accounts such as the Domain Admin can log into will help to reduce the chance of an attacker compromising the account.