This post is duel posted on the Semperis blog.

Another day, another “by design” but clearly unintended Windows AD feature. While playing with Kerberos tickets I discovered an issue that allowed me to authenticate to other domains within a forest across external non-transitive trusts. This means that there is in fact no such thing as a “non-transitive trust”, and the description as such when creating a trust is at best misleading, leaving systems administrators with a false sense of security. After reporting this issue to Microsoft, I received the following response:

Figure 1: MSRC Response

This post details the issue discovered but as Microsoft do not feel that it affects security and as a result are not planning on fixing this issue, there is no way to avoid what is being described within this post apart from not using external trusts at all.

Trusts and Transitivity

Will Schroeder published a great post on trusts back in 2017. If you are not too familiar with the different trusts and how they work, I highly recommend reading that first as I will not be going into as much detail on the various types. For this post, I will not be discussing intra-forest trusts (trusts within a single forest) other than as they apply to the specific attack path that I am going to discuss. I also will not be discussing selective authentication trusts, but I have never actually seen these in real environments. The remaining trusts are forest trusts and external trusts. Forest trusts are trusts between two forests; or more accurately a transitive trust between the root domains of two forests, which means any user from any domain within the trusted forest can authenticate to any domain within the trusting forest. External trusts, on the other hand, are trusts between two domains and are described as being “non-transitive”, which should mean that only users within the trusted domain can authenticate against only the trusting domain.

Figure 2: External Non-Transitive Trust

Other technical differences are present between forest and external trusts, but these will be discussed if and when required for this post.

Microsoft describes trust transitivity as follows:

Transitivity determines whether a trust can be extended outside of the two domains with which it was formed.

• A transitive trust can be used to extend trust relationships with other domains.
• A non-transitive trust can be used to deny trust relationships with other domains.

This description is very clear. For non-transitive trusts, only the two domains involved in the trust can authenticate to each other and not beyond. As I will demonstrate in this post, this is not the case.

Lab Setup

To properly demonstrate this issue, several multi-domain forests are required with external trusts between them. I have setup the lab as follows:

Figure 3: Lab Setup

This setup involves three (3) forests, two (2) of which have three (3) domains and the other containing two (2) domains. The domains semperis.lab and treetest.lab have a bidirectional non-transitive external trust:

Figure 4: External Trust 1

The domains grandchild1.child1.semperis.lab and semperisaz.lab also have a bidirectional non-transitive external trust:

Figure 5: External Trust 2

This should make it possible to demonstrate the implications and limitations of this issue.

How Kerberos Cross-Trust Authentication Works

The main thing that is required to authenticate to a service across a trust using Kerberos is a referral (or referral TGT). This is a ticket requested from your local domain controller (DC) for the foreign domain. This section assumes a basic understanding of how the normal Kerberos authentication flow works, for a detailed explanation of that check out Sean Metcalf’s Detecting Kerberoasting Activity post. It would also be advantageous to be reasonably familiar with Rubeus (as I will be using it to request tickets in the remaining sections). This section will focus on the semperis.lab forest which is sufficient to demonstrate how ticket requests across trusts are performed, the information here is, however, applicable to any “allowed” trust path.

The simplest example of cross-trust authentication is to authenticate to a service on a domain which has a direct trust with the local domain. The trust that the domain grandchild1.child1.semperis.lab has with child1.semperis.lab, shown in Figure 5 above, is an example of this. In this situation, the first step, after obtaining the initial TGT, in obtaining a service ticket for an account in grandchild1.child1.semperis.lab to a service in child1.semperis.lab is to obtain a referral for child1.semperis.lab:

Figure 6: Referral Request For child1.semperis.lab

As shown in Figure 6 above, the request was made to a DC (SGC1DC1.grandchild1.child1.semperis.lab) within the domain (grandchild1.child1.semperis.lab) local to the authenticating user (lowpriv). The request was made for the service krbtgt/child1.semperis.lab and the fact that the ServiceRealm (srealm) is the local domain (grandchild1.child1.semperis.lab) within the resulting ticket, shows that this ticket is a referral. The diagram below shows this:

Figure 7: Referral Request

This referral can now be used to request service tickets (STs) from the foreign domain:

Figure 8: Example Usage of Referral

Here an ST was requested from the foreign DC (SC1DC1.child1.semperis.lab) for the service host/SC1DC1.child1.semperis.lab using the referral retrieved previously.

Figure 9: Requesting ST Using Referral

To take this one step further, if a service on the forest root domain (semperis.lab) is required, a referral for this domain cannot be directly requested from the local (grandchild1.child1.semperis.lab) domain:

