In my previous post, I’ve blogged about how Pass-the-Hash is still a nuclear bomb on most networks around the world.
Despite that Microsoft has released mitigation guidance’s around this security threat. I always felt that most companies didn’t (fully) understood the whole problem about this, which has led that many companies didn’t implemented the mitigations around Pass-the-Hash at all.
I’m certainty not the only one who thinks about this, because a Microsoft employee who works in incident response has shared his thoughts as well. Pass-the-Hash is still used a lot, and many companies don’t seem to understand the problem, even in 2020. Except the folks who work in offensive security or do similar work with, etc.
Pass-the-Hash can be done with Domain accounts as well, but the primary focus in this blog post will be on the well known RID-500 account. I will make a separate blog post on Domain joined accounts later.
Before we’ll go further in to the details on how to execute this attack and how to defend against it. Lets first have a brief overview on what this attack is.
A Pass-the-Hash attack is an technique whereby an attacker is capturing the NT hash of a compromised system and then pass it through authentication without having access to the user’s password in clear text. After the password hash(es) has been obtained by an attacker. It is use to trick an authentication system into creating a new authentication session on behalf of a compromised user. Later on, the attacker can move laterally with PsExec, WinRM, etc. Pass-the-Hash forms a common part of lateral movement.
One of the common reasons why this attack still works is because of the following scenario:
Imagine if you had to deploy multiple systems with an unique password. It is nearly impossible to do that, so you would probably deploy those systems from an image and that will often set the same password for each system.
The second thing is that the power of the RID-500 account has always been underestimated. If the password of this account is the same on all the systems in the network. An attacker only needs to compromise one system in the network to compromise all the systems in the network.
By default, the Builtin local Administrator account can connect remotely to other systems if the password is the same, and the account cannot be locked out. Oh and it can’t be deleted as well, but there’s an option to disable it.
A good thing to keep in mind is that local accounts are stored in the SAM database while Domain accounts are stored in the LSASS process.
Security Account Manager (SAM)
When we’re talking about the RID-500. We usually mean the Builtin local Administrator account that exist on each Windows computer. This local account is stored in the local SAM database, which authenticates local user logons.
With local users we mean something like this. Where a Windows computer has at minimum two accounts with the likes of the local Guest and Administrator, account. I have renamed the Administrator account to Testing, but it still stays the same. It just has another username.
Besides of local users, there are also local groups on a Windows computer, where both Domain and Local accounts can be a member of a group. We can think of local groups, such as Administrators for example.
All the local users their passwords are stored encrypted in the SAM database that is located at C:\Windows\System32\config
A SAM database runs in the background when a computer boots up and is backed by the Local Security Authority (LSA) that contains all the secrets of Windows. LSA is responsible for the local security policy, auditing, authentication, logging users on a system, and storing other private data. It creates logon sessions for a local computer.
LSA validates logon attempts against the SAM database to see if the entered password matches with the local SAM, because the SAM database contains sensitive information. Only the SYSTEM principal is able to retrieve it.
Pass-the-Hash with RID-500 account
As discussed before. All the local accounts are stored encrypted in the SAM database and only the SYSTEM principal is able to extract it.
Here we can see all the local accounts on the WINDOWS2012 machine after we extracted them from the SAM database. We can see the user Testing, which is formerly known as the Builtin local Administrator account, because it has the RID-500. The only thing is that the username has been changed.
What we are now going to do is perform reconnaissance to find local admins on other systems. As example we’re going to perform reconnaissance on the FILESERVER.
As you can see, the FILESERVER has the RID-500 account as well. Like all other systems. You can recognize it through the SID that ends with 500.
Get-NetLocalGroupMember -Method API -ComputerName FILESERVER
Our user Carol has been compromised and it does has admin privileges on the WINDOWS2012 machine, but when we’re trying to connect to the FILESERVER. We are denied, because we don’t have the rights. Makes senses so far?
We did had admin privileges on the WINDOWS2012 machine, so we’re allowed to extract the SAM database to obtain the NT hash of the RID-500 account. As discussed before, this password is often the same across all the systems in the network.
We are now going to execute a Pass-the-Hash attack with the RID-500 account to get access to the FILESERVER.
sekurlsa::pth /user:Testing /domain:FILESERVER /ntlm:7ee68699a16f305b993019ce5f86f05d /run:powershell.exe
After executing a PtH attack to the FILESERVER. We can use PsExec to move laterally to that system.
PsExec -s \\FILESERVER cmd
Here you go, mission achieved. We have access to the FILESERVER.
Now you might wondering. Why were we able to connect with the RID-500 account from the WINDOWS2012 machine to the FILESERVER? Well, you have read it a few times, where I’ve mention that the password is often the same, but is this really true?
I will now connect to the FILESERVER and extract credentials from the local SAM database to get the NT hash of the RID-500 account.
PsExec \\FILESERVER -s cmd /c C:\x64\mimikatz.exe
All the credentials from the local SAM database has been extracted from the FILESERVER, so if you have recognize it. The NT hash of the RID-500 on the FILESERVER is exact the same as the NT hash of the RID-500 account on the WINDOWS2012 machine.
What are the risks?
If the RID-500 has the same password on all the systems in the network. An attacker only needs to compromise one machine to compromise all of them, but other evil things can be done as well, with the likes of enabling the Guest account on a machine or create a new local admin account as backdoor.
- Enabling the guest account
net user guest /active:yes
- Creating a new local admin account
net user Evil Passw0rd! /add net localgroup administrators Evil /add
Imagine that the password of the RID-500 was rotated on the FILESERVER, but since we created our local account as backdoor. We still can use that account to RDP in to the FILESERVER for example.
Now when taking a look at the local SAM database on the FILESERVER. We can see our Evil user and that the Guest account is enabled.
There are two things you could do to mitigate this attack. One is to deploy the Microsoft LAPS solution across all the workstations and servers, which will rotate the password of the Administrator account on each individual system every 30 days. Second thing you could do is denying logon access with the Builtin local Administrator account, so it can’t connect remotely to other systems, even if it has the same password. Other option is to do both.
A Group Policy needs to be rolled out on the servers and workstations with the following two settings that can be found at User Right Assignment.
- Deny access to this computer from the network: Local account and member of Administrators group
- Deny log on through Remote Desktop Services: Local accounts and member of Administrators group
After these two settings has been rolled out. Lets see if we still can connect with local accounts 😉
We can’t logon with the RID-500 to the FILESERVER despite that the NT hash is the same.
But, wait. We did created a local account as backdoor. Can we use that local account to RDP in to the FILESERVER? Unfortunately we can’t.
Denying logon access with Group Policy enforces that local accounts can’t connect remotely to other systems. Even when they have the same passwords.
At many companies. I can tell from experience that the RID-500 password is the same across each individual systems. Have you already put security measures to mitigate against this attack?