> ## Content Index
> Fetch the complete content index at: https://niklas-heringer.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Active Directory Journey Day Three - All about Users & Groups
- URL: https://niklas-heringer.com/penetration-testing/active-directory-journey-day-three/
- Published: 2025-06-16T07:42:00.000Z
- Updated: 2025-11-16T09:18:14.000Z
- Description: This post digs into Active Directory user accounts, local vs. domain context, and why SYSTEM access is a bigger deal than you think. You’ll learn where users live, how machines act like users, and how attackers use this to map, move, and mischief.
- Author: Niklas Heringer
- Tags: active-directory, ad-challenge, ad-infrastructure, blood-hound, group-management, penetration-testing

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

| Property               | Description                                                                                                                                                                                           |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Security Principal** | Yes - Can be assigned permissions and authenticated                                                                                                                                                   |
| **SID**                | Unique identifier used for access control and security                                                                                                                                                |
| **Token**              | Created at login; contains the SID and group memberships                                                                                                                                              |
| **Group Membership**   | Defines access to files, systems, and privileges                                                                                                                                                      |
| **UserPrincipalName**  | Primary login name (usually like an email): alice@corp.local                                                                                                                                          |
| **sAMAccountName**     | Legacy login name (pre-Win2000): alice                                                                                                                                                                |
| **ObjectSID**          | The actual SID string (e.g., S-1-5-...) that identifies the account                                                                                                                                   |
| **sIDHistory**         | Stores previous SIDs (e.g., after domain migration); used in attacks if unchecked                                                                                                                     |
| **ObjectGUID**         | 🔐 Globally unique identifier for the object. **Never changes**, even after renaming or movement. Remains the same if restored from deletion. Ideal for tracking users across migrations or restores. |

For any terminology questions, you can look up [here](https://niklas-heringer.com/penetration-testing/introduction-to-active-directory/)

> `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**

| Property | SID                   | ObjectGUID                     |
| -------- | --------------------- | ------------------------------ |
| Purpose  | Access control & auth | Unique object tracking         |
| Changes? | Yes (if re-created)   | No (stays constant)            |
| Use case | Permissions           | Replication, forensic tracking |

> SID is your **name tag;** GUID is your **fingerprint**.

🔗 [AD User Object Attributes](https://www.windows-active-directory.com/active-directory-user-objects-management.html?ref=niklas-heringer.com)

## Types of User Accounts

| Type                  | Example                       | Relevance                                            |
| --------------------- | ----------------------------- | ---------------------------------------------------- |
| **Standard User**     | alice@corp.local              | Daily login account                                  |
| **Admin User**        | alice.admin@corp.local        | Higher privileges (often second account)             |
| **Service Account**   | sqlsvc, backupsvc             | Used by services/apps (**watch for over-privilege**) |
| **Deactivated Users** | Former employees, contractors | Often **still have privileges** (!), recon target    |

> 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.

| Risk Type                 | Why It’s Dangerous                                                   |
| ------------------------- | -------------------------------------------------------------------- |
| **Shared Accounts**       | No individual accountability, makes lateral movement harder to trace |
| **Guest Accounts**        | Often poorly configured, can allow **unauthenticated login**         |
| **Hardcoded Credentials** | Often tied to apps/scripts; if shared, a compromise spreads fast     |

> 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

| Account            | SID Ending                         | Rights / Use                                    |
| ------------------ | ---------------------------------- | ----------------------------------------------- |
| **Administrator**  | \-500 (full SID: S-1-5-domain-500) | Full local control, disable/rename recommended  |
| **Guest**          | \-501                              | Rarely used, often disabled, big risk           |
| **SYSTEM**         | (none)                             | **💥 Highest local privs**, used by OS services |
| **LocalService**   | (none)                             | Minimal privileges, network = anonymous         |
| **NetworkService** | (none)                             | Moderate local, **presents creds on network**   |

> 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.

| Group Name           | Abuse Potential / Privileges                                        |
| -------------------- | ------------------------------------------------------------------- |
| **Administrators**   | Full control over the system                                        |
| **Backup Operators** | Can bypass file permissions, **read any file** (e.g., ntds.dit)     |
| **Print Operators**  | Can load drivers — historically used for **DLL injection**          |
| **Server Operators** | Can log on locally to DCs, manage services; serious risk if misused |

> 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

```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](https://docs.ldap.com/ldap-sdk/docs/tool-usages/ldapsearch.html?ref=niklas-heringer.com), 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.

```powershell
# 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**](https://github.com/SpecterOps/SharpHound?ref=niklas-heringer.com) → Full AD recon via bloodline data
- [**PowerView**](https://powersploit.readthedocs.io/en/latest/Recon/?ref=niklas-heringer.com) → 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: 

| Tool / Cmdlet                         | Purpose                         |
| ------------------------------------- | ------------------------------- |
| whoami /groups                        | Show group memberships          |
| net group /domain                     | List all domain groups          |
| net user /domain                      | List users, check lockout, etc. |
| dsquery group -samid                  | See group members               |
| Get-ADGroupMember -Identity "<Group>" | PowerShell-based view           |

> 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.

| SYSTEM Access (On Host) | Equivalent to...               |
| ----------------------- | ------------------------------ |
| SYSTEM on WEBSERVER01   | WEBSERVER01$ AD account        |
| AD Group Membership     | Often just "Domain Computers"  |
| Access Scope            | Most read-level AD enumeration |

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**](https://niklas-heringer.com/penetration-testing/active-directory-journey-day-two/#practical-enumeration-tip) accounts
- Misconfigured ACLs

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

---

# Where Are Users Stored?

[**Organizational Units (OUs)**](https://niklas-heringer.com/penetration-testing/introduction-to-active-directory/#third-level---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

| Issue                                | Why It's Risky                                    |
| ------------------------------------ | ------------------------------------------------- |
| Users in wrong groups                | Privilege escalation via misgrouping              |
| Service accounts with DA rights      | Full domain compromise possible via Kerberoasting |
| Shared user accounts                 | No auditability, easy for lateral movement        |
| Old/deactivated accounts not cleaned | Still have SID access, attack surface remains     |
| Weak naming conventions              | Easy to fingerprint (e.g. svc\_sql, bob-admin)    |

## 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.

| Concept              | Explanation                                                               |
| -------------------- | ------------------------------------------------------------------------- |
| **Token Bloat**      | Too many group memberships → issues with logon, GPO application, auditing |
| **Nested Groups**    | Users inherit privileges from groups inside groups → great for BloodHound |
| **Access Confusion** | Admins lose track of who really has access to what                        |

> **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

| Property               | Explanation                                                                  |
| ---------------------- | ---------------------------------------------------------------------------- |
| **Name**               | Typically HOSTNAME$, e.g., WS01$                                             |
| **Password**           | Yes — Automatically managed & changed every 30 days (by default)             |
| **Stored in AD**       | Usually under the CN=Computers container or custom OU                        |
| **Security Principal** | Yes, has a SID and can be authenticated                                      |
| **Used For**           | Auth to domain controllers, group policy application, log tracking, and more |

## 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

| Property               | Domain-Joined Host                    | Workgroup Host                          |
| ---------------------- | ------------------------------------- | --------------------------------------- |
| **Account Type**       | Has a machine account in AD (WS01$)   | Local accounts only                     |
| **Central Management** | Yes, via AD and Group Policy          | No, fully manual                        |
| **User Logins**        | Any authorized domain user            | Only local users defined on that host   |
| **Policy Enforcement** | GPOs apply automatically              | No group policy – local config only     |
| **Use Case**           | Enterprises, org-wide standardization | Home, small biz, test labs, DMZ hosts   |
| **Security Surface**   | Tightly monitored, often logged       | More isolated, but potentially outdated |

## Machine Accounts in Attacks

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

| Attack Use Case             | What It Means                                             |
| --------------------------- | --------------------------------------------------------- |
| **Lateral Movement**        | Misconfigured services or trust paths may use COMPUTER01$ |
| **Kerberoasting**           | If a service is tied to a machine account with SPNs       |
| **Pass-the-Hash (PtH)**     | Hash of the machine account may be reused for auth        |
| **Recon via SYSTEM access** | You act as the machine account, great for enumeration     |
| **Misused Permissions**     | If COMPUTER01$ is added to privileged groups (!?)         |

> 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

```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)

