PowerShell’s Shadow Execution: Bypassing Defenses Without powershellexe + Video

By /

Listen to this Post

Featured Image

Introduction:

The PowerShell execution engine is not bound to powershell.exe. As Andrea Pierini’s research and Jake Hildreth’s security deep-dive have shown, the true power lies in the System.Management.Automation.dll—a library that can be loaded by any .NET process. By directly interacting with this assembly, attackers can execute any PowerShell command or script from within memory, entirely bypassing security tools that rely on monitoring the `powershell.exe` process. This fundamental design, intended for developer flexibility, has created a critical detection blind spot that every defender must understand and address.

Learning Objectives:

  • Understand how PowerShell execution can occur without spawning `powershell.exe` or `pwsh.exe` by interacting directly with the System.Management.Automation.dll.
  • Identify and implement enterprise detection strategies to uncover malicious PowerShell activity hidden within legitimate processes.
  • Apply critical security controls like Script Block Logging, WDAC, and Constrained Language Mode to mitigate these advanced evasion techniques.

You Should Know:

1. The Core Exploit: PowerShell Without PowerShell

Andrea Pierini’s research provides a foundational technique for executing PowerShell scripts solely from a compiled C binary. The core concept is straightforward: any .NET application can reference the `System.Management.Automation.dll` assembly, create a PowerShell runspace, and execute commands, all from within a custom or legitimate process.

Step‑by‑step guide explaining what this does and how to use it (for educational and defensive analysis only):

1. Create a new C Console Application project.

  1. Add a reference to System.Management.Automation.dll. In Visual Studio, right-click “References” > “Add Reference” > “Browse” and navigate to `C:\Program Files\PowerShell\7\pwsh.dll` or the legacy C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation.
  2. Write the following code to execute a simple command: 
    using System;
using System.Management.Automation;</li>
</ol>

namespace SilentPowerShell
{
class Program
{
static void Main(string[] args)
{
using (PowerShell ps = PowerShell.Create())
{
ps.AddScript("Write-Host 'Executed from memory!'; Get-Process");
var results = ps.Invoke();
foreach (var result in results)
{
Console.WriteLine(result.ToString());
}
}
}
}
}

    4. Compile the code.

    1. Run the resulting executable. You will see the output of Get-Process. Monitor your EDR or process list. You will see the compiled executable name, but not `powershell.exe` or pwsh.exe. This simple binary has successfully executed PowerShell code while evading detections based solely on process name.

    This technique is the basis for more advanced frameworks like PowerLessShell, which uses MSBuild to execute PowerShell code, and NoPowerShell, a C tool that remains invisible to many logging mechanisms. Recent research has also shown the possibility of creating a PowerShell console using purely native C/C++ code, bypassing managed runtime monitoring entirely.

    1. The Defenders’ Blind Spot: Hunting Alternate PowerShell Hosts

    In an enterprise environment, many security tools are configured to alert on any process named `powershell.exe` or pwsh.exe. This creates a massive detection gap. The tool PowerShdll, for instance, leverages this exact design. It is a DLL that, when loaded into a process via `rundll32.exe` or other means, initializes a PowerShell runspace to execute commands. An attacker could use the following command:

    On a Windows command line:

    rundll32.exe PowerShdll.dll,main <powershell_command>

    From a detection perspective, the command line shows `rundll32.exe` running, a process that is almost universally trusted. There is no `powershell.exe` process for EDRs to inspect. This is known as “living off the land” using an Alternate PowerShell Host.

    Step‑by‑step hunting guide for defenders:

    1. Enable Script Block Logging: This is the single most critical PowerShell defense. It logs the de-obfuscated code of all PowerShell commands, regardless of the hosting process. Enforce it via Group Policy.

    GPO Path: `Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell`

    Set: “Turn on PowerShell Script Block Logging” to Enabled.
    Consequence: Even if an attacker uses the C technique above, the entire `Write-Host` and `Get-Process` script block will be written to the `Microsoft-Windows-PowerShell/Operational` event log (Event ID 4104).

    1. Monitor for Unusual Process Parents: `powershell.exe` is frequently launched by legitimate processes. However, hunt for `powershell.exe` being spawned by unexpected parents, such as Microsoft Office applications (Word, Excel), web browsers, or scripting engines like `cscript.exe` or wscript.exe. These are classic signs of a phishing or drive-by download attack.

    2. Correlate Logs Across Event IDs: Use a SIEM to correlate Event ID 4104 (Script Block Logging) with the process creation event (Event ID 4688 for Windows Security Log or Sysmon Event ID 1). This will tell you which process hosted the suspicious PowerShell script block, providing crucial context for the investigation.

    3. The Arms Race: AMSI and Its Many Bypasses

    The Antimalware Scan Interface (AMSI) is designed to inspect script content before it is executed, catching malicious commands regardless of the host process. However, it has become a primary target for attackers. As of 2026, public research continues to evolve, with techniques focusing on patching the `AmsiScanBuffer` function in memory to disable the scan.

    Step‑by‑step guide to an AMSI bypass in action (for educational/analysis only):

    A common AMSI bypass technique in PowerShell is to overwrite the `AmsiScanBuffer` function with assembly code that always returns AMSI_RESULT_CLEAN. The following is a highly simplified example of a known bypass pattern:

     This code is for educational analysis. Do not use maliciously.
