Kerberoasting Attack - Post exploitation attack

Background — high-level explanation 

Kerberoasting is an offline password attack that targets service accounts in Active Directory that have Service Principal Names (SPNs). Any domain user can request a Kerberos service ticket (TGS) for a service account. The ticket is encrypted with a key derived from the service account’s password (or key material). An attacker can collect those encrypted tickets and attempt to crack them offline if successful, they recover the service account password and can use it to escalate. 

Objective

As a domain user, enumerate SPNs, request TGS (service) tickets from the DC, capture the encrypted TGS blobs for the SQL service account, perform offline analysis to assess password strength, and document mitigations.

Lab Environment

I used the same  Active Directory lab consisting of one Windows Server machine acting as the Domain Controller and two Windows 10 workstations. A dedicated SQL service account was created in Active Directory and assigned a Service Principal Name (SPN) for the SQL service. This account was later used as the target for the Kerberoasting attack.

Walkthrough

I ran GetUserSPNs.py from an authenticated domain user session. The script enumerated AD objects with SPNs and requested Kerberos service tickets (TGS) for each discovered SPN.


I saved the hash for offline cracking so i searched for the particular module on hashcat as seen below👇


After i got the module i  cracked the service account password as seen below 👇


Quick takeaway

This lab demonstrates why service accounts must not be domain-privileged and why service-account passwords must be strong or managed. If a service account with an SPN has weak credentials and also has Domain Admin (or other highly privileged) rights, cracking its TGS can immediately lead to full domain compromise. In short: SPNs + weak passwords + excessive privileges = catastrophic risk.

Mitigations & prioritized remediation

  1. Move service to gMSA or vault the password (preferred).

  2. Rotate the  service account password immediately if targeted or cracked (coordinate service restart if needed).

  3. Remove SPNs from user accounts; ensure SPNs are on dedicated service accounts only.

  4. Enforce strong unique passwords for service accounts if gMSA not possible.

  5. Disable RC4 / legacy Kerberos etypes on DCs and clients; enforce AES where supported.

  6. Least-privilege for service accounts — reduce  account scope to minimum required.

  7. Inventory SPNs and audit pwdLastSet to find stale or weak accounts.

  8. Retest in lab after fixes to verify attack does not succeed.

Comments

Popular posts from this blog

Using Hydra to Brute-Force SSH And WI-Fi Login Portal

Discover AWS Organization ID Via S3 Bucket

SMB Relay Attack in AD Lab (Step-by-Step)