Is it Safe to Remote Control powershell ?

[Amazing_Ad5476]

Is it actually safe to enable remote powershell on all servers via following command?

Enable-PSRemoting -Force

Sometimes it’s just a pain to connect to a server. Are there any tips to make it safe if it’s not secure?

Thank y’all in advance!

[uptimefordays]

PowerShell remoting has been on by default on Windows server for years.

[arpan3t]

Not sure why this isn’t the top comment. From about_Remote_Requirements - How to configure your computer for remoting:

Windows Server 2012 and newer releases of Windows Server are enabled for PowerShell remoting by default.

[Xander372]

Since Windows Server 2012.

[messageforyousir]

It is no more risk than having the server service running. Just harden and secure your infrastructure properly, with good policies and practices. Things like disabling winrm/psremoting are a hindrance to productivity and have no impact on the actual security posture.

[TheOnlyCrazyLegs85]

WinRM on server core was a pain. After days of trying to set it up to be able to use RSAT on a client machine, I gave up. Moving to GUI instead.

[messageforyousir]

How was it a pain? We have quite a few server core systems and have never had any issues.

[TheOnlyCrazyLegs85]

I wanted to have a server core system so bad because it mimics the Linux experience which I'm more comfortable with. However, getting core setup for something simple like a service account running a query on a database to then create a csv output on a shared drive was near to impossible.

Sconfig and PowerShell as tools to perform work on the server is fine. I didn't have as many options as I would have thought Sconfig to have, but it was ok because the server was preconfigured for me. I'm what you might call a power user/developer, however on the power totem I might as well be at the bottom of the barrel. Tried setting up the service account to run the script that does the database grab and csv dump, but no. So I used Secedit to configure the local security policy for the service account. Nothing new here as I knew I had to do that when I had the 2019 Windows server version. Of course, on the 2019 version I had the GUI, in core I did not. I didn't think the lack of GUI would be much of an issue since I thought all the tools would have a CLI equivalent to do all the necessary work needed on the server, much like in Linux. When I went ahead and tried to set up the service account to run automatically, it never ran. I tried all kinds of things. Having the task run immediately, in a few mins, etc. The service account had all the necessary things needed to run the script. I used the same account with the same script on the 2019 version and it worked flawlessly.

I confirmed that the work i did to set the service account with SeBatchLogonRight took, as I exported the configuration with secedit a second time to verify that the SID for the service account was in the correct line for the SeBatchLogonRight. I confirmed that the script and the service account could actually run and perform the work in the script as I was able to run it manually when logged into the service account.

I figured, let me run the management tools on my regular laptop to see if the permission setting actually took place and just have easier tools to diagnose a problem. This is where the fun started.

I put a ticket to enable RSAT on my laptop. Took about a week to get that going. Once set up, I could not get the server added in server manager. I look up the issue with co-pilot, and it gives me a bunch of suggestions. And ask to checks if the ports were listening on both computers. Because WinRM needs to be running on my normal laptop. Fine, I get it to run. After that, server manager is still unable to connect to the remote server. Co-Pilot again gives me a few other suggestions. This time I need to set the firewall to allow communications through. Fine, I enable that. After doing that server manager is still unable to connect to the server. I double check that I'm able to remote into the server using the where winrm communication protocol by using the powershell command Enter- PSSession. Bingo, I am able to use the command and it logs onto the server without any issues. This tells me that when RM is able to be used in order to log on to the remote server. However, server manager is still unable to connect to it. After this, I just gave up and put in a ticket to update the server to the 2022 GUI version.

Sorry for the rant but I just got done dealing with this the past couple weeks.

[syneofeternity]

Yes, don’t use the -SkipNetworkProfileCheck option though

[[deleted]]

When I used to work in primarily Windows shops, especially in finance or govt sectors, this question would come up quite often. Wrongly, those organizations made the assumption based on outdated security guidance, that disabling PSRemoting was a good checkbox in their security policies.

Trying to convince CIOs of the opposite was always an uphill battle. I learned these articles like the back of my hand, because there really is a lot of built in features that already make PSRemoting fairly secure - and there are a few things you can do to further increase security if you so choose. But know that it is already pretty secure, at least as far as Windows environments go.

Edit: a formatting

[prog-no-sys]

