Abusing S4U2Self: Another Sneaky Active Directory Persistence

Étiquettes
Category
dim 27/01/2019 - 21:58

As part of the recent publication of Elad Shamir’s work on Kerberos delegation (“Wagging the Dog - Abusing Resource-Based Constrained Delegation to Attack Active Directory”), Alsid is publishing a series of blogposts deepening the uncovered new attack vectors and shedding a light on pragmatic solution for Blue Teams trying to measure the impact of this breakthrough on their Active Directory infrastructure.

This second publication will be focused on Kerberos’ S4U2Self extension. In his paper Shamir describes a new Active Directory backdoor based on this unsung functionality. This blogpost will examine how this technique can be extended to target different types of AD accounts after describing how an attacker would deploy and use such a backdoor. Using the opposite delegation direction, we will then describe another possible loophole. We will end with specific details and considerations to help security teams protecting themselves against those scenario.

Understanding the S4U2Self backdoor

Fully explained in the original research paper, the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute can be tricked in a way to hide privileged accesses on an Active Directory infrastructure.

Setting the SID of a user account into the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the “krbtgt”(a detailed how-to is explained in the next section) account allows to get, for an arbitrary user, a TGS for the KDC service… which turns out to be a valid TGT, meaning a Golden Ticket! In possession of a Golden Ticket, the attacker obtains the complete control of the Active Directory domain.

 

Planting a S4U2Self backdoor, the step-by-step explanation

Let’s recap how an attacker can use publicly available tools to register the S2USelf backdoor and use it afterwards to regain administrative privileges.

Part 1. Setting-up the backdoor

Let’s say that an attacker managed to find a way to temporary obtain “Domain Admins” privileges (having such privileges implies this backdoor can only be played as a post-exploitation scenario) through an account called “adm-compromised” and wants to achieve persistence on the domain with Shamir’s backdooring technique. Using the account, the attack would follow the following approach:

  • Identify a user account having an SPN and configured with a password that does not expire. In a corporate environment, this will be reasonably easy as many service accounts will match those criteria.
Find the appropriate service account using a simple PS request
Find the appropriate service account using a simple PS request
  • Extract the secrets associated to this account using the famous “DCSync” feature implemented in various offensive security tools, e.g. Mimikatz.
Extract the service account secret using Mimikatz
Extract the service account secret using Mimikatz
  • Set the S4U2Self backdoor on the “krbtgt” account. In this example, the attacker is using a service account named “svc-backdoor” on which he has full control. We detail in the section “Persistence considerations on the account planted as a S4U2Self backdoor” of this article how to select this account.

Set the S4U2Self backdoor
Set the S4U2Self backdoor

Part 2. Leveraging the backdoor to regain administrative privileges

In this second section, we will be describing how an attacker could recover “Domain Admin” rights using its previously planted backdoor. To regain its administrative privileges, the attacker will leverage his access to the “svc-backdoor” account and follow the next 3 steps:

 

  • Trigger the backdoor in order to get a TGT for any user, the “administrator” account in this scenario.
First, a TGT for “svc-backdoor” account is retrieved by Rubeus using its own Kerberos AES key.
First, a TGT for “svc-backdoor” account is retrieved by Rubeus using its own Kerberos AES key.
Secondly, this TGT is used by S4U2Self to get a TGS only valid on the service account but created on behalf of the “administrator” account.
Secondly, this TGT is used by S4U2Self to get a TGS only valid on the service account, but created on behalf of the “administrator” account.
Finally, S4U2Proxy gets the TGS for the “administrator” account
Finally, S4U2Proxy gets the TGS for the “administrator” account

Import remark: Because the TGS is targeted for the Krbtgt service, by design it means that this is a TGT for the “administrator” account.

  • From the retrieved TGT, the attacker can easily get a TGS for the CIFS and LDAP services on the domain controller for the previously-impersonated user, administrator here, and inject them into the current session.
Retrieve valid TGS from the previously-obtained TGT
Retrieve valid TGS from the previously-obtained TGT
  • Finally, the attacker can use its recovered privileges to do any malicious action, e.g. dump other user credentials.
