I'm tasked with fully disabling PowerShell and CMD unless they're running with elevated permissions, but I'm unsure if this is the right move. Currently, we only permit signed scripts, and we have Sophos agents with default settings across all devices. CMD is disabled for regular users via Intune configuration. I'm considering implementing Controlled Folder Access (CLM) for PowerShell through Defender as an additional protection layer. The goal is to guard against unauthorized actions from users who don't have admin privileges, aiming to prevent technically skilled users from circumventing our Intune policies and misusing the devices.
There's a real concern about malicious actors who might have access to our devices, though these users are monitored 24/7 and are employed by us, so I'm not overly worried. I believe that if someone is malicious and has unsupervised access long enough, they'll eventually find a way around the protections we set, but I'm open to correction on that.
My main question is whether implementing CLM along with blocking CMD and using Sophos offers adequate security, or if disabling user-level PowerShell is necessary and worth the potential disruption it could cause.
5 Answers
Based on my experience, limiting PowerShell like you're suggesting could break things, especially with scripts deployed via Intune. I tried allowing only signed scripts, and it caused issues for user context scripts, making troubleshooting a nightmare!
I think blocking PowerShell and CMD is kind of a pointless effort. PowerShell is just a shell host, and with the right wrappers, attackers can still access it. Instead, consider using AppLocker policies to block access to PowerShell executables, but remember to allow it for IT and local admins. Just be cautious—blocking these tools might break essential automations that rely on PowerShell.
Don't forget about .NET compilers! Tools like csc.exe and vbc.exe are often overlooked but can be exploited too.
Blocking PowerShell and CMD actually doesn't necessarily improve security; it just makes troubleshooting harder. Remember, some applications may even require these tools to run properly, so it's worth considering.
It really boils down to your team's specific needs. In my business, blocking something like PowerShell or CMD would create chaos since we have many automations that rely on them, including batch files for simulations. I lean towards an 'assume breach' strategy—limit access to only what users genuinely need, and continuously segment your network. PowerShell also has a built-in Execution Policy set to 'restricted' for regular users, so they're forced to change it explicitly.
Totally! Most of the risky actions they can do in PowerShell can also be executed through the GUI. As long as they can't run as admin, they should be mostly contained.