Detection of Alternate PowerShell Hosts

Attackers frequently leverage alternative hosts to execute PowerShell scripts as a means to evade detection mechanisms configured to monitor only the standard powershell.exe or pwsh.exe processes. By embedding the PowerShell engine within custom binaries, signed trusted applications, or living-off-the-land binaries, adversaries can maintain persistence and perform post-exploitation activity while remaining invisible to standard process-creation telemetry focused on known interpreters. This technique involves utilizing the PowerShell managed API to host the runtime in-process, effectively decoupling the execution from the standard command-line wrappers. Defenders must monitor the PowerShell Module logging (Event ID 4103) to identify the "HostName" and "HostApplication" fields, which reveal the actual binary initiating the PowerShell runspace, rather than relying on process-based detection.

Attack Chain

1. Attacker identifies a legitimate, signed, or obscure binary that supports hosting the .NET runtime.
2. Attacker develops or selects a payload to execute in-memory via the hosted PowerShell engine.
3. Attacker triggers the execution of the target binary with arguments that invoke the PowerShell runspace initialization.
4. The host process initializes the System.Management.Automation assembly to host the PowerShell environment.
5. The PowerShell engine executes the malicious script block or command, which appears as child activity of the host process, not powershell.exe.
6. Attacker performs discovery, credential access, or data staging within the context of the host process.
7. Attacker maintains stealth by avoiding spawns of child processes commonly monitored for PowerShell execution.

Impact

Successful abuse of alternate PowerShell hosts allows attackers to bypass endpoint detection and response (EDR) rules that alert on common PowerShell-related command-line arguments. This increases the attacker's dwell time and operational security, facilitating long-term access, lateral movement, and data exfiltration within target environments.

Recommendation

• Enable Microsoft-Windows-PowerShell/Operational (Event ID 4103) to capture "HostName" and "HostApplication" metadata.
• Deploy the provided Sigma rule to detect PowerShell code execution initiated by unexpected parent processes.
• Baseline legitimate administrative tools in the environment to minimize false positives, specifically identifying software that uses the PowerShell API (e.g., system management or backup agents).