Active Directory Security Fundamentals (Part 1)-

Kerberos
Scarred Monk on Oct 10, 2021
6 min

Active Directory Security

The information about different AD objects is stored in AD in object and attribute format, all of that is defined
in Active directory Schema as we discussed earlier. This data stored in the Active Directory is replicated across
the forest since AD is highly scalable and designed in such a manner that it handles a large numbers of read
and search operations as well as changes and updates by authenticating the requests and responding to them
with access to the required resources. In this section, we’ll discuss about Active Directory from a security
perspective and see how authentication works in the AD environment. We’ll discuss different security
protocols used in AD, different level of permissions.

Kerberos
Kerberos is an authentication protocol which was initially developed at MIT and uses symmetric key
cryptography. To verify user identities, it requires trusted third-party authorization. Microsoft uses Kerberos as
the preferred authentication protocol in domain environments. Kerberos (or Cerberus) was the name of the
three-headed dog that guarded the entrance to Hades in Greek mythology and, here it just like its name, it
requires three entities to authenticate:

- Client (or user that requires access to a service)

- KDC (Key Distribution Center)
- Resource server (which hosts the service required by user)

Detailed information about Kerberos Protocol can be found in RFC 4120.

Components of Kerberos
Kerberos has the following components:

• Principal: Client (user) or service.

• Realm: A logical Kerberos network.
• Ticket: Data that authenticates a principal's identity.
• Credentials: A ticket and a service key.
• KDC: Key Distribution Center, which authenticates principals.
• TGT: Ticket Granting Ticket.
• TGS: Ticket Granting Service.
• C/S: Client Server, regarding communications between the two.
In case of Active Directory environment, each domain controller acts like a Key Key Distribution Center that
provides two core services:

Authentication Service : Authenticates clients and issues them tickets.

Ticket-Granting Service : Issues tickets to authenticated clients to access other
resources.

In this scenario, users are allowed to prove their identity to gain access to domain resources securely. Kerberos
uses tickets to allow users to be authenticated against a principal like a service. To request a ticket for an
service, you have to specify its Service Principal Name for example, HTTP/RDSWEB01. SPN is a unique
identifier of a service account.

TGT
TGT stands for “Ticket Granting Ticket”. A ticket-granting ticket (TGT) is a special ticket that permits the
client to obtain additional Kerberos tickets within the same Kerberos realm. When a client sends a request for a
ticket to the Key Distribution Center (KDC), the KDC creates a ticket-granting ticket (TGT) for the client,
(encrypts it using the client’s password as the key) and sends the encrypted TGT back to the client. The client
then attempts to decrypt the TGT, using its password. If the client successfully decrypts the TGT (i.e., if the
client gave the correct password), it keeps the decrypted TGT, which indicates proof of the client’s identity.

TGT permits the client to obtain additional tickets (like TGS) which gives permission for specific services.

TGS
TGS stands for “Ticket granting service”. TGS is a KDC component that issues a service ticket when a client
requests connection to a Kerberos service. Client needs to have a valid TGT, only then the TGS will be issued
to it.

Inter-Realm TGT
In case of authentication in inter-forest trusts, instead of encrypting with Domain1’s krbtgt account, a ticket is
encrypted/signed with the inter-realm trust key that the domains previously exchanged, which is called as an
“Inter-realm ticket-granting-ticket/TGT.” Then Domain2 verifies the TGT included in the referral, decrypts it
with the previously negotiated inter-realm trust key and proceeds further. An inter-realm TGT can be forged.
We’ll do that in coming posts. I’ll explain the Kerberos process in detail in the next posts when performing
kerberoasting.

Let’s say a client from Domain 1 wants to access the server located in Domain 2.

Here is how it happens:

 1. A client from Domain1 requests a TGT from the DC1.
