Insights
Windows security – what is LSASS dump. How to protect against it?
The ability of Advanced Persistent Threat (APT) groups and other threat actors to take a dump of Windows credentials is a serious threat especially to enterprises and other organizations. The MITRE ATT&CK knowledge base, which is created primarily to support defense against cyber threats, contains descriptions of techniques and tactics derived from observations of actual attacks. This text deals with a technique with the identifier T1003.001, which is a method of learning the credentials of Windows family systems using a memory dump of the Local Security Authority Subsystem Service (LSASS) process.
The memory of the LSASS process can contain credentials such as hashes, PIN-type codes and even plain-text passwords, among others. Reviewing, for example, the stigviewer.com website (STIG stands for Security Technical Implementation Guide), one can find a recommendation to deactivate WDigest authentication by resetting (0x00000000) the value named UseLogonCredential in the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Wdigest\
This is to mitigate the possibility of reading passwords in plain text from the LSASS process memory. The BlackCat ransomware attack can be cited as an example of a memory dump of passwords as a result of a bad WDigest configuration (or more precisely, a swap of a good configuration for a bad one made by the attackers).
To begin with, we will try to understand what authentication is and what authorization is, and realize that these are not terms to be used interchangeably. We will learn about the structure of a computer network in an organization using Microsoft operating systems. We will also learn what system processes are and how to take a memory dump of such a process. After this perhaps somewhat lengthy introduction, we will move on to methods of reading credentials from an LSASS process and how to defend against these techniques.
Authentication and authorization
The terms authentication (AuthN) and authorization (AuthZ) should not be used interchangeably. They are not synonymous. Credentials are used to verify that a person is who he or she claims to be. Only after authentication can appropriate access to a system, network or resource be granted or denied. It is the authorization that determines what privileges a person has. As an example, the following sentence can be cited: “An unethical hacker gained unauthorized access to a directory and changed a file,” i.e. as a regular user he could, for example, browse a directory, but he did something in addition, i.e. changed the data, which was an unauthorized action (as a regular user he should not be allowed to do such things).
Windows-based computer networking
In organizational structures (e.g., enterprises), environments based on Windows family systems use Active Directory (or the cloud equivalent of Azure Active Directory) – a directory service whose tasks include linking computers into domains and centralized management of the domain environment. Computers linked into a domain are managed by a domain controller. Such a solution is particularly applicable in vast environments, where up to thousands of computers may be connected to a domain. The accounts of computers in a domain are stored on a local server (domain controller) or in the cloud (Azure Active Directory).
The opposite of Windows computer domains are workgroups, in which individual computers do not share authentication, for example. This allows for decentralization and independence. Workgroups are used in small networks, such as in a home or small business. In the case of a workgroup, user accounts are stored locally rather than on a server (as in a domain environment).
In this text, we look at the lsass.exe process, whose name unfolds as Local Security Authority Server Service, and which is responsible for authentication in both the domain environment and independent workgroup computers. The LSASS process is also responsible for managing the Active Directory service and, among other things:
It is also possible to load other authentication components into the LSA. Without elaborating further, you can already see from this summary information how important LSASS is as a process.
LSASS process memory dump
You can manage processes using the system’s built-in Task Manager and other tools such as Process Explorer from the Windows Sysinternals suite and Process Hacker.
A process memory dump is the writing of a piece of operating memory to the computer’s disk for further analysis. The resulting data file will contain the machine code of the process, variables in memory, such as subtitles or numeric values, and other data contained in the process. It is worth mentioning that the snapshot will preserve the memory state of the process from a “specific moment”. For example, if we take a memory dump before the user logs in, the credentials will not be there. On the other hand, if the dump is taken after the user has logged in, then with a bit of luck it will be possible to find, for example, password hashes in it.
A real-world example of extracting credentials from the LSASS process memory can be seen in the BlackCat ransomware attack, during which the attackers dumped legitimate remote desktop software over the SMB protocol, changed the WDigest configuration and read user account passwords by taking a memory dump of the LSASS process and using the Mimikatz tool.
The launch of the tool, which performs the LSASS memory dump, takes place in the post-exploitation phase and allows lateral movement, i.e. penetration of the environment by gaining unauthorized access to multiple devices. The attacker mostly wants access to the domain controller of computers in the organization.
Examples of tools the attacker can use include:
The success of using a particular security bypass tool depends on the version of the operating system and active security features. When offensive tools are not effective then you should consider writing your own tool or modifying existing ones.
It is worth mentioning that the listed tools should be run after privilege escalation, that is, on the local administrator or SYSTEM account (has the highest privileges).
LSASS process memory dump using the Task Manager
An example of a fairly trivial way to take a process memory dump is to use the system’s Task Manager (Figure 2). However, a quick experiment on Windows 11 with Defender enabled showed that an antivirus alert is raised (Figure 3).
Taking a memory dump of the LSASS process using Process Explorer
Taking a memory dump using the Process Explorer tool is very similar to the previous method. The tool can be downloaded from the address:
https://live.sysinternals.com/procexp.exe
However, there are security features that can get in the way of the memory dump.
LSA (RunAsPPL) security.
According to Microsoft’s documentation, the LSASS process is included in the LSA (Local Security Authority) process. The security feature called LSA Protection or RunAsPPL (PPL stands for Protected Process Light) is to protect the said processes. A tutorial from Microsoft presents that the protection is enabled (Figure 4) by creating a 0x00000001 double-word (DWORD) value in the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
It is not always so trivial to enable and disable this protection. If the machine has Secure Boot, this value is stored in the firmware and will be active regardless of changes to the registry. To verify that LSA Protection is enabled, you can open the Event Viewer (Figure 5) and see if there is an entry in it:
LSASS.exe program was started as a protected process with level: 4.
Figure 5. Verify in the Event Viewer whether LSA Protection (RunAsPPL) is active (here it is active).
To verify whether the LSASS process light is protected, enable an additional column in Process Explorer (Figure 6).
Figure 6. Selecting the Protection column in Process Explorer.
Figure 7. The Protection column indicates that the LSASS process light is protected.
Figure 8. An attempt to dump the memory of a protected process ends with an access denial.
Within last year I shared a a few writeups of my bypasses of HTML sanitizers, including: > Write-up of DOMPurify 2.0.0 bypass using mutation XSS > Mutation XSS via namespace confusion – DOMPurify < 2.0.17 bypass While breaking sanitizers is fun and I thoroughly enjoy doing it, I reached a point where I began to think whether I can contribute even more and propose a fix that will kill an entire class of bypasses.
A few days ago, the Anaconda project announced the PyScript framework, which allows Python code to be executed directly in the browser. Additionally, it also covers its integration with HTML and JS code. An execution of the Python code in the browser is not new; the pyodide project has allowed this for a long time...
Summary: During my research on other bug bounty program I've found Cross-Site Scripting vulnerability in cmp3p.js file, which allows attacker to execute arbitrary javascript code in context of domain that include mentioned script. Below you can find the way of finding bug bounty vulnerabilities from the beginning to the ...