The Anatomy of a Privilege Escalation Attack
… or why it’s important to follow security best practices. In this Ask the Admin, I’ll explain how an attacker can get local and domain admin privileges.
Microsoft has designed modern versions of Windows to be more secure, but security is always a difficult balancing act as impermeable fortresses don’t lend themselves to providing the features and usability we’re accustomed to. For example, single sign-on, by nature, introduces some security compromises that allow it to function. But by following security best practices, the risks can be minimized.
To understand why adhering to security best practices is important, let’s look at the anatomy of a typical privilege escalation attack, where a hacker with no privileges on the network can gain domain administrator rights. I found this example buried in Microsoft’s Advanced Threat Analytics (ATA) Playbook, a document that outlines how you can test that ATA is providing the protection it promises on the tin. And because I think it describes an attack well, I’m going to summarize it below.
Nuck Chorris is a domain admin logged into Admin-PC. Ron works on the help desk and is a member of the Helpdesk group in AD, which in turn is a member of the local Administrators group on every device. Jeff is an employee at the company, who also has local administrator rights on his PC. The ultimate prize is Nuck, because he has domain admin privileges.
Jeff opens a malicious link in an email that provides a hacker with access to Jeff’s PC. If Jeff didn’t have administrator privileges on the PC, the attacker would need to find an unpatched or zero-day vulnerability on the PC that allows privilege escalation. But Jeff has made it easy.
The attacker can now install his wares on Jeff’s PC. Tools such as PowerSploit and Mimikatz will come in useful. But even without any additional software, the attacker can use tools included in Windows to gather information about the device and network. For example, running net user /domain and net group /domain will return a list of domain users and groups, making it easier to ascertain users’ privileges.
From the information gathered using the NET command, the hacker has established that Ron is a member of the Helpdesk group in AD. Not only is Ron an administrator on Jeff’s PC, but he’s also a local administrator on every other device. Ron has logged into Jeff’s PC in the past and his credentials were cached by Local Security Authority Subsystem Service (LSASS), so using Mimikatz, the attacker is able to harvest Ron’s NTLM hash. A password hash is an encrypted version of a password created using a one-way function.
Pass the Hash
Using Mimikatz and Ron’s NTLM hash, the hacker can get a Kerberos Ticket-Granting Ticket (TGT) for Ron from AD using a technique called Overpass-the-Hash, allowing the hacker to log into Admin-PC with administrative privileges.
Using Netsess, SMB enumeration helps establish where Nuck is logged on, and the attacker already knows that Nuck is a domain administrator. PowerSploit can then be used remotely to establish who is a member of the local Administrators group on Admin-PC.
Then in much the same way that the hacker was able to compromise Ron’s account on Jeff’s PC, and because Nuck is logged into his PC with domain admin privileges, it’s possible to get Nuck’s Kerberos ticket from Admin-PC and masquerade on the network as Nuck.
While the attacker could now wreak havoc on the network, it’s more likely that he will try to lay low and plant some backdoors on domain controllers to regain access should he be discovered. This process is known as domain dominance (i.e. making it hard to eradicate the hacker’s presence on the network).
Although something of a simplification, the above gives you an idea of how it’s possible to gain access to domain admin privileges on a network. Naturally, there are various defenses and best practices that could thwart such an attack, including:
- Standard user accounts
- Application Control
- Windows 10 Credential Guard
- Restricting use of domain admin accounts to DCs
- Just-Enough and Just-In-Time Administration
- AD Protected Users group
- Ensuring Windows and applications are fully patched
- Microsoft ATA or similar
If you have to start with one of the above issues, I’d recommend restricting use of domain admin accounts to DCs or specially secured management workstations as a first step. Domain and enterprise admins are the keys to your kingdom, and once compromised, there’s no easy way back.