2. DC1 responds back with the TGT (encrypted with krbtgt hash)
3. Client shows the TGT and requests a TGS for accessing the server in Domain2.
o As DC1 doesn’t find the server in current domain and realizes that the TGS needs to be issued
by the DC2 (of Domain2) because the server is located in the Domain2. So it responds back to
client with the Inter-realm TGT.
4. Client shows the TGT encrypted with Inter-Realm trust key to DC2 in the Domain2 and requests TGS
to access the server.
5. DC2 sends back the TGS for Server encrypted with server’s account hash
6. Client presents the TGS (encrypted with server’s account hash) to the server for access.

Kerberos Authentication Flow

Kerberos authentication works like this:

 Client requests an authentication ticket (TGT) from the Key Distribution Center (KDC)
 Key distribution server verifies the credentials and sends back an encrypted TGT and session key
 TGT is stored by client and the local session manager will request another TGT when it expires.

When Client requires access to a service/resource on the network, below process is followed:

 Client sends the current TGT to the TGS with the Service Principal Name (SPN) of the resource the
client wants to access
 KDC verifies TGT of the client and also if client has access to the service
 TGS sends a valid session key for the service to the client
 Client forwards the session key to the service to prove it has access, and the service grants access.

PAC validation
In the above diagram, PAC validation is happening between the resource server and KDC. Let’s discuss more
about PAC validation. PAC (Privilege Attribute Certificate) represents an structure (included in almost all
tickets) which contains useful information like security identifiers, group membership, user profile
information, and password credentials. PAC is signed with the KDC key.

PAC validation is the process of validating the PAC of a user authenticating to a server against Active
Directory to make sure that it is valid. The server’s OS performs Kerberos PAC validation to protect from a
man in the middle attack tampering with the PAC structure to avoid forged PACs.

It can be enabled with the registry key ValidateKdcPacSignature found here: HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\Lsa\Kerberos\Parameters

“ValidateKdcPacSignature”=dword:00000001

When the value of this entry is 0, Kerberos does not perform PAC validation on a process that runs as a
service. When the value of this entry is 1, Kerberos performs PAC validation as usual. You have to restart the
computer after you modify this registry entry. When this entry is not present, the system behaves as if the entry
is present and has a value of 1. The default value in Windows Server 2008 for this entry is 0.

NTLM
NTLM stands for NT Lan Manager. It is a challenge-response authentication protocol. Before Kerberos,
Microsoft used NTLM for authentication. The target computer or domain controller challenges and checks the
password, and stores password hashes for continued use. It is still available for older clients and systems on a
workgroup.

NTLM relies on a challenge-response protocol to confirm the user without requiring them to submit a
password

Active Directory Security Fundamentals (Part 2)-

SPN, Kerberoasting
Scarred Monk on Nov 14, 2021
5 min

Service Principal Name (SPN)

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos
authentication to associate a service instance with a service logon account. This allows a client application to
request that the service authenticate an account even if the client does not have the account name.
Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be
registered on the account object that the service instance uses to log on. A given SPN can be registered on only
one account.

When a client wants to connect to a service, it locates an instance of the service, composes an SPN for that
instance, connects to the service, and presents the SPN for the service to authenticate.

SPN (servicePrincipalName) uniquely identifies a service account and it looks like below :

Why it is important to set up SPN❗

The most important reason for setting up an SPN is that it allows to identify your target Server hosting a
particular service on the network.

When we configure our Servers (hosting a service) to use Kerberos authentication for the clients to access that
service, there are a couple of prerequisites that must be met. First, the clients and servers must be joined to a
domain. If the server is from other domain, then a trust must be setup between the two domains. Secondly an
SPN must be successfully registered for the Server hosting the service so that it can be identified on the
network.

There are a few ways that we can check if the SPN has been registered successfully. If the server hosting the
service is running under a domain account (which is recommended) we can run the following command to see
the services that are registered.
How to set up SPN ❓

A Service Principal Name (SPN) is a name in Active Directory that a client uses to uniquely identify an
instance of a service. An SPN combines a service name with a computer and user account to form a type of
service ID. For Kerberos authentication (a protocol that authenticates client and server entities on a network) to
function, an SPN must be registered for each service account in the Active Directory.

Demo

For this demonstration, let’s setup a SPN for SQLServiceAccount.

We have a domain account SQLServiceAccount that we’ll be using as a service account. And we’ll register it
with a computer pretenting to be SQL server SQLServer Let’s register a SPN using below command:

setspn -s MSSQLSvc/sqlserver.rootdse.lab ROOTDSE\SQLServiceAccount

Let’s verify the attribute from the Active Directory Users and Computers as well to see if it is set up
correctly.

Now, if we search for SPNs across the domain, we should be able to see it:

Or we can simply enumerate the Service Principal Name (SPNs) of service accounts through a LDAP queries
with the help of adsisearcher:
PS C:\> ([adsisearcher]'(servicePrincipalName=*)').FindAll()
Path Properties
---- ----------
LDAP://CN=RDSEDC01,OU=Domain Controllers,DC=rootdse,DC=lab {ridsetreferences, logoncount,
codepage, objectcategory...}
LDAP://CN=krbtgt,CN=Users,DC=rootdse,DC=lab {logoncount, codepage,
objectcategory, description...}
LDAP://CN=SQLServiceAccount,CN=Users,DC=rootdse,DC=lab {givenname, codepage,
objectcategory, dscorepropagationdata...}

Now that we can do see that the SPN is configured properly, let’s see how to do kerberoasting.

Kerberoasting
Before starting Kerberoasting, let’s dicuss a bit about how this attack actually works. Kerberoasting is one of
the popular AD Kerberos attacks which was persented in the talk of Tim Medin (Kerberoast Guy) at Derbycon
2014. In this attack, a service account’s credential hash is extracted from Active Directory and cracked offline.
We need to identify what accounts are kerberoastable and then as any authenticated user, we can the request
service tickets (TGS) for the target service accounts without sending any traffic to the target server on which
the service is running.

As you can see in the below diagram, kerberoasting is focussed on requesting TGS from KDC. Only the
highlighted steps 3 and 4 are involved in this attack.

Below are the steps for performing Kerberoasting:

1. Enumerate the AD for accounts that have SPN values set

2. Request service ticket (TGS) from AD using the SPN values for target service account
3. Extract service ticket and download it to crack offline
4. Perform a Brute force attack on it to crack the password for target service account
This reason this attack is so effective is :

 No speacial privileges are required to do kerberoasting. Any authenticated user can do it

 Admins create weak passwords for service accounts just like normal user accounts
 Service account passwords are changed very less frequently in an organization environment.
 In most of the cases, service accounts have domain admin privileges (or atleast local admin privileges
on the target server)

Because of the above reasons, it is considered as a low hanging fruit since it is easily executed and if service
account is successfully compromised, high chances of escalating privileges in domain.

For service ticket extraction, we can use tools like:

 Mimikatz
 PowerView
 SharpView
 Rubeus

Below is a demonstration of doing kerberoasting using Rubeus:

Once we get the ticket, we can begin cracking the passwords. Cracking service accounts is a particularly
successful approach because their passwords very rarely change. Also, cracking the tickets offline will not
cause any domain traffic or account lockouts, so it is undetectable.
Conclusion
Kerberoasting is an efficient technique for attackers who have limited rights within a domain. It totally depends
on how strong the passwords are, and then once cracked, access to multiple accounts is gained and can be used
to launch further attacks. Setting up strong passwords can make this attack more difficult, hence the service
accounts should be treated much like the other privileged accounts. Best practice is to create a list of service
accounts, regularly check when the password was last changed, and implement a process for rotating
passwords on a regular basis. Few ways can be created to detect this kind of attack by implementing deception
in the environment.

I have written another blogpost on detecting possible kerberoasting attempts in the environment using AD
Decoys. Here is the link: Detecting LDAP enumeration and Bloodhound‘s Sharphound collector using AD
Decoys