Extract administrator credentials using the recovered TGT
Extract administrator credentials using the recovered TGT

Pretty powerful persistence technique, don’t you think?

Persistence considerations on the account planted as a S4U2Self backdoor

As explained in Shamir’s paper, the SID of a user must be set in the "msDS-AllowedToActOnBehalfOfOtherIdentity" attribute to make the backdoor usable. As this account is the only one that will be able to trigger the backdoor, it must be chosen wisely by the attacker.

Account John Doe set as a backdoor on the krbtgt account
Account John Doe set as a backdoor on the “krbtgt” account

The target account does not need to be privileged in any way. It can be either a user or a computer account but need to have an SPN set to allow the S4U2Self process to work.

Using a computer account as S4U2Self trustee

It is very tempting for an attacker to use a computer account because they have SPNs by design, offering a discrete shelter in the mass.

The only limitation of this approach is the auto-renew feature of computer account’s passwords. Every 30 days (by default), the computer account password is automatically renewed, the credentials will be changed, and the backdoor will not be available anymore. Attackers will have two choices to circumvent this limitation:

Disable computer account password change
Disable computer account password change

Using a service account as S4U2Self trustee

Depending on the targeted AD environment, a service account may even be a better option to hide our S4U2Self backdoor. In fact, service accounts using Kerberos authentication must have an SPN and, from our experience, use a password that does not expire. This configuration makes the service a perfect target for our backdoor:

  • it is stealthier as no SPN is added, limiting the risk of being spotted during this approach;
  • it is persistent because the Kerberos keys will not change.

Of course, even if the service account is protected against delegation (being a member of “Protected Users” group or flagged as sensitive), this does not impact the effectiveness of this AD persistence.

Exploiting constrained delegation with protocol transition

It's important to keep in mind that there is also another similar backdoor, related to constrained delegation with protocol transition this time, that can be used to accomplish the same goal.

Instead of positioning an ACE through an attribute on the “krbtgt” account (the "resource" we want to access), the configuration is done on the account that will trigger the backdoor, through the "TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION" flag of the "userAccountControl" attribute and the "msDS-AllowedToDelegateTo" attribute. Note that this last attribute can only be set by users from the "Domain Admins" group.

Part 1. Putting the backdoor in place

The different phases explained in the S4U2Self backdoor can basically be applied here, with a small variation.

  • Identify a user account configured with a password that does not expire and which has an SPN (same command as before).
  • Extract the secrets of this account, again with a tool such as Mimikatz (same command as before).
  • Configure the account for constrained delegation with protocol transition (1), then choose a Domain Controller and the LDAP service (2).
Set the constrained delegation backdoor
Set the constrained delegation backdoor

Part 2. Obtaining administrative rights again

Once again, the backdoor can be triggered by the "svc-backdoor" account.

  • Using the compromised backdoor account, retrieve a TGS for the LDAP service for any user, in particular for the "administrator" account in this example
First, a TGT for “svc-backdoor” account is retrieved by Rubeus using its own Kerberos AES key.
First, a TGT for “svc-backdoor” account is retrieved by Rubeus using its own Kerberos AES key.
Secondly, this TGT is used by S4U2Self to get a TGS only valid on the service account but created on behalf of the "administrator" account.
Secondly, this TGT is used by S4U2Self to get a TGS only valid on the service account, but created on behalf of the "administrator" account.
Finally, S4U2Proxy gets the TGS for the "administrator" account
Finally, S4U2Proxy gets the TGS for the "administrator" account, for the LDAP service on the DC
  • Now that this TGS is correctly injected in the current process, once again, we can retrieve an administrator credential for a classical pass-the-hash attack
The Active Directory domain is compromised
The Active Directory domain is compromised

As we can see, both methods are very similar, the only difference being in the used attributes for the backdoor, whether on the resource that we want to access or on the service account accessing the resource.

Efficiently detect S4U2Self backdoor in your environment

Now that we have a better understanding on how the S4U2Self backdoor works, efficient detection capabilities can be found.

