Active Directory Security

An introduction

Original Photo by Daniel Cheung

Active
Directory 101
Quick recap on how AD works
 • is an integrated identity and access solution
that is used in many (or most) corporate
networks around the world
• stores information about users, computers,
Active groups, preferences and more
Directory… • authenticates an identity (user, computer,…)
• enables auditing and access control through
group memberships
 Active Directory Components

Active Directory data store

Domain controllers

Domain

Forest

Tree (DNS)

Organizational units and Sites

Group Policy
 Active Directory Components

The data store is the Active Directory

Active Directory data store
database on disk and contains
Domain controllers
everything (including password
Domain
hashes) that is stored in AD
Forest

Tree (DNS) Default Path:

Organizational units and Sites C:\Windows\NTDS\ntds.dit
Group Policy
 Active Directory Components

The data store is the Active Directory

Active Directory data store
database on disk and contains
Domain controllers
everything (including password
Domain
hashes) that is stored in AD
Forest

Tree (DNS) Default Path:

Organizational units and Sites C:\Windows\NTDS\ntds.dit
Group Policy
 Active Directory Components

Active Directory data store

The data store is split up into multiple
partitions that can be replicated individually
Domain controllers

Domain
Domain
Forest Default partitions
Configuration
(mandatory)
Tree (DNS) Schema

Organizational units and Sites

DNS
Group Policy Application partitions
Other AD-integrated
(optional) applications
 Active Directory Components

Active Directory data store

Domain Partition
Domain controllers dc=domain,dc=com

Domain
Configuration Partition
Forest cn=configuration,dc=domain,dc=com

Tree (DNS) Schema Partition

cn=schema,dc=domain,dc=com
Organizational units and Sites

Group Policy Example: DomainController01.domain.com

 Active Directory Components
Every DC hosts the Active Directory data store and the
Active Directory data store corresponding services (LDAP, KDC, GC,…)

Domain controllers
In other words: the DC is the server that runs AD and
Domain provides access to other computers on the network
Forest
There are usually multiple (at least two) DCs for
Tree (DNS)
redundancy since AD is usually one of the most critical
Organizational units and Sites services in an enterprise network

Group Policy Since Windows 2000, every DC in a domain can write

the AD database (multi-master) - changes are synced
between DCs
 Active Directory Components

Active Directory data store

However certain operations should not be executed simultaniously
by different DCs (like changing passwords for the same account)
Domain controllers
These things are called „Flexible Single Master Operations“ (FSMO)
Domain and are assigned to a specific DC
Forest
FSMO Roles are
Tree (DNS)
• Schema master
• Domain naming master
Organizational units and Sites
• RID master
• PDC emulator
Group Policy • Infrastructure master
 Active Directory Components

Active Directory data store

A tree is a contigous DNS namespace
Domain controllers • eg. „corp.contoso.com“
• DNS is a critical component in Active Directory
Domain
A domain is an AD management structure that contains
Forest
• Users, groups, computers
Tree (DNS) • Policies (e.g. Password Policy)
Organizational units and Sites A forest contains one or more domains
Group Policy
 Active Directory Components

Active Directory data store

Domain controllers

Domain

Forest

Tree (DNS)

Organizational units and Sites

Group Policy
 Active Directory Components

Active Directory data store

Organiational units are like folders in a file
system; used to organize users, groups,…
Domain controllers

Domain Sites usually describe how a network looks like

Forest
• DCs, Computers, Users,… can be allocated to a site
Tree (DNS) • Usually these objects are in the same or in adjacent
networks (subnet)
Organizational units and Sites
• Sites can be used to make sure that a computer always
Group Policy contacts the nearest (in terms of network) DC and always
uses the nearest services (regarding AD integrated
services)
 Active Directory Components
Group policy objects (GPO) can be seen as centrally
Active Directory data store managed settings, that either apply to a user or a
computer
Domain controllers

Domain
Group policies are managed from a central console
Forest (the Group Policy Management Console) and can be
scoped to specific users, groups, organizational units
Tree (DNS) and more
Organizational units and Sites Most group policy settings eventually turn into a
Group Policy
registry key that is set on the target computer
 Active Directory Components
