0

Is it possible to allow running of PowerShell scripts, (which we have controlled via AppLocker) but completely forbid the use of an interactive PowerShell prompt?

Ideas I've tried:

  1. AppLocker. We do use AppLocker / similar extensively, but allowing C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe to run is required in order for scripting to work, so we cannot block that, which then allows PowerShell to be ran interactively.
  2. PowerShell profiles. A PowerShell profile can run commands on starting a session, so could acheive this, but profiles are easily bypassed with -NoProfile
  3. Powershell PSSessionConfiguration. PowerShell does have "PSSessionConfiguration" settings which allow you to restrict PowerShell as much as you want. I attempted to use this to create a config that ran in "NoLanguage" mode, and only allowed one useless commandlet, but it appears PSSessionConfiguration's are only used for remote connections, and you cannot force a local PowerShell prompt to use them.
  4. Hide EntryPoints to PowerShell.exe. Yes, we do already make it so users cannot use the start menu search, cannot browse the C: drive, etc, etc. However, clever users can still attempt to launch any exe they know exists using other applications such as excel to create a link to the exe's known location, or similar workarounds such as that.

Background:
Our use case is running a Windows VM in a very locked down environment, (think inside prisons, etc) where we assume the user is the primary adversary, and we want to prevent the user from doing anything harmful or even gathering information about the system. We have the system very locked down through a far-too-strict use of AppLocker, and it works quite well.

The problem stems from we have some software which behind the scenes, runs some PowerShell scripts as the user upon login. We need those to continue to work, but we want to prevent the user from being able to run their own scripts, or be able to use PowerShell at all interactively.

We are not worried about allowing Powershell scripts to run, as which scripts are ran is tightly controlled by script signing & AppLocker only allowing specific scripts to run.

Is there any supported way to prevent the user from using PowerShell, while still allowing scripts? Any unsupported way?

3
  • 1
    Have you tried adding a Deny ACE on C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe and C:\Windows\SYSWOW64\WindowsPowerShell\v1.0\powershell.exe for the Interactive identity? Commented May 15 at 21:22
  • @Greg Askew, Thanks, that was a really good idea, unfortunately, it did not work. Commented May 22 at 18:16
  • You can't, but that's OK because it won't improve your security posture anyway. Just because someone can run PowerShell does not mean they can somehow bypass security. Another way to say this: PowerShell is a program, not a security boundary. Commented Jun 18 at 18:59

1 Answer 1

1

There's no way to allow logon scripts (runnnig as user) and at the same time block interactive usage of powershell. There are some tricks I can think of to achieve almost the same: you could use scripts that get triggered by user logon but run as system account and execute certain things based on which user logged on (i.e. write to that very users profile folder or HKU registry branch) or install a scheduled task that will get triggered whenever powershell.exe is started (audit file access using ntfs auditing then trigger the task from the event that ntfs auditing generates) and simply kill any window with powershell as part of its window title. TASKKILL /FI "windowtitle eq windows powershell" and TASKKILL /FI "windowtitle eq c:\windows\system32\cmd.exe - powershell". I hope that when logon scripts run (which run windowless, by default), no windowtitle will be accessible so they won't get killed, too.

1
  • Thanks, the more I investigate this, the more I think you're correct, and there is no (clean) way to do this. I'll accept your answer as correct after I do some more research, and don't find any other solutions. Commented May 22 at 18:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.