INTUNE-POwershell block RRS feed

  • Question

  • We are moving towards the modern management and deploying apps via INTUNE and i have a request to create an Intune-Applocker policy to disable %SYSTEM32%\Windows\PowerShell\* for all users and exclude administrators. 

    Question is if i block powershell, will the powershell Win32 apps and script deployed via INTUNE will also be blocked ?

    Sunday, October 18, 2020 10:47 PM

All replies

  • My favorite question is.... What's the real problem?

    That is, what are you trying to accomplish by blocking Powershell? Do you already block VBscript? Bat files? Do you block all the executables in System32 that could be used in place of a Powershell call? If Office is installed, do you block macros? Because users can write VBA code to make system level calls. Do you block vbc.exe in the C:\Windows\Microsoft.NET folders? Users can compile DotNet programs with it. 

    It seems to me that you might want to encourage developers and powers users to use Powershell to automate/augment business processes.  

    Just my thoughts... 

    Monday, October 19, 2020 1:14 AM
  • Hi 

    We are blocking registry, Command prompt and Powershell for the end users as per Security requirement 

    Asof now the requirement is only to Block these three and i am concerned that if i block powershell, then the Win32 apps deployed will also be affected 

    Monday, October 19, 2020 7:12 AM
  • i am concerned that if i block powershell, then the Win32 apps deployed will also be affected 

    That would be my concern as well. Who is asking you to do this? Is it a security expert who can provide a logical, technical explanation of the vulnerability or is it some manager who read an article on some web site and doesn't fully understand the implication of what he's requesting? 

    Sorry to be a pain, but in the course of 35+ years of computer support, I've seen this too many times. 

    If this request sounds reasonable, or if you are forced to do it, I would start by taking several test workstations and enable Powershell logging. https://sid-500.com/2017/08/16/monitoring-windows-powershell-enable-module-logging Let the user do their normal work for a few days, and also test out installing Windows updates. 

    I'm not sure which of those gpedit settings would work best. You'll have to test. You could also enable process auditing. 

    Then review the logs to see if anything if being invoked by the user's account.  You might see accounts like TrustedInstaller and System invoking PS. That should help you define the accounts that require access. 

    Good luck.  

    Update: I had another thought.. here's a trick that you might be able to use... Ask the person making the request to provide a link to a Microsoft approved document that describes how to properly secure Powershell. Focus on addressing the vulnerability that Powershell exposes, not Powershell itself. 




    • Edited by MotoX80 Monday, October 19, 2020 2:46 PM
    Monday, October 19, 2020 1:49 PM