Навигация в power shell устранение проблем с помощью power shell 7

When working in a mixed environment, PowerShell and SSH make for a good remote management combination.

When Microsoft made its PowerShell automation tool open source in 2016, part of the reason was to develop cross-platform compatibility to include macOS and Linux systems. It came as no surprise when the PowerShell team implemented SSH connectivity to enable PowerShell remoting to Linux boxes. SSH is widely considered to be the standard for remoting. Learn how PowerShell remoting over SSH is different from traditional remote management methods in a Windows environment and the basics of how to use remoting over SSH to both Windows and Linux machines.

How to set up OpenSSH on Windows

Add-WindowsCapability -Online -Name "OpenSSH.Server~~~~0.0.1.0"

Lastly, start the SSH service:

Run the help for the cmdlet to see all the work this PowerShell command performs related to SSH remoting:

The last step is to restart the service:

sudo apt install powershell

sudo apt install openssh-client
sudo apt install openssh-server

Install-Module Microsoft.PowerShell.RemotingTools
Enable-SSHRemoting
service sshd restart

How to run scripts with a PowerShell remoting session

is great for interactive use, but running a script remotely requires a different approach. You want to use to create a session object and then run commands with the cmdlet. The command starts a persistent session to the remote machine, while enables running commands on local and remote machines.

First, generate and configure SSH keys needed to pass a password to the cmdlets. The process to set up SSH keys is outside the scope of this article, but producing them for PowerShell is the same as making them for typical SSH activities.

After creating the SSH keys, create a PowerShell session object:

Test-NetConnection -ComputerName 10.0.0.10 -Port 22

PowerShell Remoting is a native Windows feature that can be used to take over entire enterprises. It allows you to pivot between machines, automate hacking tasks, and dominate Windows environments while remaining undetected. 

This comprehensive guide will teach you about PowerShell Remoting and how to use it to start interactive sessions, execute remote commands, and run complete PowerShell scripts against multiple machines. 

You’ll also see how it can be used for common penetration testing actions like lateral movement, privilege escalation, and establishing persistence while evading detection.

Let’s jump straight in and learn how to do PSRemoting.

Table Of Contents

What Is PowerShell Remoting?

With a single command or script, you can update software, change configuration settings, or edit services across multiple machines. SOC analysts or responders can also use it to collect logs for analysis or perform remediation actions quickly. 

Remote Command Execution (RCE): Run commands or scripts on remote systems.

Interactive: Start an interactive remote session and run remote commands as if you were in a local PowerShell terminal. 

Script Execution: Execute complete PowerShell scripts as background jobs on multiple machines at once to perform using asynchronous task execution.

Secure: Use encrypted communication channels (WinRM) with Kerberos support and NTLM authentication.

Scalable: Use PowerShell Remoting across hundreds of machines concurrently, allowing you to control and manage fleets of enterprise workstations and servers.

Execute Commands Remotely

PowerShell Remoting allows you to execute commands and scripts on remote systems. This means you don’t need to sit in front of the workstation you’re targeting to perform attacks. Once you’re inside the network, you can attack any network-connected machine. 

Stealth and Evasion

Also, PowerShell Remoting is encrypted. This makes it harder for security operations teams to detect and analyze malicious traffic.

Automated Reconnaissance and Exploitation

PowerShell Remoting allows you to execute entire PowerShell scripts against hundreds of machines at once. This is perfect for automating common reconnaissance and exploitation tasks like scanning network ports, finding vulnerable machines, and performing credential stuffing. Automating saves you time and energy.

Post-Exploitation Activities

After gaining initial access, hackers will perform post-exploitation activities like setting up persistence mechanisms, performing credential harvesting to exfiltrate data, and eventually performing lateral movement. Again, PowerShell Remoting is an excellent tool with its ability to remote code execution, native support in Windows environments, and automation capabilities. 

Set Up and Enable PowerShell Remoting

If you can establish a WMIC connection to the target, you can activate PowerShell Remoting remotely using the Windows Management Instrumentation (WMI) command wmic /node:<RemoteHost> process call create "powershell enable-psremoting -force".

This is all you need if you’re using domain-joined computers to perform PowerShell Remoting. 

However, if you execute remote PowerShell commands from a computer not connected to the same domain as the target machine, your machine is considered an “untrusted host.” For instance, your Kali Linux machine would be an untrusted host.

To ensure PowerShell Remoting works from any machine, you must either add that single machine to the Trusted Hosts list for the machine you’re PowerShell Remoting into or set all hosts as trusted hosts using a wildcard (*):

• To add your machine, execute the command Set-Item wsman:\localhost\Client\TrustedHosts -Value "<YourComputerName>".
• To add all hosts, run the command Set-Item wsman: localhostClientTrustedHosts -Value *. Use this command only in controlled testing environments.

If successful, you can use PowerShell Remoting to execute PowerShell commands and scripts. 

How to Use PowerShell Remoting

Once PowerShell Remoting has been enabled on the target machine, you can start running remote PowerShell commands. 

Firstly, to establish a PowerShell Remoting session with the target, open a PowerShell terminal on your Kali Linux machine using the dropdown menu at the top of the GUI.

Once you’ve established a PowerShell Remoting session, you can interact with the target machine just like you had opened a PowerShell terminal locally. 

PowerShell Remoting Scripts

PowerShell commands are great, but you probably don’t want to run them interactively, one by one every time. 

Good news: PowerShell Remoting allows you to bundle your commands into a script and execute it asynchronously on a target machine to automate tasks.         

Here, the host-recon.ps1 script contains the same PowerShell commands as before, just in a script rather than listed individually. Check out PowerSploit for excellent PowerShell hacking scripts to run during a penetration test.

PowerShell Remoting Session Management

You just saw how the Enter-PSSession cmdlet can create an interactive session, and New-PSSession creates a session you can use to execute commands. These are PowerShell Remoting session management cmdlets used to manage sessions. Here is a summary of all the session management cmdlets you can use:

Malicious actors can use PowerShell Remoting to perform lateral movement, escalate their privileges, install persistence mechanisms, and evade detection. 

Let’s explore how you can do this during a penetration test.

PowerShell Remoting for Lateral Movement

Lateral movement is a key step in any penetration test, and PowerShell Remoting can make it very easy. 

You just need to steal credentials from a compromised system using a tool like Mimikatz or Meterpreter. Then, use these credentials to authenticate to other systems using PowerShell Remoting. 

PowerShell Remoting for Privilege Escalation

PowerShell Remoting can also be used to elevate your privileges on a target machine by executing arbitrary PowerShell commands. 

You can run specific commands to check for privilege escalation opportunities or entire scripts that automatically escalate your privileges. 

For instance, many post-exploitation activities during a penetration test require elevated privileges, such as checking for misconfigurations, installing persistence mechanisms, or exfiltrating sensitive data. 

The commands demonstrated here run against a Windows 10 machine with Microsoft Windows Defender and Smart Screen disabled.

PowerShell Remoting for Persistence

You can use various persistence mechanisms, such as creating a Windows Startup folder script that connects to your command and control (C2) server, installing a malicious service, or using a registry run key. 

Avoiding Detection

As mentioned, lateral movement is a key step in any penetration test. However, usually, this requires you to use a C2 framework like PowerShell Empire and install a C2 agent on each machine you move to so you can interact with it. 

If this sounds like a lot of work, don’t worry: this is where PowerShell Remoting shines. In fact, your PowerShell Remoting sessions, commands, and scripts run entirely in memory. 

This means common detection techniques like signature-based scanning won’t detect your post-exploitation activities, and you can perform lateral movement without disruption. 

Additionally, because PowerShell Remoting is so common in enterprise environments, your actions will likely go unnoticed by defenders, unlike with a tool like PsExec. 