| Concept   | What It’s For                          | Can Assign Permissions? |
| --------- | -------------------------------------- | ----------------------- |
| **Group** | Access control, user/resource bundling | Yes                     |
| **OU**    | Logical grouping, GPO targets          | Nope (not directly)     |

> If you don't remember the [analogy in part 1 to illustrate such concepts](https://niklas-heringer.com/penetration-testing/introduction-to-active-directory/), i recommend to check it out.

## Group Types

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

| Type             | Purpose                                                    | Can Assign Permissions? |
| ---------------- | ---------------------------------------------------------- | ----------------------- |
| **Security**     | Used to assign permissions (e.g., access to files, shares) | Yes                     |
| **Distribution** | Used for email (e.g., marketing@company.local)             | No                      |

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

## Group Scopes – Where Do They Work?

| Scope            | Can Contain...                         | Can Be Used In...                   | Replication Scope         |
| ---------------- | -------------------------------------- | ----------------------------------- | ------------------------- |
| **Domain Local** | Anything (users, groups) from anywhere | Only within the **local domain**    | Local domain only         |
| **Global**       | Only users/groups from **same domain** | Across **any domain in the forest** | Domain-wide               |
| **Universal**    | Users/groups from **any domain**       | **Across the entire forest**        | Replicates to **all GCs** |

> 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)

| From → To                    | Allowed?                                         | Notes           |
| ---------------------------- | ------------------------------------------------ | --------------- |
| **Global → Universal**       | Yes, *if not nested in another global*           |                 |
| **Domain Local → Universal** | Yes, *if it doesn’t contain other domain locals* |                 |
| **Universal → Domain Local** | Yes                                              | No restrictions |
| **Universal → Global**       | Yes, *if it doesn't contain other universals*    |                 |

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

### Built-in vs. Custom Groups

| Type         | Example Group    | Scope       | Purpose / Note                              |
| ------------ | ---------------- | ----------- | ------------------------------------------- |
| **Built-in** | Administrators   | DomainLocal | Full control on domain systems              |
|              | Print Operators  | DomainLocal | Can manage printers, and maybe inject DLLs? |
|              | Backup Operators | DomainLocal | Can bypass file perms; love ntds.dit?       |
| **Custom**   | NYC-Marketing    | Global      | Created for departments, projects, etc.     |

> 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

```plaintext
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

| Attribute | What It Means                            |
| --------- | ---------------------------------------- |
| cn        | Group name                               |
| member    | Who’s in the group                       |
| memberOf  | Which groups this group is in (nesting!) |
| objectSid | Group’s unique SID                       |
| groupType | Encodes type (Security/Dist) & scope     |

## 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:

```powershell
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](https://github.com/SpecterOps/BloodHound?ref=niklas-heringer.com) and [SharpHound](https://github.com/SpecterOps/SharpHound?ref=niklas-heringer.com) 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.