Figure 10: Referral Request For semperis.lab

As shown in Figure 10 above, a referral for krbtgt/semperis.lab was requested from the local DC sgc1dc1.grandchild1.child1.semperis.lab. However, the ticket returned by the DC was for the service krbtgt/child1.semperis.lab, meaning that this is a referral for the domain child1.semperis.lab, NOT semperis.lab.

Figure 11: Requesting Referral For semperis.lab

This can be explicitly shown by trying to use this ticket to request a ST for the semperis.lab domain:

Figure 12: Root Domain Service Ticket Request

As shown in Figure 12 above, this results in an AP_ERR_BAD_INTEGRITY error. This is because the referral ticket is encrypted with the trust key for the grandchild1.child1.semperis.lab --> child1.semperis.lab trust. The DCs in the root domain semperis.lab do not have knowledge of this key and so are not able to decrypt the ticket.

Figure 13: Requesting ST From semperis.lab

To request a service ticket for the root domain semperis.lab, first a referral for semperis.lab must be requested from a DC in the domain child1.semperis.lab using this referral:

Figure 14: Referral Request For semperis.lab

Here a request was made to the foreign DC (sc1dc1.child1.semperis.lab) using the referral for the domain child1.semperis.lab to request a further referral for the root domain semperis.lab. It should be noted here that in order to request this ticket, the /targetdomain argument is required. This is because by default Rubeus will use the domain within the ticket passed to it to fill in the domain in the TGS-REQ, in this case that would be grandchild1.child1.semperis.lab and would result in a ERR_WRONG_REALM error as the domain local to the DC is child1.semperis.lab. This will be very important in the next section.

Figure 15: Requesting Referral For semperis.lab

Lastly, this resulting referral for semperis.lab can be used to request STs for the semperis.lab domain:

Figure 16: Service Ticket Request For semperis.lab

This ST request from the user [email protected] made to the DC SDC1.semperis.lab for the SPN host/SDC1.semperis.lab is shown in the following diagram and was successful even though the two domains involved do not have a direct trust due to the trust path being allowed:

Figure 17: ST Request For host/sdc1.semperis.lab

This method of requesting referrals for trusting domains can be followed to request STs for any service within any domain for which the trust path is “allowed”.

Making The Non-Transitive Transitive

Now that we understand how authentication across trusts happens, let’s look at how it is possible to traverse external trusts to authenticate to domains that should be prohibited.

As shown in the Figure 3, the domains semperisaz.lab and grandchild1.child1.semperis.lab have a bidirectional external trust, this means that after retrieving a TGT for any account within the domain semperisaz.lab it is possible to request a referral for grandchild1.child1.semperis.lab:

Figure 18: Referral To granchild1.child1.semperis.lab

The diagram showing this request is below:

Figure 19: Request Referral For grandchild1.child1.semperis.lab

This referral can be used to request STs for services on the domain grandchild1.child1.semperis.lab, but if we try to obtain a referral to other domains within the same forest (for example child1.semperis.lab) we get an ERR_PATH_NOT_ACCEPTED error, which is expected:

Figure 20: Path Not Accepted Error

This is because the semperisaz.lab --> granchild1.child1.semperis.lab trust is non-transitive, so the path from semperisaz.lab to child1.semperis.lab is not allowed.

Figure 21: Requesting Referral For child1.semperis.lab

However, we can request a “local” TGT for grandchild1.child1.semperis.lab:

Figure 22: Requesting “local” TGT For grandchild1.child1.semperis.lab

I call this a “local” TGT because unlike the referral, which has a ServiceRealm (srealm) of semperisaz.lab, the ServiceRealm is grandchild1.child1.semperis.lab.

Figure 23: Requesting "local" TGT

Using this “local” TGT, a referral for child1.semperis.lab can now be requested:

Figure 24: Referral For child1.semperis.lab

This process can be seen in the following diagram:

Figure 25: "local" TGT To Request Referral For child1.semperis.lab

We now have a usable referral which can be used to request STs for child1.semperis.lab using any account from the semperisaz.lab domain and without making any changes to trusts or accounts within AD. This is demonstrated below:

Figure 26: Requesting ST For DC In child1.semperis.lab

In Figure 26, a ST was requested from the DC sc1dc1.child1.semperis.lab for the service host/sc1dc1.child1.semperis.lab as the user [email protected]:

Figure 27: Requesting ST For host/sc1dc1.child1.semperis.lab