On every Windows computer, a dedicated
Active Directory data store
service („Group Policy Client“) checks if
Domain controllers there are new settings to be applied
Domain
Computer settings are applied on startup
Forest and every 90-120 minutes later
Tree (DNS)

Organizational units and Sites

User settings are applied upon logon and
Group Policy every 90-120 minutes later
 Active Directory Components

Active Directory data store

Every domain controller hosts a share that is readable by
all domain users
Domain controllers \\DOMAINNAME\SYSVOL\DOMAINNAME\Policies
Domain
The „Policies“ folder inside the Sysvol share contains all
Forest
group policies
Tree (DNS) • Every policy is stored in a separate directory,
named after the GUID of the policy
Organizational units and Sites
• The folder can contain different files, depending on
Group Policy the GPO setting (.ini, .inf, .pol, .xml,…)
• These files contain the actual configuration items
Active
Directory
Security
Into the rabbit hole
 • Reconnaissance
AD Security • Authentication-based Attacks

in a Nutshell • ACL-based Attacks

• Persistence
Reconnaissance
Enumerate all the things
What do we
want to know?
And where could we find it?
 Domain Admins

Other privileged users (= server admin, helpdesk, developer,...)

Executives

Soft targets (Weak password, old passwords, passwords do not

change, accounts that never logged in…)
What do we
Network mapping (based on AD sites, determine IP topology)
want to know?
And where could we find it? Group Policy (weak spots and protection mechanisms in place)

Software deployment (SCCM et Al.)

Services and service accounts

Delegation rights
Protocols
• Most tools use the LDAP protocol (TCP 389) to enumerate AD which is
the best choice in most cases because
• Structured queries make it fast
• Network traffic is encrypted if LDAPS (TCP 636) is available
• LDAP log volume is VERY high, which makes it expensive for defenders to act
on it
• There is however also a legacy, SMB-based protocol called SAMR
• It is slow, there aren’t many tools and you only get a limited set of results but
it can be useful if firewall restrictions are in place
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-
samr/4df07fab-1bbc-452f-8e92-7853a3c7e380
 Exercise 1:
Reconnaissance

Photo by Daniel Cheung

Authentication-
based Attacks
NTLM, Kerberos, oh my…
Source: https://www.thehacker.recipes/ad/movement/ntlm
NTLM
…
NTLM Intro
The term NTLM is often used synonymously for two different things

NTLM
as a part of the MS-NLMP NT hash
authentication protocol, which the hash algorithm which is
is used to authenticate a user used to store a password
over the network
NTLM Intro
MS-NLMP is a challenge-/response-based authentication scheme for
authentication over the network

MS-NLMP is supported by various „transport“ protocols like SMB or HTTP

MS-NLMP includes

