Welcome to the final installment of The Attacker’s Playbook. So far, we’ve covered exploiting the human element (Part 1), finding unlocked doors (Part 2), and using forgotten keys to the kingdom (Part 3) to get inside a network.

But initial access is just the beginning. The real damage is done when we move through the internal network, abusing trust and misconfigurations to turn a minor foothold into a major compromise.

Navigating the Active Directory Maze

Active Directory (AD) is the heart of most corporate networks, but its permissions can become a tangled “rat’s nest” of complexity. An automated vulnerability scanner can’t understand the intricate web of trust relationships that a human attacker can exploit.

The Flaw: A standard user account may seem harmless, but it could have a hidden, indirect path to administrative power. It’s not uncommon to find that the default “Domain Users” group has overly broad permissions, such as the ability to log into nearly every computer on the network, including servers. 

Specifically, we look for the “GenericAll” permission. This allows one group to fully control another object. Even if the target account is disabled, an attacker with GenericAll rights can enable it and abuse those permissions.

The Attack: As we acquire user accounts, we use Bloodhound to map complex relationships and find unexpected privilege escalation paths.

This exact flaw was enumerated on a recent pentest where the “Domain Users” group had GenericAll access to a disabled service account. Seemingly for no reason, this permission existed on an account no one was monitoring.

From there, we enabled the account, reset the password, and masqueraded as that service account on the network. We discovered this service account had interesting permissions, including the ability to modify the password of a Domain Administrator.

After confirming this action was allowed within the Rules of Engagement (ROE), the team abused these permissions to take over the entire AD forest and ultimately the network.

The Result:  By manually navigating this maze, we can turn a low-privilege account into a full Domain Administrator, demonstrating a critical risk that no vulnerability scanner would discover.

Mitigation Strategies: Active Directory is a common target because it’s often a “rat’s nest” of complex permissions.

• Audit Regularly: Conduct regular AD audits to enforce least privilege.
• Restrict the Defaults: Remove overly broad permissions, especially for large groups like “Domain Users.”
• Defensive Mapping: Use BloodHound defensively to identify and remediate risky attack paths before adversaries exploit them.

Thinking Like an Attacker

The most damaging breaches rarely rely on a single vulnerability. Instead, they emerge from creative chaining of minor, overlooked issues, a forgotten file, an exposed port, a default password—into a pathway through the maze of internal trust.

Key Takeaways:

• Chains vs. Checklists: Attackers think in chains, not checklists. Automated tools can miss the complexity of real attack paths.
• The Human Edge: Human-led testing is critical for finding and fixing hidden risks.

Defending against these threats requires adopting the attacker’s perspective. This is where red team expertise provides the greatest value, simulating real-world thinking, not just automated scans.

Your security journey doesn’t end with this playbook. Contact us to learn how our expert-led penetration testing helps organizations secure their networks from the inside out.

---

That wraps up The Attacker’s Playbook. But your security journey shouldn’t stop here. Check out our deeper dives on Active Directory in  “Abusing Active Directory: Down the Rabbit Hole We Go,” and watch this short clip from our recent webinar on Active Directory permission risks  — or get in touch to test your defenses before attackers do.

In penetration tests and red team engagements, we frequently exploit privilege escalation paths in Active Directory (AD). When discussing remediation, clients often think, “I’ll just disable that account to eliminate the risk.” However, in some instances, simply disabling the account does not remove the risk. When we explain this to customers, they tend to look confused because the account is indeed disabled. Still, the residual risk is tied to specific escalations involving permissions over a higher-privilege account from alternative access. For example, privileges such as “WriteDACL” or “GenericAll” can enable an attacker to exploit a disabled account by re-enabling it and leveraging the escalation path as if it were never disabled.

Basic Example:

During an engagement, the team gains access to several users through password guessing or by discovering cleartext passwords on shared drives and begins evaluating the access and privilege escalation paths of these compromised users within Active Directory. The team identifies one user (User A) who has (GenericAll) rights over User (B).

This is especially interesting because appears that User A’s access to User B is somewhat outside the normal permissions, as the rest of the permission paths reside with high-value targets.

Further investigation shows that User B can do a lot of interesting things (effectively has control over all the domain objects):

In this instance, User B is disabled. However, since the attackers have User A, who has “GenericAll” over User B, they can enable the user and leverage it to escalate their privileges.

This perfectly demonstrates how simply disabling the account of User B does not reduce the risk for this attack path; it just adds an extra step for the attacker to enable the account, which is trivial.

So What Should You Do?

Now that you understand simply disabling accounts within AD doesn’t always eliminate the attack surface, you should consider the following:

1. Removing the account if it’s no longer needed
2. Removing the access from the account if you are unable to remove it entirely
3. Evaluate attack paths to this disabled account to see if paths exist that expose you to risk

Tips for Investigation:

We find it useful to assess the outbound rights of all disabled accounts (we do this for every account in the domain, but to focus on the topic of this blog, we will concentrate on disabled users) to identify those with significant access. From this point, examine who has rights to reach them (inbound permissions). This can assist in pinpointing potential escalation paths from lower targets to disabled accounts that possess considerable access. Below are some helpful Cypher Queries you can leverage within Neo4j against the Bloodhound database:

List all Disabled Users:

MATCH (m:User {enabled: false}) return m.name, m.objectid, m.admincount

Using the SID for each user (m.objectid), you can list out transitive permissions for each user based on a count:

MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH p=shortestPath((u:User 
{objectid: '"+objectid+"'})-
[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|AllExtendedRights
|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)

In practice, we find querying is best done in Python. Below is a more complete snippet of code:

def get_disabledUserOutboundRights_transitive():
    with GraphDatabase.driver(URI, auth=AUTH) as driver:
        result = do_query(driver, "MATCH (m:User {enabled: false}) return m.name, m.objectid, m.admincount")
        disabled_outbound_file=open("disabled_user_outbound_transitive_rights.txt", "w")
        for record in result:
          if record["m.name"]:
              username = record["m.name"]
              objectid = record["m.objectid"]
              admincount= record["m.admincount"]
              result1 = do_query(driver, "MATCH (n) WHERE NOT n.objectid='"+objectid+"' MATCH 
p=shortestPath((u:User {objectid: '"+objectid+"'})-[r1:MemberOf|AddSelf|WriteSPN|AddKeyCredentialLink|AddMember|
AllExtendedRights|ForceChangePassword|GenericAll|GenericWrite|WriteDacl|WriteOwner|Owns*1..]->(n)) RETURN count(p)")
              for record1 in result1:
                  if record1["count(p)"]:
                      trans_rights=str(record1["count(p)"])
                      disabled_outbound_file.write("[-] User: "+username+" Transitive Outbound Rights: "+trans_rights+" 
Admincount: "+str(admincount)+"\n")
        disabled_outbound_file.close()

    with open("disabled_user_outbound_transitive_rights.txt", "r") as fp:
        entries = str(len(fp.readlines()))
    print("[+] Generating a List of Disabled Users with Transitive Outbound Rights: disabled_user_outbound_trans_rights.txt 
("+entries+") lines")

The result will make a text file of all the disabled users and their transitive outbound rights, one per line. This can help us analyze the outbound rights of all disabled users quickly to find interesting targets for additional analysis:

The output will look like this:

[-] User: userb@BREAKPOINT.LABS First Degree Outbound Rights: 20771 Admincount: True

So to sort the data based on "who has the most rights", first we will use the Linux sort utility based on a number in reverse 
order on the 7th element in the line (which is the outbound right count).

└─$ cat disabled_users_outbound_transitive_rights.txt | sort -nr -k 7,7 | less -S
[-] User: userb@BREAKPOINT.LABS Transitive Outbound Rights: 20771 Admincount: True
[-] User: userc@BREAKPOINT.LABS Transitive Outbound Rights: 6165 Admincount: True
[-] User:userd@BREAKPOINT.LABS Transitive Outbound Rights: 5098 Admincount: True
[-] User: usere@BREAKPOINT.LABS Transitive Outbound Rights: 4821 Admincount: True
[-] User: userf@BREAKPOINT.LABS Transitive Outbound Rights: 4821 Admincount: True

From here, review the inbound rights for these accounts in Bloodhound, and you might discover an interesting way to control one of these disabled users who have extensive rights in the domain.

Key Takeaways

Disabling an Active Directory account does not always equate to eliminating risk. Attackers can potentially re-enable disabled accounts if they possess the necessary permissions, such as “GenericAll” or “WriteDACL,” on those accounts. To truly mitigate risks, organizations should go beyond simply disabling accounts. Consider removing the account entirely if it’s no longer needed, revoking its access rights, and thoroughly evaluating potential attack paths leading to these disabled accounts.

By proactively assessing outbound and inbound rights, especially for disabled accounts with significant access, and utilizing tools like Bloodhound and Cypher queries, you can uncover hidden vulnerabilities and strengthen your Active Directory security posture. Remember, a seemingly disabled account can still pose a threat if the underlying permissions are not properly addressed.