Furthermore, this method can be used to hop around any domain within the same forest that grandchild1.child1.sermperis.lab exists in. We can demonstrate this by requesting a referral to the root domain semperis.lab:

Figure 28: Requesting Referral For semperis.lab

A referral was requested for semperis.lab from the DC sc1dc1.child1.semperis.lab as the user [email protected]:

Figure 29: Requesting Referral To semperis.lab

Fortunately for security, hopping across further trusts outside of the forest (external or forest trusts) is not possible using this method. As shown in Figure 3, the root domain semperis.lab has a bidirectional external trust with treetest.lab, this trust can be used to demonstrate that limitation:

Figure 30: Requesting Referral For treetest.lab

This at least stops an attacker using this method of trust hopping from hopping into another forest.

Figure 31: Requesting Referral For treetest.lab

This issue is clearly useful for attackers trying to elevate privileges within a forest from across a trust. Other than being able to query domain information from domains that systems administrators may think would be disallowed (and query more sensitive domains or potentially domains with weaker security), this also makes it possible to perform attacks such as Kerberoasting or NTLM authentication coercion on domains that may seem to be disallowed.

Hopping Further

While it is not possible to hop further using this specific method, I did write a post a while ago about the ability to create machine accounts across trusts and that this may open up new avenues of attack for attackers. This situation is another example of that.

Using the referral retrieved for semperis.lab, it is possible to request a ticket for the LDAP service on a DC in semperis.lab:

Figure 32: Request ST For LDAP

Here a ST for ldap/sdc1.semperis.lab was requested using the referral for semperis.lab as the user [email protected]:

Figure 33: Request ST For ldap/sdc1.semperis.lab

This ST can be injected and used to create a machine account directly in semperis.lab (given the configuration allows Authenticated Users, as is default):

Figure 34: Create Machine Account In semperis.lab

This causes the DC sdc1.semperis.lab to create the machine account TestComp within the semperis.lab domain:

Figure 35: Create Machine Account TestComp

This newly created TestComp machine account is a local account within the domain semperis.lab. Now that we have a machine account that exists within semperis.lab, we can retrieve a TGT for that account:

Figure 36: Machine Account TGT

Requesting the machine account TGT looks as follows:

Figure 37: Requesting TGT For TestComp

This machine account TGT is allowed to request a referral to the trusting domain treetest.lab:

Figure 38: Requesting Referral For treetest.lab

Here the machine account’s TGT was used to request a referral for the treetest.lab domain from the DC SDC1.semperis.lab:

Figure 39: Request Referral For treetest.lab

Lastly, the issue described in this post can again be used to gain access to the inaccessible dsptest.lab domain. First by requesting a “local” TGT for treetest.lab:

Figure 40: Requesting Local TGT For treetest.lab

The “local” TGT is requested using the referral for treetest.lab as the account [email protected] from the DC TDC1.treetest.lab:

Figure 41: Requesting "local" TGT For treetest.lab

Then using this “local” TGT to request a referral for dsptest.lab:

Figure 42: Requesting Referral For dsptest.lab

Here a referral was requested for the domain dsptest.lab from the DC TDC1.treetest.lab as the user [email protected]:

Figure 43: Requesting Referral For dsptest.lab

It should be clear that using the combination of these two methods would make it possible to hop very deep into AD enterprise infrastructures, using any low privileged account on a domain which has an external trust to any domain within a forest.

Detection

Unfortunately, the only way to prevent this attack path is to remove external trusts completely. If this is not possible, detection is possible. The relevant Windows events are 4769’s (A Kerberos service ticket was requested). The first indication is that a “local” TGT is requested from an account in a different forest:

Figure 44: 4769 For Local TGT

Here the Account Domain field is a domain that belongs to a different forest and the Service Name is krbtgt. This event is followed by another 4769 requesting a referral:

Figure 45: 4769 For Referral

Here the Account Domain is a domain within a different forest and the Service Name is another domain within the local forest.

It is worth noting that these two events can be on different DCs within the same domain, they do not have to reside on the same DC. At this point, any service tickets requested (4769’s) using this referral will have an Account Domain that contains a domain that should not be allowed to authenticate to the local domain.

Plans to consume these events and detect this attack are planned for an upcoming release of Directory Services Protector (DSP).

Conclusion

The biggest problem here is Microsoft’s description of non-transitive trusts being, at best, misleading to systems administrators. This problem is exaggerated by Microsoft’s refusal to accept that this affects security. As it stands, by creating an external “non-transitive” trust, companies must accept that any account within the trusted domain can authenticate against any domain within the whole forest where the trusting domain resides.