PsExec is not pre-installed on most workstations or servers, so your chances of blending into the target environment are lower than PowerShell Remoting.

One way to use PowerShell Remoting to remain undetected is to download and execute PowerShell scripts completely in memory on a target machine. 

The Meterpreter reverse shell is downloaded from the attacker machine (10.0.200.17) and executed on the target machine without touching the disk, evading on-disk detection mechanisms. A fully interactive shell connects back to your attack machine.

However, before getting ahead of yourself, remember that PowerShell Remoting has some limitations, especially if Constrained Language Mode is enabled. 

PowerShell scripts must be allowed to execute on the Windows system you’re attacking to download and execute them in memory. You can enable this by changing the Set-Execution policy parameter.

Constrained Language Mode

You can execute the PowerShell command $ExecutionContext.SessionState.LanguageMode to detect if CLM is enabled.

This will return the language mode for the current system:

• FullLanguage: This is the default mode. It provides full scripting capabilities without any restrictions. All cmdlets, language features, and .NET types are available.
• RestrictedLanguage: This option limits you to basic cmdlets and expressions. It doesn’t allow complex language scripts, constructs, or .NET types.
• NoLanguage: Here, script execution is completely disabled, and only basic command execution is allowed.
• ConstrainedLanguage: In this mode, basic scripting is allowed, but access to advanced features and .NET types is restricted. This language only allows you to perform basic administrative tasks.

If you find CLM is enabled on the machine you’re PowerShell Remoting to, you can try several bypass methods. 

The easiest way to bypass CLM is to downgrade your PowerShell remote session to a previous PowerShell version. For instance, you can downgrade to PowerShell version 2.0 with the command powershell -version 2.

Downgrading to an older PowerShell version requires that version to have already been installed on your target machine. If this isn’t the case, there are other CLM bypasses, including: 

• Make the path where you execute your scripts contain system32, as discussed here.
• PowerShell CLM bypass scripts.
• Using PowerShell Runspaces to bypass CLM.

Let’s see how PowerShell Remoting compares to another tool commonly used for lateral movement in Windows environments.

PowerShell Remoting vs PsExec

PsExec is another popular tool frequently used by threat actors to perform lateral movement, escalate privileges, and execute remote code. 

However, unlike PowerShell Remoting, PsExec is designed for quick, ad-hoc tasks like running simple commands or non-PowerShell executables. 

You can’t use it to automate complex tasks like executing complete scripts, running commands against multiple machines, or creating an interactive session. It only shines when performing single tasks with minimal configuration. 

PowerShell Remoting is the way to go if you want a more robust solution. The only issues are whether it’s configured in the environment you’re targeting and whether you can bypass any PowerShell protections like CLM. 

Conclusion

PowerShell Remoting is a powerful Windows feature that allows you to perform lateral movement, escalate privilege, and install persistence mechanisms. 

This guide demonstrated how to use it to start interactive sessions, run ad-hoc commands, and execute entire PowerShell scripts that can automate many hacking tasks. 

You’ve also seen how to use PowerShell Remoting to evade detection, discovered tips on bypassing PowerShell’s Constrained Language Mode (CLM), and learned how PowerShell Remoting stacks up against PsExec. 

We encourage you to set up your hacking lab and play with this Windows feature’s awesome capabilities.

Here are some of the courses available:

Frequently Asked Questions

How do you tell if PowerShell remoting is enabled?

There are several ways of enabling PowerShell Remoting on a target machine. For instance, you can use a hacking tool like evil-winrm to check if you can establish a session. Otherwise, you can use the Test-WSMan cmdlet to test the availability of the WS-Management (WinRM) service on a local or remote computer. You can also use the Get-WSManInstance cmdlet to check the configuration settings of the WinRM service. Lastly, if you have local access to the machine, you can use the Get-Service -Name WinRM command to check the service status or Enable-PSRemoting -Force command to enable PowerShell Remoting.

Is it safe to enable PowerShell remoting?

