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. 

How SOC Analysts Can Change The Landscape of Cyber Defense

    On August 27th, 2022, I had the amazing opportunity to attend my first cyber security conference, Blue Team Con. I learned so much and my perspective on defensive security has changed. I will explain how I think SOC Analysts can change the landscape of defensive security and how to think two steps ahead of our adversaries.

    I firmly believe every analyst should try to have the mindset of a CISO, no matter if they are L1, L2, or L3. By this I mean, think of where the crucial information or data is for the organization and work outwards. Defensive Security is a game of infinity. It is impossible to fix every vulnerability, and by doing so, we are wasting valuable time. Hypothetically speaking, if you knew an adversary would launch an attack on you, how would you prepare? What vulnerabilities would you focus on? You most certainly would not focus on vulnerabilities that pose no risk to that critical data to your organization. We should understand risk by a simple equation of Risk = Threat x Vulnerability. 

    Every analyst should gain hands on experience in emulating these offensive attacks that they are defending against. It ultimately boils down to containing is not enough, become proactive and not reactive and understanding the adversary. It is great that you understand how to stop a MITM (Man-In-The-Middle) Attack, but do you know how it actually works? Before an adversary launches an attack, they have already some understandings of what data they want, how they will get this data and the techniques and sub-techniques of doing so. How can you beat the enemy if you don't understand the enemy? Adversaries know how to exploit a vulnerability and bypass certain defenses, because they know how it works. If you know what is needed for an attack to be successful, you can prevent it before it happens.

    We can look at how a ransomware campaign happens. Often times, the adversary wants to hide their presence. How do they do this? They can make configuration changes once they have breached. But, on the defensive side, we can track this by logging any audit changes. 

    Lastly, I think every analyst should understand their tools. They should be the subject matter expert and know how this tool works under the hood. We see this mindset with our adversaries. They don't just run a tool or execute a script. Often times, they will modify it, create their own tools and scripts and go from there. I would argue that it is even more crucial for us to be subject matter experts.