As demonstrated above, in the “Hopping Further” section of this post, this research again highlights the importance of disallowing Authenticated Users from being able to create machine accounts, as not doing so not only puts domains within the forest at a higher risk, but also puts any domains (and the whole forest within which they reside) which have an external trust with any domain within the forest at a higher risk. This is due to the ability to create machine account across trusts, even while using the technique used within this blog post to authenticate against domains which should be disallowed. More information on the machine account quota and how to prevent low privileged machine account creation can be found on Kevin Robertson’s excellent post “MachineAccountQuota is USEFUL Sometimes”.

If nothing else, I hope this blog post informs systems administrators of the real forest-wide risk involved in implementing external trusts. Afterall, how can systems administrators be expected to properly secure their environments while thinking authentication is not possible where it actually is.

Timeline

• 2022/05/04 – MSRC case created.
• 2022/05/12 – Case status changed to “Review/Repro”.
• 2022/06/17 – Case status changed to “Develop” with email that stated "We confirmed the behavior you reported. We'll continue our investigation and determine how to address this issue."
• 2022/06/17 – Case status changed to “Complete – Resolved”.
• 2022/08/24 – Comment left on case to find out the status.
• 2022/09/02 – A follow-up comment left on case to find out the status.
• 2022/09/14 – A follow-up email sent to find out the status of the case.
• 2022/09/29 – Email received explaining the issue was not determined to affect security.
• 2023/03/14 – Public disclosure - Blog post released.

Acknowledgements

• Will Schroeder for the creation of Rubeus without which this research very well may not have been done.
• Everyone that reviewed this post and provided feedback, including:
  • Elad Shamir
  • Harjinder Nijjar
  • Andrew Schwartz
  • Jonny Johnson

Data Encryption Standard (DES) is a symmetric-key block cypher algorithm created in the 1970’s and was historically used within Active Directory (AD) environments to secure data. Most notably, DES was used as an encryption type for Kerberos tickets, although on modern environments it is disabled by default. This tweet by Steve Syfuhs mentions that DES is uninteresting and “off by default” but that got me thinking, what is involved in re-enabling it?

In this research, I’ll describe exactly how DES can be re-enabled and when it is enabled, how to use DES to takeover any AD account that isn’t krbtgt or a trust account.

Domain Controller Configuration

The main configuration required for DES to be enabled for Kerberos on a domain is at the domain controller’s level. The following GPO setting can be used to configure which encryption algorithms are supported by the DC’s, when it is applied to DC’s:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: Configure encryption types allowed for Kerberos

Figure 1: Kerberos Encryption Types GPO Setting

Ultimately this sets the following registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\parameters\SupportedEncryptionTypes

Figure 2: Kerberos Encryption Types Registry Setting

This is a bitfield where 2 represents DES-CBC-MD5. This means that the GPO setting does not need to be set for DES to be supported, this registry key only requires the bit that represent ‘2’ to be set on 1 domain controller on the domain.

The best way I’ve found to test this without the ability to query the registry for each DC is to request a TGT with a DES session key. I have modified Rubeus, which now includes the /suppenctype argument to asktgt, to make it easy to request TGT’s this way:

Figure 3: Requesting a TGT with a DES session key

Even though the TGT is encrypted with the krbtgt AES256 key, the session key is DES-CBC-MD5. It is important to note that this is possible to perform with any account without requiring any changes to the account. As shown below, there is no indication that the account supports DES in any way:

Figure 4: Account Supported Encryption Types and UAC

If the DC does not support DES-CBC-MD5, a KDC_ERR_ETYPE_NOTSUPP error is returned:

Figure 5: DES Unsupported

Cracking DES Tickets (Kerberoasting)

After understanding how DES could be enabled and how to tell if it was enabled, the next step was to understand exactly how to exploit this configuration.

The simplest example is when a service account is already configured for DES, this means has an SPN (service account) and has the useraccountcontrol (UAC) setting USE_DES_KEY_ONLY set:

Figure 6: Service account configured for DES

This makes it possible to request a service ticket (ST) for the service user des that is encrypted using DES:

Figure 7: Request DES encrypted service ticket

While the “KeyType” shown here is the session key type, which can be different to the encryption type of the ticket, the following wireshark output shows that the ticket is in fact encrypted using DES:

Figure 8: DES encrypted service ticket

Now the question was how can this be cracked? And more importantly, can the key be brute forced rather than cracking back to the plain text password? The reason this second question is more important is because if this is possible it would mean that any key can be recovered, even that of machine accounts.

