Abusing S4U2Self: Another Sneaky Active Directory Persistence

Introduction

As part as 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’s S4U2Self extension. In his paper Shamir describes a new Active Directory backdoor based on this unsung functionality. This blogpost will first describe how an attacker would deploy and use such backdoor. Secondly, we will examine how this technique can be extended to target other AD user accounts. Finally, additional details and considerations around this will be introduced to help security teams protecting themselves against this 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.

INSERT HERE ELAD SHAMINR VIDEO Domain persistence via RBCD on the krbtgt account

Setting the SID of a user account into the “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute of the “krbtgt” 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 administration privileges.

Part 1. Setting-up the backdoor

Let’s say that an attacker managed to find a way to temporary obtain “Domain Admins” privileges 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:

1. 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.

2. Extract the secrets associated to this account using the famous “DCSync” feature implemented in various offensive security tools, e.g. Mimikatz.

3. 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 plant as S4U2Self backdoor” of this article how to select this account.

Part 2. Leveraging the backdoor to regain administration 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 administration privileges, the attacker will leverage his access to the “svc-backdoor” account and follow the next 3 steps:

1. Trigger the backdoor in order to get a TGT for any user, the “administrator” account in this scenario.

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

2. 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.

3. Finally, the attacker can use its recovered privileges to do any malicious action, e.g. dump other user credentials.

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.

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 a 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:

• either to reconnect every 30 days to the compromised host and dump the Kerberos secrets again;
• or to change the host local configuration to disable the password renewal process using the “DisablePasswordChange” registry value

Using a service account as S4U2Self trustee

Depending of 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 a 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.

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.

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 very moment someone will set an attribute into the “msDS-AllowedToActOnBehalfOfOtherIdentity”, Alsid will raise an alert to the SOC team explaining the issue.

However, 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 a 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, 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 a 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)}