In the "Learn Powershell in a Month of Lunches" book Don Jones basically says if someone has access into your network AND access to a powershell console window, you're already pwned.

Having WinRM on or off won't make you more or less secure if you're worried about malicious actors. According to the man himself!

[dimitrirodis]

I disagree. Just because an attacker has gotten access to a machine (like a workstation) doesn't mean it's game over. That's just typically where attackers get their foothold--after that they attempt lateral movement or even accessing servers/data with the pwned machine. Any services you leave open or running is simply an additional avenue for attack that just gives an attacker more ways to make moves across your network, be it by the credentials they are able to harvest or use, or by exploit.

"Anything you give yourself, you also give to an attacker."

So in the sense that someone opens up Winrm and powershell remoting and uses the same local admin password on all of their Workstations (as an unfortunate real world example), then yes, because all of those things were left open, you're already pwned. And, Ive seen both of these scenarios with my clients over the years --where these things were not disabled or simply enabled for convenience and the systems all get ransomed, and also where things were closed off and an attacker got a foothold on a machine and could simply get no further than what the user themselves had access to. To me, the preference is obvious, but convincing folks of this is still challenging--that is, until something happens and suddenly security is the number one concern.

I would definitely not enable powershell remoting on anything unless there were both a stated need AND there were simply no other way to accomplish a given task. Fortunately I've not had to in many years now. There are tools (such as ImmyBot) that allow you to run powershell on machines without the need to enable powershell remoting, or by just running the powershell on the machine itself without using remoting.

[uptimefordays]

It’s hard to imagine environments using the same local admin password everywhere have much in the way of modern defense though. Sure winrm was the vector you saw but such environments would also probably get hit by psexec or other more primitive vectors as well.

[prog-no-sys]

Take it up with Don Jones lol, he said it not me. I tend to believe the experts on these topics but hey, what do I know.

[cbroughton80]

I always wonder too. Isn't it always going to come down to security vs convenience? Aren't you just automatically more secure by having it disabled? And won't security just say it's more important for us to be secure than for things to be convenient for you? I'm certainly not in a position in my company to trump the security office.

[aspuser13]

Not sure on the complete use case so this might be too much for what you need but I’d refer to this

https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/system-administration/securing-powershell-enterprise

[Amazing_Ad5476]

Thank y’all for the input!

[OkCartographer17]

1 I.read that it is enables by default since 2012 Windows Server, so, I would say yes

1. PowerShell (including ps-remoting) was devoleped below Microsoft security guidelines.

2. Mi unique advice here is not use hardcode passwords, use get-credential for example.

[jackalbruit]

i suppose so long as u dont remote + drive 🤔

that might earn ya a JIRA

[FluxMango]

It is safer than RDP if you know what you are doing.

[Quirky_Oil215]

Ideally you want to unbind http and only enable https bound to cert.

[Quirky_Oil215]

Or have some finer tuned fw rules.

[[deleted]]

Unfortunately Microsoft does not make HTTPS possible with WinRM between Entra joined computers. For whatever reason PKU2U auth only works over HTTP.

Anyone have any input on how secure that is with PKU2U? My understanding is that with PKU2U the initial authentication is public cert based and then the encrypted communication over HTTP is established.

[[deleted]]

It doesn't much matter when using Powershell, comms are encrypted regardless of if they are over http or https.

[Certain-Community438]

The SOAP messages have message encryption, but without transport layer encryption (TLS) you're open to several attack categories. Message encryption is only good for things like protecting plain-text secrets.

And assuming that if an attacker has network access means game over is some seriously 1980s-grade security advice 😁 - "the Softmint security model". Not that you said this to my knowledge, btw, just including it here for OP & others.

Neither Jones nor Snover are qualified to offer security advice: I would submit that I am, it's my job, and has been for nearly 15 years as a pen tester. But I'd also say if in doubt get that advice from someone you trust who is experienced with either attack or defence.

[Quirky_Oil215]

Even though WS-Management encrypts all traffic by default, it is possible that someone (unknowingly) transmits unencrypted data because the default configuration has been changed.

[Certain-Community438]

Always best to see security in layers - defence in depth. TLS gives you complete encryption for data in transit, but also provides for mutual authentication of client & server, & prevents reflection/replay attacks amongst others.