Kerberoasting
Last updated
Last updated
Kerberoasting is an attack that can be used to escalate privileges to perform lateral movement and/or maintain persistence. An attacker that has gained access to a system which can communicate with the domain can request Kerberos tickets for the service accounts that are set up as service principal names. The Kerberos tickets can be cracked offline which provide the credentials for the service account. Often these credentials are privileged and don’t expire. This is a very stealthy attack that should be a focus for blue-teams.
“All standard domain users can request a copy of all service accounts along with their correlating password hashes, so we can ask a TGS for any SPN that is bound to a "user"account, extract the encrypted blob that was encrypted using the user's password and bruteforce it offline.”
we have : user account with any privilege
we acquire : credentials for the service account
Remember: TGS encrypted by service password “NTLM hash” we crack (TGS) which is the reply of (TGT)
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.
If you install multiple instances of a service on computers throughout a forest, each instance must have its own SPN. A given service instance can have multiple SPNs if there are multiple names that clients might use for authentication. For example, an SPN always includes the name of the host computer on which the service instance is running, so a service instance might register an SPN for each name or alias of its host. For more information about SPN format and composing a unique SPN, see Name Formats for Unique SPNs.
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. For Win32 services, a service installer specifies the logon account when an instance of the service is installed. The installer then composes the SPNs and writes them as a property of the account object in Active Directory Domain Services. If the logon account of a service instance changes, the SPNs must be re-registered under the new account. For more information, see How a Service Registers its SPNs.
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.
Format be like service_name/machine_name.AD_name for example mssql_svc/sql_server.company.local
The main security issue surrounding the use of Service Principle Name (SPN) accounts is the fact that any valid user on the domain can abuse the Kerberos authentication protocol to begin the authentication process and receive a hash of any SPN accounts in use. This action can be performed by any user on the domain and does not require any elevated privileges. Most often, the accounts set up with a Service Principle Name (SPN) are service accounts or other accounts with elevated privileges on the domain.
Once an SPN account’s user hash has been captured, it can be taken offline and potentially cracked by the attacker. If the password cracking process is a success, then the attacker has the ability to log in as that SPN account and will have all privileges of that user.
With Impacket example GetUserSPNs.py:
With Rubeus:
With Powershell:
According to the MITRE ATT&CK Framework, the following steps should be performed to mitigate this type of attack:
Enable AES Kerberos encryption (or another more robust encryption algorithm), rather than RC4, where possible.
Ensure strong password length (ideally 25+ characters) and complexity for service accounts and set these passwords periodically expire. Also, consider using Group Managed Service Accounts or another third-party product such as password vaulting.
Limit service accounts to minimal required privileges, including membership in privileged groups such as Domain Administrators.
Resources
https://docs.microsoft.com/en-us/windows/win32/ad/service-principal-names
https://sbscyber.com/resources/kerberoasting-the-potential-dangers-of-spn-accounts
https://www.youtube.com/watch?v=-3MxoxdzFNI
https://gist.github.com/TarlogicSecurity/2f221924fef8c14a1d8e29f3cb5c5c4a