Welcome back! Today it is "All About Users".. let's see if we come even further along into some more advanced concepts. Maybe we can even progress so far that next time, we can come to the HTB Active Directory Lab. At latest in Part 5.

Active Directory Accounts Demystified - Part 1: Users, Machines & Security Principals

Active Directory (AD) environments revolve around accounts, whether users, services, or machines.
Every action in AD happens in the context of an account, and attackers are laser-focused on abusing misconfigurations here.

User Accounts: Your Digital Identity Badge

Purpose

User accounts grant interactive login access or background access (like for services). They authenticate users or processes and control access via group membership and assigned rights.

Think of a user account like an employee's ID card and key badge - it identifies who they are, what rooms they can access and which machines they can use.

Anatomy of a User Account

For any terminology questions, you can look up here

sIDHistory is a high-value attribute during recon; attackers love it when SID filtering is off, as it allows impersonation across domains.

SID vs GUID: The Misunderstood Twins

SID is your name tag; GUID is your fingerprint.

🔗 AD User Object Attributes

Types of User Accounts

Tip: Watch for service accounts running with Domain Admin or similar privileges - a common and risky misconfig. Why ObjectGUID matters:
Even if a user is deleted and re-created with the same name, the ObjectGUID will be different, which helps admins (and attackers) distinguish between original and replaced accounts. It’s also essential during AD replication and disaster recovery.

Shared & Guest Accounts – Risks to Watch For

While domain environments aim for individual accounts, shared accounts and enabled guest accounts still appear in real-world environments.

On an assessment, always check if Guest is enabled or if multiple machines share the same svc_user login - a prime indicator of low maturity.

Local Accounts vs. Domain Accounts

Local Accounts

Exist only on a specific machine (not tied to the domain).

Examples: Administrator, Guest, SYSTEM, LocalService, NetworkService

Auth only works on that host - it is managed locally (no domain policy applies)

Notable Local Accounts

Gaining SYSTEM == full local compromise → lateral movement → AD recon.

Built-In Groups That Can Bite You

AD ships with default groups that often hold privileges attackers love, and admins often assign to users without understanding their full power.

Always audit who is a member of these groups, and whether machine accounts are present in them (a misconfig seen in real-world pentests).

BloodHound Goldmine Groups

• Backup Operators → Can read ntds.dit directly (!)
• Print Operators → Can load unsigned drivers
• Server Operators → Can log into DCs (!)

Always check Get-ADGroupMember "<Group>"; even if empty, it’s worth knowing.

Domain User Accounts

• Created in AD
• Can log in across any domain-joined host
• Governed by Group Policies
• Controlled centrally via ADUC / PowerShell

PS C:\> Get-ADUser -Identity <ACCOUNT_NAME>

Always check Enabled, GroupMembership, LastLogonDate, SID, and whether it's a stale account still holding privileges.

SYSTEM != Local Only

When you're SYSTEM on a domain-joined host, you're often able to:

• Query AD with ldapsearch, PowerView (see below), or SharpHound (see below)
• Access NetSession, NetUser, and WMI info
• Pull creds from memory (e.g., with Mimikatz or LSASS dump)
• Start AD enumeration without any stolen user credentials

SYSTEM access is frequently underestimated, but it can give you read access to most of the domain’s public data, which is gold for attackers.

SYSTEM Recon: Real-World Use

Once SYSTEM access is obtained (via RCE, LPE, misconfigured service, etc.) on a domain-joined host, the door opens for deep Active Directory enumeration, even without a single stolen credential.

# From SYSTEM shell
whoami                         # Returns "NT AUTHORITY\SYSTEM"
nltest /domain_trusts          # Enumerate trust relationships
net group "Domain Admins" /domain

Tools you can (and should) run as SYSTEM:

• SharpHound → Full AD recon via bloodline data
• PowerView → Flexible LDAP queries
• dsquery, nltest, net user /domain → Built-in native tooling

Here’s a handy list of built-in tools and PowerShell one-liners that work even from low-priv SYSTEM or user shells:

Combine with PowerView to go deeper, or use these from SYSTEM shells for fast visibility.

SYSTEM = Machine Account = Domain User

Think of SYSTEM as:

You’ve hijacked the company car, you’re driving around with a machine’s identity, getting access wherever that host could go. No user creds needed.

Remember: a domain-joined computer (i.e., COMPUTER01$) is itself an AD account. When you're SYSTEM, you're using that computer account's identity to talk to the domain.

This level is ideal for recon, but usually not privileged enough for major changes, yet it's a fantastic launchpad for identifying:

• Open shares
• BloodHound paths
• Kerberoastable accounts
• Misconfigured ACLs

Many initial footholds in red teaming start with SYSTEM, not a stolen user credential.

Where Are Users Stored?

Organizational Units (OUs) group users for:

• Structure
• GPO (Group Policy) application
• Delegation

Common OUs:

• Employees
• Admins
• Service Accounts
• Former Employees ← Check for disabled-but-still-privileged accounts

Common Misconfigurations

Token Bloat, Group Nesting & Access Confusion

In large domains, users may be in dozens of nested groups; directly or indirectly. This leads to "token bloat", where a user's access token becomes massive.

BloodHound is your best tool here, use it to resolve "Who can actually do X?" based on group nesting.

Machine Accounts, Domain Join & Workgroup Differences

What is a Machine Account?

Just like users, machines (computers) get their own account in Active Directory. These accounts:

