Adaptive Emulation (Part 2): Execution Methods

‍

In part 1 of my adaptive emulation blog series, we covered how small changes to specific commands can provide your purple teaming or security testing engagements with a more robust coverage. These small changes are the first step in building an understanding of the defensive posture of the environment being tested. Once a few of those techniques have been tested and tuned, it is time to look at the next step for increasing the complexity and adaptability of your testing: execution methods.

Execution methods are the ways in which adversaries are able to execute techniques and procedures on systems. MITRE ATT&CK® lists most execution methods that have been attributed to adversary use under the Execution Tactic. I’ll mention a quick reminder here that all the techniques listed in ATT&CK are tied to cyber threat intelligence that has recorded adversaries using the specified technique, and does not include all execution methods.

One of the main challenges around execution methods is historic, as with many of the challenges in information security. When new features or applications are added to operating systems, understanding of their security implications is not always clear. Separately, the ability to log or monitor those new features on release typically focuses on debugging and crash reporting. Once these new implementations or features are abused, then a common reaction is to provide more visibility into that process for defenders. This story is reflective of how PowerShell and other administrative functionality tools began and changed into their modern day implementations. I outlined some of the specifics around PowerShell in the blog post around why it is still a challenge even in 2021.

Vary Execution Methods

One of the quickest ways to identify major gaps in logging, alerting, and detection capabilities is to change how a technique is being executed. For iterative testing, changing one variable at a time is preferred, so choosing a single other ATT&CK technique that can be executed with multiple execution methods is ideal.

‍

Let’s walk through an example using Process Discovery, T1057.

‍

‍

*I’d also highly recommend executing PowerShell techniques with both using powershell.exe AND the Unmanaged PowerShell technique, better known as PowerPick method that I outlined in my previous PowerShell blog here.

‍

Using a tool like SCYTHE or another listed in the C2 Matrix Project, a single or series of tests can be built to test all of these execution methods at once.

‍

‍

All of these methods accomplish the same technique of Process Discovery, but require defenders to potentially leverage different detections for alerting (more on that later). SCYTHE customers can import the above compound action from our Github repository here.

‍

In addition to these overall execution methods that provide adversaries with options for executing different techniques and procedures, there are ways that adversaries leverage in-built signed binaries to execute malicious code. In ATT&CK, these are referred to as Signed Binary Proxy Execution (T1218) or Trusted Developer Utilities Proxy Execution (T1127) however they were made famous with the term coined by Matt Graeber: Living off the Land Binaires or LOLBINS. Additional research has identified many more of these binaries, also finding scripts and other Windows tools that can be leveraged. This expansion from the result of research has broadened the initial term from LOLBINS to LOLBAS (Living Off the Land Binaries And Scripts). For a full list of LOLBAS and the functions you can leverage them for, here is the Github project page. I also highly recommend the talk by Casey Smith and Ross Wolf from Blackhat 2019: Fantastic Red-Team Attacks and How to Find Them.

‍

My colleague, Nathali Cano has done a fantastic job introducing and breaking down Rundll32 (T1218.011) and MSBuild (T1127.001) LOLBAS techniques in a previous blog here. I’d recommend checking out her blog if you’re not familiar with LOLBAS.

‍

To leverage some of these specific techniques, you may need different types of payloads to maximize their effectiveness. To leverage MSBuild, you may need to create an XML file that contains shellcode to execute your desired payload.

‍

For an example of a way to embed shellcode into an XML file for execution with MSBuild, check out this how-to guide and script in our compound actions repository.

Detecting Execution Method Variance

Adversaries and security testers have found a lot of success leveraging different execution methods because defenders often have to address each execution method with a separate detection. Execution methods are typically used legitimately for different reasons, which adds to the difficulty of determining malicious intent behind newly discovered or logged execution methods. Let’s look at two examples of this in action.
‍

‍

Common Detection Opportunity Chart

‍

Analysis of the overlapping detection opportunities shows there’s only one overlap and it is highlighted in purple. Since both procedures leverage wmiutils.dll, loading of the DLL (Dynamic Link Library) can be analyzed for the environment to find anomalous usage that may be indicative of an adversary. Roberto Rodriguez contributed WMI Modules Loaded to Sigma to help hunt, baseline, and develop an alert for such activity. It’s worth noting though an attacker could leverage or masquerade as one of the filtered processes in the rule. For better coverage of the procedures, we must look at each one individually and the detection opportunities generated by it.