To help figure out how to do this, I asked my friend Spiros Fraganastasis for help and he asked Sam Croley. Sam realised that if we knew the first block (8 bytes) of plain text, we could form a hash that would be crackable using hashcat’s mode 14000.

To form the hash, we need the initialization vector (IV), first block of cypher and first block of plain text. The IV is stored as the first 8 bytes of the cypher (after the checksum), the first block of cypher is the following 8 bytes after the IV. So, the only thing left to determine was the first block of plain text.

Dumping the decrypted enc-part for several tickets at first showed the same first block, but after more testing it was clear that this was changing a little:

Figure 9: Decrypted enc-part

Looking at this in an Asn.1 viewer it’s clear that the first 4 bytes are the header for the outer most tag, which contains the length of the data inside it (essentially the full length of the decrypted enc-part minus the length of the header (4 bytes)):

Figure 10: Application Asn.1 Tag

Similarly, the next 4 bytes is the header for a Sequence tag which contains the rest of the actual data and contains a length which is 4 bytes less than the previous length (length of the header less):

Figure 11: Sequence Asn.1 Tag

At first, I thought I could predict these values from having only the cypher, this is because the length of the plain text is always 24 bytes less than the full length of the cypher. The problem with this is after some testing, the full length of the plain text often differed from the full length of the actual data. This is because with DES the data is padded to ensure 8 byte blocks, so the plain text often had some junk padding at the end, which couldn’t be determined just from the cypher.

What I needed was a way to know with as close to 100% certainty what this first block is. After looking at the plain text again, I realised there are 3 sections which can vary in length:

Figure 12: Full enc-part Asn.1

These sections, from top to bottom, are the session key, client username (cname) and the PAC.

The session key type is determined, in large part, by the supported etypes supplied within the req-body of the request (controlled by the user requesting the ticket), the client username is determined by the TGT used to request the ticket. All that is left is the PAC, most of which is determined by the client user attributes within the AD database, the only exception is the server checksum, whose length is determined by the encryption type of the ticket (AES results in a 12 byte checksum, DES/RC4 results in a 16 byte checksum).

With all of this in mind, I realised it was possible to request a user-to-user (U2U) ticket which would match all of these requirements and result in a ticket that I could decrypt to get the first block of plain text. The session key as previously mentioned is determined by the supported etypes within the req-body of the request. The client user will be the user within the ticket granting ticket (TGT) which will be the same for the U2U request as for the service ticket request, meaning the cname along with most of the PAC will be the same (providing nothing changes for that user within AD between when the U2U ticket is requested and the DES encrypted ST is requested). And the U2U ticket encryption type (and ultimately the server checksum length within the PAC) is determined by the TGT session key, controllable when requesting the TGT.

After modifying Rubeus to return the first block of plain text when a ticket is decrypted within the DisplayTicket function, which is run when requesting a U2U ticket by default with Rubeus, we can see the plain text within the output:

Figure 13: Request U2U ticket to get plain text of first block

With knowledge of the plain text, it was now possible to form a crackable hash to brute force the DES key. This is done as follows:

CYPHER:(PLAINTEXT XOR IV)

So, imagine we have the following:

• IV: D98C3338A9CB3626
• CYPHER: 6C25DDEE294588FD
• PLAINTEXT: 638203F8308203F4

We XOR the PLAINTEXT and IV, resulting in: BA0E30C0994935D2, and we end up with the following hash:

6C25DDEE294588FD:BA0E30C0994935D2

I’ve automated this into Rubeus’ describe command with the newly implemented /desplaintext argument, supplying the plain text we received from the U2U request along with the ST we requested earlier, we get back a crackable hash:

Figure 14: Rubeus describe returns crackable DES hash

Using this hash, the DES key used for encryption can be brute forced using the following hashcat command:

hashcat -a 3 -m 14000 A2CCBE7DA8A76607:94D29CF55C02153B -1 charsets/DES_full.charset --hex-charset ?1?1?1?1?1?1?1?1

Figure 15: Crack DES key

It’s worth noting 2 things here:

1. For the DES key cracking in this post, I’ve put the first byte in manually to reduce the cracking time length, this is because I do not have access to a powerful cracking rig to demonstrate in the post.
2. Due to DES having a parity bit at the end of each byte, there are 16 possible usable keys, the cracking will stop when it finds the first usable key, which may not be exactly the same as the key within the AD database but will work none-the-less.

This key can then be used to request a TGT as the service user:

Figure 16: Request TGT using DES

