Made by Nae3m
Contents
Kerberoasting Attack ..................................................................................................... 3
Service Principal Name (SPN): .................................................................................... 3
Example: ............................................................................................................... 3
# Find all service accounts with SPNs by PowerShell ................................................ 3
# List all SPNs in the domain by setspn .................................................................... 3
Kerberos Authentication: ........................................................................................... 4
Example ................................................................................................................ 4
Kerberoasting Attack Example .................................................................................... 5
Key Points of the attack: ............................................................................................. 6
How Make the Attack ................................................................................................. 7
Prevention................................................................................................................. 8
Detection .................................................................................................................. 9
What the problem in Detection ............................................................................... 9
Multiple Scenarios for Event ID 4769: ...................................................................... 9
Detection Strategy Based on Encryption Types ......................................................... 9
Detection Rules Based on This Activity .................................................................. 10
One of the solutions ................................................................................................ 11
Honeypot user ..................................................................................................... 11
Example Scenario ................................................................................................ 11
Kerberoasting Attack
Service Principal Name (SPN):
An SPN is a unique identifier in Active Directory that represents a specific service
instance.
Example:
If your SQL Server is running under the service account svc_sqlserver, the SPN might
be MSSQLSvc/sqlserver.company.com:1433. This SPN ties the SQL Server instance to
the svc_sqlserver service account.
# Find all service accounts with SPNs by PowerShell
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties
ServicePrincipalName |
Select-Object SamAccountName, ServicePrincipalName
# List all SPNs in the domain by setspn
setspn -T company.com -Q */*
Kerberos Authentication:
Kerberos is a network authentication protocol used to securely authenticate users
and services in an Active Directory environment.
In the Kerberos authentication process, after a user authenticates with the Key
Distribution Center (KDC) and receives a Ticket Granting Ticket (TGT), they use the TGT
to request access to specific services.
Example
When a client (e.g., a user or application) needs to access a service (e.g., the SQL
Server), it requests a Kerberos ticket from the Key Distribution Center (KDC).
The KDC provides a Ticket Granting Service (TGS) ticket, encrypted with the service
account’s password hash (e.g., the password hash of svc_sqlserver).
Kerberoasting Attack Example
In a Kerberoasting attack, the steps above are exploited as follows:
1. Enumeration:
o An attacker inside the network identifies the SPN
MSSQLSvc/sqlserver.company.com:1433 using tools like setspn.exe or
PowerShell.
2. Requesting the TGS Ticket:
o The attacker requests a TGS ticket for
MSSQLSvc/sqlserver.company.com:1433 from the KDC.
3. Receiving the Encrypted Ticket:
o The attacker receives the TGS ticket, which is encrypted with the NTLM
hash of svc_sqlserver, 31d6cfe0d16ae931b73c59d7e0c089c0.
4. Offline Cracking:
o The attacker uses password-cracking tools like Hashcat to try to decrypt
the TGS ticket.
o Since 31d6cfe0d16ae931b73c59d7e0c089c0 is the hash of an empty
password, the attacker would immediately know the service account's
password if they were able to crack it.
Command Example with Hashcat:
hashcat -m 13100 -a 0 encrypted_ticket.txt wordlist.txt
o If the password was weak, such as Password123, the attacker might
successfully crack the hash, revealing the password for svc_sqlserver.
5. Post-Compromise:
o With the svc_sqlserver password, the attacker can authenticate to the
SQL Server or any other system where this service account has access,
potentially leading to further compromise of the network.
Key Points of the attack:
SPN: Identifies services within the AD environment.
Kerberos: Authenticates users and services using tickets encrypted with password
hashes.
Kerberoasting: Exploits weak passwords of service accounts by cracking TGS tickets
offline.
The success of this attack depends on the strength of the service account's password.
Another factor that has some impact is the encryption algorithm used when the ticket
is created, with the likely options being:
• AES
• RC4
• DES (found in environments that are 15+ old years old with legacy apps from the
early 2000s, otherwise, this will be disabled)
There is a significant difference in the cracking speed between these three, as AES is
slower to crack than the others. While security best practices recommend
disabling RC4 (and DES, if enabled for some reason
How Make the Attack
Alternatively, the captured TGS hashes can be cracked with John The Ripper:
sudo john spn.txt --fork=4 --format=krb5tgs --wordlist=passwords.txt --pot=results.pot
Prevention
By following these best practices, you can significantly reduce the risk of Kerberoasting
attacks in your environment:
• Use strong, complex passwords for service accounts.
• Limit SPNs to only necessary accounts and regularly clean up outdated or unused
SPNs.
• Leverage Group Managed Service Accounts (GMSA) wherever possible,
particularly for services that support them.
• Avoid assigning SPNs unnecessarily to accounts that don't require them
Example (GMSA):
• Suppose you have a web service running on a server websrv01 that supports GMSA.
Instead of using a regular service account with a manually set password, you
configure the service to use a GMSA, such as gmsa_webservice.
• Active Directory automatically generates and manages a strong password like:
(bN5!wYrF#kH9%tL3@Vm2ZcG7*Dp8Qr$X)
• The password is rotated regularly, and no administrator needs to manually manage
this password.
Detection
What the problem in Detection
When a TGS is requested, an event log with ID 4769 is generated. However, AD also
generates the same event ID whenever a user attempts to connect to a service, which
means that the volume of this event is gigantic, and relying on it alone is virtually
impossible to use as a detection method
Multiple Scenarios for Event ID 4769:
• Normal User Activity: Anytime a legitimate user attempts to connect to a service
(e.g., opening a file share, connecting to a database, or accessing a web
application), a TGS request is made, generating Event ID 4769.
• Service-to-Service Communication: When one service needs to authenticate to
another service (e.g., a web server connecting to a database server), the service
account requests a TGS ticket, also generating Event ID 4769.
• Potential Malicious Activity: In a Kerberoasting attack, an attacker deliberately
requests TGS tickets for services with the intent of extracting them and cracking
their passwords offline. This activity also generates Event ID 4769.
Detection Strategy Based on Encryption Types
By focusing on the Encryption Type field in Event ID 4769, you can more effectively filter
out noise and detect suspicious activity related to Kerberoasting:
• In AES-only environments, any RC4 ticket request should be treated as suspicious.
• In mixed environments, a high volume of RC4 requests or requests from unusual
accounts can indicate a potential attack.
Detection Rules Based on This Activity
• Rule 1: Alert on User-Level Anomaly:
o Trigger an alert if any user account generates more than, say, ten Event ID
4769 logs within one minute.
o This would catch cases where Rubeus or similar tools are being used by an
attacker.
• Rule 2: Alert on Machine-Level Anomaly:
o Trigger an alert if a single machine is responsible for generating a high
number of Event ID 4769 logs within a short time, regardless of the user
account.
o This helps in identifying potentially compromised systems where tools like
Rubeus are being run.
Summary
The main idea is to detect abnormal patterns in the generation of Event ID 4769 logs, which
would indicate potential Kerberoasting attempts. The focus is on the volume and speed of
ticket requests, which can be unusual under normal circumstances. By setting up alerts
that consider both user and machine activity, you can better detect and respond to these
kinds of attacks.
One of the solutions
Honeypot user
One of the best solution use A honeypot users
Why This Works
• Detection through Unusual Activity: Since the honeypot user has no real use, any
interaction with it is suspicious. If someone attempts to request a TGS ticket for this
user, it likely indicates malicious intent. For example:
o Kerberoasting: An attacker running a Kerberoasting tool like Rubeus might
attempt to extract TGS tickets for all accounts with SPNs, including the
honeypot user. This activity would trigger an alert because there's no
legitimate reason to request a ticket for this user.
o Logon Attempts: Any successful or failed logon attempt involving this
account would be abnormal and trigger an alert.
Example Scenario
1. Setup: You create the honeypot user svc_oldsqladmin, an old SQL service account
with an SPN registered and an unchanged password for over five years.
2. Attack Detection:
o An attacker gains access to the network and runs Rubeus.exe to perform
Kerberoasting, trying to extract service tickets for accounts with SPNs.
o The attacker unwittingly requests a TGS ticket for svc_oldsqladmin.
o Event ID 4769 is generated for the honeypot user.
o Your monitoring system is configured to alert when the honeypot user's
account generates any activity. The alert is triggered, flagging this as a
suspicious event.
3. Response:
o Security analysts investigate the alert. They see that the honeypot user,
which should not have any legitimate activity, had a TGS request.
o This investigation leads to further examination of the environment,
potentially identifying the attacker’s presence and stopping further
exploitation.
