RedTeamNotes started as a mini project to try and make a better note taking application than what was currently available. The big issue for me with apps such as Obsidian or OneNote was that whilst they have great note taking capability, they struggle to show how different notes relate to each other – unless you follow every link and manually piece it together.
Whilst doing CRTO, I often found myself in a position where I was trying to achieve an objective but would struggle to remember all of the various ways of achieving this. For example, to move laterally, I would likely remember that I could:
Dump LSASS to obtain AES256 keys
Obtain the plaintext password and perform overpass-the-hash
Use Rubeus to monitor for TGTs using the /monitor command
But would I remember that I could also use the following?
NTLM Relaying, if I have control of an device with unconstrained delegation
ADCS to obtain a certificate, then leverage THEFT5
And several other options..
Dun Dun Dun
So I decided to build my own note taking application – RedTeamNotes!
I had a few aims for this tool:
It should be possible to reuse the notes in other applications.
i.e. Use JSON
Try to avoid dependencies on too many tools just to build the application
I don’t want to have to download Node and 100 dependencies if I want to play around in HackTheBox
The relationships between notes should be very clear
With a few known limitations:
The tool wont handle editing the notes or relationships
The notes will be intentionally quite brief and will mainly signpost other resources
After many changes, I ended up choosing a few great JavaScript libraries to help me out. The graphing UI is handled by Drawflow. Positioning the various nodes turned out to be one of the hardest parts of the project, as it is very easy to know what the correct graph looks like, but it is very hard to actually implement in an automated way from my experience! Luckily I found Dagre’s GraphLib, which I believe uses the ‘Dagre’ algorithm to sort the nodes, but this might well be wrong!
Aside from these two libraries, the rest was blood, sweat, tears and swearing at CSS selectors.
On the right, we can view information on our selected technique, which currently supports:
Description
OPSEC considerations
Links
Code examples
Defensive guidance
This data would be represented with the following JSON:
"constrained_delegation" : {
"name": "Constrained Delegation",
"description": "Constrained delegation is a feature of AD which allows a service to act on behalf of another user to specific other services. If we can compromise a service with constrained delegation enabled, we can potentially steal cached TGTs",
"opsec" : ["Make sure the msdspn value (If using Rubeus) is a valid SPN which we can delegate to, only specific SPNs will be allowed."],
"code_examples": [
{
"description" : "Find machines with uncontrained delegation enabled via BloodHound",
"code" : "MATCH (c:Computer), (t:Computer), p=((c)-[:AllowedToDelegate]->(t)) RETURN p"
},
{
"description" : "Find machines with constrained delegation enabled via LDAP",
"code" : "(&(objectCategory=computer)(msds-allowedtodelegateto=*))"
},
{
"description" : "Find SPNs we can delegate to via PowerView",
"code" : "Get-DomainComputer -Identity PC_NAME | Select-Object -Expandproperty msds-allowedtodelegateto"
}
],
"links" : ["https://www.guidepointsecurity.com/blog/delegating-like-a-boss-abusing-kerberos-delegation-in-active-directory/"]
}
Using our earlier example of pass-the-ticket, we can see how this is represented below. Notice the 6 lines leading into the left of ‘Pass The Ticket’, showing 6 techniques which could get us to that position.
I decided to make a node for some of the ‘tactics’ (As MITRE ATT&CK would refer to them), which helps Dagre to better position the nodes. This has the added benefit of being able to help me perform a pseudo-checklist when I am stuck on a machine.
For example, below are a set of the privilege escalation techniques I have currently added into the tool:
The tool also can handle quite a lot of nodes. Especially considering that the relationships are quite complex, there is no caching, and it is not a super-efficient algorithm!
Searching
The tool has a search bar which will query the title and description of all the nodes on the current page, which is performed using FuzzySort. For example, lets look for techniques related to ‘tgt’:
We can then click on the top item “Dump TGT’s” and be taken to the relevant node
We can also switch between multiple datasets. For now, I currently have 3 datasets within my notes:
With code samples, we can click on the clipboard emoji, and the example text will be copied to the clipboard.
Hopefully this serves as some inspiration as to what can be done to make note-taking a bit more user-friendly and usable. I’m hoping to develop this idea into a few other directions in the coming weeks and months, as I think this style of program could be useful for a few other applications!
SharpRDPHijack by Bohops is a tool which has sat in my Twitter likes for far, far too long! In this article I am going to dig into SharpRDPHijack, as well as some alternate tooling which can also be used to perform RDP session hijacking. This technique is covered by MITRE ATT&CK under T1563.002.
For this demo, I will have 2 computers. A domain controller (DC) and an Exchange box (Exchange). I will assume we have local admin on the Exchange machine. This is a little contrived but I will treat the Exchange server as a standard server – rather than the privileged server that it is. I also enabled RDP (and NLA) via a GPO on all devices on my domain.
SharpRDPHijack
Initially, I will connect from DC to Exchange, showing what would happen when a highly privileged (and a bit thick) user RDP’s onto a lower tier machine. Attack paths like this will always be of interest to an attacker, as it allows them to gain additional privilege in the target environment.
After disconnecting our RDP session on DC, we can now see we have a disconnected session under ID 3 on the Exchange server, by using the command SharpRDPHijack.exe --tsquery=localhost
Using SharpRDPHijack.exe --session=3 we will be put into a GUI where we can interact with the session created by the Administrator account on the Exchange server. We can then pull up a command prompt to verify we are now acting as the Domain Admin account on Exchange. As part of this process, SharpRDPHijack will attempt to elevate to SYSTEM privilege.
After logging out of that session, we can no longer see session 3 in the output from SharpRDPHijack.
But if we opt to disconnect instead, the session will unsurprisingly remain in a disconnected state – so we can reuse it.
TSCon
Instead of using attacker tooling, we could use the tscon executable to interact with a disconnected session. To do this, we can query for sessions using the query user command
From this point, you need to obtain SYSTEM privileges, where the command (tscon 3 /dest:console) can be run. Two common ways of achieving this would be either PSExec.exe -s cmd.exe or creating a service to spawn cmd.exe with your chosen arguments and session IDs.
In my lab, I was unable to get this technique to spawn a GUI RDP session. I suspect this is due to it already running via Guacamole & RDP, which interfered with the technique. Using VMs on my laptop, this technique worked successfully.
Mimikatz
Unsurprisingly, Mimikatz has a module for interacting with Terminal Services. We can query the sessions with ts::sessions. In reality, using Mimikatz for this purpose is seriously overkill, but I guess its another handy feature of Mimikatz nonetheless! I have recently dug into some other functions of Mimikatz, and discovered some new modules I wasn’t previously aware of.
We can then connect to this disconnected session with ts::remote /id:3.
Remember that this requires SYSTEM privileges, so you will need to run token::elevate before this.
Detections
Looking around, there aren’t many articles which cover how to detect this behaviour. Kevin Beaumont recommends creating a GPO to log off all disconnected sessions, but it might well have a pretty hefty real-world impact and wont be popular, therefore a detective measure would likely be better.
I would say that the best detection for this is likely via a series of different detections as part of a defense-in-depth methodology. The process of exploiting RDP session hijacking has several steps, which introduces potential places where an attacker could be caught:
Escalating to SYSTEM privilege (i.e. Interacting with LSASS, PSExec, service creation)
Using several brittle detections for command line arguments, such as the Sigma rule for detecting TSCon being used. Whilst these may not be very high fidelity, they might be able to add some value for detection.
Detect users querying for disconnected RDP sessions, as that should be fairly unusual behaviour.
Summary
RDP session hijacking is a really interesting technique for privilege escalation without purely leveraging Active Directory (i.e. Kerberoasting or abusing ACLs). I think SharpRDPHijack fills a neat gap between the very noisy Mimikatz and the likely better signatured tscon.exe executable.
Whilst it is a somewhat noisy tool, its definitely one I will be adding to my toolset for future use!
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 thesekurlsa::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.
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
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.
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.
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.
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.
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:
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.
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.
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 bedetectable 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.
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.
This is another credential provider which Mimikatz can parse. There are some interestingblogs 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.
Functionally, I believe this is similar to Rubeus’striage 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!
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.
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.
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.
