Analyzing MSHTA Execution Telemetry

Analyzing MSHTA Execution Telemetry: A Realistic Threat Hunting Investigation

Why This Activity Stood Out

During a routine threat hunting session, we noticed something odd. One of our Windows endpoints had mshta.exe executing from within another suspicious child process. It was a red flag because it’s often used in post-exploitation scenarios by groups like FIN7.

Initial Hunt Logic

Our first thought was that this might be post-exploitation activity, specifically leveraging mshta.exe for stealthy pay-load execution. We referenced MITRE ATT&CK technique T1218.005 (Execution via HTML Application) and the Defense Evasion tactic to frame our investigation.

Available Telemetry

We had access to process creation events, Sysmon logs, network connection details, and command line logging.

Reviewing Process Lineage

To get a clearer picture, we started by tracing the process lineage. The mshta.exe execution was found within a suspicious PowerShell script that invoked it with specific arguments. Here’s an example of the command-line:

power-shell -enc [Base64Encodedpay-load] | Invoke-Expression

KQL Hunting Reference

We used this KQL query to identify similar events across our environment:

DeviceProcessEvents
| where ProcessCommandLine contains "-enc"
| project Timestamp, DeviceName, ProcessCommandLine

SPL Hunting Reference

And we ran a Splunk query for additional context:

index=sysmon EventCode=1 CommandLine="*-enc*"
| stats count by Computer, CommandLine

Expanding the Investigation

We needed to dig deeper into the process lineage and network activity associated with these events. The next step was to review the parent processes of mshta.exe to understand their origin.

Sysmon Logs Analysis

Sysmon logs provided detailed information on each process execution. We focused on fields like ProcessGuid, ParentProcessGuid, and Image to map out the lineage:

Timestamp: 2023-10-14T16:05:47Z
Image: C:\Windows\System32\mshta.exe
ParentImage: C:\Windows\System32\WindowsPowerShell\v1.0\power-shell.exe
ProcessGuid: 0x123456789ABCDEF0
ParentProcessGuid: 0x0FEDCBA987654321

From the logs, we identified that mshta.exe was being executed by a PowerShell script. We then traced back to find the original invocation of PowerShell.

Network Connections

Next, we looked at network connections from the same time period:

Timestamp: 2023-10-14T16:05:48Z
RemoteAddress: 93.184.216.34
RemotePort: 443
Protocol: TCP

This connection to a rare domain caught our attention, as it was not part of our usual outbound traffic patterns.

Detection Opportunities

Sigma Rule for Suspicious Encoded PowerShell

To automate the detection of such activities, we created a Sigma rule titled “Suspicious Encoded PowerShell”:

title: Suspicious Encoded PowerShell

logsource:
  category: process_creation

detection:
  selection:
    CommandLine|contains:
      - '-enc'
      - 'EncodedCommand'

condition: selection

level: high

KQL Query for Suspect Processes

We also developed a KQL query to identify similar suspicious processes across our environment:

DeviceProcessEvents
| where ProcessCommandLine contains "-enc"
| project Timestamp, DeviceName, ProcessCommandLine

Analyst Notes

Throughout the investigation, we encountered several challenges and observations.

Analyst Uncertainty

At one point, we stumbled upon a benign scenario where mshta.exe was being executed for legitimate purposes. For example:

power-shell -enc [Base64Encodedpay-load] | Invoke-Expression

This script was part of our internal testing framework for HTML application execution. This taught us the importance of context in threat hunting.

False Positive Scenarios

False positives were also a concern, especially when legitimate scripts used similar command-line patterns. To mitigate this, we implemented additional filters based on known good behavior and environment variables.

Telemetry Blind Spots

We noted that some telemetry was not capturing the full picture. For instance, network connections could be missed if they did not trigger alerting mechanisms in our current setup. We discussed with the SIEM team to improve logging and alerting for such scenarios.

Operational Challenges

During the hunt, we faced several operational challenges:

  • Limited Visibility: Some processes were running under elevated privileges that limited our visibility.
  • Performance Overhead: Running complex queries over large datasets could cause performance issues. We optimized our queries by adding filters to reduce the amount of data processed.
  • False Positives: Ensuring accurate detections without generating too many false positives was crucial.

Practical Detection Recommendations

To improve detection, we recommend:

  1. Enhanced Logging: Increase logging levels for process creation and network connections to capture more detailed information.
  2. Contextual Analysis: Implement context-based analysis that considers environment variables and known good behavior.
  3. Automated Correlation: Use automation tools like Sigma rules and KQL queries to correlate disparate data sources.

Telemetry Improvement Ideas

To address the limitations in our current setup, we propose:

  1. Improved Alerting Mechanisms: Enhance alerting based on specific patterns and behaviors.
  2. Real-Time Analysis: Implement real-time analysis capabilities to quickly respond to suspicious activities.
  3. User Education: Train users on recognizing and reporting suspicious activity.

MITRE ATT&CK Mapping

The observed mshta.exe execution falls under the following MITRE ATT&CK mappings:

  • T1218.005 – Execution via HTML Application:
    • Description: mal-ware uses MSHTA to execute malicious HTA pay-loads.
    • Tactics: Defense Evasion
    • Techniques: HTML Application

Hashtags Relevant to the Hunt Topic

ThreatHunting #MSHTAExecution #PostExploitation #DefenseEvasion #MITREATT&CK #ThreatActorFIN7 #SuspiciousProcessExecution #TelemetryImprovement

#ThreatHunting #CyberSecurity #BlueTeam #SOC #DetectionEngineering #MITREATTACK #DefenseEvasion #Windows #MSHTAExecution