• LM (Lan Manager)
• NTLM (NT Lan Manager Version 1)
• NTLMv2 (NT Lan Manager Version 2)
NTLM Summary
Protocol Message calculation Hash used as input Security provided
LM DES LM Hash (DES) Extremely weak
NTLMv1 DES NT Hash (MD4) Very weak
NTLMv2 HMAC-MD5 NT Hash (MD4) Weak – yeah, that's the
best we got :-(

Bottomline
All flavors of NTLM are old and weak and it would be best to not use
them at all
However, this is a very complicated endeavor in real life due to
compatibility problems 
NTLM/MS-NLMP basic authentication flow
NTLM/MS-NLMP basic authentication flow
• The client sends its username to the server
• The server generates a random 16 byte number (challenge/nonce) and sends it to the
client
• The client encrypts the challenge with the hash of its password and sends the result to
the server (this is the “response”, we’ll follow up on this in a minute)
• The server sends the following three items to the Domain Controller for verification
• Username
• Challenge sent to the client
• Response received from the client
• The DC uses the username to retrieve the corresponding password hash from the AD
database and encrypts the servers challenge
• If the results match (the client's response and the response calculated by the DC),
authentication is successful
LM/NTLM Response

Please note: the hash values are strongly simplified for demonstration purposes and do not represent real values.
NTLMv2 Response

Please note: the hash values are strongly simplified for demonstration purposes and do not represent real values.
NTLM Attack Vectors in a Nutshell
Pass-the-Hash
• Using the hash of a password without knowledge of the cleartext password to
authenticate against other devices on the network.

Overpass-the-Hash
• Get a Kerberos ticket from a NTLM hash, again without knowledge of the cleartext
password.

Relay
• Relay an incoming NTLM authentication attempt to another host. Mix of protocols
possible.
 Pass-the-Hash Attack
• The Pass-the-Hash attack abuses the
previously described fact, that the password
of the user is not required to successfully
authenticate over the network, as long as the
hash of the password is available
• Cracking the password is no longer
necessary(!)
• Typical attack vectors are
• Password hashes of local admin accounts, as long
as they are identical across systems (e.g. all
clients)
• Hashes of privileged accounts (e.g. service
accounts or administrators) acquired from
memory
 Exercise 2:
Pass-the-Hash

Photo by Daniel Cheung

NTLM Relay Attacks
NTLM is vulnerable to so called relay attacks

In a relay attack, the attacker redirects/relays an incoming

authentication request from a higher privileged user (relay account)
to another computer (relay target)
The attacker can then use the privileges of the relayed account to
access the relay target
NTLM Relay Attacks
Due to the simplicity of the
protocol, NTLM authentication is Protocols that support NTLM
supported by various „transport are (among others)
protocols“
• LDAP
• HTTP
Therefore, NTLM relay is also • SMB
possible in a cross-protocol • SMTP
fashion. E.g: incoming • POP/IMAP
authentication via HTTP, outgoing
authentication via SMB
 Common (passive) relay vectors
(1) Highly privileged service account
"ServiceA" (typically with local admin (2) Attacker forwards incoming
rights) tries to access attackers host authentication to target host

(4) Original authentication (3) Attacker is successfully

request fails authenticated as "ServiceA"
IT Admin‘s
Server Attacker Client

Scenario #1: Inventory tool queries clients remotely via SMB

Caveat: disabling the SMB service in Windows is not possible without wracking
your host (feel free to try), so you need to do some port bending magic
 Common (passive) relay vectors
(1) Highly privileged user (e.g. Helpdesk
user with local admin rights on clients) tries
to access compromised host via SMB (4) Attacker forwards incoming
authentication to target host
(2) Attacker blocks SMB traffic
(5) Attacker is successfully
(3) Windows explorer automatically authenticated as "ServiceA"
IT Admin‘s
Helpdesk User falls back to HTTP (Webdav) Compromised Client
or Admin Client

Scenario #2: Helpdesk user tries to access a compromised host via SMB (using explorer.exe)

In this scenario, the attacker can operate on a compromised corporate machine because we mitigiate the
SMB-caveat from the last scenario by redirecting the victim to HTTP
 Common (passive) relay vectors

(1) Attacker introduces Man-in-the- (2) Attacker forwards incoming

Middle Scenario (WPAD, ARP, etc.) authentication to target host

(2) Victim authenticates against (3) Attacker is successfully

attackers host authenticated as "ServiceA"
IT Admin‘s
User Attacker Client

Scenario #3: Man-in-the-Middle attack

Caveat: MitM-scenarios heavily depend on target configuration and network

adjacency (e.g. same subnet)
Enhancing relay with coerced
authentication
• Coercing authentication means forcing a victim host to
authenticate against an attacker-controlled system
• As of July 2021, this kind of attack is known as
"PetitPotam"
• Coercing authentication makes NTLM relay attacks
extremely powerful since it removes a key limitation
discussed in the previous slides: the attacker can now
trigger authentication at will
 At the time of this writing (January 2022), there are 3
well-known attack paths
• SpoolSample by Lee Christensen
• SpoolSample relies on a remote printing protocol called MS-RPRN
• Can be mitigated through RPC filters or by disabling the affected
component (e.g. stop print spooler service)

Coerced • https://github.com/leechristensen/SpoolSample

Authentication – • PetitPotam by topotam

• PetitPotam relies on EFS (MS-EFSR)

key facts • Can be mitigated through RPC filter

• https://github.com/topotam/PetitPotam
• Should be fixed as of March 8th (KB5009763)

• VSSTriger by Wh04m1001
• Relies on MS-FSRVP
• Needs the FS-VSS-Agent installed which is not installed by default but
might be installed to facilitate backups of the host
Coerced Authentication – sample scenario

PC1 Domain
Controller

Attacker
 Exercise 3:
Coerced
Authentication

Photo by Daniel Cheung

NTLM relay is
complicated...

Source: https://www.thehacker.recipes/ad/movement/ntlm/relay
Kerberos
The guard dog who protects the gate
to the underworld
This is Jack. Jack
attends
SecureCon – a
conference for
security experts.
 AS issues Ticket-Granting Ticket to User after initial Authentication

User authenticates againts TGS and receives Service-Ticket (also called TGS in short)

User authenticates with TGS against target Service APP01

Kerberos – Step by step
Step 1 - Authentication Service Request (AS-REQ)
• First, the user authenticates against the authentication service (AS) of the KDC to get a valid
ticket-granting ticket (TGT)
• Initial request contains
• UTC timestamp in the format YYYYMMDDHHMMSSZ
• Encrypted with long-term key of the the user (long-term key is derived from password)
• Encryption types depend on the Windows version
• DES-CBC-CRC (disabled since Vista/2008)
• DES-CBC-MD5 (disabled since Vista/2008)
• RC4-HMAC (XP & 2003 default)
• AES128-CTS-HMAC-SHA1-96 (introduced in Vista/2008)
• AES256-CTS-HMAC-SHA1-96 (default since Vista/2008 and newer)
Kerberos – Step by step
Step 2 - Authentication Service Response (AS-REP)
• If authentication is successful (correct and timestamp within tolerance), KDC issues a
TGT to the user
• Think of the TGT as a special form of service ticket
• Contains Privilege Attribute Certificate (PAC)
• Username
• User, Group IDs
• Group memberships
• Encrypted with long-term key of the target service (!)
• Since there is no dedicated target service for the TGT, the long-term key is the key
of the „krbtgt“ account
Kerberos – Step by step
Step 3 – Ticket-Granting Service Request (TGS-REQ)
• Client wants to access application / service an sends request to KDC
• Contains TGT
• Contains target service name (service principal name)
• If the request is valid, a service ticket is issued (see step 4). Valid TGT means:
• Encrypted with „krbtgt“ long-term key
• Within time limits
• Important
• Kerberos authentication is „stateless“
• KDC does not „know“ if a user was authenticated before
• TGS „assumes“, that a user is authenticated if he can present a valid TGT
• Validity of the TGT depends on the long-term key of the „krbtgt“ account
Kerberos – Step by step

Step 4 – Ticket-Granting Service Response (TGS-REP)

• TGS (Ticket-Granting Service) issues service ticket for user
• User information will be copied out of the PAC within in the TGT
• Service ticket is encrypted with long-term key of the target service
• Important
• KDC does not know if a user has permission to access the target
system (authentication vs. authorization)
• Authorization has to be done by the target system
Kerberos – Step by step

Step 5 – Application Server Request (AP-REQ)

• Target service decrypts service ticket with long-term key
• Extracts user information from PAC
• Checks permissions and decides access level
• Optional: PAC can be cross-checked with KDC to make sure that the user
information is correct
• Important
• PAC validation is typically not active due to performance reasons
• If an attacker is able to obtain the service long-term key, then he can issue
arbitrary service tickets, as long as the PAC is not validated
Kerberos – Step by step

Optional (Step 6 / 7)
• Verify Service Ticket PAC (VERIFY-PAC)
• Target service cross-validates PAC with KDC to verify user information
• Typically not active due to performance reasons
• Application Server Response (AP-REP)
• User can request authentication of the target service in step 5 (Mutual
authentication)
• Service encrypts the timestamp with the session key, which should only be
known by the user and the service and sends it back to the user for
verification
Kerberos Attack Vectors in a Nutshell
Kerberoasting (TGSRoasting)
• Offline password guessing against a ticket you grab from network or memory.

ASREProasting
• Offline password guessing against a user with disabled (default = on) Pre-Authentication

Pass-the-Ticket
• Like PTH but with Tickets, still no knowledge about the cleartext password needed

Silver Ticket
• Fake tickets against a single principal. Think: impersonate any User on one host

Golden Ticket
• Fake tickets against the DC. Think: impersonate any User on all hosts in the domain

Delegation
• Fake tickets by design against one or more hosts. Too complicated to explain in one sentence - more on this later ☺
Kerberoasting (TGSroasting)

The service ticket the KDC issues (see TGS-REP) is encrypted with the long-term-
key of the target principal

In case of RC4, the long-term-key is the NTLM hash of the users password

Therefore an attacker can:

• Request a service ticket for any principal (any account with an SPN) with weak encryption (RC4)
• Extract the ticket from memory (see PTT)
• Run an offline attack on the accounts password (hashcat -m 13200)
Kerberoasting (TGSroasting)

Kerberoasting works best for service accounts

• no one dares to touch them so they

• rarely change passwords and
• the passwords are often bad due to their age

Kerberoasting usually can not be applied against random users because a

user object has no SPN by default

If you can modify a user object however (think: ACL), then you can apply
targeted Kerberoasting ☺
 Exercise 4:
Kerberoasting

Photo by Daniel Cheung

ASREProasting – oldy but goldy
Kerberos Pre-Authentication is turned on by default
for all accounts, however it can be disabled on a
per-user basis

If Pre-Authentication is disabled, an attacker can

request a TGT for the target user and run an offline
password guessing attack on the encrypted material
in the ticket (hashcat -m 18200)

Can also be used in a targeted form if you have

write-access on the object in Active Directory
Pass-the-Ticket (PTT)
Extracting the ticket (TGT/TGS) from memory and using it without knowledge of the
cleartext password

Extraction and injection can be done without elevation if applied to your own logon
session
• Rubeus.exe dump
• Rubeus.exe ptt /ticket:…

PTT vs. PTH

• Kerberos is never disabled (like NTLM may be), so it always works

• However a Kerberos TGT has a limited lifetime of about 10 hours (depending on GPO settings), whereas a
password hash usually lasts for at least a month under real life conditions
Silver Ticket / Golden Ticket
Silver/Golden describe a scenario in which an attacker acquires a password or a password hash of an
account and can therefore fake tickets against that account
Tickets

Silver Ticket Usually means faking tickets against a regular account – typically a service account due
to SPN requirement
This means you can impersonate any account against that one account (or application
that runs in the context of that account)

Golden Means faking tickets against the krbtgt account, which allows an attacker to create
arbitrary TGTs
Ticket
Silver Ticket

Compromise a password or hash of an account and

impersonate any User via Kerberos against that account

Example

• An MSSQL Server uses a domain account to run the SQL service

• An attacker gets access to the password hash of the account
• The attacker can now create a valid service ticket, impersonating a Domain
Admin, for the sql account
Golden Ticket

Compromise the password of the krbtgt account and impersonate

any user against any host in the domain

Example

• An attacker can access the AD Database on a DC and acquire the krbtgt-hash

• The attacker can now create a valid TGT for the Domain Administrator (500)
• Due to the valid TGT, the attacker can request service tickets for any principal
using the normal procedure
• Therefore, the attacker can access any domain member as Domain Admin
Delegation
Delegation allows a principal (typically an application or server) to act on behalf of
another principal (typically a user)

The delegation features in Active Directory have been added to the Kerberos
protocol as an extension called MS-SFU (S4U) as documented here
• https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu

In a nutshell, there are three different types

• Unconstrained
• Constrained
• Resource-based Constrained
Unconstrained Delegation
User01 authenticates against a computer SRV01, which is enabled for
unconstrained delegation and requests a service ticket for that computer

The domain controller places a copy of the user’s TGT into the service
ticket that is returned to the user

The users sends the service ticket to the computer

The computer can decrypt the ticket and is in possession of the users TGT
– therefore, the computer can now impersonate the user without any
constrains ( == unconstrained)
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
Unconstrained Delegation
Unconstrained delegation is very powerful since you can impersonate any user (possibly
also an administrator) as long as you get them to authenticate against you
(think: Print Spooler Bug)

The only exception are accounts that are

• marked as sensitive for delegation

• members of the “Protected Users” group

Microsofts recommends guarding any host enabled for unconstrained delegation like you
would guard a DC
Unconstrained Delegation

Unconstrained delegation is controlled with the flag

ADS_UF_TRUSTED_FOR_DELEGATION in the userAccountControl attribute

It can be enabled for user and computer objects

Use Powerviews "Get-DomainComputer" or "Get-DomainUser" with the

“-Unconstrained” parameter to identify these objects
Constrained Delegation

Since unconstrained delegation might be too unconstrained in many scenarios, Microsoft

implemented constrained delegation to allow more control over the delegation process

Constrained delegation consists of two features

• S4U2Proxy
• S4U2Self

Classic constrained delegation is configured outbound (on the principal that is allowed to
delegate)
Constrained Delegation / S4U2Proxy
User01 authenticates against a computer SRV01 which is enabled for
constrained delegation and requests a service ticket for that computer

SRV01 is allowed to delegate to another computer called SRV02

SRV01 can present the service ticket for himself from User01 to the
authentication service and get a new service ticket for User01 to SRV02

SRV01 can take the service ticket to impersonate User01 against SRV02
 https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

S4U2Proxy
Constrained Delegation / S4U2Self

Since users might authenticate via many different protocols other than Kerberos
(e.g. web form, basic, ntlm,…) the S4U2Self allows a so called protocol transition

What does “protocol transition” mean exactly?

• A host invoking S4U2Self basically requests a service ticket for a random user to itself from the
authentication service
• The host then uses this very service ticket as an input for the S4U2Proxy process

However there is no way for the DC to verify if the user

really authenticated against the host in the first place (!)
Constrained Delegation / S4U2Self

Since users might authenticate via many different protocols other than Kerberos
(e.g. web form, basic, ntlm,…) the S4U2Self allows a so called protocol transition

What does “protocol transition” mean exactly?

• A host invoking S4U2Self basically requests a service ticket for a random user to itself from the
authentication service
• The host then uses this very service ticket as an input for the S4U2Proxy process

However there is no way for the DC to verify if the user

really authenticated against the host in the first place (!)
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
Constrained Delegation

S4U2Proxy/S4U2Self are controlled with two attributes

• The userAccountControl flag TRUSTED_TO_AUTH_FOR_DELEGATION needs to be set and

• the attribute msds-allowedtodelegateto should contain the list of allowed delegation
targets in the form of SPNs (e.g. HTTP/host.domain.com)

Only if the TRUSTED_TO_AUTH_FOR_DELEGATION flag is set, the DC

returns a forwardable ticket when invoking S4U2Self and a forwardable
ticket is necessary to successfully invoke S4U2Proxy
 Exercise 5:
Constrained
Delegation

Photo by Daniel Cheung

Resource-based Constrained Delegation

Resource-based Constrained Delegation (RBCD) was introduced with Windows

Server 2012 and allows delegation to be controlled on a per host basis

Where classic constrained delegation is configured outbound (on the

delegation source), resource-based constrained delegation is configured
inbound (on the delegation target)

Basically every principal can control for himself which other principal is
allowed to delegate against him
Resource-based Constrained Delegation

As described in Elad Shamir’s excellent blog post on RBCD, this is a key

difference regarding classic constrained delegation
• https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html

In classic constrained delegation, the user who invokes the delegation

needs to have the permissions. So not every user can invoke delegation.

In RBCD however, it does not matter which user invokes the delegation
since permissions are set at the delegation target.
Resource-based Constrained Delegation

RBCD is controlled via the following attribute on every principal

• msDS-AllowedToActOnBehalfOfOtherIdentity

The value of the attribute above needs to be in the form of a binary

formatted SDDL string (…)

If you have control over this attribute, you can allow any other principal to
delegate against the target host - this opens another ACL-based attack path
Resource-based Constrained Delegation

This opens an interesting attack path using a special service account that usually
exists in every organisation: the account that joins computers to the domain

This account meets all requirements because

• The default ACLs allow some degree of control over all computer it joined (think: all clients,
including IT)
• This account let‘s us create a principial with an SPN (another computer) which we need for the RBCD
attack
Resource-based Constrained Delegation

This opens an interesting attack path using a special service account that usually
exists in every organisation: the account that joins computers to the domain

This account meets all requirements because

• The default ACLs allow some degree of control over all computer it joined (think: all clients,
including IT)
• This account let‘s us create a principial with an SPN (another computer) which we need for the RBCD
attack
Resource-based Constrained Delegation

The Domain join usually is an automated process, which means that

the password of this account is rarely changed and the account itself
usually has limited permissions (simple domain user)

This in turn means, that you commonly find an account that

• Is rarely considered a threat

• Lives for a very long time without password change (because not a threat)
• Is able to take control over most/all of the infrastructure
 Exercise 6:
RBCD

Photo by Daniel Cheung

ACL-based
Attacks
Spot me if you can
Quick Recap – Access Control Basics
Access Control in Active Directory
Every object in Active Directory (User, Computer, OU,…) has an
Key Access Control List (ACL)

facts ACLs can be used for security or auditing

ACLs contain Access Control Entries (ACE)

ACEs match principals to access rights and either Allow or Deny

access
ACEs can be inherited through the „folder“-structure of Active
Directory (which means Domain, OUs)
Access Control in Active Directory
• You can give access based on different types of access rights defined
in the Access Control Mask of the ACE
• https://docs.microsoft.com/en-us/windows/win32/api/iads/ne-iads-
ads_rights_enum
• Simply spoken, there are simple and complex access rights. A simple
ACE looks like this

http://www.selfadsi.de/deep-inside/ad-security-descriptors.htm#ACEInheritedTypeGUID
 Access Control in Active Directory
• A complex access right allows to further restrict access to a certain
attribute or a group of attributes.
• These attributes are defined by the field “object type/object ace
type”
• An example of a complex right is the “Send-As” permission

http://www.selfadsi.de/deep-inside/ad-security-descriptors.htm#ACEInheritedTypeGUID
ACL-based vectors

ACL-based vectors abuse ACL misconfigurations to elevate privileges

Based on what type of object you have access to, different techniques can be
used
• User: reset the users password or apply targeted kerberoasting
• Computer: use RBCD to get admin
• Group Policy: deploy logon script, install service...endless possibilities ;-)

The best tool to analyse ACLs in large environments is Bloodhound

What‘s Bloodhound?
• Bloodhound uses Neo4j, a graph database,
to find relationships between AD objects
that can be used to escalate privileges
• Through the power of graph theory,
bloodhound can find „attack paths“ that are
complex and difficult to identify with tools
like PowerView or similar
• Bloodhound is also an excellent tool for
defenders to regularly test and reduce the
attack surface
How it works
Cypherdog

Neo4j Graph DB

Powershell library for direct DB

access

UI app imports ...and allows for

LDAP queries
JSON files into easy querying
(users, computers, groups, ACLs,...)
neo4j DB...

Bloodhound.exe (UI)
Sharphound

Windows desktop application

ZIPed JSON files Bloodhound User
C# data collector for (single page .JS based on Electron)
bloodhound
https://github.com/SadProcessor/HandsOnBloodHound/blob/master/BH21/BH4_SharpHound_Cheat.pdf
 Exercise 7:
ACL-based
attacks

Photo by Daniel Cheung

Persistence
I am the Domain Controller
 What‘s A way to keep access
and acquired privileges
Simplest form of
persistence can be the
Good persistence
methods are not easily

Persistence? for a longer timeframe knowledge of a

privileged accounts
password
revoked or identified
and provide long-term
access (6 months or
more)
ACL-backdoors

ACL-backdoors refer to a general class of persistence methods using

manipulated ACLs on directory objects

Common examples for ACL backdoors are

• Write access on a highly privileged group, which allows an attacker to add/remove himself
to/from the group as desired
• Write access on a group policy object, which allows an attacker to run code as system on
affected computer objects
• Write access on a computer object, which allows an attacker to gain admin privileges on
that machine through resource-based constrained delegation
DCSync

This allows an attacker to replicate content from the Active Directory database like a
regular Domain Controller does

The attacker has access to the password hashes of all accounts in the domain and can
impersonate them using other techniques like Pass-the-Hash/Overpass-the-Hash

The so called „DCSync privilege“ actually consists of two different rights that need to
be granted in the ACL of the domain object
• Replicating Directory Changes
• Replicating Directory Changes All
Golden Ticket

Golden Tickets are crafted TGTs with arbitrary usernames and group-
memerships (e.g. domain admins, enterprise admins,…).

Since they rely on the password hash of the krbtgt account, golden tickets
usually have a very long lifetime (at least one year).

The krbtgt-hash is not changed automatically. This has to be initiated by the

sysadmins, who usually are very reluctant to do that due to possible availability
issues.
 Exercise 8:
Persistence

Photo by Daniel Cheung

 Before we
move on…
Time for Q&A

Photo by Daniel Cheung