Securing PowerShell On Your Domain

I realize this question isn’t just about PowerShell, but moreso about securing/deploying PowerShell on a domain, but it’s purpose is to get information from experienced PowerShell users who may have experience in this piece of IT/Domain management.

So, I have been looking for some quality references on securing PowerShell in your domain. I have found a pretty mixed bag on it… >:\ Just some pre-qualifiers, I help manage a edu(K-12) domain. All of our Techs have regular account as well as privileged accounts, primarily for local PC admin stuff. I have the same as well as a domain admin account. My goal is to make it so admin accounts have the ability for execute remote scripts and sessions on staff and student PC’s, however I’m not sure of the security risks involved and the recommended way to do such a thing.

I would like to consider enabling WinRM on all of our staff and student PC’s so I can to remote script execution and installs via PowerShell. Some of the naysayers suggest it’s a huge security vulnerability. Once I started researching more on this I found an overwhelming amount of information that was very “general” and on both sides of the fence…

Does anyone have any quality references I can review for such a thing.

Thanks in advance.

https://www.youtube.com/channel/UCxgrI58XiKnDDByjhRJs5fg

and

https://www.youtube.com/user/powershellorg

Both these YT channels contain several talks from the recent PS conferences in the US and EU that deal with security with PS. :slight_smile:

Have you looked at what other orgs are documeting / defining / recommending. For example, the DoD, specifically DISA, has docs called STIGs. They are the mandated guidance for the DoD on net worthiness (ATO - Authority to operate), security and accredatation. Many commercial enterprises I work in have taken all or parts of these docs for their needs.

‘iase.disa.mil/stigs/Pages/index.aspx’
stigviewer.com/stig/windows_10/2017-02-21/finding/V-68819

Every vendor trying to work with the FedGov/Dod/Intel sectors have to deal with these or somehting like them.

There have been public courseware on the topic for few years now. For example:

Securing Windows with PowerShell and the Critical Security Controls
sans.org/simulcast/details/sec505-mar-2016-jason-fossen/course/securing-windows-with-powershell

SEC505: Securing Windows and PowerShell Automation
sans.org/course/securing-windows-with-powershell

SANS Pen Test Cheat Sheet: PowerShell
pen-testing.sans.org/blog/2016/05/25/sans-powershell-cheat-sheet

Securing Windows and PowerShell Automation
niccs.us-cert.gov/training/search/sans-institute/securing-windows-powershell-and-critical-security-controls

Are you saying, that the below is far to general for you to consume and leverage, or are you loking for some industry SOP (standard operating proceedure) doc or template. Just like other GRC (Governance, Risk and Compliance) industry policies (GDPR, PCIDSS, etc…) this can a will vary per org / industry. YOu need to assess your org risk manamgent policies, stance before looking into wha tyiou can really do. Ohterwise, anything you review is just knowledge transfer / thought provoking stuff.

PowerShell Security at Enterprise Customers
blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers

Who’s afraid of PowerShell security?
blogs.technet.microsoft.com/ashleymcglone/2016/06/29/whos-afraid-of-powershell-security

PowerShell Remoting Security Considerations
docs.microsoft.com/en-us/powershell/scripting/setup/winrmsecurity?view=powershell-6
blogs.technet.microsoft.com/ashleymcglone/2017/04/12/powershell-remoting-and-kerberos-double-hop-old-problem-new-secure-solution
blogs.technet.microsoft.com/ashleymcglone/2016/08/30/powershell-remoting-kerberos-double-hop-solved-securely

Practical PowerShell Security: Enable Auditing and Logging with DSC
blogs.technet.microsoft.com/ashleymcglone/2017/03/29/practical-powershell-security-enable-auditing-and-logging-with-dsc

Script Tracing and Logging
docs.microsoft.com/en-us/powershell/wmf/5.0/audit_script

Greater Visibility Through PowerShell Logging
fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html

Windows PowerShell Securing the Shell
technet.microsoft.com/en-us/library/2007.09.powershell.aspx

PowerShell Security Best Practices
blogs.msdn.microsoft.com/powershell/2013/12/16/powershell-security-best-practices

Just Enough Administration: Windows PowerShell security controls help protect enterprise data
msdn.microsoft.com/en-us/library/dn896648.aspx

I never thought about the DoD/FedGov/DISA guidelines. This is good stuff! Thank you for the reference.

No worries, glad it gave you another option.
You could also look the other industry orgs (CERT, ISSA, ISC2, etc…) even some of the college.edu write ups.

I have created a GPO to enable powershell on our domain PC’s. I’m trying to make it more secure and I’m running into an issue with the following settings:
Browse to Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
Set the IPv4 and IPv6 filters to * unless you need something specific there (check out the help on the right).
When I use * in the IPv4 section, my policy works as expected. When I put in a specific IP address(i.e. my workstation IP address) in cannot connect to a New-PSSession on the target PC.
I have verified the connecting PC when using the * is my ip address by using the netstat -n command.
Any thoughts?

What is the error you are getting, the policy you have enabled is to add the destination node(s) to the trusted host list of the local machine.

Once I remove the specific IP address or address range and replace it all with the * it works like a charm.

PS C:\Windows\system32> New-PSSession -ComputerName Y35614

New-PSSession : [Y35614] Connecting to remote server Y35614 failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1

  • New-PSSession -ComputerName Y35614

  • 
    
  • CategoryInfo : OpenError: (System.Manageme…RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin

gTransportException

  • FullyQualifiedErrorId : WinRMOperationTimeout,PSSessionOpenFailed

 

 

Add hostname in the list or use the IP address to Invoke you have added in the policy.