Attack(ing) Surface Reduction – Part 1

In our previous article, we explored ASR (Attack Surface Reduction) and learned how to configure them to prevent potential online threats. In this installment, we'll delve into various techniques to bypass specific ASR rules that professionals may come across in their daily tasks.

PSEXEC ?

PsExec is a command-line tool developed by Sysinternals, which is now a part of Microsoft. This tool is designed to facilitate the execution of processes on remote systems in Windows environments. It is particularly useful for system administrators and IT professionals for managing and automating tasks on a network of computers. https://learn.microsoft.com/en-us/sysinternals/downloads/psexec

PsExec excels in its capability to initiate interactive command prompts on distant systems and enable tools such as IpConfig to display information about remote systems . also it can be used to escalate to nt authority priveleges using the -s parameter

PsExec64.exe \\ -u  -p

Attackers have exploited PsExec as a potent tool for malicious activities, leveraging its remote execution capabilities to compromise systems and move laterally within networks.

PsExec is a legitimate tool from the Sysinternals Suite that can bypass Windows Defender's checks. Unfortunately, attackers often misuse this tool to move laterally within networks. While it can evade some defenses (depends on your settings ofc), PsExec is quite noisy, providing defenders with several ways to detect its presence. Detection efforts can focus on various artifacts, such as:

Psexec typically operates by creating remote services, which can be detected by monitoring for EventCode 7045 in the system logs. This event is triggered when a new service is installed, and the default service name used by Psexec is 'PSEXESVC'.

A registery created when accepting EULA

There are several methods to prevent PsExec usage, and one of the key strategies we will explore in this series is ASR.

However, if asked whether ASR can prevent attackers from moving laterally using tools like PsExec, the straightforward answer would be no. This is because attackers consistently develop innovative methods to circumvent protections whenever new defensive techniques are implemented.

ASR VS PSEXEC :

Microsoft has implemented a specific policy to prevent the creation of processes that originate from PSExec and WMI commands.

Name : Block process creations originating from PSExec and WMI commands Guid : d1e49aac-8f56-4280-b9ba-993a6d77406c

As previously detailed in our earlier article, we outlined the steps for setting up ASR rules. 🙂

in the image we can see that Psexec gets blocked by rule we implemented .

so as a normal user we can say that any usage of psexec will be blocked , let's check out first how psexec work .

When running Psexec it goes like the following :

Creation of a service under the name of PSEXESVC
Drop the service the binary to %windir% (C:\windows) under the name of PSEXESVC.exe
Creation of named pipe for remote communication under the name of .pipepsexesvc

Alright, we have a basic understanding of what happens when we launch PsExec. But to really dig deeper and understand what prevents its execution, we need to first discuss the mechanism behind ASR.

ASR is a component of Windows Defender. It operates using a set of signatures, many of which are Lua scripts found in the mpasbase.vdm file. Check this repo it contains extracted Lua scripts from mpavbase.vdm and mpasbase.vdm. If you want to try get them by yourself, you can retrieve this file on your disk C:\ProgramData\Microsoft\Windows Defender\Definition Updates\Backup\ or by downloading the windows defender update file and extracting it with cabextract from mpam-fe.exe.

After extracting the Windows Defender database from mpasbase.vdm, you can either use a hex editor to search for any GUID you are interested in (psexec in our case), or you can extract the Lua bytecode and decompile it with luadec (you may encounter some errors while decompiling them since there are some differences in the Lua data structure size and the header). We have this script to fix the issue. For a deeper understanding, I highly recommend watching this amazing research by commial .

After all these steps, we got this good-looking Lua code:

GetRuleInfo = function()
  -- function num : 0_0
  local l_1_0 = {}
  l_1_0.Name = "Block Process Creations originating from PSExec & WMI commands"
  l_1_0.Description = "Windows Defender Exploit Guard detected remoting application (wmiprvse and psexesvc) creating child process"
  return l_1_0
end

GetMonitoredLocations = function()
  -- function num : 0_1
  local l_2_0 = {}
  l_2_0["%windir%\\system32\\wbem\\WmiPrvSE.exe"] = 2
  l_2_0["%windir%\\PSEXESVC.exe"] = 2
  return 1, l_2_0
end

GetPathExclusions = function()
  -- function num : 0_2
  local l_3_0 = {}
  l_3_0["%windir%\\system32\\wbem\\WmiPrvSE.exe"] = 2
  l_3_0["%windir%\\system32\\wbem\\mofcomp.exe"] = 2
  l_3_0["%windir%\\system32\\svchost.exe"] = 2
  l_3_0["%windir%\\system32\\WerFault.exe"] = 2
  l_3_0["%windir%\\system32\\wuauclt.exe"] = 2
  l_3_0["%windir%\\system32\\gpupdate.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\wbem\\WmiPrvSE.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\wbem\\mofcomp.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\svchost.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\WerFault.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\wuauclt.exe"] = 2
  l_3_0["%windir%\\SysWOW64\\gpupdate.exe"] = 2
  l_3_0["%windir%\\system32\\spool\\drivers"] = 2
  l_3_0["%windir%\\PSEXESVC.exe"] = 2
  return l_3_0
end

From the Lua code, we identify three functions: GetRuleInfo, GetMonitoredLocations, and GetPathExclusions. Their names give a clear indication of their purposes.

GetRuleInfo: This function defines the rule's name and provides a brief description of it. GetMonitoredLocations: This function lists the paths and programs that are being monitored. GetPathExclusions: This function lists the paths and programs that are excluded from the rule.

If we try to obtain a SYSTEM shell using psexec to run cmd.exe or any other program that isn't on the exclusion list, we get a nice block message from the ASR rule.

If we use psexec to run something from the exclusion list, it works without any problems.

Bypass and Get SYSTEM :

A closer look at GetMonitoredLocations we can see that PSEXESVC.exe is being monitored. If it appears and tries to run something (outside the exclusion list) as a child process, it gets blocked.

When reading the help message of psexec, we can see a parameter called -r which is described as "Specifies the name of the remote service to create or interact with." Essentially, this option allows us to control the name of the service dropped by psexec.

we changed the name of the service now is not matching the rule , and we got a shell as SYSTEM without triggering the block rule

2nd bypass

When we run psexec, it drops PSEXESVC.exe and relies on it as a service to execute commands. This raises an interesting question: what if we extract PSEXESVC.exe, place it somewhere other than %windir%, and manually create the service before running psexec? By doing this, we might be able to bypass the ASR rule that blocks PSEXESVC.exe when it tries to run a child process outside the exclusion list. This approach could potentially allow us to run the desired command without being blocked.

Install the service by running : PSEXESVC.exe -install then start the service .

Worked as expected !

When checking the process properties, we observe that PSEXESVC.exe is now located on the user's Desktop, a location that is not monitored by the ASR rule.

see you in the next one .

references :