Embed Size (px)
Citation preview
THE GOLDEN TICKET ATTACK -A LOOK UNDER THE HOODBY: GERARD LAYGUI
>WHOAMI
• In the IT industry for almost 20 years
• Various jobs including network, system,
web and security admin related
• Currently works for a Fortune 50 company
doing compromise forensics and malware
reverse engineering
DISCLAIMER: THE VIEWS AND OPINIONS EXPRESSED IN THIS PRESENTATION ARE THOSE OF THE AUTHOR’S AND DOES NOTNECESSARILY REPRESENT THE OFFICIAL POLICY OR POSITION OF THE COMPANY THAT THE AUTHOR WORKS FOR.
WHAT IS A GOLDEN TICKET ATTACK?
A GOLDEN TICKET ATTACK OCCURS WHEN AN ATTACKER FORGES A TICKET GRANTING TICKET (TGT) IN A KERBEROS ENVIRONMENT IN ORDER TO IMPERSONATE A USER AND/OR GROUP MEMBERSHIPS.
A BRIEF HISTORY…..
AT BLACK HAT 2014, SKIP DUCKWALL & BENJAMIN DELPY SPOKE ABOUT A METHOD (USING MIMIKATZ) TO GENERATE YOUR OWN KERBEROS TICKETS.
HTTP://WWW.SLIDESHARE.NET/GENTILKIWI/ABUSING-MICROSOFT-KERBEROS-SORRY-YOU-GUYS-DONT-GET-ITHTTPS://WWW.YOUTUBE.COM/WATCH?V=-IMRNGPZTL0&INDEX=4&LIST=UUBBGNIFXFH-NQX6Z9XQ963Q
SYMMETRIC ENCRYPTION
SYMMETRIC-KEY ALGORITHMS ARE ALGORITHMS FOR CRYPTOGRAPHY THAT USE THE SAME CRYPTOGRAPHIC KEYS FOR BOTH ENCRYPTION OF PLAINTEXT AND DECRYPTION OF CIPHERTEXT.
HASH
A HASH FUNCTION IS ANY FUNCTION THAT CAN
BE USED TO MAP DIGITAL DATA OF ARBITRARY
SIZE TO DIGITAL DATA OF FIXED SIZE.
PASSWORDS ON A WINDOWS SYSTEM ARE
CONVERTED FROM PLAINTEXT TO AN NTLM
HASH.
Example conversion from plaintext to NTLM
gerardlaygui@BadApple:~$ echo -n "password" |iconv -t utf-16le|openssl md4
(stdin)= 8846f7eaee8fb117ad06bdd830b7586c
KERBEROS PROTOCOL
Kerberos is a computer network authentication
protocol which works on the basis of “tickets” to
allow nodes communicating over a non-secure
network to prove their identity to one another in a
secure manner.
Kerberos is built on symmetric key cryptography.
KERBEROS PARTS
Keys - An entity’s master keys (aka Long Term Key)
are derived when the entity joins the domain.
Authenticator – This encrypted packet contains the
user’s master key and the timestamp.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
1. Client requests a ticket granting ticket (TGT) from KDC
3. Client sends TGT to a TGS to request a service ticket
2. Authentication service sends encrypted TGT and session key
4. TGS returns a service ticket
7. Client reuses ticket for a later initial client /server session
5. Client sends service ticket to network resource for initial
client /server session
THE KERBEROS TICKET PROCESS IN AD
6. Server sends encrypted time stamp for client validation
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
1. Client requests a ticket granting ticket (TGT)
KERBEROS – ZOOM IN
The user tries to log on to the client by providing user
credentials. The Kerberos service on the client computer sends a
Kerberos authentication service request to the Key Distribution
Center (KDC). The request contains the user name, the service
information for which the ticket-granting ticket (TGT) is
requested, and a time stamp that is encrypted using the user's
long-term key, or password.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
2. AS returns a TGT.
KERBEROS – ZOOM IN
The KDC gets the long-term key, or password, for the user from
Active Directory, and then decrypts the time stamp that was
passed along with the request. If the time stamp is valid (within
policy, default is 5 min), the user is genuine. The KDC
authentication service creates a logon session key and encrypts
the copy with the user's long-term key. The authentication
service then creates a TGT, which includes user information and
a logon session key. Finally, the authentication service encrypts
the TGT with its own key and passes both the encrypted
session key and the encrypted TGT to client.
Note: The key used by the authentication service is derived
from the password of the krbtgt account.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)3. Client sends TGT to a TGS to request a service ticket
KERBEROS – ZOOM IN
The client decrypts the logon session key using its long-term key,
or password, and caches it locally. Additionally, the client stores
the encrypted TGT in its cache. When accessing a network
service, the client sends a request to the KDC ticket-granting
service (TGS) with information, including the user's name, an
authenticator message encrypted using the user's logon session
key, the TGT, and the name of the service (and server) that the
user wants to access.
Note: This is where the golden ticket attack occurs. Using a
stolen hash of the krbtgt account an attacker can create a
malicious TGT and send this to the KDC. Inside of the TGT is the
PAC (Privilege Attribute Certificate) which will be used to
impersonate a user and/or groups.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
4. TGS returns a service ticket
KERBEROS – ZOOM IN
The TGS on the KDC decrypts the TGT using its own key and
extracts the logon session key. Using the logon session key, it
decrypts the authenticator message (which is usually a time
stamp). If the authenticator message is successfully decrypted,
the TGS extracts user information from the TGT, and using the
user information creates a service session key for accessing the
service. It encrypts one copy of the service session key with the
user's logon session key, creates a service ticket with the service
session key and user information, and then encrypts the service
ticket with the server's long term key (password). The TGS then
sends the encrypted service session key and service ticket to the
client.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
5. Client sends service ticket to network resource for initial
client /server session
KERBEROS - ZOOM IN
When a client accesses the service, it sends a request to the
server. The request contains the authenticator message (time
stamp), which is encrypted using the service session-key and the
service ticket.
Key Distribution
Center (KDC)/DC
Server hosting
network resource
Client
Ticket Granting
Service (TGS)
Authentication
Service (AS)
KERBEROS – ZOOM IN
6. Server sends encrypted time stamp for client validation
The server decrypts the service ticket and extracts the
service session-key. Using the service session-key, the
server decrypts the authenticator message (time stamp)
and evaluates it. If the authenticator passes the test, the
server encrypts the authenticator (time stamp) using the
service session-key and then passes the authenticator
back to the client. The client decrypts the time stamp,
and if it is the same as the original, the service is genuine
and the client proceeds with the connection.
GOLDEN TICKET CREATION
GOLDEN TICKET CREATION
DOMAIN INFORMATION
KRBTGT ACCOUNT??The KRBTGT account is a local default account that acts as a service account for the Key
Distribution Center (KDC) service. This account cannot be deleted, and the account name
cannot be changed. The KRBTGT account cannot be enabled in Active Directory.
KRBTGT is also the security principal name used by the KDC for a Windows Server domain,
as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security
principal, and it is created automatically when a new domain is created.
Windows Server Kerberos authentication is achieved by the use of a special Kerberos
ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the
password of the server or service to which access is requested. The TGT password of the
KRBTGT account is known only by the Kerberos service. In order to request a session ticket,
the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the
KDC.
WHERE IS THIS KRBTGT?
HOW DO WE GET THE KRBTGT HASH?
The KRBTGT hash can only be found on a domain controller.
NTDS.DIT Backups - Your backup admins have access to the KRBTGT hash
DCs on virtual machines - VM admins may have access to KRBTGT hash
Attack the domain – Pass the hash/ticket till you get on a read/write domain
controller. Extract the hash from the read/write domain controller.
WHERE IS THE KRBTGT HASH?
DATA EXTRACTED FROM AD
GOLDEN TICKET CREATION & USE
KERBEROS TICKETS ON THE CLIENT - BEFORE
C:\users\ImaUser\klist
Current LogonId is 0:0xe4ca6
Cached Tickets: (3)
#0> Client: ImaUser @ OHNOES.INTERNAL
Server: krbtgt/OHNOES.INTERNAL @ OHNOES.INTERNAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags
0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize Start
Time: 5/4/2016 10:37:28 (local)
End Time: 5/4/2016 20:37:28 (local)
Renew Time: 5/11/2016 10:37:28 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
KERBEROS TICKETS ON THE CLIENT - AFTER
C:\users\ImaUser\klist
Current LogonId is 0:0xe4ca6
Cached Tickets: (1)
#0> Client: ImaDomainAdmin @ OHNOES
Server: krbtgt/OHNOES @ OHNOES
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) Ticket Flags 0x40e00000 ->
forwardable renewable initial pre_authent Start Time: 5/4/2016 22:00:01 (local)
End Time: 5/4/2026 22:00:01 (local)
Renew Time: 5/4/2036 22:00:01 (local)
Session Key Type: RSADSI RC4-HMAC(NT)
EVENT LOGSGood Guy
Bad Guy
DATA EXTRACTED FROM AD
LEARNING FROM MISTAKES
EVENT LOGSGood Guy
Bad Guy
KLIST AFTER A PURGE
Good Guy Purge
Current LogonId is 0:0xe4ca6
Cached Tickets: (0)
Bad Guy Purge
Current LogonId is 0:0xe4ca6
Cached Tickets: (0)
MAKING A STATEMENTThere is no
user in active
directory
named
“UguysRn00bs
” and there is
no user that
has a relative
ID of 8888.
What will show
up in the
server’s
security event
log?
THIS LOOKS REALLY BAD
IMPLICATIONS• Security event logs can show erroneous information (Security
ID and Account Name can be forged)
• If the attacker is meticulous it will be hard to detect
breaches when the golden ticket is used.
• The attacker can make it look like a compromised
administrator account. Makes the entire IR chain work
harder.
REMEDIATION• Manually change the KRBTGT password twice
(http://cert.europa.eu/static/WhitePapers/CERT-EU-
SWP_14_07_PassTheGolden_Ticket_v1_1.pdf)
• Make sure the domain converges before doing the second
password change
• MS has a script to assist (https://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-
now-available-for-customers/)
POSSIBLE DEFENSESDon’t let the attacker get a copy of your NTDS.DIT
• Encrypt backups
• Audit when restores on any part of a domain controller takes place
• Whole disk encryption on VM images
• Restrict access to domain controllers and use of domain administrator equivalent
accounts.
Honey Accounts /Honey Information (Big Thanks to Shane Steiger)
• There are products out there that can populate the environment with fake data such as:
• User Accounts (local/network)
• Hashes (LSASS & other – local/network)
• Network Configs (fake routes)
• Network Connections (fake connections, ie mapped drives)
• Files (fake shortcuts)
• RDP (fake sessions)
• Database (fake connections)
• Browsers (fake saved sites, user/passwords)
POSSIBLE DEFENSESManual Password Change Policy on the
KRBTGT account
• Since the account is disabled, the
account is not impacted by password
expiration policies
• Manually change the krbtgt password
in accordance with password policy
POSSIBLE DEFENSESRODC (Read Only Domain Controller) Proliferation
• Keep RWDCs segregated using network segregation and AD sites to
force users to logon to RODCs. This will make breach detection easier.
• RODCs don’t have any real users hashes or KRBTGT hash
LIVE DEMO
QUESTIONS?
BIG THANKS TO THE CACTUSCON CFP
COMMITTEE
BIG THANKS TO MIKE LANDECKFOR HOSTING MY SLIDE DECK
SLIDES ARE POSTED ATHTTP://CYBERSECOLOGY.COM/
