Signed Binaries Proxy Execution – T1218

What is MITRE ATT&CK? Review this MITRE ATTACK Framework summary.

Introduction

The MITRE ATTACK April release included is a new TTP known as ‘Signed Binaries Proxy Execution’ which is T1218. This TTP is based on an attacker using signed binaries to perform malicious activities.

Using signed binaries to execute code isn’t a new technique. System-administrators have been using have using psexec.exe and other signed binaries like ProcDump for years. Mark, is owed many beers for his great work! So you may be asking yourself what’s the big deal?

Many organization trust everything that comes from Microsoft since they run the Windows Operating System. Unfortunately, attackers can use many of the binaries that are signed by Microsoft in malicious ways.  These methods blend in since their usage is similar to an engineer or system administrator using these binaries to perform normal activities (or semi-normal looking activities).

Signed binaries actually fall into several groupings which are listed below:

  • Binaries included on the latest supported operating systems
  • Binaries included on the old/unsupported operating systems
  • Binaries that are commonly used by administrators or developers, but are not included in the operating system

In this post, we will demonstrate some of these techniques and discuss options for migrations.

Attack Demonstration

PSExec

PSExec is probably the best-known executable that is signed by Microsoft that has been used maliciously. It was designed to be used by system administrators to execute code on a remote system by using the SMB service. It starts an SMB service on the remote system and transfers the output back using SMB.

This command executes whoami on the remote system, and displays the resulting output locally:

PSExec64.exe -accepteula win10 whomi

sysinternal codeblock results

Friendly reminder to always be sure you have accepted the EULA when uploading SysInternal tools to a target.

ProcDump

Procdump is another very powerful tool that can be used to extract the memory contexts of a process. For example, an attacker can use it to extract credentials from LSASS memory. Mimikatz.exe doesn’t need to be uploaded to a system for it to be used in this attack. Procdump can be executed on the victim system, and the contents of LSASS memory can be downloaded for memory extraction inside an attacker’s local virtual machine. To do this we can execute the following commands.

procdump.exe -accepteula -ma lsass.exe C:lsass-mem.dmp 2>&1

Or (depending on the arch)

procdump64.exe -accepteula -ma lsass.exe C:lsass-mem.dmp 2>&1

sysinternal codeblock results

*download C:lsass-mem.dmp*

on the attackers VM:

mimikatz codeblock results

		c:mimikatzx64 > mimikatz.exesekurlsa::minidump lsass-mem.dmpsekurlsa::logonPasswords[outputs credentials]	

WMIC

That shows the power of some of the common system administrator tools to do malicious things. However, there are many binaries already on systems that don’t require anything to be downloaded. For example, WMIC can be used to execute a command on a remote system. This can be done using the following syntax:

Create a new account (Hacker on the target system).

wmic /node:[remoteHost] process call create “c:windowssystem32net user Hacker Password1! /add

Add the user to the Administrators group.

wmic /node:[remoteHost] process call create “c:windowssystem32net localgroup Administrators Hacker /add”

wmic process call codeblock results

One thing to keep in mind when trying to use WMIC is that there is no output, so attackers that are executing a remote system and want the output will need to copy them over after the execution has completed.

Also, if the path or command fails, the result from WMIC will still include ‘Method execution successful’ as long as the user has the right permissions.

SyncAppvPublishingServe

Another example of a binary that already is SyncAppvPublishingServe. This is a lesser known binary which allows attackers to execute PowerShell commands without powershell.exe. If blue-team believe that blocking powershell.exe is the best way to prevent using PowerShell, they need to make sure they consider alternative paths such as this one.

c:windowssystem32SyncAppvPublishingServe.exe “n;Start-Process calc”

windows version

Windows 10 Version 1803 Fully patched. July 3, 2018

Defenders will also need to consider older versions as well. For example, let’s take an older version of SyncAppvPublishingServe.exe and get it to run calc for us.

sigcheck64 codeblock results

We see clearly that the signed date is 12:27 AM 9/29/2017 and the file version is 10.0.16299.15.

Mitigations

Monitor and/or block signed binaries that can be used to execute malicious code.

This will be challenging since even if the organization can block the paths for the binaries that are known, attackers can still copy the binaries or locations. The best approach is to monitor the execution of known application whitelisting bypasses. If a specific known application whitelisting bypass isn’t needed by the organization the default paths can be restricted.

Overall, not trusting signed by Microsoft is a challenge. Tools exist such as AppLocker to restrict binary execution which will help to reduce some of the exposure. However, this isn’t enough, an attacker can still download the same binary to other locations or copy the pre-existing binary to another location. Not have wide write permissions will also help to reduce the exposure.

References

icon-praetorian-

See Praetorian in Action

Request a 30-day free trial of our Managed Continuous Threat Exposure Management solution.

About the Authors

Catch the Latest

Catch our latest exploits, news, articles, and events.

Ready to Discuss Your Next Continuous Threat Exposure Management Initiative?

Praetorian’s Offense Security Experts are Ready to Answer Your Questions