For the sake of completion, it should be clear that with write access to an account it would be possible to perform targeted DES Kerberoasting of the account (user or computer, due to brute forcing of the key) similar to Will Schroeder’s targeted Kerberoasting with the addition of modifying the accounts UAC bit USE_DES_KEY_ONLY to allow for retrieving the DES encrypted ST as well as authenticating using the DES key, of course this bit can be removed in between these actions to cause as little disruption as possible.

It is also worth noting that once the TGT has been retrieved, the USE_DES_KEY_ONLY UAC bit can be switched off:

Figure 17: USE_DES_KEY_ONLY disabled

Even with the USE_DES_KEY_ONLY bit off, the TGT retrieved using the DES key is still usable for its lifetime:

Figure 18: Use TGT retrieved using DES key

This means the USE_DES_KEY_ONLY bit can be on for a minimum amount of time for during a targeted account hijack to make risk of detection as low as possible.

Destroying DCs

As this method of Kerberoasting allows for the recovery of any account key due to a full address space brute forcing being possible, there are 3 types of accounts for which DES encrypted ST’s cannot be retrieved, even with the USE_DES_KEY_ONLY UAC bit set. These are the krbtgt account, trust accounts (INTERDOMAIN_TRUST_ACCOUNT) and DC accounts (SERVER_TRUST_ACCOUNT).

For science, I decided to see what could be done when write access to a DC is possible, partly because this is a semi-common situation where unprivileged users are joining the servers to the domain before a domain administrator (DA) promotes it to a DC, leaving the unprivileged user as the CREATOR OWNER.

I do not advise performing this attack on a live environment as the potential to cause disruption to the infrastructure is real, but it is, however, an interesting attack path.

So, in this example, the user one has GenericWrite over the DC DC2:

Figure 19: GenericWrite permission

While GenericWrite was chosen for ease of demonstration, this will also all work with CREATOR OWNER.

For this to be a useful attack path, it is assumed all the admin accounts are protected from delegation, as shown below:

Figure 20: Administrator marked as “Sensitive and cannot be delegated”

If this was not the case, it would be possible to use Resource-Based Constrained Delegation (RBCD) to escalate. It is also assumed that PKINIT is not configured, otherwise shadow credentials could be used to escalate.

Initially the DC2 accounts UAC value is usual for a DC:

Figure 21: DC2 UAC value

Enabling the USE_DES_KEY_ONLY UAC bit:

Figure 22: Enable DES for DC2

It can be demonstrated that a DES encrypted ST cannot be requested:

Figure 23: ETYPE_NOTSUPP error

So, to exploit this SERVER_TRUST_ACCOUNT (8192) needs to be changed to WORKSTATION_TRUST_ACCOUNT (4096), to do this the UAC field can be XOR’d with 12288:

Figure 24: Downgrade DC from SERVER_WORKSTATION_ACCOUNT to WORKSTATION_TRUST_ACCOUNT

Now that the DC2 account has been downgraded to a normal workstation account, it is possible to request a DES encrypted ST:

Figure 25: Request DES encrypted ST for DC account

Request a U2U ticket to get the valid plain text of the first block (as described previously):

Figure 26: Request U2U ticket to get plain text of first block

Use Rubeus’ describe, with the /desplaintext to get the crackable DES hash:

Figure 27: Rubeus describe returns crackable DES hash

As with the user hash in the previous example, this hash can be used to brute force the DES key for the DC2 account using the following hashcat command:

hashcat -a 3 -m 14000 31812F50B7AC7122:41299994A5D5ADB3 -1 charsets/DES_full.charset --hex-charset ?1?1?1?1?1?1?1?1

Figure 28: Brute forcing DES key

Using this DES key, a TGT can be requested for the DC2 account:

Figure 29: Request TGT for DC2 account

Now a TGT has been retrieved, DES needs to be disabled again:

Figure 30: Disable DES on the DC2 account

The DC2 account also needs to be escalated back to a SERVER_TRUST_ACCOUNT, unfortunately while this level of access grants the ability to downgrade from SERVER_TRUST_ACCOUNT to WORKSTATION_TRUST_ACCOUNT, it does not allow for the reverse:

Figure 31: Fail to escalate DC2 account

Escalation within the domain is required to escalate the DC2 account back to a SERVER_TRUST_ACCOUNT. This can be done by requesting a S4U2self ticket for DC2 as an administrative user (Administrator in this case):

Figure 32: S4U2self ticket for Administrator to DC2

This ticket can be used with impacket to DCsync the AES key for the Administrator from DC2:

Figure 33: DCsync Administrator AES key

This key can be used to request a TGT as the Administrator user:

Figure 34: Request Administrator TGT

Finally, the DC2 account can be escalated back to a SERVER_TRUST_ACCOUNT:

Figure 35: Escalate DC2 account

Again, I’d like to reiterate, I do not advise performing this attack path on a live environment. There is a LOT of room for real disruption.

DES In The Middle (TGT Session Roasting)

Anyone that was paying attention earlier and understood my previous research on AS-REQ ST’s may realise that there is another potential abuse here. In my previous post, in the section called “Proof of concept: RoastInTheMiddle” I demonstrate that it is possible to capture, modify and replay AS-REQ’s. In the section “Domain Controller Configuration” above, I showed that it is possible to request a TGT with a DES session key providing the DC supports DES and without changing the account in any way to support DES. This is done by only including the DES-CBC-MD5 etype within the req-body inside the AS-REQ.

This means if a valid AS-REQ with pre authentication can be captured, it could be modified to only include the DES-CBC-MD5 etype, replayed to a DC supporting DES which will result in a TGT with a DES session key being returned. All that is required to use this TGT is the session key. As the key used to encrypt the pre authentication data is unknown, it is not possible to decrypt the enc-part of the AS-REP to retrieve the session key and use the TGT immediately, it is possible however to request an ST that is encrypted with the TGT session key, using U2U. This is done by providing a TGT for an account for which credentials have been obtained and providing the TGT with a DES session key as the additional ticket. This will result in a ST encrypted with the DES session key but for the user of the account for which credentials have been obtained.

For example, User1’s credentials are known.

1. Request a valid TGT for User1.
2. Send U2U with User1’s TGT as both authentication and additional tickets to extract known plain text of first block.
3. Man-in-the-Middle (MitM) is performed.
4. AS-REQ for Computer1 is captured.
5. AS-REQ modified to only include the DES-CBC-MD5 etype.
6. Forward AS-REQ to a DC that supports DES.
7. Extract TGT for Computer1 from AS-REP.
8. Send U2U with User1’s TGT as the authentication ticket and Computer1’s TGT as the additional ticket to get an ST encrypted with Computer1’s TGT’s session key.
9. Create a DES hash from U2U ST encrypted with Computer1’s TGT’s session key.
10. Create KERB_CRED from Computer1’s TGT and known information, missing the session key.
11. Crack the DES hash back to the TGT session key.
12. Insert the TGT session key into the KERB_CRED.
13. Use the TGT to authenticate as Computer1.

I modified my RoastInTheMiddle tool to perform steps 2-10 automatically:

Figure 36: RoastInTheMiddle session roasting

RoastInTheMiddle performs an ARP poison MitM of 192.168.74.13 and takes a TGT using the /tgt argument, this can be a valid TGT for any account. What it does next is shown in the following wireshark output:

Figure 37: RoastInTheMiddle wireshark output

So here, the first 2 (TGS-REQ/TGS-REP) is the initial U2U using the TGT passed in as the /tgt argument to retrieve the plaintext (displayed in the output with the line “Got usable known plain text:”).

The next 4 is a genuine authentication of the DSP computer account, normally Windows sends an AS-REQ without pre authentication first, this is to retrieve the correct salt for the key. These are passed along to the DC (192.168.74.11) as usual to avoid interrupting the authentication, but the AS-REQ that contains pre authentication is stored (this is shown in the output on the line that says “Got AS-REQ for user [email protected] to service krbtgt/DES.LAB”).

The last AS-REQ/AS-REP is the modified AS-REQ, containing only the DES-CBC-MD5 etype, being sent to a DC (192.168.74.12) and the TGT being sent back.

Lastly the U2U request is sent using the TGT passed in as the /tgt argument as the authentication ticket and the TGT retrieved in the previous step as the additional ticket is sent which results in the DC (192.168.74.12) sending back an ST encrypted with the session key of the DSP computer accounts TGT.

In the RoastInTheMiddle output above, the DES hash for the TGT session key is printed along with the KERB_CRED containing the DSP computer accounts TGT without the session key (making it currently unusable).

The next step is cracking the DES hash of the TGT session key, it is important however that this key is cracked within the lifetime of the TGT (by default 10 hours), otherwise the TGT will be unusable anyway, the following hashcat command was used for this:

hashcat -a 3 -m 14000 EF746FE49C358B28:DF4C43FC01762CA3 -1 charsets/DES_full.charset --hex-charset ?1?1?1?1?1?1?1?1