• Represent the machine's identity in the domain
• Enable secure communication and authentication
• Apply group policies
• Track changes, logins, and ownership

A machine account is like a registered company vehicle – it gets its own plate, logbook, and access rights based on trust.

Machine Account Characteristics

Domain Join Process: What Happens?

When a machine joins a domain:

1. A machine account is created in AD (COMPUTER01$)
2. A shared secret (password) is set between the machine and the domain controller
3. The machine gets:
   • Group Policy Objects (GPOs)
   • Central authentication ability (Kerberos, NTLM)
   • AD DNS resolution
4. It can now be managed by IT via AD tools (updates, scripts, compliance, etc.)

A domain join is not just “joining a group” – it’s a full trust relationship established through secure credentials and policy sync.

Domain-Joined vs. Workgroup (Non-Domain) Hosts

Machine Accounts in Attacks

While they’re not interactive users, machine accounts can still be leveraged:

Some environments accidentally grant machine accounts excessive rights (like write access to OUs or GPOs) – always look for ACL misconfigurations!

Key Defense Tips for Machine Accounts

• Regularly review computer object ACLs
• Avoid giving write/modify access to non-admin machine accounts
• Monitor for machines in sensitive AD groups
• Use LAPS (Local Admin Password Solution) to manage local admin creds
• Harden RDP, WMI, and service-to-service auth to prevent PtH abuse

Spotting a Domain Join in PowerShell

# Check domain membership
(Get-WmiObject Win32_ComputerSystem).PartOfDomain

# Show machine domain
(Get-WmiObject Win32_ComputerSystem).Domain

If this returns True and shows a domain name like corp.inlanefreight.local, you're dealing with a domain-joined box.

Active Directory Groups - The What, Why & How

Groups in AD – Why Bother?

Think of groups like buckets of access rights. Instead of assigning 50 people access to the printer room one by one, you drop them into a group called PrinterPeople, and grant that group the rights.

• Simple to manage
• Easier to audit
• Reversible without tears

But beware: these “buckets” can become overflowing cauldrons of unintended privilege if no one’s watching.

Groups vs. Organizational Units (OUs)

If you don't remember the analogy in part 1 to illustrate such concepts, i recommend to check it out.

Group Types

When creating a group in AD, you pick one of two types:

You’ll care way more about security groups when doing pentests or recon.

Group Scopes – Where Do They Work?

Universal groups are like VIP passes, but every change triggers a domain-wide update. Use them wisely!

Scope Change Rules (because of course there are rules)

If a group contains stuff that doesn’t "fit" in the new scope, conversion fails.

Built-in vs. Custom Groups

Always check who is in the built-in groups and what rights they actually have!

"Groups are Access Abstractions"

• Want access to something? Join a group.
• Want to give access? Add a group to the ACL.
• Want minimal headaches? Nest cleanly, scope smartly, and audit regularly.

You’re now primed on how groups work structurally. Next up: how attackers (or savvy admins) use nested groups, BloodHound, and subtle privilege chains to climb the access ladder without being loud.

Active Directory Groups – Nesting, Recon & Privilege Escalation Without the Noise

What the Heck Is Nested Membership?

A group inside a group… inside a group. Like Matryoshka dolls.. or access inception.

If DCORNER is in Help Desk, and that’s in Helpdesk Level 1, which is in Tier 1 Admins… → DCORNER now has Tier 1 Admin rights.

You don’t need to be in the admin group… if your group is.

Why Attackers LOVE Nested Groups

• Grants unintended privileges (quietly)
• Hard to see without tools
• Ideal for privilege escalation in large or old environments

“I’m not admin... but I can add myself to the group that is.” – Hopefully we, later in the lab.

BloodHound: Your Best Recon Tool

BloodHound untangles this spiderweb.

Use built-in queries like:

• Shortest Paths to Domain Admins
• Effective Access over Objects
• Group Membership Escalation Paths

Use it to:

• Spot GenericWrite on sensitive groups
• Find nested paths to high-value access
• Detect stealthy escalation paths admins forgot about

BloodHound doesn’t just tell you “who’s in what group” — it tells you “who can become what by abuse.”

Example: GenericWrite Escalation

User: DCORNER
Group Chain: Help Desk → Helpdesk Level 1 → Tier 1 Admins
Tier 1 Admins has GenericWrite on “NY Workstations” group
→ DCORNER can now edit group membership or linked GPO

Boom. From low-priv helpdesk to full host access. The domain never saw it coming.

“One nested group away from some nice privileges.” – Also you, soon

AD Group Cheat Sheet

Gotchas to Remember

• Users can gain access through nesting, even if not directly listed
• Universal groups cause forest-wide replication
• Scope changes have rules (some block conversions)

“No access” at first glance? Dig deeper. That intern might be 2 steps from controlling GPOs.

Group Investigator Starter Pack

A few commands to get your recon rolling:

whoami /groups                    # See current shell's token
Get-ADGroupMember "Tier 1 Admins"  # List members
Get-ADUser -Identity USER -Prop MemberOf

Want the deep view? Grab BloodHound and SharpHound for full domain visibility.

AD Groups TL;DR

• Groups grant access. Nested groups grant hidden access.
• BloodHound exposes real effective privileges.
• Admins forget. You won’t. Trace those chains!

I think that's it for this time. Hope you had a good read, i'm sick with the flu so this post will come a few days late.