Enable Windows remote access (SSH, WinRM, PSRP & WMI)

Enable Windows remote access (SSH, WinRM, PSRP & WMI)

Before the Attack Vector can reach a Windows System Target, remote access must be enabled on that machine. BlackNoise supports three protocols — SSH, WinRM (with NTLM authentication) or PSRP, and WMI. Enable whichever you plan to use.


Run every command below as administrator, a local admin account, or a domain account with local admin rights on the machine.
Shared requirement for WMI and WinRM: LocalAccountTokenFilterPolicy. For remote access with a local admin account, this registry key must be set to 1, for both WinRM and WMI:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy
Microsoft's rationale: in a workgroup using Negotiate authentication, only the built-in Administrator account can access the service unless this value is 1, which grants access to all accounts in the Administrators group. A GPO can overwrite this key, so re-check it if remote access stops working.


SSH

Enable

Install and enable the OpenSSH Server feature by following Microsoft's own procedure,  Get started with OpenSSH for Windows . On Windows Server 2025 the server component ships with the operating system, so only enabling it is required, which makes the setup faster still.
Then check that TCP 22 is reachable between the target and the Attack Vector. The Microsoft procedure creates and enables the OpenSSH-Server-In-TCP rule in the local Windows Firewall, but the network profiles it covers are not documented and vary with the Windows version and the way OpenSSH Server was enabled, so verify its scope as shown below. Also pen the port if another host firewall, or a network firewall between the subnets, still blocks it. BlackNoise connects on TCP 22 only, and this fixed, well-known port is what makes the flow simple to open and to maintain.

Verify the SSH service

Run the four commands below on the target, in any PowerShell session, to confirm that the feature is installed, that the service runs, that the port listens, and that the firewall rule covers the right network profile.
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
The OpenSSH.Server~~~~0.0.1.0 capability must be reported as Installed.
Get-Service sshd | Select-Object Name, Status, StartType
The sshd service must be Running. A StartType set to Automatic also guarantees it comes back after a reboot.
Get-NetTCPConnection -LocalPort 22 -State Listen
The command must return a listening socket on port 22.
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' | Select-Object Name, Enabled, Profile
The rule must be reported as Enabled = True, and its Profile must include the profile of the interface that faces the Attack Vector. Do not assume the rule applies to all three profiles: on some versions it is enabled for private networks only.
What this check does not cover. These results prove the SSH stack answers on the machine; they do not prove that the account used by BlackNoise can authenticate and run commands. Use the connection test in the web app (Resources > System Targets) to validate the full chain.

Troubleshooting

  • The firewall rule does not cover the right profile. Widen the existing rule from an administrator PowerShell with Set-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -Profile Domain,Private (use Any to include public networks), or move the interface that faces the Attack Vector to a profile the rule already covers.
  • The service is not running. Start it from an administrator PowerShell with Start-Service sshd , then set it to start on its own with Set-Service -Name sshd -StartupType Automatic .
  • Nothing listens on port 22. Confirm that the OpenSSH Server capability is installed, then restart the sshd service.
  • Access fails from the Attack Vector while the local checks pass. Check that TCP 22 is open between the Attack Vector and the target, then confirm the credentials and the account's local admin rights.

WinRM / PSRP

Enable

    In an administrator PowerShell, run:
Enable-PSRemoting -Force
This enables the WinRM service, adds a listener on port 5985, and creates a Windows Firewall rule.
Expected output:
WinRM service type changed successfully.
WinRM service started.
WinRM firewall exception enabled.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.
    Check that TCP 5985 is reachable between the target and the Attack Vector. Step 1 already added the rule to the local Windows Firewall; open the port only if another host firewall, or a network firewall between the subnets, still blocks it.
    Confirm LocalAccountTokenFilterPolicy is set to 1 (see above).

Verify the WinRM service

Once remote access is enabled, confirm that WinRM actually answers. Run this on the target, in any PowerShell session — the command only sends an identification request and needs no administrator rights:
Test-WSMan
The service is ready when PowerShell returns the WS-Management identity schema (wsmid), the protocol version, ProductVendor = Microsoft Corporation, and a ProductVersion line. That line reading OS: 0.0.0 SP: 0.0 Stack: 3.0 is expected: the request is sent unauthenticated, so the target discloses no operating system version. Add -Authentication Negotiate if you want the real version returned.
To also validate the network path, run the same command from another Windows machine with access to the target:
Test-WSMan -ComputerName <target>
If the command fails. PowerShell returns a WSManFault stating that the client cannot connect to the destination. Check the service state on the target with Get-Service -Name winrm — Status should be Running — re-run Enable-PSRemoting -Force if needed, and review the firewall points in Troubleshooting below.
What this check does not cover. A successful reply proves the WinRM stack answers; it does not prove that the account used by BlackNoise can authenticate and run commands. Use the connection test in the web app, or the script below, to validate the full chain.

