Are your credential policies implemented right? Are your enterprise accounts configured correctly? How do you know?
Most phishing, ransomware, and credential attacks start by gaining access to a host and compromising a domain user (Credential Attacks – Horizon3.ai). With a credential in hand, an attacker can persist and pervade, appearing like a legitimate user and maneuver through your network with a small risk of being detected. Additionally, your zero trust framework falls apart when an attacker creates their own trust.
In more than 1,000 pentests this last year, our autonomous attacker platform – NodeZero – has discovered, dumped, captured, cracked, brute forced, and reused over a million credentials leading to critical impacts in nearly every environment we’ve encountered – from compromising a single user to an entire domain. In doing so, our customers have taken on the attacker’s perspective within their environments and learned lessons on their own policies, implementation, and enforcement they may have never seen otherwise. Repeatedly, our most successful attack paths take advantage of misconfigured management tools. One of the most prevalent, valuable, and easily misconfigured tools is Active Directory.
In Microsoft trust environments, we’ve relied on Active Directory (AD) for 30+ years to centrally manage access and permissions to resources. Where we used to have to manage asset and account access locally, AD enabled remote management, and there was much rejoicing.
Now, 90% of Fortune 1000 companies use AD (Active Directory Holds the Keys to your Kingdom, but is it Secure?) and because AD holds the keys to your kingdom, it’s a primary target for attackers and a basic building block of APTs (https://docs.broadcom.com/doc/ten-active-directory-misconfigurations-that-lead-to-total-domain-compromise-en)…including NodeZero.
Coupled with the fact that AD can easily be misconfigured (Misconfigurations in most Active Directory environments create serious security holes, researchers find), this is an easy and exploitable attack path that can lead to complete domain compromise if attackers are allowed to gain but an inch. You can’t just install a security agent or implement a framework and tell the board they can sleep safe at night; to minimize the damage that can be done, it’s really important to understand what an attacker can do with the credentials of a compromised domain user.
Therefore, you need to think like an attacker.
Attackers will probe for weak spots and exploit them. Sure, they could create a weak spot with a zero-day, but then that capability is burned; why not just take advantage of a weakness you’re offering them? Often, those weak spots start with credentials and end with privileges.
Attackers want to take advantage of “all the things” that are:
- Commonly used
- Easily misconfigured
- Holding value
As you know, AD checks each of these boxes. The value AD holds is the ability to dump or create a credential and look legit, and that credentialed access to resources then enables an attacker to legitimately persist. This is also why Active Directory misconfigurations are incredibly lucrative – one misstep in assigning account access, and the difference between a user and an administrator is just a click.
The accounts in Active Directory that are most commonly targeted by attackers are those that are members of the most-highly privileged groups… When we evaluate the membership of the highest privileged groups in Active Directory, we commonly find excessive membership in all three of the most privileged groups. – “Avenues to Compromise” – Microsoft Docs (Avenues to Compromise)
This is also why it is SO important to see what an attacker could do with any credential in your environment, testing your AD configurations – accounts, hosts, permissions – and verifying that the policies and privileges you’ve assigned to your users and admins is what you intended. This is exactly what one of our customers did.
In a recent operation (op), a customer wanted to conduct an internal pentest to see what the “blast radius” might be from a couple of compromised users and injected the following credentials: a Domain User and a System Admin.
- The system administrator credential turned out to also have domain admin rights (an AD misconfiguration).
- The domain user credential turned out to be a local admin on a box and was used to discover several other domain user credentials, one of which turned out to be a domain admin.
NOTE: in the following two use scenarios, the original credential logons, passwords, domain names, and IP address have been obfuscated.
CASE #1: From System Admin to Domain Admin
Because misconfigurations are easily introduced and credential reuse is so prevalent (Save Your Data with Empowering Password Statistics | DataProt), once it discovers a credential, NodeZero will verify it is a legit credential and then attempt to gain access anywhere it can.
While we usually chart an attack path towards what is most valuable and vulnerable, NodeZero immediately used the injected credential to successfully log in to a domain controller over SMB. It discovered the credential had domain admin rights because it had read/write privileges on administrative shares.
In case you missed it, this was a System Admin credential and was NOT supposed to also have Domain Admin rights. There was zero privilege escalation and zero dump to get domain admin credentials; this credential was all NodeZero needed to wreak havoc.
After checking their Active Directory and screenshotting this credential to prove that it didn’t have Domain Admin rights, the customer wanted to review the operation with us to make sure this was not a false positive. We rallied with the customer, shared screens, and ultimately asked them to attempt to log in to the DC with the credential. It worked. This credential had administrative access to administrative shares. Immediately, the customer dug in and removed rights from this account. Then, when they checked, the admin rights were still present.
Our NodeZero Certified Partner, Liberman Networks, was also on the call and requested the admin to pull up the credential’s security groups/rights and check the “Member Of” tab; and among the six groups was an embedded group tying back to a Domain Administrator group, thereby giving this credential – and several other users and administrators –Domain Admin rights.
At this point, they called in the lead system administrator, found this additional rights tree, and started pruning.
In this first instance, NodeZero was able to take advantage of a misconfigured system administrator credential to create a domain compromise impact.
CASE #2: From Domain User to Domain Admin
- NodeZero launched and injected the environment with a single Domain User credential.
- NodeZero executed a Host Discovery and found two Domain Controllers and 3K workstations.
- NodeZero executed a TCP Port Scan and discovered the SMB service was running on both DCs and a workstation.
- NodeZero attempted an SMB login on the first DC with the injected system user credential and verified as a Domain User.
5. NodeZero attempted and was able to use the domain user credential with local admin rights, so it dumped several new user credentials in cleartext from the workstation.
6. NodeZero then attempted an SMB login on the second DC with newly found user credentials and was able to use one of the newly found credentials to login as a Domain Admin.
7. NodeZero accessed the DC with Read & Write privileges.
8. Game Over.
In this case, NodeZero was able to utilize a simple domain user credential to great effect, chaining together an attack path en route to Domain Administrator. Whether misconfigured or wrongly-but-deliberately approved, that credential also had local admin rights that were then used to dump other credentials – one of which was a domain admin.
Domain admins are often looking to AD for managing access to every resource, while local admin rights can be (mis)configured directly on the host, and AD isn’t going to spotlight that personal credential as having those rights. Understanding your local configurations is just as important as understanding your enterprise-wide ones. Having that awareness of how domain, local, and service accounts tie together – and CAN be used to lead to other credentials compromised – is critical. That’s why we ask the question: how do you know?
- Is this directly an AD misconfiguration? Maybe.
- A credential misconfiguration? Maybe.
- A risk misunderstanding? Definitely.
The greatest issue is the lack of attention we allocate to verifying our policies, our implementation, and our enforcement. This lack of attention exacerbates misunderstanding and misconfiguration, creating a destructive security cycle… for which attackers are all too ready to exploit.
“This is a good experience for me to teach the team the importance of credential use and reuse. We never would have found this without you guys…” – Director of Infrastructure
Lessons Learned
You need to think like an attacker.
Your digital environments are complex, and therefore, prone to to misconfigurations. It’s no secret that Active Directory requires active management. If there is an area of our networks we’ve got to get right every time, it’s our domains and credentials. Personnel and their roles are in constant flux, and the maintenance of those permissions and privileges is critical to your cybersecurity. Key to simplifying the complexity in your environment is the perspective of an attacker, which often thrives in those misconfiguration gaps and seams.
Active Directory administration is critical to your remote network management, so you can expect misconfigurations to lead to critical impacts because the implementation and enforcement of policies is fraught with missteps. Administrative vigilance is key and not a bad law: (10 Immutable Laws of Security Administration).
A couple recommendations going forward:
- If you haven’t already, implement a least-privilege administrative model (and include resources, accounts, privileges, and access location, timing, and rights) and review with your IT, security, and dev teams how they’ve implemented your guidance in AD workflows. Every connection, path, and point is a potential (opportunity for attacker) for misconfiguration.
- Continuously verify account access to prove your AD policy is working, or not working. Your AD system administrators should be able to see every account and every embedded group membership. You have to cross-reference this with HR to ensure your current personnel align with current AD resource access.
- Test your security tools to see how an attacker might use lower level protocols get around your policy enforcement; then, invite an offensive security expert’s insight and ask them to show you proof.
Bottom Line: Test your rules and tools. If you don’t, you’re presuming success… and that’s a risk none of us can afford. Proof wins, every time.
