Enable-PSRemoting
Enable-PSRemoting
This command configures the computer to receive remote commands.
The Enable-PSRemoting cmdlet configures the computer to receive Windows PowerShell remote commands that are sent.
to enable Windows PowerShell remoting on other supported versions of Windows
You need to run this command only once on each computer that will receive commands. You do not need to run it on computers that only send commands. Because the configuration activates listeners, it is prudent to run it only where it is needed.
To run this cmdlet, start Windows PowerShell with the “Run as administrator” option.
CAUTION: On systems that have both Windows PowerShell 3.0 and the Windows PowerShell 2.0 engine, do not use Windows PowerShell 2.0 to run the Enable-PSRemoting and Disable-PSRemoting cmdlets. The commands might appear to succeed, but the remoting is not configured correctly. Remote commands, and later attempts to enable and disable remoting, are likely to fail.
- In Windows PowerShell 3.0, Enable-PSRemoting creates the following firewall exceptions for WS-Management communications.On server versions of Windows, Enable-PSRemoting creates firewall rules for private and domain networks that allow remote access, and creates a firewall rule for public networks that allows remote access only from computers in the same local subnet.On client versions of Windows, Enable-PSRemoting in Windows PowerShell 3.0 creates firewall rules for private and domain networks that allow unrestricted remote access. To create a firewall rule for public networks that allows remote access from the same local subnet, use the SkipNetworkProfileCheckparameter.On client or server versions of Windows, to create a firewall rule for public networks that removes the local subnet restriction and allows remote access , use the Set-NetFirewallRule cmdlet in the NetSecurity module to run the following command:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any - In Windows PowerShell 2.0, Enable-PSRemoting creates the following firewall exceptions for WS-Management communications.On server versions of Windows, it creates firewall rules for all networks that allow remote access.On client versions of Windows, Enable-PSRemoting in Windows PowerShell 2.0 creates a firewall exception only for domain and private network locations. To minimize security risks, Enable-PSRemoting does not create a firewall rule for public networks on client versions of Windows. When the current network location is public, Enable-PSRemoting returns the following message: “Unable to check the status of the firewall.”
- Beginning in Windows PowerShell 3.0, Enable-PSRemoting enables all session configurations by setting the value of the Enabled property of all session configurations (WSMan:\<ComputerName>\Plugin\<SessionConfigurationName>\Enabled) to True ($true).
- In Windows PowerShell 2.0, Enable-PSRemoting removes the Deny_All setting from the security descriptor of session configurations. In Windows PowerShell 3.0, Enable-PSRemoting removes the Deny_All and Network_Deny_All settings, thereby providing remote access to session configurations that were reserved for local use.
Enable-PSRemoting -Force
This command configures the computer to receive remote commands. It uses the Force parameter to suppress the user prompts.
Enable-PSRemoting -SkipNetworkProfileCheck -Force
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
This example shows how to allow remote access from public networks on client versions of Windows. Before using these commands, analyze the security setting and verify that the computer network will be safe from harm.
The first command enables remoting in Windows PowerShell. By default, this creates network rules that allow remote access from private and domain networks. The command uses the SkipNetworkProfileCheckparameter to allow remote access from public networks in the same local subnet. The command uses the Force parameter to suppress confirmation messages.
The SkipNetworkProfileCheck parameter has no effect on server version of Windows, which allow remote access from public networks in the same local subnet by default.
The second command eliminates the subnet restriction. The command uses the Set-NetFirewallRule cmdlet in the NetSecurity module to add a firewall rule that allows remote access from public networks from any remote location, including locations in different subnets.
-SkipNetworkProfileCheck
Enables remoting on client versions of Windows when the computer is on a public network. This parameter enables a firewall rule for public networks that allows remote access only from computers in the same local subnet.
This parameter has no effect on server versions of Windows, which, by default, have a local subnet firewall rule for public networks. If the local subnet firewall rule is disabled on a server version of Windows, Enable-PSRemoting re-enables it, regardless of the value of this parameter.
To remove the local subnet restriction and enable remote access from all locations on public networks, use the Set-NetFirewallRule cmdlet in the NetSecurity module.
How to Run PowerShell Commands on Remote Computers
PowerShell Remoting lets you run PowerShell commands or access full PowerShell sessions on remote Windows systems. It’s similar to SSH for accessing remote terminals on other operating systems.
PowerShell is locked-down by default, so you’ll have to enable PowerShell Remoting before using it. This setup process is a bit more complex if you’re using a workgroup instead of a domain—for example, on a home network—but we’ll walk you through it.
Enable PowerShell Remoting on the PC You Want to Access Remotely
Your first step is to enable PowerShell Remoting on the PC to which you want to make remote connections. On that PC, you’ll need to open PowerShell with administrative privileges.
-In Windows 10, press Windows+X and then choose PowerShell (Admin) from the Power User menu.
-In Windows 7 or 8, hit Start, and then type “powershell.” Right-click the result and choose “Run as administrator.”
-In the PowerShell window, type the following cmdlet (PowerShell’s name for a command), and then hit Enter:
Enable-PSRemoting -Force
This command starts the WinRM service, sets it to start automatically with your system, and creates a firewall rule that allows incoming connections. The -Force part of the cmdlet tells PowerShell to perform these actions without prompting you for each step.
If your PCs are part of a domain, that’s all the setup you have to do. You can skip on ahead to testing your connection. If your computers are part of a workgroup—which they probably are on a home or small business network—you have a bit more setup work to do.
Note: Your success in setting up remoting in a domain environment depends entirely on your network’s setup. Remoting might be disabled—or even enabled—automatically by group policy configured by an admin. You might also not have the permissions you need to run PowerShell as an administrator. As always, check with your admins before you try anything like this. They might have good reasons for not allowing the practice, or they might be willing to set it up for you.
Set Up Your Workgroup
If your computers aren’t on a domain, you need to perform a few more steps to get things set up. You should have already enabled Remoting on the PC to which you want to connect, as we described in the previous section.
Note: For PowerShell Remoting to work in a workgroup environment, you must configure your network as a private, not public, network.
Next, you need to configure the TrustedHosts setting on both the PC to which you want to connect and the PC (or PCs) you want to connect from, so the computers will trust each other. You can do this in one of two ways.
If you’re on a home network where you want to go ahead and trust any PC to connect remotely, you can type the following cmdlet in PowerShell (again, you’ll need to run it as Administrator).
Set-Item wsman:\localhost\client\trustedhosts *
The asterisk is a wildcard symbol for all PCs. If instead you want to restrict computers that can connect, you can replace the asterisk with a comma-separated list of IP addresses or computer names for approved PCs.
After running that command, you’ll need to restart the WinRM service so your new settings take effect. Type the following cmdlet and then hit Enter:
Restart-Service WinRM
And remember, you’ll need to run those two cmdlets on the PC to which you want to connect, as well as on any PCs you want to connect from.
Test the Connection
Now that you’ve got your PCs set up for PowerShell Remoting, it’s time to test the connection. On the PC you want to access the remote system from, type the following cmdlet into PowerShell (replacing “COMPUTER” with the name or IP address of the remote PC), and then hit Enter:
Test-WsMan COMPUTER
This simple command tests whether the WinRM service is running on the remote PC. If it completes successfully, you’ll see information about the remote computer’s WinRM service in the window—signifying that WinRM is enabled and your PC can communicate. If the command fails, you’ll see an error message instead.
Execute a Single Remote Command
To run a command on the remote system, use the Invoke-Command cmdlet using the following syntax:
Invoke-Command -ComputerName COMPUTER -ScriptBlock { COMMAND } -credential USERNAME
“COMPUTER” represents the remote PC’s name or IP address. “COMMAND” is the command you want to run. “USERNAME” is the username you want to run the command as on the remote computer. You’ll be prompted to enter a password for the username.
Here’s an example. I want to view the contents of the C:\ directory on a remote computer with the IP address 10.0.0.22. I want to use the username “wjgle,” so I would use the following command:
Invoke-Command -ComputerName 10.0.0.22 -ScriptBlock { Get-ChildItem C:\ } -credential wjgle
Start a Remote Session
If you have several cmdlets you want to run on the remote PC, instead of repeatedly typing the Invoke-Command cmdlet and the remote IP address, you can start a remote session instead. Just type the following cmdlet and then hit Enter:
Enter-PSSession -ComputerName COMPUTER -Credential USER
Again, replace “COMPUTER” with the name or IP address of the remote PC and replace “USER” with the name of the user account you want to invoke.
Your prompt changes to indicate the remote computer to which you’re connected, and you can execute any number of PowerShell cmdlets directly on the remote system.
Enable-PSRemoting
Enable-PSRemoting configures a computer to receive PowerShell remote commands sent with WS-Management technology.
To run this cmdlet, start PowerShell with the “Run as administrator” option.
PS Remoting only needs to be enabled once on each computer that will receive commands.
Computers that only send commands do not need to have PS Remoting enabled; because the configuration activates listeners (and starts the WinRM service), it is prudent to run it only where needed.
To run a command on the remote system, use Invoke-Command or Enter-PSSession for multiple commands.
If your computers aren’t on a domain, you’ll need to perform the following extra steps:
On both computers:
Configure the TrustedHosts setting so the computers will trust each other:
Set-Item WSMan:\localhost\client\trustedhosts PC64,PC65,PC66
The comma-separated list can be IP addresses or computer names or even a * wildcard to match all.
run : Restart-Service WinRM
To view the current trusted hosts:
Get-Item WSMan:\localhost\Client\TrustedHosts
Examples
Configure the local computer to receive remote commands:
PS C:\> Enable-PSRemoting
Configure the computer to receive remote commands & suppress user prompts:
PS C:\> Enable-PSRemoting -Force
Configure the remote computer workstation64 to receive remote commands, via psexec. If you are running this from an account which is NOT a domain administrator, then specify the username/password of an account with admin rights to the remote machine:
PS C:\> psexec \\PC64 -u adminUser64 -p pa$$w0rd -h -d powershell.exe "enable-psremoting -force"
Test that the computer computer64 is setup to receive remote commands:
PS C:\> Test-WsMan PC64
Run a single command on the remote computer using Invoke-Command:
PS C:\> Invoke-Command -ComputerName PC64 -ScriptBlock { Get-ChildItem C:\ } -credential jdoe
Run multiple commands by starting a Remote PowerShell Session:
PS C:\> Enter-PSSession -ComputerName PC64 -Credential AshleyT
“He who lies hid in remote places is a law unto himself” ~ Publilius Syrus
Related PowerShell Commands:
Enter-PSSession – Start an interactive session with a remote computer.
Disable-PSRemoting – Prevent remote users from running commands on the local computer.
Test-WSMan – Test if a computer is setup to receive remote commands via the WinRM service.
Invoke-Command – Run commands on local and remote computers.
WINRM – Windows Remote Management
Question: PowerShell: Configure WinRM and enable PSRemoting
1 – Enable WinRM
First thing to do before starting to manage your server remotely is to enable this function in your server. For this, you need to use the Windows Remote Management (WinRM) service. WinRM is the service which will allow you to use the WS-Management protocol necessary for the PowerShell remoting.
Enable WinRM is quite simple to do, you just need to run this command in a PowerShell prompt:
Winrm quickconfig or winrm qc
It should display a message like this if it is already configured:
Otherwise it will ask you to configure it:
2 – Enable PSRemoting
Once you have started your WinRM service, you must configure PowerShell itself to allow the remoting:
Enable-PSRemoting
3 – TrustedHosts file configuration
3.1 – Add server to the TrustedHosts file
The configuration above implies a domain environment. If you are working with servers which are not in your domain or in a trusted domain, you will have to add them in the TrustedHosts list of your local server. To do so, you must run the command below:
winrm s winrm/config/client ‘@{TrustedHosts=”MyServerName”}’
And the result you should see (you just need to replace “MyServerName” by the name of your server):
Another way to add a server to this file, by using the Set-Item cmdlet, like below:
Set-Item WSMan:\localhost\Client\TrustedHosts –Value “MyServerName,MyServerName2”
In the command above you can see that I added two values between the quotes “ “. If you want to add more than one server to this file, you must add them separated by a coma. Attention anyway, if one day you decide to add a new server, if you run the same command with only one server name, it will overwrite the existing file. You need to add all the server names’ that must be in this file.
PowerShell will also prompt you to warn about the risks of adding a computer which is not trustworthy in this file.
And if I do a Get-Item, I should see my two servers:
Get-Item WSMan:\localhost\Client\TrustedHosts |fl
If you want to trust every servers which are not in your domain, even if it far far… far away from being secure… you can use the wildcard, like that:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value “*”
And the result:
Get-Item WSMan:\localhost\Client\TrustedHosts |fl Name, Value
And of course, sometimes it can also be interesting to be able to check this TrustedHosts file to see what is inside. You can also use PowerShell to it by using the Get-Item cmdlet:
Get-Item WSMan:\localhost\Client\TrustedHosts
3.2 – Remove servers from the TrustedHosts file
While you can easily add servers to your TrustedHosts file it can also be interesting to be able to remove a server from it, for security reasons, if you don’t need to use it anymore.
To do so, there are two different ways…
Clear the whole file, by using the command below:
Clear-Item -Path WSMan:\localhost\Client\TrustedHosts –Force
Or, by only replacing one value by an empty value, with the command below:
$newvalue = ((Get-ChildItem WSMan:\localhost\Client\TrustedHosts).Value).Replace(“MyServerName1,”,””)
Set-Item WSMan:\localhost\Client\TrustedHosts $newvalue
And by using this command, we can remove one server but still keeping the other servers in the list. As we can see on the output below:
Before clearing:
And after:
And there we are! Your PowerShell is now configured to handle the remote management.
Question: PowerShell Remoting Cheatsheet
I have become a big fan of PowerShell Remoting. I find my self using it for both penetration testing and standard management tasks. In this blog I’ll share a basic PowerShell Remoting cheatsheet so you can too.
Enabling PowerShell Remoting
Before we get started let’s make sure PowerShell Remoting is all setup on your system.
- In a PowerShell console running as administrator enable PowerShell Remoting.
Enable-PSRemoting –forceThis should be enough, but if you have to troubleshoot you can use the commands below - Make sure the WinRM service is setup to start automatically.
# Set start mode to automatic Set-Service WinRM -StartMode Automatic # Verify start mode and state - it should be running Get-WmiObject -Class win32_service | Where-Object {$_.name -like "WinRM"} - Set all remote hosts to trusted. Note: You may want to unset this later.
# Trust all hosts Set-Item WSMan:localhost\client\trustedhosts -value * # Verify trusted hosts configuration Get-Item WSMan:\localhost\Client\TrustedHosts
Executing Remote Commands with PowerShell Remoting
- Executing a Single Command on a Remote SystemThe “Invoke-Command” command can be used to run commands on remote systems. It can run as the current user or using alternative credentials from a non domain system. Examples below.
Invoke-Command –ComputerName MyServer1 -ScriptBlock {Hostname} Invoke-Command –ComputerName MyServer1 -Credential demo\serveradmin -ScriptBlock {Hostname}If the ActiveDirectory PowerShell module is installed it’s possible to execute commands on many systems very quickly using the pipeline. Below is a basic example.Get-ADComputer -Filter * -properties name | select @{Name="computername";Expression={$_."name"}} | Invoke-Command -ScriptBlock {hostname}Sometimes it’s nice to run scripts stored locally on your system against remote systems. Below are a few basic examples.Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 -Credential demo\serveradminAlso, if your dynamically generating commands or functions being passed to remote systems you can use invoke-expression through invoke-command as shown below.$MyCommand = "hostname" $MyFunction = "function evil {write-host `"Getting evil...`";iex -command $MyCommand};evil" invoke-command -ComputerName MyServer1 -Credential demo\serveradmin -ScriptBlock {Invoke-Expression -Command "$args"} -ArgumentList $MyFunction - Establishing an Interactive PowerShell Console on a Remote SystemAn interactive PowerShell console can be obtained on a remote system using the “Enter-PsSession” command. It feels a little like SSH. Similar to “Invoke-Command”, “Enter-PsSession” can be run as the current user or using alternative credentials from a non domain system. Examples below.
Enter-PsSession –ComputerName server1.domain.com Enter-PsSession –ComputerName server1.domain.com –Credentials domain\serveradminIf you want out of the PowerShell session the “Exit-PsSession” command can be used.Exit-PsSession - Creating Background SessionsThere is another cool feature of PowerShell Remoting that allows users to create background sessions using the “New-PsSession” command. Background sessions can come in handy if you want to execute multiple commands against many systems. Similar to the other commands, the “New-PsSession” command can run as the current user or using alternative credentials from a non domain system. Examples below.
New-PSSession -ComputerName server1.domain.com New-PSSession –ComputerName server1.domain.com –Credentials domain\serveradminIf the ActiveDirectory PowerShell module is installed it’s possible to create background sessions for many systems at a time (However, this can be done in many ways). Below is a command example showing how to create background sessions for all of the domain systems. The example shows how to do this from a non domain system using alternative domain credentials.New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "" -Server a.b.c.d -credential domain\user cd RemoteADS: Get-ADComputer -Filter * -Properties name | select @{Name="ComputerName";Expression={$_."name"}} | New-PSSession - Listing Background SessionsOnce a few sessions have been established the “Get-PsSession” command can be used to view them.
Get-PSSession - Interacting with Background SessionsThe first time I used this feature I felt like I was working with Metasploit sessions, but these sessions are a little more stable. Below is an example showing how to interact with an active session using the session id.
Enter-PsSession –id 3To exit the session use the “Exit-PsSession” command. This will send the session into the background again.Exit-PsSession - Executing Commands through Background SessionsIf your goal is to execute a command on all active sessions the “Invoke-Command” and “Get-PsSession” commands can be used together. Below is an example.
Invoke-Command -Session (Get-PSSession) -ScriptBlock {Hostname} - Removing Background SessionsFinally, to remove all of your active sessions the “Disconnect-PsSession” command can be used as shown below.
Get-PSSession | Disconnect-PSSession
Wrap Up
Naturally PowerShell Remoting offers a lot of options for both administrators and penetration testers. Regardless of your use case I think it boils down to this:
- Use “Invoke-Command” if you’re only going to run one command against a system
- Use “Enter-PSSession” if you want to interact with a single system
- Use PowerShell sessions when you’re going to run multiple commands on multiple systems
Hopefully this cheatsheet will be useful. Have fun and hack responsibly.
Question: Enable PSRemoting Remotely
So it’s been an interesting week for me at work as we brought a new customer online. It’s really great to be working with a dynamic team in a rapidly evolving environment. One of the things that’s keeping us ahead of the game is relying on PowerShell when performing repetitive tasks. In this week’s article I’m going to talk about a set of functions I had to come up this week to start PSRemoting remotely.
I’d seen a bunch of postings where people used Schtasks.exe and or PSExec to enable PSRemoting but I didn’t like either of those approaches. I wanted to do it in a more native powershell way. I got a lot of help from Thomas Lee’s blog where he talked about writing registry keys remotely using powershell.
From there I went on to write a set of functions, 5 total, that will perform all the functions required to enable PSRemoting. In order to accomplish the configuration for the WinRM service and the windows firewall remotely I had the functions write entries in the policy node of the registry.
So I’ll stop talking and get onto the functions.
All of them can be downloaded here
Set-WinRMListener, works by creating 3 registry keys that configure the WinRM service when it restarts.
Restart-WinRM, Uses Get-WmiObject to start and stop the WinRM service.
Set-WinRMStartup, sets the startup type of the WinRM service to automatic.
Set-WinRMFirewallRule, creates 2 registry keys to configure the firewall exemptions required by PSRemoting.
Restart-WindowsFirewall, restarts the windows firewall service to allow the registry configurations to take hold.
Anyway, all the functions are defined in the script on the TechNet gallery. I hope you guys like the functions and get some use out of them. Go ahead and leave a comment or email me if you’re interested in further explanation. Also, feel free to leave comments on the TechNet entry.
Question: Enable-PSRemoting
The Enable-PSRemoting cmdlet configures the computer to receive Windows PowerShell remote commands that are sent by using the WS-Management technology.
By default, on Windows Serverr 2012, Windows PowerShell remoting is enabled. You can use Enable-PSRemoting to enable Windows PowerShell remoting on other supported versions of Windows and to re-enable remoting on Windows Server 2012 if it becomes disabled.
You have to run this command only one time on each computer that will receive commands. You do not have to run it on computers that only send commands. Because the configuration starts listeners, it is prudent to run it only where it is needed.
Beginning in Windows PowerShell 3.0, the Enable-PSRemoting cmdlet can enable Windows PowerShell remoting on client versions of Windows when the computer is on a public network. For more information, see the description of the SkipNetworkProfileCheck parameter.
The Enable-PSRemoting cmdlet performs the following operations:
— Runs the Set-WSManQuickConfig cmdlet, which performs the following tasks:
—– Starts the WinRM service.
—– Sets the startup type on the WinRM service to Automatic.
—– Creates a listener to accept requests on any IP address, if one does not already exist.
—– Enables a firewall exception for WS-Management communications.
—– Registers the Microsoft.PowerShell and Microsoft.PowerShell.Workflow session configurations, if it they are not already registered.
—– Registers the Microsoft.PowerShell32 session configuration on 64-bit computers, if it is not already registered.
—– Enables all session configurations.
—– Changes the security descriptor of all session configurations to allow remote access.
—– Restarts the WinRM service to make the preceding changes effective.
To run this cmdlet, start Windows PowerShell by using the Run as administrator option.
CAUTION: On systems that have both Windows PowerShell 3.0 and Windows PowerShell 2.0, do not use Windows PowerShell 2.0 to run the Enable-PSRemoting and Disable-PSRemoting cmdlets. The commands might appear to succeed, but the remoting is not configured correctly. Remote commands and later attempts to enable and disable remoting, are likely to fail.
Examples
- Configure a computer to receive remote commands:
PS C:> Enable-PSRemotingThis command configures the computer to receive remote commands. - Configure a computer to receive remote commands without a confirmation prompt:
PS C:> Enable-PSRemoting -ForceThis command configures the computer to receive remote commands. It uses the Force parameter to suppress the user prompts. - Allow remote access on clients:
PS C:> Enable-PSRemoting -SkipNetworkProfileCheck -Force PS C:> Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress AnyThis example shows how to allow remote access from public networks on client versions of the Windows operating system. Before using these commands, analyze the security setting and verify that the computer network will be safe from harm.The first command enables remoting in Windows PowerShell. By default, this creates network rules that allow remote access from private and domain networks. The command uses the SkipNetworkProfileCheck parameter to allow remote access from public networks in the same local subnet. The command specifies the Force parameter to suppress confirmation messages.The SkipNetworkProfileCheck parameter does not affect server version of the Windows operating system, which allow remote access from public networks in the same local subnet by default.The second command eliminates the subnet restriction. The command uses the Set-NetFirewallRule cmdlet in the NetSecurity module to add a firewall rule that allows remote access from public networks from any remote location. This includes locations in different subnets.
SomaBright 