In our current workflow, we have to RDP to several servers just to know if a service is up-and-running. We do not have admin rights to those servers but are allowed to view, start and stop services.

We would like to use Powershell Remoting instead. Something like

 (1..8)|%{gsv -c "server$($_" -n "*ourservice*"}

would be both easier and faster to do.

Am I correct that by adding our users to the WinRMRemoteWMIUsers group

  • We can execute the command (our concern).
  • We can't do anything to the system we couldn't be doing right now by just by RDP'ing to it (security management's concern).


Following extract taken from Secrects of Powershell Remoting seems to addres the security concerns

powershellorg · Secrets of PowerShell Remoting

Neither PowerShell nor Remoting are a "Back Door" for Malware

This is a major misconception. Keep in mind that, by default, PowerShell does not execute scripts. When it does so, it can only execute commands that the executing user has permission to run - it does not execute anything under a super-privileged account, and it bypasses neither existing permissions nor security.


Bottom line: Because of the way it works, PowerShell Remoting does not allow any user, authorized or not, to do anything that they could not do through a dozen other means

  • Since you can RDP to those servers don't you have enough privileges to setup a scheduled tasks that would periodically check the service status, then send some kind of alert on a failure? – Zoredache Oct 29 '15 at 17:09

We can't do anything to the system we couldn't be doing right now by just by RDP'ing to it (security management's concern).

The risk is an attacker may have access via PowerShell if an account in that group is compromised. Evaluating the risk of that access and the compensating controls is something you need to determine based on your environment.

To answer your followup, I don't believe anyone can provide a general assumption/conclusion that the account could also logon using RDP. If the account/server(s) is configured for smartcard required, no they could not logon using RDP.

Security is about assessing risk and implementing compensating controls. A constructive counter proposal may be to suggest:

  • Use the firewall to limit network access for PowerShell Remoting to specific administrative computers/jump hosts (tcp/5985 and/or tcp/5986).
  • Use Group Policy to limit/enforce the membership of WinRMRemoteWMIUsers to specific domain groups.
  • Only allow authorized accounts membership in those specific domain groups.
  • Implement auditing of PowerShell/WinRM/WinRS activity, and ship/include those event logs in the events the security team sends back to the central event log collector (assuming that they do this). The builtin event logs for PowerShell and WinRM are actually pretty weak in this regard, but you can use SysInternals SysMon for this. Here is a sample:

PowerShell Remoting sample event commandline:

SysMon PSRemote Audit

WinRS sample event commandline:

SysMon WinRS Audit

  • True but if an account in that group is compromised, the attacker can just as wel RDP into the server?! – Lieven Keersmaekers Oct 29 '15 at 12:53
  • You still determine acceptable risk by evaluating the security vulnerability in the same way. Greg was really trying to give you the process to figure this out as it's not something anyone outside your organization can determine for you. – Colyn1337 Oct 29 '15 at 14:03
  • 1
    @Colyn1337 - If I sounded pedantic, apologies, that wasn't my intention. Nevertheless, in that case I believe I am in a no-win scenario. All I can bring to the table is how much easier it would make our work but it's beyond my scope and knowledge to correctly assess the risk involved. The people that could allow the change on the other hand have nothing to gain from it so why would they. Frustrating... – Lieven Keersmaekers Oct 29 '15 at 14:23
  • @LievenKeersmaekers: I added some information to the answer – Greg Askew Oct 29 '15 at 17:17
  • @GregAskew - Thanks for a detailed answer Greg. As using procmon/procexp is currently also being questioned (on other servers) to troubleshoot problems, I doubt sysmon will get installed but good to know if (the lack of) monitoring comes into play. – Lieven Keersmaekers Oct 30 '15 at 6:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.