What is PowerShell remoting used for?

How can PowerShell remoting be used for malicious purposes?

Level Up in Cyber Security: Join Our Membership Today!

In my lab setup, I had carefully configured a network of Windows servers, each armed with PowerShell 7. My intention was to seamlessly manage these servers from a Windows 11 client, also equipped with PowerShell 7. The logical choice was to employ the well-known Enter-PSSession cmdlet to establish a remote connection. However, this seemingly straightforward process took an unexpected turn. Instead of connecting to the PowerShell 7 instance on the remote machines, I found myself interacting with PowerShell 5.1.

This encounter with version mismatch ignited a curiosity to dive deeper into the intricacies of PowerShell remoting and uncover the methods to explicitly connect to PowerShell 7’s WSMan interface. Join me as I unravel the journey of understanding and overcoming this challenge, shedding light on the nuances of PowerShell remoting with a focus on PowerShell 7.

Problem statement

Armed with a lab comprising Windows servers and a Windows 11 client, all equipped with PowerShell 7, my intention was to streamline remote management using the trusty Enter-PSSession cmdlet. Little did I know that this endeavor would lead me to uncover an intriguing version discrepancy.

The initial signs of this enigma appeared innocuously. After executing Enter-PSSession to connect to one of the Windows servers, I promptly fired the $PSVersionTable cmdlet to examine the PowerShell version of the remote system. Much to my surprise, the version reported was 5.1, not the expected 7 that I had anticipated.

My Windows 11 client and the Windows servers were all equipped with PowerShell 7, and my assumption was that the remote sessions would automatically align with the PowerShell 7 environment. However, reality had other plans, as the remote session seemed to default to PowerShell 5.1.

Let’s find out how this can be fixed!

PowerShell Remoting

1. Session: A PowerShell remoting session is a connection established between a local and a remote computer. This session allows you to send commands and receive output as if you were working directly on the remote machine.
2. Remote Session Configuration: On the remote machine, a session configuration (also known as an endpoint) defines which PowerShell commands and features can be used in the remote session. This configuration ensures security and control over what operations can be performed remotely.
3. Enter-PSSession: This cmdlet is used to initiate an interactive remote session with a remote computer. It allows you to interact with the remote machine’s PowerShell environment as if you were using it directly. You can run commands, navigate the file system, and more.
4. New-PSSession: This cmdlet creates a persistent remote session (or session state) that can be reused for multiple commands. This is particularly useful for reducing the overhead of establishing a new session for each command.
5. Invoke-Command: This cmdlet lets you execute scripts or commands on a remote computer. You can pass in script blocks or script files, and the results are returned to the local machine.
6. Exit-PSSession: This cmdlet is used to end an interactive remote session that was initiated using Enter-PSSession. It returns you to the local machine’s session.

Setting Up PowerShell Remoting:

1. Enable Remoting: PowerShell remoting must be enabled on both the local and remote machines. On Windows, you can use the Enable-PSRemoting cmdlet to configure the necessary settings.
2. Firewall Considerations: Remoting requires specific ports to be open in the firewall. The necessary ports can be configured using Group Policy or by running the Enable-PSRemoting cmdlet with appropriate parameters.

1. Authentication: Remoting supports various authentication methods, including Kerberos and NTLM for Windows machines, and SSH for cross-platform remoting.
2. Encryption: By default, remoting sessions are encrypted to protect data transferred between the local and remote machines. Specially in domains it’s not necessary to enable TLS encryption on top of encryption by Kerberos.

Use Cases: PowerShell remoting is incredibly versatile and can be used for a variety of tasks, including:

• Configuration Management: Remotely configure software, services, and settings on multiple machines simultaneously.
• Software Deployment: Install or update software across a network of machines.
• Troubleshooting: Remotely investigate and resolve issues on remote computers.
• Data Collection: Retrieve information, logs, and system data from remote systems.
• Automation: Create and deploy scripts to automate repetitive tasks across multiple machines.

