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.

Rights = Access something. Privileges = Do something powerful.

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

In Windows, there's a setting called User Rights Assignment - 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.

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:

Some look harmless.. but aren't

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

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

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.

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

Get-LocalGroupMember -Group "Remote Desktop Users"

Abuse

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

mstsc /v:<target-ip>

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

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

Abuse (NTDS.dit via Shadow Copy):

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.

Used in

• Credential Dumping (e.g., Mimikatz)
• Reverse Engineering
• Manipulating protected processes

Abuse with 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

Tools & Examples

Notable tools to exploit this right are JuicyPotato, RoguePotato, PrintSpoofer, GenericPotato, RogueWinRM

Example (PrintSpoofer):

PrintSpoofer.exe -i -c cmd.exe

Modern GenericPotato:

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:

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

and start the driver cia:

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:

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

Granting yourself full control:

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

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.

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.

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.

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

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

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 or Seatbelt can enumerate these rights across systems.

Takeaways

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:

whoami /priv

vs.

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

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?

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 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 – Free, local Windows updates server
• SCCM – Paid, enterprise patch + config manager

Missed patch = EternalBlue 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:

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

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:

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
• Enable 2FA for RDP access wherever possible

Spray attacks 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:

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:

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

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:

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:

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

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:

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:

Force a GPO update manually:

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:

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:

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!