Example 1: WMIC (Windows Management Instrumentation Command-Line)

In the “wmic process” command we have a few areas we can focus on. First, it does generate a target process of wmic.exe and we can look for wmic.exe execution if it is rare or baselined in the environment. The next detection opportunity is WMIC.exe with a command line containing ‘process’ by leveraging the Suspicious WMI Reconnaissance Sigma rule which identifies a log such as the one below.

Finally, when the process parameter is used it presents us with another detection opportunity of WMIC.exe loading vbscript.dll. The Sigma rule WMIC Loading Scripting Libraries can be leveraged to detect this activity.

Example 2: Unmanaged PowerShell

First in this section we will focus on detecting unmanaged PowerShell (upsh module) execution, before diving into the command line parameters and their functions. To catch unmanaged PowerShell it is recommended to look for System.Management.Automation.ni.dll being loaded by abnormal processes. Sigma offers the In-memory PowerShell and Alternate PowerShell Hosts rules to help address this activity. Next, another indicator of unmanaged PowerShell is the creation of a PShost pipe name from unusual processes and we recommend baselining the Alternate PowerShell Hosts Pipe Sigma rule for your environment. Another DLL that we can look for the loading up is Microsoft.WSMan.Management.ni.dll, but this depends on the way an adversary crafts their unmanaged PowerShell capability. For this, we recommend implementing the applicable Sigma rule, Suspicious WSMAN Provider Image Loads.

Finally, when we get to the command line parameters in this procedure. It should be noted that this detection opportunity will be uncommon for most organizations, as most have PowerShell Logging enabled. As shown in the image below this can be detected with PowerShell Script Block Logging in events 4104. This log source allows rule generation when a script block contains ‘get-wmiobject’, ‘win32_process’, or both depending on your environment. If correlation is available a higher level alert can be engineered when flagging on a non-typical PowerShell process, meaning a high degree of confidence that an adversary is running the enumeration from unmanaged PowerShell.

‍

Similar to Script Block Logging, Module Logging may be used to identify abnormal Get-WmiObject commands with a value of win32_process, such as the event 4103 pictured below. It should be noted that adversaries can turn off or bypass logging, and further detections may be needed to catch such actions.

Closing

In closing it’s important to understand that there can be differences in procedures, even when they fall into the same category of technique. These differences drive different detection opportunities and are why it is paramount to not construe coverage of a technique on the detection results of a single or few procedures.

This post discusses active research by SCYTHE and other cited third parties into an ongoing threat. The information in this post should be considered preliminary and may be updated as research continues. This information is provided “as-is” without any warranty or condition of any kind, either express or implied.‍

About the Authors

Tim Schulz is SCYTHE’s Adversary Emulation Lead. He has been helping organizations build and train teams to understand and emulate cyber threats for the last seven years while working at SCYTHE, MITRE, and Sandia National Labs. He is the author of the Purple Maturity Model, and has given talks on purple teaming, adversary emulation, MITRE ATT&CK, and technical leadership.

‍

Christopher Peacock is an Adversary Emulation - Detection Engineer at SCYTHE, specializing in Purple Team Exercises and Detection Engineering. His previous experience includes multiple roles such as Cyber Threat Intelligence Analyst, Cyber Threat Hunter, Tier 3 SOC Analyst, Incident Responder, Cyber Security Consultant, and Purple Team Lead. He previously worked at Raytheon Intelligence & Space and General Dynamics Ordnance & Tactical Systems. Additionally, he has experience in multiple industries, including Energy, Finance, Healthcare, Technology, and Defense. Current certifications include GCTI, GCFA, GCED, eJPT, and CSIS.

‍

About SCYTHE

SCYTHE provides an advanced attack emulation platform for the enterprise and cybersecurity consulting market. The SCYTHE platform enables Red, Blue, and Purple teams to build and emulate real-world adversarial campaigns in a matter of minutes. Customers are in turn enabled to validate the risk posture and exposure of their business and employees and the performance of enterprise security teams and existing security solutions. Based in Arlington, VA, the company is privately held and is funded by Gula Tech Adventures, Paladin Capital, Evolution Equity, and private industry investors.