Blocking Command Prompt and PowerShell in Corporate Networks
By CtrlOne Team ·
Command-line tools are a favorite of attackers because they are already installed, trusted, and capable of almost anything - downloading payloads, changing configurations, or moving through a network. On most user machines, ordinary employees never need them. Applying PowerShell restrictions and blocking Command Prompt closes a major avenue, but only if you avoid the common bypasses. Here is how to do it properly.
Why block CMD and PowerShell
'Living off the land' attacks abuse built-in tools like PowerShell to avoid dropping obvious malware. Because these tools are signed and trusted, they slip past defenses that watch for unknown executables. For the average user who never touches a command line, blocking them removes a powerful capability from anyone who compromises the account.
The native methods
Windows offers several partial controls, each addressing part of the problem:
- Group Policy 'Prevent access to the command prompt' (the DisableCMD value).
- PowerShell Constrained Language Mode, which sharply limits what scripts can do.
- AppLocker or WDAC rules that block the shell executables outright.
- Execution policy - useful for controlling script sources, but not a security boundary on its own.
The gotchas that trip teams up
This is where many blocks fail. There is more than one shell: cmd.exe, powershell.exe, the PowerShell ISE, and the newer cross-platform pwsh.exe all need to be considered. Blocking one and forgetting the others leaves the door open. Execution policy is frequently mistaken for a security control when it is trivially bypassed. A partial block gives a false sense of safety.
A complete approach
Doing this well means covering every shell surface, combining UI blocking with execution-level controls like Constrained Language Mode and application control, and confirming the block actually holds on each machine - not just assuming the policy applied. Anything less leaves a gap that a motivated user or attacker can find.
Enforcing shell restrictions with CtrlOne
CtrlOne handles Command Prompt and PowerShell restrictions as managed controls that account for the multiple shell surfaces, applied across the fleet from one console and kept tamper-resistant. You turn the restriction on and it is enforced consistently, closing the bypasses that catch hand-rolled Group Policy configurations.
Frequently asked questions
How do I block PowerShell and Command Prompt in Windows?
Combine several controls: the 'Prevent access to the command prompt' policy for CMD, PowerShell Constrained Language Mode, and AppLocker or WDAC rules that block the shell executables. Crucially, cover every shell - cmd.exe, powershell.exe, the ISE, and pwsh.exe.
Is PowerShell execution policy a security control?
No. Execution policy helps manage which scripts run by default, but it is easily bypassed and was never intended as a security boundary. Real PowerShell restrictions rely on Constrained Language Mode, application control, and blocking the executables.
Why do command-line blocks often fail?
Because teams block one shell and miss the others - cmd.exe, powershell.exe, the ISE, and pwsh.exe - or rely on execution policy alone. A complete block covers every shell surface and confirms enforcement on each machine.
Close the command-line gap
See how CtrlOne blocks every shell surface across your fleet from one console.