As an attacker, I frequently leverage LSASecrets to escalate privileges within the context of an ongoing compromise. Generally, the attack path is something like this:

Gain Initial Foothold > Escalate to Limited User > Dump LSASecrets on Systems Where Credentials are Administrator

A pretty slick way to identify targets to dump LSASecrets on is to query Active Directory for systems where Service Principal Names (SPNs) are set. There are many ways to do this, but I like LDAPPER, or if I have Bloodhound data, that can be used as well.

You are looking for instances where systems you have Administrator access to are also systems with an SPN set. This is because on those types of systems, it is likely that the account set up as a service is also running as a service, which means the credentials are stored in the registry (LSASecrets) and available in plaintext. There are several methods for extracting these, and while I will not go into detail with this post, they are worth checking out:

• Impacket - (SecretsDump.py)
• Mimikatz - (Beware, this method touches LSASS)
• TellMeYourSecrets - (Class Library in C#)

Below are some LSASecrets extracted as an example:

Here, in the services configuration, you can see the conditions that make this attack possible:

This leads into to the main point of this post. Attackers are susceptible to deception, mostly because we rely on the tools and circumstances that we have seen or used before to identify patterns that work. Disruption in these patterns is a highly effective defensive tactic, and many times, as is the case here, deception has no negative effects and is very simple for the security team to implement with no capital or operational expenses. That said, please also ensure that changes to your environment are tested prior to implementation.

To set up a trap similar to what I have above, simply create a realistic-looking service:

Note that while you have to use an actual user in your domain, you SHOULD NOT USE THE REAL PASSWORD. Choosing where to place these traps should be done judiciously. Do you have a system that you know every user is Local Administrator on? That would be a decent place for a trap like this. Are there systems that have accounts with SPNs pointed to them? Those would also be good targets for this type of trap.

Once you have the trap set, you will be responsible for the configuration of a viable method to generate an alert, should an adversary attempt to leverage the false password you placed in LSASecrets. Simply setting up monitoring and alerts for Windows 4625 Event IDs and the account used would be decent. If you mimic a real service account, there really shouldn’t be any failed logins, and if there are, you would probably want to know that as well.

This mindset of creating deceptive traps for adversaries extends to nearly every aspect of defense. Hopefully, this little trick has sparked your imagination and inspired you to pursue the creation of your own traps.