LSASS Memory Dumps: What is It, How Does It Work & How to Defend Against It

According to the MITRE ATT&CK Framework, LSASS Dumping (T1003.001) is a sub-technique that belongs to the technique of OS Credential Dumping (T1003) and belongs to the tactic of Credential Access. LSASS Dumping refers to the sub-technique where the adversary attempts to access credentials stored in memory by dumping the LSASS.exe process. But to really understand how this attack vector works under the hood, it is important to understand the Windows Operating System, how and why credentials are stored in memory. 

First, we should understand what processes are and how they are created within the Windows Operating System. A process is quite simply, an executing program. When we look at PowerShell commands and processes, we can understand that they are written in C# and utilize the Windows API. 

LSASS belongs to a framework that Windows uses called LSA (Local Security Authentication). LSA authenticates and logs users onto the local computer. It is able to do this because it validates the user information by checking the SAM (Security Accounts Manager).  SAM is a database file and registry located within C:WindowsSystem32Config.  This database contains username and password information, and the hashed password is in the registry key of _HKEY_LOCAL_MACHINESAM. 

Now, it is very important to note that LSA stores this data in a set of objects. Remember, everything is written in C#. Why is this important? Well, to understand LSASS dumping, we need to understand what dumping means. A memory dump file is also known as a crash dump file. This will happen if a program crashes unexpectedly, and it is great for debugging. However, you can create a dump file whenever you like.

According to the documentation provided by Microsoft (Cached and Stored Credentials Technical Overview | Microsoft Docs), LSASS stores credentials in memory on behalf of users with active sessions. This is done to allow for convenient access to network resources, shares, or services within a domain. It would be annoying if every single time, a user had to remote session into a service or resource, they would have to re-enter the credentials. 

This is where the threat of LSASS dumping lies. Since, all of this information is stored in a database file called SAM, essentially being stored in memory, the adversary can dump the LSASS.exe process and all the important credential information they are looking for is all there. 

It is important to note that LSASS does not store credentials with current versions in plaintext. However, they do store these credentials in multiple forms, like NT Hash, LM Hash, Reversible Encrypted Plaintext, and Kerberos Tickets. 

Let's take a look at one of these forms, specifically the NT Hash. An NT Hash is essentially an unsalted MD4 hash of the account's password. This is outdated and insecure. Passwords can be easily cracked if they utilize the NT Hash.

With current operating systems, Kerberos is the default authentication method. However, if, for some reason, Kerberos is unavailable, NTLM will be enabled. However, this can be changed by changing settings within Group Policy of the Domain. 

NTLM is a suite of security protocols that Windows used in legacy systems to authenticate users on a domain. However, it is extremely insecure because it uses an outdated hashing algorithm, and the passwords are not salted at all. The hashed password can be found in various places, such as SAM, as previously discussed. So, the adversary doesn't need to know your password. They can obtain the hash and the username, and easily get your password via Pass-The-Hash Attack. 

Also, since Windows is heavy on backwards compatibility, there is an authentication method called WDigest that still exists. However, it is only with Windows 8 and prior, and Windows Server 2012 R2 and prior. Essentially, WDigest is used as part of the process for domain authentication and the users' credentials are stored in plaintext within LSASS. So, if an adversary were to gain access and conduct an LSASS dump, there would be no need for a Pass-The-Hash Attack to crack the password, because the password is there in plain sight. 

So, how do we defend against this? Here are some methods and best practices that organizations and individuals should implement to help mitigate an LSASS Dump Attack. 

• Decommission all EOL Windows Operating System. There is no reason why you should still be using Windows 8 or Windows 2012 R2. 
• If you are currently using Windows 8 and/or Windows 2012 R2, you should disable WDigest Authentication. 
• You should also create an alert if WDigest is re-enabled and any creation of dump files.
• Restrict local administrative access as much as possible. 
• SEDebugPrivilege is required to dump LSASS memory. So, by disabling it for local administrators, it would make this attack impossible to happen.
• Utilize the Least Privilege Access Principle. 
• Only the minimum necessary privilege rights to perform an operation should be granted and should be for the shortest duration as possible.
• If someone doesn't need admin rights, do not give them admin rights.
• Use remote management tools that do not place reusable credentials on a remote computer's memory like RDP. 
• Remove standard users from local administrative groups
• Restrict all inbound connections to all workstations except for those with expected traffic originating from trusted sources. 
• This will restrict the adversary from conducting lateral movement and compromising other accounts. 
• Enforce credential removal after logoff
• Previous Windows releases were susceptible to session leaks that allowed credentials to remain in LSASS memory after logoff.