The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes.
I presented on this AD persistence method in Las Vegas at DEF CON 23 (2015).
Complete list of Sneaky Active Directory Persistence Tricks posts
The Security Support Provider Interface (SSPI) enables Windows authentication methods to be easily extended allowing new Security Support Providers (SSPs) to be added without additional coding.
Some of the standard Windows authentication SSPs:
Mimikatz supports DLL/registry (scenario 1) & in-memory updating of SSPs (scenario 2).
Scenario 1: Copy mimilib.dll to the same location as LSASS (c:\windows\system32) & Update Security Packages registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages\) with the SSP DLL name.
Scenario 2: Use mimikatz to patch LSASS in memory with new SSP with no reboot required (rebooting clears the memssp Mimikatz injects).
Either of these scenarios enable adding a new SSP to a Windows system. The SSP included with mimikatz provides automatic logging of locally authenticated credentials. This includes the computer account password, running service credentials, and any accounts that logon.
This data is logged by default in the same location as the dll file to a log file, though it’s possible to log this data elsewhere on the system. The alternate log location could be in SYSVOL if the Windows system is a Domain Controller which provides access to Authenticated Users.
This is what a typical Group Policy template file might look like.
This is what a fake Group Policy template file might look like when as the Mimikatz SSP log file location.
- Monitor the LSA registry key that controls security packages: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Security Packages\
- Monitor commands run on Domain Controllers in cmd.exe
- Monitor commands run on Domain Controllers in PowerShell.
- Protect Active Directory admins.