Last updated
Last updated
was published by in 2021, in which he discusses the possibility of relaying Kerberos authentication in a Windows domain without MitM. It's a fairly heavy read but obviously contains all the granular details. This lesson will attempt to summarise the key points and demonstrate two popular attack vectors for LPE on domain-joined hosts.
One major challenge in relaying Kerberos is that service tickets are encrypted with the service's secret key. A ticket for CIFS/HOST-A cannot be relayed to CIFS/HOST-B because HOST-B would be unable to decrypt a ticket that was encrypted for HOST-A. However, in Windows, the service's secret key is derived from the principal associated with its SPN and is not necessarily unique per-service. Most services run as the local SYSTEM, which in a domain context, is the computer account in Active Directory. Therefore, service tickets for services run on the same host, such as CIFS/HOST-A and HTTP/HOST-A, would be encrypted with the same key.
As James puts it - "there's nothing inherently stopping Kerberos authentication being relayed if the attacker can control the SPN", but until now, we have not had a way to do this. One method for achieving it is detailed in his post: . The demonstrated approach is very similar to how the exploit works - stand up a local listener and coerce a privileged COM server into connecting to it; capture the subsequent authentication request and relay it somewhere else. Again, there are a lot of nuanced detail in James' post, but these are the highlights.
The attacker starts a malicious RPC server that will force connecting clients to authenticate to it using Kerberos only, and by using appropriate security bindings, they can specify a completely arbitrary SPN. This will force a service ticket to be generated for a service/SPN that that attacker doesn't control, such as HOST/DC. They then coerce a privileged COM server into connecting to their malicious RPC server, which will perform the authentication and generate the appropriate Kerberos tickets. In this example, the malicious RPC server would receive a KRB_AP_REQ for HOST/DC as the local computer account, which the attacker can relay to LDAP/DC instead. With a valid service ticket for LDAP, they can submit requests to the DC as the computer account to modify the computer object in Active Directory. This opens the door for other attacker primitives like RBCD and shadow credentials in order to achieve the LPE.
It's worth noting that if signing or channel binding are enabled then these attacks are not possible. Thankfully (or not, depending on your point of view), signing is still disabled by default, even on critical protocols such as LDAP.
There are tools such as that automate most of the exploitation steps required, but we'll do them manually. The primary reason is 1) that we understand all of the steps in more detail; and 2) we know how and what clean-up afterwards (which these tools often omit). For the relaying, we'll use the original tool by ; and for the LPE, tools we're already familiar with including StandIn, Whisker, and Rubeus.
This lesson will show how Kerberos relaying can be used to LPE to SYSTEM on WKSTN-2 as bfarmer.
One unfortunate aspect to KrbRelay is that because it uses the BouncyCastle Crypto package (which is quite large), its total compiled size is larger than the default task size allowed for Beacon. Trying to run it with execute-assembly will throw an error:
We could try and modify the tool to make it smaller or modify Beacon's task size to make it larger. The latter option is quite straightforward because it can controlled with the tasks_max_size setting in Malleable C2 - the downside is that it cannot be applied retrospectively to existing Beacons. To double the task size, add set tasks_max_size "2097152"; to the top of your C2 profile.
You will notice significantly more lag within the CS client when executing tasks with large artifacts.
You must also remember to restart the team server and re-generate your payloads after making changes to the Malleable C2 profile.
As mentioned in the RBCD lesson, it is necessary to have control over another computer object to abuse. If available, the easiest way is to add your own computer object to the domain and get its SID.
The next step is to find a suitable port for the OXID resolver to circumvent a check in the Remote Procedure Call Service (RPCSS). This can be done with CheckPort.exe.
With that, run KrbRelay.
Where:
-spn is the target service to relay to.
-clsid represents RPC_C_IMP_LEVEL_IMPERSONATE.
-rbcd is the SID of the fake computer account.
-port is the port returned by CheckPort.
If we query WKSTN-2$, we'll see that there's now an entry in in its msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
Because we have the password associated with EvilComputer, we can request a TGT and perform an S4U to obtain a usable service tickets for WKSTN-2. Let's use this to get a ticket for HOST/WKSTN-2.
Notice how this is one occasion where we do not use the FQDN of the target machine in the msdsspn parameter.
The advantage of using shadow credentials over RBCD is that we don't need to add a fake computer to the domain. First, verify that WKSTN-2 has nothing in its msDS-KeyCredentialLink attribute.
Run KrbRelay as before, but this time with the -shadowcred parameter.
If you perform these attacks back-to-back and see an error like (0x800706D3): The authentication service is unknown. then reboot the machine or wait for the next clock sync.
Like Whisker does, KrbRelay will helpfully provide a full Rubeus command that will request a TGT for WKSTN-2. However, it will return an RC4 ticket so if you want an AES instead, do:
The S4U2Self trick can then be used to obtain a HOST service ticket like we did with RBCD.
To perform the elevation, we'll use this ticket to interact with the local Service Control Manager over Kerberos to create and start a service binary payload. To streamline this, I've created a BOF and Aggressor Script that registers a new elevate command in Beacon. It can be found in C:\Tools\SCMUACBypass and is based on James' gist.
