Different Day, Same Path to Domain Admin

One of the most common tests we perform for clients is an internal penetration test, designed to explore the vulnerabilities across a company’s internal networks. This testing emulates what an attacker that gained an initial foothold on the network could do or what kind of problems a malicious insider could cause, to put it briefly. This includes trying to find an exploitable path to domain admin and taking full control of the network as part of it (but not the whole point of the test, see red team vs. penetration test). But there is exponentially more attack surface on your internal network than your Internet-facing perimeter, and this soft underbelly often goes ignored while resources are spent on protecting the perimeter.

So one of the things we find ourselves doing often is repeating the same set of findings to organizations as part of their initial penetration test with us. So to try and help educate and get in front of some of that, let’s talk about one of the most common attack paths that continues to work, including what the elements of it are and how can you can stop an attacker at different points in the kill chain. Many organizations have probably already taken care of at least some of these things, so keep in mind that this is not a comprehensive list, but merely some low hanging fruit to take care of so you can focus on bigger problems in network security. Here’s a quick rundown of one potential path to domain admin:

1. Responder is used to conduct spoofing attacks to gather hashed credentials. This exploit takes advantage of vulnerabilities associated with the way NetBIOS Name Server (NBNS) protocol and Link-Local Multicast Name Resolution (LLMNR) protocol operate. These legacy protocols often aren’t needed in modern environments, but they are on by default on all Windows systems unless they are explicitly disabled by an organization. By listening and spoofing responses to broadcast requests from these protocols, an attacker can gather hashed credentials for users logging in on the local subnet they have a foothold on. Disabling these protocols help stop many different types of spoofing, relay, and man-in-the-middle attacks that take advantage of these legacy “features.”
2. Crack those collected, hashed credentials. Once we are able to collect hashed passwords, we’ll usually be able to crack a significant percentage of those passwords. For organizations with lower password requirements, this is usually a quick process to get at least a handful of valid credentials. For organizations with longer minimum password lengths in place, this can be slightly more difficult. Strong password policies can make an attacker’s life much more difficult at this phase of the attack.
3. Credentials cracked are local administrators of a workstation/machine somewhere and are used to dump local hashes from that particular machine . This is where organizations are starting to catch-on the dangers and are preventing users from being local admins on any machine, including their own. The ones you have to watch out for are test systems, lab machines, one-off workstations, etc. No regular user accounts in your environment should be members of a local administrator group. If you can prevent an attacker from getting local administrator access to a machine, you can can prevent an attacker from the rest of these attack vectors along the path.
4. That password is shared across all or multiple systems in the environment, and an attacker can move laterally across the network. Using the local NTLM hash of the built-in administrator, an attacker can conduct a pass-the-hash attack, using that hashed password to log into any machines with the same account/password combo without the need to crack the password. Local Admin passwords should never be shared between systems (and should definitely not be set by GPO), but instead use a solution, like LAPS, to roll-out unique passwords for all your Windows systems.
5. An attacker finds a system with cached Domain Admin credentials in memory and takes a memory dump of the LSASS process to recover the LSA secrets, which include cleartext credentials for that cached DA account. There are multiple steps to unpack and prevent all forms of privileged credentials from being dumped, but briefly, you should:

• Set “Interactive Login: Number of Previous Logins to Cache” to “0” via GPO for all Windows systems.
• Use modern operating systems (Windows 10, Windows Server > 2016) that disable WDigest caching and LSA secret access by default. If you still have older OSs, modify the appropriate registry keys (a quick summary can be found here).
• Monitor registry keys associated with these settings. They should never change, and if they do, this is a serious indicator of an attack.

So that covers a quick and dirty run-down of a very common path to domain admin that we continue to see. There are variations of this, of course, and most organizations are implementing some but not all of these recommended fixes. If you’re curious where you are at as an organization and what you should still be working on, reach out and we can discuss an internal penetration test to help you answer those questions!