PowerShell: Malwares Can Use It Without PowerShell.exe

Overview

PowerShell is one of the most powerful tools available on Windows systems. Unfortunately, it has also become one of the most popular tools for attackers. While many security solutions monitor powershell.exe to detect malicious activity, sophisticated malware has found ways to execute PowerShell code without ever launching the PowerShell executable.

How Malware Bypasses PowerShell.exe Detection

The System.Management.Automation Assembly

The core of PowerShell's functionality resides not in powershell.exe itself, but in the System.Management.Automation.dll assembly. Any .NET application can load this DLL and execute PowerShell commands directly, completely bypassing the powershell.exe process.

using System.Management.Automation;
using System.Management.Automation.Runspaces;

Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();
Pipeline pipeline = runspace.CreatePipeline();
pipeline.Commands.AddScript("Get-Process");
var results = pipeline.Invoke();

PowerShell Runspace via .NET

Attackers can create custom .NET executables that host PowerShell runspaces internally. These applications appear as legitimate .NET processes while executing arbitrary PowerShell code.

Key techniques include:

• Direct assembly loading: Loading System.Management.Automation.dll from the GAC
• Reflection-based execution: Using .NET reflection to invoke PowerShell APIs
• MSBuild abuse: Embedding PowerShell execution within MSBuild project files
• InstallUtil exploitation: Using InstallUtil to run .NET assemblies containing PowerShell runspaces

Real-World Examples

Several prominent malware families have adopted this technique:

1. PowerSploit: A popular post-exploitation framework that can operate without powershell.exe
2. Empire: Uses embedded runspaces for C2 communication
3. Cobalt Strike: Supports inline PowerShell execution through its beacon
4. SILENTTRINITY: A modern C2 framework built entirely on .NET, using PowerShell without the executable

Detection Challenges

Traditional detection methods that rely on monitoring powershell.exe process creation are completely ineffective against these techniques. The malware runs within a legitimate-looking .NET process, making it difficult to distinguish from normal application behavior.

What Security Teams Should Monitor

• Assembly loading events: Monitor for System.Management.Automation.dll being loaded by non-PowerShell processes
• Script block logging: Enable PowerShell script block logging (Event ID 4104), which captures scripts regardless of how they're executed
• AMSI integration: The Antimalware Scan Interface (AMSI) hooks into the PowerShell engine at the assembly level
• .NET runtime events: Monitor ETW providers for suspicious .NET activity
• Module load events: Track DLL loads via Sysmon Event ID 7

Defensive Recommendations

1. Enable PowerShell v5+ features: Script block logging and constrained language mode
2. Deploy AMSI-aware solutions: Ensure your endpoint protection leverages AMSI
3. Monitor .NET assembly loads: Use Sysmon or EDR to track suspicious assembly loads
4. Implement application whitelisting: Tools like AppLocker or WDAC can restrict which applications can load .NET assemblies
5. Use PowerShell Constrained Language Mode: Limits the functionality available to PowerShell scripts
6. Disable PowerShell v2: Older versions lack modern security features and are often targeted by attackers

Conclusion

The ability to execute PowerShell without powershell.exe represents a significant challenge for defenders. Organizations must move beyond simple process monitoring and adopt deeper inspection capabilities that operate at the .NET runtime level. By implementing comprehensive logging, leveraging AMSI, and monitoring assembly loads, security teams can better detect and respond to these sophisticated attack techniques.