Installing PowerShell 7

Before you can start using PowerShell 7, you’ll need to download and install it. You can obtain the latest version of PowerShell 7 from the official GitHub repository or the PowerShell website. Visit https://github.com/PowerShell/PowerShell or https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows to access the downloads.

Installing PowerShell 7 with the GUI:

1. Download: Navigate to the official PowerShell website or the GitHub repository to download the latest installer for PowerShell 7.
2. Run the Installer: Once the installer executable (e.g., PowerShell-7.x.x-win-x64.msi) is downloaded, run it.
3. Setup Wizard: The installer will launch a setup wizard. Follow the on-screen instructions to proceed through the installation process.
4. Choose Installation Location: You can either accept the default installation location or choose a different one. Remember the installation path for future reference.
5. Installation Options: The wizard may provides options for interacting with PowerShell 7. In our case we should at a minimum select the option “Enable PowerShell remoting”.

6. Completing the Installation: Once you’ve made your selections, click “Install” to begin the installation process.
7. Finish: Once the installation is complete, you’ll see a confirmation message. You can now launch PowerShell 7 from the Start Menu or by typing pwsh in a command prompt.

Note! At the time of writing there seems to be a bug in the GUI installation. Selecting the “Enable PowerShell remoting” option doesn’t enable PowerShell remoting. The MSI installation however works as expected. I’ve reported the bug here: https://github.com/PowerShell/PowerShell/issues/20173

Installing PowerShell 7 Using the MSI File:

1. Download: As before, download the latest MSI installer for PowerShell 7 from the official PowerShell website or the GitHub repository.
2. Command Prompt: Open a Command Prompt window with administrative privileges.
3. Navigate to the Download Location: Use the cd command to navigate to the directory where the downloaded MSI installer is located.
4. Install: Run the following command to install PowerShell 7 using the MSI file:

msiexec.exe /package PowerShell-7.3.6-win-x64.msi /quiet ENABLE_PSREMOTING=

Replace PowerShell-7.3.6-win-x64.msi with the actual filename of the MSI installer. Just in case I’ve listed all the options here for reference.

• ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL – This property controls the option for adding the Open PowerShell item to the context menu in Windows Explorer.
• ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL – This property controls the option for adding the Run with PowerShell item to the context menu in Windows Explorer.
• ENABLE_PSREMOTING – This property controls the option for enabling PowerShell remoting during installation.
• REGISTER_MANIFEST – This property controls the option for registering the Windows Event Logging manifest.
• ADD_PATH – This property controls the option for adding PowerShell to the Windows PATH environment variable.
• USE_MU – Use Microsoft Update to update the version of PowerShell.
• ENABLE_MU – Enable the use of Microsoft Update.
• DISABLE_TELEMETRY – This property controls the option for disabling PowerShell’s telemetry by setting the POWERSHELL_TELEMETRY_OPTOUT environment variable.

• Open a Powershell 7 terminal as administrator.
• cd to $PSHOME, in my case that’s “C:\Program Files\PowerShell\7”.
• Execute the script, “Install-PowerShellRemoting.ps1“.
• Restart the WinRM (Windows Remote Management) service, “Restart-Service winrm“.

Understanding PowerShell Remoting Endpoints

In the realm of PowerShell remoting, an “endpoint” refers to a pre-defined configuration that determines how remote sessions are established and what commands can be executed on a remote computer. Endpoints serve as gateways to the remote machine’s PowerShell environment, controlling the scope and capabilities of the remote session.

• Configuration Control: Endpoints allow administrators to define specific settings for remote sessions. These settings can include which PowerShell version to use, which modules are available, and what security protocols are required.
• Security: Endpoints play a crucial role in ensuring security during remoting. They help enforce security policies by allowing administrators to control which commands and scripts can be executed remotely.
• Scalability: By defining endpoints, you can create consistent and tailored remote session experiences for various users and use cases. This scalability enhances the efficiency and manageability of remote administration.

