Active Directory
1. Constrained vs. Unconstrained Delegation in Active Directory
What Is Delegation?
Delegation in Active Directory (AD) allows certain computers or services to impersonate users, enabling them to access resources on the user's behalf. This is primarily used to support scenarios where web servers or application servers need to pass authentication credentials further down to backend services.
There are two main types:
Unconstrained Delegation: The most permissive and insecure form. Any service running on a computer with this setting can impersonate any user to any service within the domain.
Constrained Delegation: A more secure method where an account can only impersonate users to specified backend services (defined by Service Principal Names, or SPNs).
How Do They Lead to Privilege Escalation?
Unconstrained Delegation
How it works: When unconstrained delegation is enabled, any time a user authenticates to that computer or service, their Kerberos Ticket Granting Ticket (TGT) is stored in memory on the server.
Attack scenario: If an attacker compromises a server with unconstrained delegation, they can extract the Kerberos tickets—including those of privileged users (like Domain Admins) who log in to the server—and use these tickets to impersonate these users anywhere in the domain.
Privilege escalation: Attackers can leverage extracted tickets to access sensitive resources or escalate to full domain admin privileges.
Constrained Delegation
How it works: With constrained delegation, AD restricts what backend services an account can impersonate users to (e.g., only a database or file share).
Attack scenario: If an attacker takes over a user/computer account with constrained delegation, they can impersonate any user (even privileged users) but only to specified backend services.
Privilege escalation: If those allowed services include critical resources (like the Domain Controller), attackers can use tools to impersonate a Domain Admin to the DC, potentially escalating to full control.
Real-Time/Live Example: Unconstrained Delegation
Scenario:
An organization configures an application server with unconstrained delegation for seamless authentication.
An attacker gains admin access on this server (via phishing, vulnerability, etc.).
A Domain Admin logs into the server for routine maintenance or by mistake.
The attacker's malware dumps Kerberos tickets from memory (using a tool like Mimikatz).
The attacker extracts the Domain Admin's TGT and "passes the ticket" to authenticate as that Domain Admin across the domain—possibly taking over the Domain Controller.
Constrained Delegation Example:
Suppose a service account is trusted for constrained delegation to the CIFS (file service) on the Domain Controller.
If an attacker compromises this service account, they can impersonate any user (even Domain Admin) to the file service on the DC, potentially performing sensitive operations such as DCSync to dump Active Directory hashes—thus escalating their privileges.
Summary Table
Unconstrained Delegation
Impersonate any user to any service
Highest—steal admin tickets, total control
Compromised server, steal Domain Admin TGT
Constrained Delegation
Impersonate any user to specified services only
High—if misconfigured to sensitive SPNs
Compromised SPN, impersonate to DC
Key Takeaways
Unconstrained delegation is a major security risk—attackers can leverage it for privilege escalation to full domain compromise if any privileged user logs in.
Constrained delegation is safer but can still be abused if permissions are too broad or include critical domain resources.
Always limit delegation, audit delegated accounts, and prevent privileged accounts from logging onto delegated systems.
2. Kerberoasting
What Is It and Why Does It Happen?
Kerberoasting is an attack where attackers request Kerberos service tickets (TGS) for accounts with Service Principal Names (SPNs) in Active Directory, then attempt to crack the ticket offline to recover the account password.
It happens because service tickets are encrypted with the hash of the service account’s password. If that password is weak, attackers can obtain and crack it.
How to Identify Vulnerable Accounts
Look for accounts (typically service accounts) with SPNs set.
Use tools or scripts to enumerate accounts with SPNs in the environment.
How to Check for Kerberoasting Configurations
Use PowerShell command:
Look for service accounts with non-strong passwords and accounts not marked as “sensitive and cannot be delegated.”
Attack Steps (Kerberoasting)
Enumerate accounts with SPNs.
Request service ticket (TGS) for those accounts.
Extract the ticket, then attempt to crack it offline using tools like Hashcat or John the Ripper.
3. AS-REP Roasting
What Is It and Why Does It Happen?
AS-REP Roasting targets accounts with “Do not require Kerberos preauthentication” enabled.
It happens because the Key Distribution Center (KDC) returns an authentication response encrypted with the user's password hash, without verifying their identity.
How to Identify Vulnerable Accounts
Find accounts with Kerberos pre-authentication disabled.
These accounts have the
DONT_REQ_PREAUTHflag set.
How to Check for AS-REP Roasting Configurations
Use PowerShell command:
Review legacy accounts, lab/service accounts, or test users.
Attack Steps (AS-REP Roasting)
Scan Active Directory for accounts with pre-authentication disabled.
Request an AS-REP response for those accounts.
Extract and crack the response offline to recover clear-text passwords using password-cracking tools.
Comparison Table
Kerberoasting
Account with SPN set
Enumerate SPNs
Crack service ticket offline
AS-REP Roasting
Pre-authentication disabled on user
Check DoesNotRequirePreAuth
Crack AS-REP response offline
Analogy: Imagine a hacker getting access to the special “master key” of your office building. This key can unlock every room, at any time, forever, without anyone noticing.
In a Golden Ticket attack, an attacker:
Steals the hash (cryptographic password) for the KRBTGT account, which is responsible for generating authentication tickets in an Active Directory (AD) environment.
Creates fake universal “master” tickets (Ticket Granting Tickets, or TGTs) that allow them to impersonate anyone in the domain—including administrators—and access any service or resource.
Since these tickets look authentic to the system, the attacker can move throughout the network without setting off alarms and have continual access, even if user passwords are changed.
Real-World Example: An attacker breaches the network, gets domain administrator access, steals the KRBTGT hash, and forges TGTs to log into email, file servers, or confidential databases as any employee or exec, at any time.
Analogy: Instead of the master key, the hacker gets a “service key” to just the HR records room (or any single room). They’ve forged a badge that lets them in there, but nowhere else.
In a Silver Ticket attack, an attacker:
Steals the password hash of a service account (e.g., one that runs SQL, IIS, or a file share).
Forces a fake Kerberos service ticket (Ticket Granting Service, or TGS) for that specific service, without needing a TGT from the domain controller.
Can then access only those resources the service account manages, but can do so stealthily and persistently—even if domain passwords are changed.
Real-World Example: An attacker grabs the password hash for the SQL Server service account, forges a “Silver Ticket,” and can access the corporate database as if they are that service, reading or modifying sensitive data.
Key Differences Table
Golden Ticket
KRBTGT Account Hash
Forge universal master TGTs; impersonate anyone
Entire domain
Silver Ticket
Service Account Hash
Forge TGS for specific service
Single service/resource
Last updated