Alsid customers, you are already protected

Alsid provides the first proactive solution being able to detect breaches or backdoors on Active Directory infrastructures before attackers can exploit them. Relying on real-time monitoring capabilities, Alsid is able to isolate in real time any attack vector and elaborate in-context remediation plans to secure critical assets. 

As Alsid is aware of any modification on attributes on the AD objects in real time, it becomes possible to detect an attacker installing the backdoor from the very beginning. Last week, Alsid published an out-of-band update to deliver new detection capabilities able to detect Shamir’s work. Dear customer, don’t worry, you already are able to detect this new attack vector.

Detecting S4U2Self using Alsid for AD
Detecting S4U2Self using Alsid for AD

Let’s describe the technical approach Alsid engineering team followed to efficiently detect this new persistence mechanism.

As we now understand, the “krbtgt” account is a critical asset and must be protected at all costs. In a regular configuration, this account should not be delegated at all (neither through S4U2Proxy nor S4U2Self). Thus, at the moment someone will set an attribute into the "msDS-AllowedToActOnBehalfOfOtherIdentity", Alsid will raise an alert to the SOC team explaining the issue.

This is also true for the "msDS-AllowedToDelegateTo" attribute. As soon as this attribute is set for a constrained delegation with protocol transition, it suggests that there is something wrong about the configuration. And if this is pointing to a Domain Controller, this is clearly something that should be considered by the security team.

Finally, monitoring the “krbtgt” account is not the end of the road. If an administrative account has an SPN, the attack could target this account instead. This would enable the Kerberoast attack and everything seen here for the “krbtgt” account. As Kerberoast is an attack vector fully detected by the product, Alsid was already preventing this attack scenario. And as such, if an attacker would use another privileged account for this backdoor, he would put an SPN on this user, which would trigger an alert.

Detecting S4U2Self backdoors when you are not using Alsid solution

For those of you not being Alsid customers, there is still hope! Several ways can be used to discover the presence of the backdoor.

As an example, using an unprivileged Active Directory user account and the RSAT package(https://www.microsoft.com/en-US/download/details.aspx?id=45520), the following PowerShell command can be used to detect the backdoor on the “krbtgt” account:

PS C:\ > Import-Module ActiveDirectory
PS C:\ > Get-ADUser krbtgt -Properties PrincipalsAllowedToDelegateToAccount

Unfortunately, this approach is good for security audits but not for real-time detection. Another approach would be to set an SACL on the “krbtgt” account to be informed of every change, analyze the content of the change to detect the set of the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute. Please refer to the previous article from Alsid to learn more about this approach.

To detect S4U2Self backdoors on other privileged accounts, we should first consider every built-in group with sensitive privileges on an AD environment. Other than the famous “Domain Admins” group, a lot of other groups should be considered as privileged as well. Every member of those groups should NOT have an SPN, otherwise both Kerberoast and the backdoor of this article will apply.

Those are the groups that should be considered as privileged and protected accordingly:

  • Domain Admins
  • Enterprise Admins
  • Administrators
  • Schema Admins
  • Domain Controllers
  • Group Policy Creator Owners
  • Server Operators
  • Account Operators
  • Cert Publishers
  • Key Admins
  • Enterprise Key Admins
  • Print Operators
  • Backup Operators
  • DnsAdmins

In practice, it means that all those groups must be queried recursively in order to retrieve their members. Those accounts will then need to be checked for the presence of an SPN.

As explained in this article, the S4U2Self requires to have an SPN and to never renew their password. The accounts that would be interesting as target for the attribute "msDS-AllowedToActOnBehalfOfOtherIdentity" can thus be found using the following PowerShell command:

PS C:\ > Get-ADUser -Filter * -Properties ServicePrincipalName, PasswordNeverExpires | ? {($_.ServicePrincipalName -ne "") -and ($_.PasswordNeverExpires -eq $true)}

Contactez-nous

Découvrons ensemble comment Alsid peut améliorer la sécurité de vos infrastructures d’annuaire

Contactez-nous