Listen to this Post
Introduction:
Constrained Language Mode (CLM) is a PowerShell execution restriction that cripples most post-exploitation tradecraft—blocking reflective DLL injection, arbitrary .NET loading, and COM object abuse. Yet despite being a free, native Windows security control documented for years, organizations routinely avoid enabling it because legacy scripts break unpredictably. This article dissects how CLM neutralizes MITRE ATT&CK techniques T1059.001, T1027, T1055.001, and T1218.005, then provides a step-by-step deployment and hardening guide to overcome the “rollout fear” that keeps attackers’ shells alive.
Learning Objectives:
- Understand how Constrained Language Mode blocks PowerShell-based attack vectors including Empire stagers, AMSI patches, and reflective injection.
- Implement WDAC script policies and CLM enforcement across Windows endpoints using Group Policy and PowerShell commands.
- Audit and remediate incompatible scripts, apply bypass monitoring, and integrate CLM with existing EDR/SIEM solutions.
You Should Know
- Enforcing Constrained Language Mode via WDAC Script Policy
Extended explanation:
The post correctly notes that CLM alone is insufficient without a proper Windows Defender Application Control (WDAC) script policy. WDAC locks down which scripts, modules, and PowerShell commands can run, while CLM restricts the language elements available to those scripts. Attackers bypassing CLM typically rely on unconstrained full language from trusted publishers—WDAC removes that loophole.
Step‑by‑step guide to deploy CLM + WDAC:
- Audit current PowerShell usage – Run this to identify scripts using blocked features (Add-Type, reflection, COM):
Get-ChildItem -Path C:\Scripts -Recurse -Filter .ps1 | ForEach-Object { $content = Get-Content $<em>.FullName -Raw if ($content -match 'Add-Type|[Reflection.Assembly]|New-Object -ComObject|Invoke-Expression') { Write-Host "Potentially incompatible: $($</em>.FullName)" } } -
Enable Constrained Language Mode via registry (no WDAC required but less effective):
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine" -Name "PSConstrainedLanguage" -Value 1 -Type DWord
-
Deploy WDAC base policy – Generate a policy from a reference machine in audit mode:
On clean reference system $Policy = New-CIPolicy -Level Publisher -FilePath C:\WDAC\BasePolicy.xml -UserPEs Convert to binary ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\BasePolicy.xml -BinaryFilePath C:\WDAC\BasePolicy.bin
-
Apply the policy via Group Policy: Copy `BasePolicy.bin` to
%SystemRoot%\System32\CodeIntegrity\CiPolicies\Active. Run `gpupdate /force` and reboot.
5. Test CLM behavior – After deployment, verify:
$ExecutionContext.SessionState.LanguageMode Should output "ConstrainedLanguage"
Linux comparison: Similar restrictions exist with `rbash` (restricted Bash) or Firejail profiles, though less granular than CLM.
2. Bypass Detection: Monitoring Attempts to Escape CLM
Extended explanation:
Attackers will try to disable CLM by killing the PowerShell process, injecting into a new unconstrained runspace, or exploiting WDAC policy refresh race conditions. Monitoring for these attempts requires event logging and real-time alerting.
Step‑by‑step guide for CLM bypass detection:
- Enable PowerShell script block logging (Group Policy: Admin Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging).
-
Monitor Event ID 4104 (script block) and Event ID 4105 (CLM enforcement status). Use this `Get-WinEvent` query:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} | Where-Object {$_.Message -match 'ConstrainedLanguage|FullLanguage'} -
Detect attempts to modify WDAC policy – Enable Code Integrity operational logs:
wevtutil set-log Microsoft-Windows-CodeIntegrity/Operational /enabled:true
Alert on Event ID 3076 (policy refresh attempt) and 3077 (policy load failure).
-
Harden against runspace injection – Block creation of new runspaces with full language by setting `$host.Runspace.LanguageMode` readonly via constrained endpoint configuration:
$session = New-PSSessionConfigurationFile -Path C:\Configs\ConstrainedEndpoint.pssc -LanguageMode ConstrainedLanguage Register-PSSessionConfiguration -Name ConstrainedEndpoint -Path C:\Configs\ConstrainedEndpoint.pssc -Force
-
Integrate with SIEM – Forward events to Splunk/ELK with this sample logstash filter:
if [bash] == 4104 and [bash] =~ /LanguageMode.Full/ { add_tag => ["clm_bypass_attempt"] }
What fails in CLM: Empire’s Invoke-Shellcode, Cobalt Strike’s execute-assembly, any AMSI bypass relying on reflection (e.g., [Runtime.InteropServices.Marshal]::WriteByte). Verified: All common loader patterns die.
3. Hardening COM Object Allowlists for CLM Compatibility
Extended explanation:
CLM does not block all COM objects – only those outside an approved list. Attackers can still use WScript.Shell, Shell.Application, or `ScriptControl` for limited execution. You must explicitly deny dangerous COM objects via WDAC or AppLocker.
Step‑by‑step guide:
1. Identify dangerous COM objects commonly abused:
– `WScript.Shell` (execute commands)
– `Shell.Application` (launch executables)
– `ScriptControl` (run VBScript)
– `Msxml2.XMLHTTP` (download files)
- Block via AppLocker DLL rules (Windows 10/11 Enterprise): Create a rule to deny `%SystemRoot%\System32\wshom.ocx` (WScript.Shell).
-
Or use WDAC COM allowlist policy – Export allowed COM CLSIDs from a reference system:
Get-CimInstance -ClassName Win32_COMSetting | Select-Object -ExpandProperty CLSID | Out-File C:\WDAC\AllowedCOM.txt
Then create a WDAC policy with `-DenyCOMObjects notInAllowedList`.
-
Test COM restriction impact – Run a PowerShell command under CLM:
$com = New-Object -ComObject WScript.Shell Expect: "Cannot create COM object. ConstrainedLanguage mode restricts this operation."
-
Windows hardening also applies to signed MSHTA (T1218.005) – CLM blocks `mshta.exe` from invoking arbitrary script unless signed by an allowed publisher. Verify by trying:
mshta javascript:"alert('test')"Under CLM + WDAC, this fails unless the MSHTA binary has a valid signature in the policy.
Linux analogy: Use AppArmor or SELinux to confine wget, curl, and interpreter execution – similar to COM allowlisting.
4. Remediating Legacy Scripts That Break Under CLM
Extended explanation:
The post’s core pain point: “The helpdesk runbook nobody owns. PowerShell Bob wrote in 2014.” Most incompatibilities arise from `Add-Type` compilation, direct .NET loading, or dynamic assembly generation. Rewrite these patterns without reflection.
Step‑by‑step remediation guide:
- Replace Add-Type with inline C alternatives – Instead of:
Add-Type -TypeDefinition "public class Calc { public static int Add(int a, int b) { return a+b; } }"
Use pure PowerShell:
function Add($a,$b) { return $a + $b }
- Remove `[Reflection.Assembly]::Load` – If loading a custom DLL, convert to a PowerShell module (
.psm1) or use `Import-Module -FullyQualifiedName` when safe. -
Replace COM objects with native cmdlets – Example: `New-Object -ComObject WScript.Shell` → `Start-Process` for command execution:
Instead of $com.Run("calc.exe") Start-Process calc.exe -NoNewWindow -
Migrate Invoke-Expression to script blocks – `Invoke-Expression $userInput` is blocked. Use safe evaluation:
$scriptBlock = [bash]::Create($userInput) & $scriptBlock Still risky but allowed under CLM if no reflection inside
-
Test all scripts in audit mode first – Enable CLM but set WDAC to audit only:
Set-RuleOption -FilePath C:\WDAC\BasePolicy.xml -Option 3 Audit mode ConvertFrom-CIPolicy -XmlFilePath C:\WDAC\BasePolicy.xml -BinaryFilePath C:\WDAC\BasePolicy.bin
Review CodeIntegrity event log for blocked operations without breaking production.
Windows command to check compatibility after changes:
$PSVersionTable.PSCompatibleVersions
Get-Command -Module MyModule | Where-Object {$_.Visibility -ne 'Public'}
- Combining CLM with AMSI and Antimalware Scan Interface
Extended explanation:
CLM blocks the most common AMSI bypass techniques (patching amsi.dll, reflective injection into scanning functions). However, an unconstrained PowerShell process elsewhere can still bypass AMSI. Lock down all PowerShell hosts (ISE, VS Code’s integrated terminal) via WDAC.
Step‑by‑step integration:
- Verify AMSI is active under CLM – Run this in a constrained session:
Error: "Cannot load assembly because ConstrainedLanguage mode prohibits reflective loading."
The AMSI bypass attempt fails before reaching the scanning layer.
-
Enforce CLM on ALL PowerShell hosts – Not just `powershell.exe` but also
pwsh.exe,powershell_ise.exe, and Visual Studio’s PowerShell tools. Use WDAC to apply the same script policy to:C:\Program Files\PowerShell\7\pwsh.exe C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe
-
Configure AMSI logging – Set Group Policy: Admin Templates → Windows Components → Windows Defender Antivirus → Scan → Enable AMSI for PowerShell. Event ID 1116 in Windows Defender Operational log records AMSI detections.
-
Test a known malicious pattern – Use safe test string (no actual harm):
"amsiUtils" -match "amsi" Triggers no alert Attackers would try "Invoke-ReflectivePEInjection" – CLM blocks before AMSI inspects.
-
Complement with antivirus – Windows Defender’s real-time protection catches what AMSI+CLM miss. Verify via:
Get-MpComputerStatus | select AMServiceEnabled, RealTimeProtectionEnabled
Cloud hardening corollary: Azure Automation accounts can enforce CLM via `DisablePowerShellCustomization` – similar to on-prem.
6. Monitoring CLM Rollouts with SIEM Queries
Extended explanation:
To answer “Why aren’t you running it today?” – you need visibility. Build dashboards showing which endpoints have CLM active, which scripts are blocked, and which users attempt bypasses.
Step‑by‑step monitoring setup (Splunk examples):
- Collect PowerShell event logs via Universal Forwarder. Add this input config:
[WinEventLog://Microsoft-Windows-PowerShell/Operational] disabled = false renderXml = true
-
Search for CLM status changes (Event ID 4097, LanguageMode change):
index=windows source="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventID=4097 | rex field=Message "LanguageMode:\s(?<LanguageMode>\w+)" | stats count by LanguageMode, ComputerName
-
Alert on FullLanguageMode appearing – Any PowerShell session not in CLM is suspicious:
index=windows EventID=4097 LanguageMode=FullLanguage | eval severity="high" | table _time, ComputerName, User, Message
-
Track blocked script executions (WDAC Event ID 3076 violation):
index=windows source="Microsoft-Windows-CodeIntegrity/Operational" EventID=3076 | rex field=Message "Script\s+'?(?<ScriptPath>[^']+)'?" | stats count by ScriptPath, ComputerName
-
Create a “CLM Coverage” report – Endpoints missing the registry key or WDAC policy file:
Inventory script $clmEnabled = Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine" -Name "PSConstrainedLanguage" -ErrorAction SilentlyContinue $wdacPresent = Test-Path "C:\Windows\System32\CodeIntegrity\CiPolicies\Active.bin" [bash]@{ Computer = $env:COMPUTERNAME; CLM = $clmEnabled.PSConstrainedLanguage -eq 1; WDAC = $wdacPresent }
Linux parallel: Monitor for restricted shells via `auditd` rules on `/etc/passwd` shell fields.
- Vulnerability Exploitation Mitigation: CLM vs. T1055.001 Reflective Injection
Extended explanation:
Reflective DLL injection (T1055.001) relies on dynamically loading a DLL from memory without touching disk. Attackers execute it via PowerShell using [Reflection.Assembly]::Load. CLM blocks the `Load` method entirely, but what about injected processes like rundll32.exe? You must pair CLM with process mitigation policies.
Step‑by‑step mitigation for reflective injection:
- Simulate an attacker’s reflective loader (educational use only):
Under FullLanguage mode – this would work $bytes = [System.IO.File]::ReadAllBytes("C:\malicious.dll")Under CLM, you receive: “Cannot load assembly because loading from byte arrays is not allowed in ConstrainedLanguage mode.”
-
Prevent rundll32.exe from loading unsigned code – Use Windows Defender Exploit Guard (ASR rules):
Add-MpPreference -AttackSurfaceReductionRules_Ids 3B576869-A4EC-4529-8536-B80A7769E899 -AttackSurfaceReductionRules_Actions Enabled
Rule 3B576869 blocks `rundll32.exe` from executing untrusted content.
-
Enable process mitigation for PowerShell – Disable Win32k system calls and child processes:
Set-ProcessMitigation -Name powershell.exe -DisableWin32kSystemCalls Enable -DisallowChildProcessCreation Enable
-
Test mitigation effectiveness – Try to inject into a new process under CLM:
This reflective injection pattern fails gracefully $bytes = [System.Convert]::FromBase64String("TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAA...") Add-Type -TypeDefinition "using System; public class Test {}" Also fails -
Monitor Sysmon Event ID 7 (image loaded) for unexpected DLL loads from non‑standard paths (e.g.,
C:\Users\Public\.dll).
Cloud hardening: Azure VM’s Guest Configuration can enforce CLM + WDAC at scale via Azure Policy for Windows Server.
What Undercode Say:
- Key Takeaway 1: Constrained Language Mode is not a theoretical control – it demonstrably kills Empire, Cobalt Strike, and custom .NET loaders. The only blocker is organizational fear of breaking legacy scripts.
- Key Takeaway 2: Successful CLM deployment requires a phased audit-and-remediate approach, not a flip-the-switch rollout. Monitor with SIEM, rewrite incompatible patterns, and combine with WDAC and AMSI for defense in depth.
Analysis:
The post nails the core paradox: security teams know CLM works, yet attackers still get unconstrained shells. Why? Because PowerShell’s flexibility is also its curse – Bob’s 2014 script with `Add-Type` and reflection is still running Finance’s critical report. The solution isn’t technical (CLM is already free and native); it’s process. Start by running `$ExecutionContext.SessionState.LanguageMode` on every server today. Then put one non‑critical script under audit mode next week. Over six months, remediate the top five breaking patterns. Attackers don’t wait for your change board; neither should you.
Prediction:
By 2027, Microsoft will deprecate FullLanguage mode in Windows default installations, forcing CLM as the baseline for all non‑administrative PowerShell sessions. This will mirror the shift from SHA-1 to SHA-2 – painful for legacy apps but inevitable. Organizations that start remediation now will avoid the 2027 “CLM Tuesday” fire drill, while those that don’t will face emergency script rewrites amid active breaches. The attackers already know their PowerShell loaders expire in 18 months; your detection team should too.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Michaelahaag Constrained – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