$amsi = [bash].GetType('System.Runtime.InteropServices.Marshal')
$patch = [Byte[]] (0xB8, 0x57, 0x00, 0x07, 0x80, 0xC3)
try {
$address = [System.Reflection.Assembly]::Load([bash]::FromBase64String("QVNET..."))
} catch { ... }

    More sophisticated techniques exist to evade detection. The ScriptBlock Smuggling technique allows attackers to execute malicious code while writing entirely harmless fake entries to the PowerShell logs, deceiving defenders who rely solely on log review. Other advanced methods use Vectored Exception Handlers (VEH) to bypass AMSI without patching memory at all, making detection by integrity-checking EDRs extremely difficult.

    1. A Modern Adversary’s Toolkit: Cloakk, PowerLine, and More

    The cat-and-mouse game between attackers and defenders has led to the creation of sophisticated, multi-layered tools. Publicly available projects provide deep insight into modern tradecraft.

    Cloakk: This tool combines an AMSI bypass with fileless PowerShell execution. It demonstrates how an attacker can deliver and execute an encrypted PowerShell payload entirely in memory. The process is: decrypt, execute, bypass AMSI—all without ever writing a `.ps1` file to disk.
    PowerLine: A tool designed to bypass modern EDRs that heavily monitor command-line arguments of powershell.exe. It focuses on obfuscating the entire execution chain.
    GlobalAMSIBypass: A project that implements a global AMSI bypass by patching `amsi.dll` in memory, disabling scanning for all scripts within the targeted process. Its public release in May 2026 indicates that this remains a relevant and effective attack vector.
    FullBypass-AMSI: These tools go a step further, chaining an AMSI bypass with a Constrained Language Mode (CLM) bypass. By successfully using both, an attacker can break out of PowerShell’s restricted security sandbox and gain a “Full Language” reverse shell, which has unrestricted access to the Windows API.

    For defenders, understanding these tools is the first step to building countermeasures, such as monitoring for the specific API calls and memory allocation patterns these tools rely on.

    5. Building the Impregnable Defense: Hardening Your Environment

    Relying solely on detection is a losing strategy. A resilient defense requires a combination of proactive hardening measures that limit what any PowerShell host can do, even if an attacker gains execution.

    Step‑by‑step hardening guide for Windows defenders:

    1. Implement Windows Defender Application Control (WDAC) or AppLocker: This is your most powerful weapon. WDAC forces PowerShell into Constrained Language Mode (CLM) for all scripts that are not explicitly trusted. CLM severely restricts access to many .NET types and APIs, breaking the C execution techniques described earlier. In contrast, the `ExecutionPolicy` is not a security boundary and can be trivially bypassed.

    2. Restrict Local Admin Privileges: Many of these advanced execution and bypass techniques require administrative rights to install tools, modify registry keys, or patch processes in memory. Limiting admin access is a crucial mitigation step.

    3. Enable and Centralize Full PowerShell Logging: Script Block Logging is your foundation. However, you must also enable Module Logging and PowerShell Transcription.
      Module Logging: Logs pipeline execution events for specific modules, capturing what cmdlets were run.
      Transcription: Captures a record of the entire input and output of every PowerShell session, including commands hidden via base64 encoding, acting as a “black box” recorder. The US Cybersecurity and Infrastructure Security Agency (CISA) strongly recommends enabling these features.

    4. Leverage Constrained Language Mode (CLM) Proactively: Even without WDAC, you can configure AppLocker to enforce CLM. This significantly reduces the PowerShell attack surface and adds a robust defense-in-depth layer. CLM helps protect your system by limiting the cmdlets and .NET types available in a session.

    What Undercode Say:

    The belief that blocking `powershell.exe` secures an environment is a dangerous misconception. The entire attack chain relies on executing code within the .NET runtime, not a specific process name. True protection must be focused on logging the content of the execution through Script Block Logging and limiting the capabilities of the session through WDAC/CLM.

    Key Takeaway 1

    Effective defense against modern PowerShell attacks has shifted from simple process monitoring to deep inspection of script content via Script Block Logging (Event ID 4104) and restricting the session’s language mode.

    Key Takeaway 2

    The most resilient security posture is not reactive detection but proactive hardening. Combining WDAC/AppLocker with CLM, and restricting administrative privileges, fundamentally breaks the majority of these advanced execution techniques at their core.

    Prediction:

    We are entering a phase of “post-PowerShell” detection, where security controls will move away from trusting or untrusting a binary name. Instead, future EDR and SIEM systems will focus on cross-process lineage and code content analysis. We will see a rise in “kernel-level” PowerShell monitors that intercept calls to `System.Management.Automation.dll` directly, rather than monitoring user-mode processes. For attackers, the focus will shift to even deeper integration, potentially moving PowerShell execution completely into the kernel or exploiting new .NET runtime features. The weaponization of artificial intelligence to generate unique, on-the-fly AMSI bypasses and payloads will become commonplace, making signature-based detection nearly obsolete and forcing a shift towards heuristic and behavioral-based protection models at the lowest levels of the operating system.

    ▶️ Related Video (94% Match):

    🎯Let’s Practice For Free:

    IT/Security Reporter URL:

    Reported By: Jakehildreth We – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: