2018 - Chris Truncer

### Overview In this presentation, Chris Truncer explores PowerShell's Constrained Language Mode (CLM) and its role in locking down Windows environments. Designed to prevent attackers from executing arbitrary code, injecting shellcode (such as Cobalt Strike beacons or Meterpreter), or invoking dangerous Windows APIs, CLM strictly limits execution to a whitelist of approved .NET data types and core language constructs. Truncer examines the boundaries of what is allowed and blocked under CLM, how attackers can navigate or live off the land within these constraints, and how administrative features like Windows Defender management and custom data encoding can still be weaponized.

### Key Topics - **Mechanics of Constrained Language Mode**: How CLM restricts COM objects, the `Add-Type` cmdlet, dot-sourcing, type conversions, and non-whitelisted .NET data types, raising errors when unapproved method invocations are attempted. - **Enumerating Allowed Data Types**: Using documented MSDN lists and Matt Graeber's reflection one-liner (`[System.Management.Automation.PSObject].Assembly.GetType('System.Management.Automation.CoreTypes')`) to discover supported types, including undocumented types like CIM sessions. - **CLM and Application Whitelisting**: Why CLM must be paired with application whitelisting (such as Device Guard / Windows Defender Application Control) to be truly effective, as attackers could otherwise compile C# code into stand-alone executables. - **Offensive Living off the Land**: Administering antivirus settings and Attack Surface Reduction (ASR) rules via allowed cmdlets (`Get-MpPreference`, `Set-MpPreference`, `Add-MpPreference`) to disable protections remotely or whitelist malicious file extensions and paths. - **Pure PowerShell Tooling (WMImplant & CLM-Base64)**: Developing CLM-compliant tools, overcoming encoding restrictions (like the inability to use default base64 conversion methods), and implementing pure-PowerShell base64 encoding with custom alphabets.

### Technical Details Truncer demonstrates that benign mathematical operations like calculating square roots (`[Math]::Sqrt(9)`) or standard base64 encoding (`[Convert]::ToBase64String`) are blocked in CLM because their underlying .NET types and methods are restricted. However, administrative cmdlets and pure PowerShell constructs continue to function.

Using allowed types like `PSCredential` and CIM sessions over DCOM, Truncer demonstrates connecting to remote targets to inspect and alter Windows Defender configurations via `Get-MpPreference` and `Set-MpPreference`: - Querying and disabling specific Attack Surface Reduction (ASR) rules (identified by GUIDs, such as the rule blocking child processes spawned via WMI or PsExec). - Overwriting or appending exclusion rules, such as adding exclusion paths (`C:\temp`) or exclusion extensions (`.pdf`, `.exe`), effectively blinding Defender to payloads. - Spawning processes remotely via WMI (`Invoke-WmiMethod` with `Win32_Process`) once the blocking ASR rules were disabled.

To overcome the restriction on `[Convert]::ToBase64String` when building tools like WMImplant, Truncer details two solutions. First, a simple byte-to-integer conversion creating comma-separated decimal representations (developed with Daniel Bohannon). Second, a complete, pure-PowerShell base64 implementation (`CLM-Base64`) that manually divides 24-bit streams into 4 six-bit chunks, handles padding, supports alternate alphabets to evade automated analysis, and resolves base-2 to base-10 conversion limitations using a custom mathematical one-liner.

### Takeaways While CLM significantly limits attackers by breaking standard weaponized PowerShell scripts and payload stagers, it is intentionally built to permit system administration. Because administrative capabilities remain intact, an attacker with sufficient privileges can abuse built-in cmdlets and CIM sessions to disable defenses and modify configurations. Defensively, organizations must pair CLM with robust application whitelisting (Device Guard/WDAC) to prevent attackers from simply switching to compiled executables, and they must enable detailed telemetry to log and detect administrative actions abused for malicious intent.