In January, 2023 Gen Digital, a firm previously popular as Symantec and NortonLifeLock , found itself targeted by a significant Credential Stuffing attack. The attack resulted in the compromise of thousands of user accounts.
Just weeks prior to this incident, LastPass, a prominent competitor of Gen Digital in the password manager market, fell victim to a breach. This breach followed a prior cyberattack against LastPass in August. According to LastPass, the hackers leveraged technical data pilfered during the August cyberattack to gain unauthorized access to its cloud storage system.
It’s worth noting the irony here – the very software designed to fortify defences against cyber attacks found itself in the crosshairs of one. To draw a parallel, it’s akin to a scenario where the police station itself becomes the target of a burglary.
Credential Stuffing
Credential stuffing refers to the use of credentials such as username, email id and personal information from previous security breaches. These credentials are fed to other login systems to gain access to other websites. Unlike other cyber attacks, Credential Stuffing does not require brute force. Instead it uses a simple web solution to stuff thousands of stolen credentials into login systems. Credential stuffing is one of the oldest tricks in the book. It’s very easy to fall victim if one uses the same or similar credentials on multiple sites.
I recently explored the website “Have I been pwned” and was shocked to see one of my personal email ids compromised in a previous attack. Going through their listing on breached websites made me realise how unsafe our credentials and information are, and how easily one can gain access to it.
Impact of the Incident
In an internal investigation in December 2022, NortanLifeLock detected “unusually large volume” of login attempts. They found that a malicious actor was using a list of credentials obtained from illegal marketplaces on “dark web”.
Nortan commented that 925,000 people were targeted in a credential-stuffing attack. It is probable that the data does contain names, phone numbers and addresses of users. The attackers might also have access to Norton Password Manager users’ private vault data. This vault contains stored passwords for other online accounts. The firm is not commenting on how much customer data actually got a negative impact because of the attack.
Nortan relaeased a warning to it’s users after failing to reject the mass login attempt. They indicated that they “strongly believe that an unauthorised third party knows and has utilised your username and password for your account.” They also suggested the users to use 2 step authentication systems and provided free credit monitoring services to affected users.
Amplification Effect
The Password managers are a hot target because they provide adversaries with an amplified power to gain access to multiple accounts by compromising one password manager account.
As they say putting all the eggs in one basket is a bad strategy. Keeping all passwords in one manager will have a huge impact if compromised.
Passwords are not assets; they represent security vulnerabilities. Rather than locking them away in a vault, consider going passwordless. #GoPasswordless
We all know how crucial our credentials are to us, these shared secrets are basically the access to our resources present on various platforms. The whole process of authentication and authorization is pretty much always dependent on these shared secrets which can be in the format of passwords, access tokens, keys, tickets etc. Today many threat actors target to get these shared secrets by leveraging the authentication and authorization process in order to get access to the victim’s resources.
Motive:
In this blog we are going to see what exactly happens under the hood during the process of authentication and authorization in the case of windows platform and how one can dump and abuse the credentials on the attack surface used in the process of authentication and authorization.
Authentication & Authorization:
Authentication is the process of verifying the entity on the basis of the information provided by the entity which is identity (identification number, or username) and shared secret. While doing authentication there are various steps that we perform and can be divided into three major steps:
Providing identity and shared secret.
Processing the identity and shared secret.
Storing the credentials for authorization.
Now from start to end in the above-defined steps of authentication, threats exist on every step, so firstly we will try to briefly discuss what threats do exist at every step with respect to the windows platform.
Now let’s focus on how one authenticates in windows and learn what happens under the hood for better understanding and this will indeed provide a broader view for us about the authentication in order to abuse the credentials used in the process.
Understanding the Windows authentication process:
Starting from the scratch the user is presented with the authentication basically known as Windows Logon UI and provides all the options for authentication (like password, PIN etc.) to the user.
User needs to supply the credentials to this Logon UI based on the choice of credentials he configured on the system (now including windows HELLO) or by which the user wants to authenticate.
Once the user provides the credentials, LSA (known as local security authority) loads the authentication packages like MSV, Kerberos and Negotiate etc. The image below illustrates what packages are available to use in Windows.
Let’s say for the first scenario if the preferred authentication package is MSV1_0, in this case, we need to understand how this authentication package deals with the credentials provided by the user:
MSV1_0 authentication package can be divided into 2 parts:
The first part, where the Windows NT client machine on which the user wants to authenticate computes the hash of password using Windows OWF (One-Way Function). Once the password is converted into a hash, this hash is stored in the security accounts manager (also referred to as SAM) database locally or in an active directory database in case of a domain environment.
The second part works according to the two scenarios: one where the user authenticates on the system which doesn’t exist in the domain environment (local logon scenario) and the other one in which the user authenticates to a windows domain machine or server which is part of the active directory environment (network logon scenario).
Let see what goes behind the scene when the user authenticates on the client machine and the client machine is not part of a domain environment.
The first part of the MSV1_0 passes the hash to the second part and the user’s hash is used to verify with the one present which is present in the SAM database.
If the hash computed by the machine is identical to the one which is present in the SAM database on the machine then the user is granted access to the machine otherwise the user is present with the message of the unsuccessful authentication due to wrong credentials.
Now that we have looked into the local authentication of the user let’s look into the authentication scenario when the machine is part of a domain environment.
Similar to the local authentication the hash is computed by the machine and passed to the second part of the MSV1_0 but NetLogon service does the part of routing the user’s hash to the second part of the MSV1_0 authentication package. A little about NetLogon service, it is used for creating a secure channel for authentication purposes in a domain environment.
Now the authentication is carried out according to the NT LanManager (NTLM protocol). The figure below describes the NTLM authentication.
But NTLM is not the only authentication protocol that is used as an authentication protocol and as a matter of fact, it is a lesser-used protocol in the case of an active directory environment, in this case, Kerberos is used.
Let’s see what happens behind the scene when the Kerberos authentication package is the preferred one by the LSA. Kerberos is defined as the primitive protocol for authentication in a domain environment which uses three subprotocol as listed below:
Authentication Service Exchange
Ticket-Granting Service Exchange
Client/Server Exchange
Kerberos uses tickets as the user’s network credentials for authentication and provides access to the resource accordingly. The figure below describes the Kerberos authentication flow:
And the last one which is Windows Negotiate, that is also a Security Support Provider which acts like application layer between SSPI (Security Support Provider Interface) and other SSPs also selects the strongest protocol, by default the Negotiate authentication package has two options NTLM & Kerberos.
Now that we have seen what goes behind the authentication very briefly, we can jump exactly to the part of stealing the credentials present on the attack surface.
Stealing the credentials on the attack surface:
One thing to notice about every authentication protocol discussed in the above context is that credentials are stored either on the disk in the form of Database in the above case SAM Database (Registry HIVE) or cached in the memory of process like LSASS (Local Security Authority Subsystem Service) in order to provide access to the network resources seamlessly.
LSASS can store multiple types of credentials that are compatible to the SSP or Authentication Package like:
LM & NTLM Hash
Kerberos Tickets
Keys
Plaintext Credentials
As this blog deals with the credential stealing and abusing it let’s assume a scenario where the attacker has the initial access on the domain joined machine with the privileges of local admin on the box.
Now before starting the demonstration part I would like to also specify that we are going to heavily use Mimikatz, a tool written by Benjamin Delpy in C which deals with windows security.
To start with, lets dump the credentials present in the memory of LSASS.exe. Now there can be multiple ways to dump credentials from LSASS, the first one is very straightforward, which is to use Mimikatz to dump the credentials directly from memory.
But in order to dump the credentials from the memory of a process (lsass.exe) we need to have the privileges to debug the process. This privilege which allows us to debug any process or program is SeDebugPrivilege and is are generally required by the debuggers like OllyDbg etc. Mimikatz does provides the functionality of enabling a set of privileges by using the RtlAdjustPrivilege, a function which is a used by NTDLL.dll in windows in order to enable a privilege from the calling process or thread.
By using the privilege module of mimikatz we can enable SeDebugPrivilege for the current process.
mimikatz # privilege::debug
If you want to look more into how to enable SeDebugPrivilege or any other privileges, @jaredatkinson has return PSReflect-Functions to deal with Win32 API functions and the same can be done using the project.
We can now easily dump the credentials from the lsass.exe process as we have enabled the SeDebugPrivilege. Mimikatz provides a module “sekurlsa” which retrieves the user’s credentials from the memory of the LSASS process.
mimikatz # sekurlsa::logonpasswords
Well important thing to notice is that sekurlsa module finds all the credentials which can be found in the memory of LSASS process, but we can also see this authentication packages wise that is calling the command by the authentication packages like:
Dumping the credentials of the msv authentication package only:
mimikatz # sekurlsa::msv
But this is not the only way to steal credentials using the LSASS process, this can also be done by dumping by the LSASS process using Sysinternals tools like procdump.
This command utilizes a system binary rdrleakdiag.exe which will dump the memory of the process whose PID (process id) is provided in input. Successful execution of the command will result in creation of two files named as minidump_656.dmp and results_656.hlk. [We will use the file with .dmp extension]
In order to use the dump files to retrieve the credentials of the users we need to use the minidump command under the sekurlsa module to make mimikatz aware of the fact that we will be using dump file.
All the user’s hash who have logon sessions on the machines can be dumped using the above techniques. But dumping the credentials from the LSASS.exe is not the only option that we have. So, let’s discuss about the other option that we have, dumping credentials from SAM registry/HIVE.
In order to dump the credentials from SAM we can use the sam command under the lsadump module which can provide us with all the local user account hashes, but before that we need to elevate our privileges to NT AUTORITY\SYSTEM to read the credentials [by using SYSKEY to decrypt the SAM hive data].
mimikatz # token::elevate
mimikatz # lsadump::sam
Running the above command, we can easily see the hash of the users that are present in the local SAM (Security Account Manager) hive.
This can also be done by dumping the System registry hive and SAM registry hive and then using these two files we can retrieve the passwords stored in the local SAM. If we look into the code of mimikatz we can see how sysKey and samKey are retrieved from the Registry HIVE.
This method can also be referred as Offline method as the threat actor only needs to transfer the SAM and SYSTEM registry hive files to their system in order to dump the hash of the users on the victim machine.
For this particular operation that involves dumping of credentials, we can also use secretsdump.py script under the project impacket.
Apart from the following type of hash there exist a different kind of hash i.e. MsCacheV2 also known as Domain Cached Credentials which was introduced in windows to keep the user connected to the domain even if the client machine is disconnected from the domain, user can perform the authentication. We can see under the registry location (HKLM\SECURITY\Cache) after Running the registry editor (regedit.msc) with NT AUTHORITY\SYSTEM privilege the cached credentials keys.
By using command lsadump::cache we can easily dump these hashes.
mimikatz # lsadump::cache
However, these hashes cannot be passed but can be cracked using tools such as hashcat or John-the-Ripper.
These hashes are one of the types of credentials that are stored, we will be switching to the other type of credential which is tickets. As discussed above, tickets are the network credentials which are used in Kerberos authentication mechanism. LSASS which is a subsystem service running under the context of LSA (Local Security Authority) stores these tickets and just like we dumped the hashes present in this process, we can do the same for dumping the tickets.
Again, we will use the sekurlsa module to dump the tickets from the LSASS process memory. These tickets can used in many ways to abuse the Kerberos authentication mechanism. In order to just see what tickets are available on the domain joined machine we can fire the klist command.
mimikatz # sekurlsa::tickets /export
This command will export the tickets present in the lsass process memory. We can also use the command kerberos::list in order to export all the tickets under the context of a user, and doesn’t require any high privileges as it doesn’t deal with lsass.
For the further demonstration, we will be using Rubeus, a tool made in C# for interacting with Kerberos authentication mechanism and abusing it by @specterops. Best part about Rubeus tool is that it doesn’t touch LSASS process memory and therefore doesn’t require local admin privileges on the machine.
Running Rubeus with triage option can list all the tickets present in the current session.
Rubeus.exe triage
We can see a detailed output using the klist option in Rubeus.
Rubeus.exe klist
If we run Rubeus under elevated privileges, we will be able to view and dump the tickets of the other users on the machine as well.
We can dump the tickets now using the dump command in Rubeus. Rubeus dump will get the base64 of all the tickets which can be further used in order to abuse the kerberos authentication resulting in lateral movement.
Rubeus.exe dump
Side note: add /nowrap to the above command we can get a single line base64 of the ticket.
In the above context, we have seen how we can dump credentials from the various sources present on the window machine. One of the prominent sources of dumping credentials was the lsass.exe process which stores almost every type of credentials for SSO (Single Sign-on) purpose (also for access tokens etc). Now focussing more on the LSASS process there were several features made available to securing the LSASS process from the threat actors.
One of the features that was arrived with windows 8.1 and is applicable for every above windows version is Running a process with protection mode named as RunAsPPL which stands for Run as Protected Process Light. By adding and enabling a registry key under “HKLM\SYSTEM\CurrentControlSet\Control\LSA”.
But with mimikatz capability of loading a kernel driver named as mimidrv we can easily remove and add protection to a process. In mimikatz we can load the driver using “!+” and “!-“ to unload the driver. I am will not do a deep dive review of the mimikatz’s driver but I would suggest going through this awesome blog written by Matt Hand on mimidrv.
Below image shows that we enabled the debug privilege but we are not able to dump the credentials from the LSASS process. Even doing memory dump of the lsass process with the procdump will not be successful.
But loading the mimikatz driver mimidrv will provide us with the capability of removing and enabling the protection of any process.
As we can see in the image above, we are able to dump all the credentials from the lsass process by removing the protection on the lsass process.
But there seems to be the other option available that is much more approachable to stop the threat actors to dump credentials from the LSASS process which is by running lsass in VSM (Virtual Secure Mode) which is done by enabling windows Credential Guard. This solves the problem of dumping the credentials as the credentials are stored under the LSAISO (Local Security Authority Isolated) process.
But there is a workaround for this solution as well and that is to inject mimikatz’s ssp (mimilib.dll) in order to steal the credentials.
Just doing that will inject the SSP in LSASS.exe process and the credentials are listed in log file of mimikatz (mimilsa.log) in the form of clear text.
In the above discussed techniques, we have seen how the credentials can be dumped from various sources like registry hive, LSASS process memory. Now these dumped credentials can be utilized to perform various attacks like Pass-the-Hash, Over-Pass-The-Hash, pass-the-ticket etc.
We will see demonstration about the abuse of these dumped credentials in the next part of the blog.
Conclusion
Threat actors have always utilized the credentials dumping techniques to move laterally in the domain environment. Sources of dumping these credentials should be heavily monitored like LSASS process etc.
![Dumping & Abusing Windows Credentials [Part-1]](https://www.pureid.io/wp-content/uploads/2020/09/Dumping-Abusing-Windows-Credentials.png)
