MSHTA and MSBuild Cat Jam: Threat Research Release January 2021

The Splunk Threat Research team is a group of distinguished security practitioners who dedicate their time and efforts in understanding actor behavior, researching known threats, and building tools and detections that the entire Splunk community can benefit from in an open source environment.

In the first month of 2021, we got off to a great start for content development, producing 29 new detections and four new analytic stories! Analytic stories are security guides that provide background on TTPs, mapped to MITRE ATT&CK, the Lockheed Martin Cyber Kill Chain, and CIS Controls. They include Splunk searches, machine learning algorithms, and Splunk Phantom playbooks (where available)—all designed to work together to detect, investigate and respond to threats. Our goal this past quarter was to generate attack data for 80% of all our detections. A step forward in validating and testing our security content and ensuring we can continually test detections via continuous integration and continuous delivery (CI/CD). We added a super neat badge to the project that displays the percentage of detections tested:

We are continuing to expand our detections for cloud applications by adding new Office 365 and AWS Cloudtrail detections this month. Alongside the development of content, we also added new content to Atomic Red Team to provide opportunities for simulating these attack behaviors. Below are some highlights from the detections and attack simulations included in this month’s releases.

Suspicious MSHTA Activity

This past month we have updated our security content related to MSHTA execution. Adversaries have been abusing mshta.exe for a long time. Mshta.exe is a signed Microsoft binary that loads .hta files. HTML Application (HTA) can contain embedded Windows Script Host, JScript, or VBScript to execute script content. Additionally, inline script execution may occur with both mshta.exe and rundll32.exe using protocol handlers such as JavaScript, About, and VBScript.

The Attack Data was collected with the Attack Range and updated with the latest from Atomic Red Team T1218.005 and AtomicTestHarnesses. Red Canary’s recent research increased the detection relevance and we wanted to ensure coverage in Security Content matched. AtomicTestHarnesses allows for customizing how we want to execute our tests; script engine (for exampleJScript and VBScript), HTA path, renamed/moved mshta.exe and so forth. This allows for many variations and opportunities for validating detection coverage.

As a defender, this content is a great starting point for you to begin reviewing mshta.exe usage in your organization. It may require looking at the data broadly, and then narrowing it into the variations of mshta.exe usage. Always look for moved and renamed instances of a binary. Investigate and analyze a network connection performed by mshta.exe and filter as needed, but be cautious of domains that are being domain fronted.

Check out new content to help you detect suspicious MSHTA activity:

• Suspicious MSHTA child process
• Detect MSHTA URL in Command line
• Detect Rundll32 inline HTA execution
• Suspicious MSHTA spawn
• Detect MSHTA inline hta execution

Trusted Developer Utilities Proxy Execution

In response to the FireEye Red Team tools released in December, we developed new content around trusted developer utilities proxy execution focused on msbuild.exe and microsoft.workflow.compiler.exe. Both utilities are Microsoft-signed binaries and native to the Windows 10 operating system.

For defenders, this content is a great place to start to detect red teams. Red teams most commonly use these utilities to bypass controls by moving the binary from its default location or renaming the binary. It’s important to note the internal name of these binaries in instances where it has been renamed as it will be the source of truth during triage that this is the legitimate binary in question. It is common for msbuild.exe to spawn from developer applications such as Visual Studio using command-line arguments that indicate an application is being compiled. But instances where there are no command-line arguments other than the script code path, and spawning from a non-standard binary (e.g. Mshta.exe, wmiprvse.exe), warrant further investigation.

Because Microsoft.Workflow.Compiler.exe is not widely used today, it’s entirely possible that no process execution is occurring in your environment. So, monitoring for any usage is probably good enough and requires limited filtering.

Here’s our new Trusted Developer Utilities Proxy Execution content:

• Trusted Developer Utilities Proxy Execution MSBuild

  • Suspicious MSBuild rename
  • Suspicious MSBuild spawn
  • Suspicious MSBuild path

• Trusted Developer Utilities Proxy Execution

  • Suspicious Microsoft workflow compiler rename
  • Suspicious Microsoft workflow compiler usage

For a full list of changes, check out the release notes on Splunk Docs:

• 3.13.0
• 3.12.0
• 3.11.0
• 3.10.0

Get the Latest Content via GitHub and Splunkbase

You can find it on GitHub and in Splunkbase. Splunk Security Essential also has all these detections now available via automatic push update.

Feedback

Got any feedback or requests? Feel free to put in an Issue on Github and we’ll follow up. Alternatively, join us on Slack channel #security-research. Follow these instructions If you need an invitation to our users Slack.

About Splunk Threat Research Team

The Splunk Threat Research team is devoted to understanding actor behavior and researching known threats to build detections that the entire Splunk community can benefit from. The Splunk Threat Research team does this by building and open-sourcing tools that analyze threats and actors like the Splunk Attack Range and using these tools to create attack data sets. From these data sets, new detections are built and shared with the Splunk community under Splunk Security Content. These detections are then consumed by various Splunk products like Enterprise Security, Splunk Security Essentials, and Mission Control to help customers quickly and effectively find known threats.

Contributors

Stuart Hopkins, Daniel Pauler, Mika Borner, John Stoner

We also want to thank all community contributors for providing feedback and helping generate new security content.