Figure 38: TGT session key recovered

Now the session key needs to be inserted into the KERB_CRED output by RoastInTheMiddle earlier, for this I added a kirbi command to Rubeus, this command can eventually be used to manipulate KERB_CRED’s further but for now it just supports modifying/inserting a session key with the /sessionkey and /sessionetype arguments:

Figure 39: Insert session key into KERB_CRED

Lastly, this TGT can now be used to authenticate as the DSP machine account and retrieve ST’s:

Figure 40: Use TGT to request ST

DES AS-REP Roasting

Some of you may be asking “what about AS-REP Roasting?” and after essentially writing this whole post, that was the same question that I asked myself. If “AS-REP Roasting” is new to you, check out Will’s post on the topic, as I won’t be going over all of the details here.

The first step was to see if a TGT could be requested without pre authentication using the DES key:

Figure 41: Request TGT without preauth using DES key

The last thing needed is to know the first block of plain text of the enc-part within the AS-REP, the decrypted enc-part is shown below, with the first block highlighted:

Figure 42: Decrypted AS-REP enc-part

The first block this time consists of the first 3 tag headers:

Figure 43: First 3 Asn.1 Tags

Let’s look first at the third tag here (CONTEXT SPECIFIC) which is the last 2 bytes of the plain text (A0 13):

Figure 44: Context Specific Tag

Here it’s clear that A0 is the tag number for CONTEXT SPECIFIC and 13 (or 19 in decimal) is the length. This tag contains only the session key, which will always be DES-CBC-MD5, so the length will always be the same. This means the last 2 bytes of plain text will always be A0 13.

The first 3 bytes of plain text (79 81 CF) is the APPLICATION tag:

Figure 45: Application Tag

Here CF is the length of 207 which is the whole enc-part of the AS-REQ. Lastly, there is the next 3 bytes (30 81 CC), which is the SEQUENCE tag:

Figure 46: Sequence Tag

Here the length (CC or 204) is the length in the APPLICATION tag (207) minus 3 (the length of the tag header). So, the only problem with being able to predict the plain text for the first block of the enc-part of an AS-REP is the ability to predict the length of the APPLICATION tag. To see how this may be possible, let’s look at the whole enc-part:

Figure 47: AS-REP enc-part

Looking at the Asn.1 above, it’s clear that the only elements that will vary in length is the srealm and realm within the sname, everything else should remain a fixed length. With this in mind, it should be relatively easy to calculate the correct length.

The domain name used in this example is “des.lab” which is 7 characters, this means the domain name takes up 14 bytes of the enc-part. The APPLICATION tag is 207 bytes, so:

207 – 14 = 193 bytes

To request a TGT without pre authentication, the domain name has to be known, so by doing the following, the proper length of the APPLICATION tag can be calculated:

193 + (length of domain name * 2)

Then to get the length of the SEQUENCE tag, just minus 3.

Using this method, I modified Rubeus’ asreproast command to support roasting DES enabled accounts when /aes isn’t passed:

Figure 48: AS-REP Roasting using LDAP

It is also possible to manually specify the account, rather than searching LDAP and requires including the /des switch:

Figure 49: AS-REP Roast without LDAP

It’s worth noting here that /format:hashcat is required because john the ripper doesn’t support cracking this type of hash. Using the following hashcat command, it is possible to crack this hash back to the account long term DES key:

hashcat -a 3 -m 14000 3DE9FBEA34F9851B:5B1E49C5BD8A76DF -1 charsets/DES_full.charset --hex-charset ?1?1?1?1?1?1?1?1

Figure 50: DES key cracked

This key can then be used to request a usable TGT:

Figure 51: Request TGT

Remediation/Detection

The best option to avoid these issues is to ensure that all DC’s have DES disabled in the relevant registry key:

HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\parameters\SupportedEncryptionTypes

The bit that represents ‘2’ has to be off. If this is the case, no DES attacks are possible on the domain.

Windows events can also be used to detect attacks that take advantage of DES encryption. The 4769 event can detect Kerberoast attacks that request DES ST’s:

Figure 52: 4769 requesting DES ticket

The 4768 event can be used to detect both the TGT session roasting MitM as well as the AS-REP roasting attacks:

Figure 53: 4768 requesting DES encryption

Conclusion

While DES is disabled by default in AD, it is still very easy to enable and when enabled puts the whole AD infrastructure at much higher risk. It should, therefore, be of utmost importance for sysadmins to ensure that DES is fully disabled on all DCs, as only a single DC supporting DES is all that is required to enable all of these attacks.