Written by: Joseph Sarkisian, GWAPT
On a recent internal penetration test, I realized something—the initial foothold on the network, privilege escalation, and full domain compromise consisted of steps that were identical to two or three other tests I had just executed.
The steps that I took are well-known attack methods used by hackers, but may not be clear to administrators trying to determine how to best close network security gaps that would easily allow attackers to gain access.
I have compiled a detailed analysis of each of these penetration testing components to allow administrators to build a more mature controls posture in their organization and help prevent attacks by hackers.
Please note that none of the following steps leverage any exploits; we’re simply taking advantage of misconfigured trust relationships in the network.
It’s often said that protocols are a pen tester’s best friend. Some of these include Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBNS), which are legacy protocols used by Windows to resolve hosts on the network, long overshadowed by the Domain Name System (DNS).
DNS tends to respect the privacy of the hosts that it isn’t seeking out. When one host needs to know the name of another host, DNS looks it up, and if it doesn’t find anything it essentially states that it can no longer help.
On the other hand, if DNS fails, LLMNR and NBNS (if enabled) will send a broadcast message across the subnet asking every host if they are the resource sought by the user.
That’s where our hacking methods come in.
In our own test environment, using a tool called Responder, we’ll position ourselves on that subnet and answer all of these broadcast messages. For example, we’ll respond to the request for a file server and say that we’re the intended file server. The tool then tricks the requesting host into providing its password hash to us to authenticate to that file server. We can then reverse the password hash using a password cracking tool. Let’s see what Responder looks like when this attack is successful:
In addition to the weak protocol itself, this also illustrates the importance of a strong password policy. If the organization isn’t enforcing strong password requirements, then we can quickly recover the password for this account and further enumerate with Alice’s privileges. But what if we don’t want to have to deal with pesky hash cracking? Then Responder once again comes to the rescue.
The tool has an option to force a basic authentication box to appear whenever an end user opens a web browser. The pop-up will ask the user to authenticate, and the credentials entered will be provided in plain text to us, which looks like this:
As you can see, we’ve taken advantage of the fact that this network doesn’t have a hard-coded location for the Web Proxy Auto Discovery (WPAD) file in DNS records.
WPAD easily allows hosts to auto-discover the web proxy that’s set up on the network so that it may reach out to the internet through that proxy. This information is stored in a file called “wpad.dat.” When looking for this information, hosts will automatically look for that file.
This means that we can answer and state that we are the WPAD host and offer a wpad.dat file. But, we can ask for authentication before allowing access to the file (hence the pop-up box asking for credentials in the browser).
Now we have an initial foothold, either by cracking a password hash or getting plaintext credentials. What do we do next? We enumerate the user’s privileges on the network and escalate.
One of the most useful enumeration tools is Bloodhound.
Bloodhound uses graph theory to help build a visual map of the domain once we have user credentials. Given the nature of how Active Directory (AD) works, users must determine what’s on the network. To do so, users have to query a domain controller (DC) which stores all of this information like computers, users, active sessions, group policy, and more.
By using a tool to extract this data from a DC, we can feed it into Bloodhound to see our map. Here’s an example of what this looks like:
In the above map, we can see that there’s an account called MSSQL that’s a member of the domain admins group. This is clearly an account we want to target, since it has the highest likelihood of granting us access to the network.
Let’s also see what kind of access Alice has on the network:
Lucky us! Alice is a member of a group call “LOCALADMINS,” which is very likely to have the escalated permissions we need to get where we want to go. To be sure, let’s use Bloodhound again to look up this group and find out:
Great! The “LOCALADMINS” group is an administrator to what appears to be a Windows 7 host on the network. This means that Alice is an administrator on this host.
So, how do we verify this and continue escalating? CrackMapExec (CME) will be used in our next escalation steps.
CME is an extremely versatile tool that wraps many types of hacking methods into one package. In our scenario, we’re telling the tool to leverage the Server Message Block (SMB) protocol to traverse the environment. We’re going to enumerate Alice’s privileges on the WIN7 host to see if she actually has any administrative rights. Let’s see what that looks like in CME:
We love seeing orange in CME because it typically means we have something very useful, and in this case, it’s the grand prize. “Pwn3d” is the tool author’s way of saying that this user has administrative privileges on this host. Clearly, this means we have many more rights than your average user, but what rights matter to us if we want to get to the MSSQL account?
It’s common in a domain to find more than one account with an active session running on any given host. While this may only be a workstation and not a server, we’ll still check to see if anyone else is logged on to this host using CME:
Perfect! It just so happens that the MSSQL account—a known domain administrator based on our Bloodhound reconnaissance—is also logged into this host. This is important because as an administrator, Alice can dump the memory of the host, specifically the Local Security Authority Subsystem Service (LSASS) process, which stores the credentials of all logged on users. Let’s see what that looks like as well:
Amazing! Not only do we now have the hashed password of the MSSQL account, which we could easily us in a “Pass the Hash” attack, but we also have the plain text password for the account.
With these domain administrator credentials, we typically give our clients a free password strength audit by using them to dump the NTDS.dit file on a domain controller. This file has all of the password hashes for the accounts in the domain, which we can feed into a hash cracking machine to reveal the plaintext password for the accounts in the domain.
Let’s see what this dump looks like:
As you can see, the file has hashes for all domain accounts, which we can then leverage. We have now compromised the entire domain, but most penetration testers don’t stop here—because during a live attack, a hacker wouldn’t either. Our clients want to see business impact, and we typically don’t need domain administrator credentials to prove this point.
For instance, let’s see what kind of data Alice can access by using CME once again to look through shares on the network. We’ll use the MSSQL account to do this, since it likely has the most access, but the following example works with Alice’s credentials as well:
Looks like Alice is storing a file with passwords to other systems on this host. This isn’t an uncommon scenario, and we’ve seen this exact situation before during actual engagements.
Whether it be a password file, customer data, health record, drug trial, or any other sensitive information, if a user is downloading it from a server and storing it locally, we now have access to it.
How Can You Mitigate These Attacks?
Initial Foothold Phase:
- Turn off LLMNR and NBNS
- Make sure you have a DNS entry for your approved WPAD file
- Turn off proxy auto-discovery from web browsers across the domain via group policy
- Enforce a strong password policy
- Train your end users to spot strange occurrences (like atypical pop-ups asking for credentials)
- Use Wireshark and NetFlow analysis tools to look for abnormally large LDAP queries right after an authentication event by an account that has no business generating this amount of traffic
- Make sure that users have as few permissions as is reasonably possible, depending on your organization
- Rid yourself of all legacy operating systems
- Disable WDigest authentication to prevent passwords from being stored in plain text in memory
- Lock down object permissions across the network
- Remove excessive write permissions across accounts
- Segment, segment, segment
The different types of hacking techniques identified in the attack narrative outlined above are not the only way attackers and penetration testers will attempt to compromise your network. However, by using this extremely common process, we can use these tools and strategies to further penetrate your systems.
If administrators lock these basic vulnerabilities and misconfigurations down, they’ll make the lives of malicious attackers much harder.