Check other parts:
- Pass-the-Hash attack : compromise whole corporate networks P1
- Pass-the-Hash attack : compromise whole corporate networks P2
Some people simply accept all of these flaws as inherent in single-sign-on and centralized authentication. But they don’t have to be. Now that we know about the Pass-the-Hash attack, we will talk here about how we can protect our network from this type of attack. We will be talking about “Network Mitigation”.
1. Local Accounts
The problem with local accounts is that many organizations use the same username and password combination across machines. This can be because you have a standard image that you are deploying across the network machines, or because you use local accounts to troubleshoot problems on the machine where the network is not accessible and you cannot use network accounts.
Local Account Traversal , the problem
If Fred’s laptop has a local admin account called “Admin” and Jo’s laptop has also a local admin account called “Admin” with the same password as the admin on Fred’s laptop, then if a network connection happening from Fred’s laptop to Jo’s laptop using that local “Admin” account, then the Security Account Manager (SAM) on Jo’s laptop will accept that connection and will consider it as the local Admin account is doing the transaction or authentication.
This is the most used attacks that happens where a malware gets access to the local Admin account hash, and authentication to all other machines with the same local admin account user name and password combination using NTLM.
Local Account Mitigation
You should not use local accounts to talk to resources across the network. When you want to do that, use domain accounts only. Moreover, if you have a machine with no network access to use a domain account, then physical access is required to that machine so that you can use the local accounts at that time.
The mitigation here is to prevent local accounts from being used to access network resources even if you have the same local account user name and passwords across your machines for some reason. So if someone compromise one machine, he cannot use the local accounts to authenticate to other machines.
Two new well-known groups are introduced (Windows 8.1 and Windows 2012 R2):
- “Local Account”
- “Local Account and member of Administrators group”
So now, you can go to your group policy editor, under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights\Assignments\Deny access to this computer from the network, and add one of those new well-known groups.
How things work in real word
Usually an attacker compromises a machine and the first thing he does is to get local administrative privileges on that machine. May be the attacker compromise the machine by drive-by-download exploit or an Excel macro and escalated privileges using an HP driver vulnerability. Some new attacks will inject the Adobe reader and prompt for Adobe reader update, and trick the user to enter his admin credentials to download the new Adobe reader version.
Then the attacker (once getting admin rights on the machine) will start to dump the local hash database and getting the hash for all local accounts. The local security databases (SAM) contains the hash for all local users The attacker now uses those user accounts and hashes to try to remotely compromise other systems on the same LAN. If the password to a local administrator accounts is the same, and the account is not prohibited from remotely logging in, the attacker will succeed in remotely compromising those systems.