Viewing Endpoint Configuration:

To view the configuration of a remote session endpoint, you can use the Get-PSSessionConfiguration cmdlet. This cmdlet provides insights into the available endpoint configurations on a remote computer.

As you can see in the picture above, the endpoints have a reference name, stay tuned as this is part of the solution we’re looking for.

Connecting to a Specific PowerShell Endpoint

One powerful aspect of PowerShell remoting is the ability to connect to specific endpoints, each tailored to different scenarios and environments. This capability allows us to not only manage version consistency but also customize the remote session experience to match our needs.

Using the -ConfigurationName Parameter:

The key to connecting to a particular endpoint lies in the -ConfigurationName parameter of the Enter-PSSession cmdlet. By specifying the desired endpoint’s configuration name, we can establish a remote session that aligns with the version and settings associated with that endpoint.

For instance, let’s consider a scenario where we have a Windows server named “lab-srv01.water.lan“, and we want to connect to a PowerShell 7-specific endpoint configuration named "powershell.7". This configuration is tailored to PowerShell 7, ensuring that our remote session operates with PowerShell 7’s capabilities and features.

Connecting to PowerShell 7 Endpoint:

In this example, we use the -ComputerName parameter to specify the target remote machine (lab-srv01.water.lan) and the -ConfigurationName parameter to specify the endpoint configuration ("powershell.7"). By doing so, we’re guaranteed to establish a remote session that operates under the PowerShell 7 environment, regardless of any other available endpoints.

Connecting a PowerShell 7 Terminal to a PowerShell 5.1 Endpoint

One of the remarkable features of PowerShell remoting is its ability to bridge the gap between different PowerShell versions. While we’ve explored the importance of version consistency, it’s worth noting that a PowerShell 7 terminal can establish a remote connection to a PowerShell 5.1 endpoint.

PowerShell remoting is designed with a compatibility layer that allows newer versions of PowerShell to communicate with older endpoints. This means that even if you’re using a PowerShell 7 terminal, you can still connect to and interact with systems running PowerShell 5.1 through remoting.

Why It Matters:

Obtaining the PowerShell 5.1 Endpoints:

So, for example we have an open PowerShell 7 terminal and we would like to connect specifically to a certain endpoint, we could use something like this:

29-08-2023

Just found another bug. After delegating remote access using:

And trying to logon remotely with the delegated account using this command:

I got a weird error message, that showed me this:

Enter-PSSession: Connecting to remote server lab-dc01.water.lan failed with the following error message : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2689860592" Machine="lab-dc01.water.lan"><f:Message><f:ProviderFault provider="PowerShell.7" path="C:\Windows\system32\PowerShell\7.3.6\pwrshplugin.dll"></f:ProviderFault></f:Message></f:WSManFault> For more information, see the about_Remote_Troubleshooting Help topic.

Obviously this is not the behavior I would like to see, and I’m assuming there’s a programming error. I filed another bug report on GitHub:

I’ve began by understanding the role of PowerShell remoting in connecting and managing remote systems. Despite encountering version discrepancies during remote sessions, I learned that using the -ConfigurationName parameter with the Enter-PSSession cmdlet provides a direct path to desired endpoints, ensuring specific PowerShell versions and tailored settings.

Moreover, I realized that the flexibility of PowerShell remoting extends to cross-version compatibility. A PowerShell 7 terminal effortlessly connects to PowerShell 5.1 endpoints, simplifying management in mixed-environment scenarios.

In conclusion, PowerShell remoting empowers us to manage remote systems with precision and flexibility. By embracing its tools, we’re equipped to streamline tasks, troubleshoot issues, and automate processes across diverse environments.

I hope this information is useful and don’t hesitate to ask questions or comment on the blog post.

Похожее:

Удаление power shell для хакеров Ftp command help Ssh-подключения к windows-серверу из linux mac os с использованием power shell Запуск exe-файлов в power shell