Test (optional)

Prefer testing from the BlackNoise web app (Resources > System Targets, connection test at creation or from the detail view). To test from your own machine instead, use the BlackNoise script available for download below. Run it as admin from any Windows machine with access to the target, not from the target itself:
  • Local admin account:
powershell .\blacknoise_check_winrm-v1.1.ps1 -Local -ComputerName <target> -UserName <user>
  • Domain account with local admin rights:
powershell .\blacknoise_check_winrm-v1.1.ps1 -ComputerName <target> -DomainName <domain> -UserName <user>
Enter the account password at the prompt.
On success you get SUCCESS: Connection to <ip address> with admin successful.
The flows validated by the script must also be open from the BlackNoise Attack Vector for access to work in production.
Script: blacknoise_check_winrm-v1.1.ps1

blacknoise_check_winrm-v1.1.ps1
3KB, Uploaded last month

Troubleshooting

  • Public firewall profile. Enable-PSRemoting opens the flow on the Domain and Private profiles, but not Public. If the interface used to reach the Attack Vector is on the Public profile, either move it to Domain or Private, or add or modify a firewall rule to open the flow on Public.
  • Access still fails after a success message. Log in to the target and confirm LocalAccountTokenFilterPolicy = 1 (a GPO may have reset it).
  • WinRM does not answer. From the target, run Test-WSMan to confirm that the service and its listener respond, as described in the Verify the WinRM service section above.


WMI

The WMI scripts are compatible with Windows 2016 and later.

Enable

    In an administrator PowerShell, run the enable script with default parameters:
powershell -ep bypass -f blacknoise_enable_wmi-v1.3.ps1 -f -w -v
Or with specific parameters:
powershell -ep bypass -f blacknoise_enable_wmi-v1.3.ps1 -f -w -v -p xxxx-yyyy -z zoneA,zoneB,zoneC
  • -p — the range of ports used for WMI connections
  • -z — the firewall zones for which a rule is opened
    Reboot the target.
    Check that the required ports are reachable between the target and the Attack Vector. The enable script already added the rules to the local Windows Firewall; open the ports only if another host firewall, or a network firewall between the subnets, still blocks them:
  • RPC: TCP 135
  • SMB: TCP 445
  • Dynamic RPC range: TCP 60000–61000, or the range set with -p. Windows' default dynamic range is 49152–65535.
    Confirm LocalAccountTokenFilterPolicy is set to 1 (see above).
Script: blacknoise_enable_wmi-v1.3.zip

blacknoise_enable_wmi-v1.3.zip
2KB, Uploaded last month
Upon successful execution, you should receive a return as illustrated below:

Verify the WMI service

The Windows Management Instrumentation service (winmgmt) must be running on the target for the Attack Vector to reach it over WMI. Check it directly on the target, in any PowerShell session — this command only reads the service state and needs no administrator rights:
Get-Service -Name winmgmt
The service is ready when the returned line shows Status = Running, with Name winmgmt and DisplayName Windows Management Instrumentation. Any other status (Stopped, StartPending) means WMI requests from the Attack Vector will fail.
If the service is not running. Start it from an administrator PowerShell with Start-Service -Name winmgmt, then confirm it restarts on its own after a reboot with Get-Service -Name winmgmt | Select-Object Name, Status, StartType — the start type should be Automatic.
What this check does not cover. A successful reply proves the WMI stack answers; it does not prove that the account used by BlackNoise can authenticate and run commands. Use the connection test in the web app, or the script below, to validate the full chain.

Test (optional)

As with WinRM, prefer the web app test. To test from your own machine, run as admin from a Windows machine with access to the target, not from the target itself:
powershell -f .\blacknoise_check_wmi-v1.0.ps1 target user password domain
target, user and password are required; domain is optional.
On success you get Success: Successfully retrieved remote computer name.
Script: blacknoise_check_wmi-v1.0.zip

blacknoise_check_wmi-v1.0.zip
3KB, Uploaded last month

Troubleshooting

  • Access still fails after a success message. Log in to the target and confirm LocalAccountTokenFilterPolicy = 1 (a GPO may have reset it).
  • Access fails from the Attack Vector. Log in to the target and confirm that the winmgmt service is running, as described in Verify the WMI service above.