General Information about SMB/WinRM Scanning

Purpose

This article explains:

How the scanner behave when providing credentials in the WinRM/SMB tab in the scan policy.
What happens if the credentials does not work.
What happens if credentials and the service manager is not accessible for one of these services.

General Information About WinRM/SMB Scanning

Authenticated scanning on Windows consists of Registry scanning and Command execution, and both are needed for reliable results.
- The Registry access is handled through the Remote Registry service regardless of whether WinRM is used or not.
- Command execution is handled either through WinRM or our SMB Powershell based connector. Their usages are mutually exclusive, although WinRM is preferred. The commands to execute are the same.
WinRM based command executions require a functional PKI with a trusted certificate.
- Self-issued/self-signed certificates are fine, as long as the CA is added and trusted on the HIAB.
- The root certificate must not be the leaf, even if trusted - you need a chain with an issuer.
- With WinRM, the account that is provided to the scanner must only have privileges to execute the actual commands it needs for scanning unlike SMB where it also needs to be able to manage services.
Our SMB Powershell based connector requires privileges to manage services on the target.
- Connects to the service control pipe, installs a Windows service called O24AUTH which executes commands sent to it from the scanner (checking signatures of course).
- Send commands to that service and feed the results back to the scanner.
- Uninstall the service when done.
- This occasionally gets blocked by antimalware programs, as this behavior does look malicious. The entire “start the service and then send commands” process exists to workaround size limitations and handle timeouts more gracefully (as opposed to just running the commands directly).
Remote Registry is used with the provided SMB credentials, and doesn’t use WinRM at all.
- If the preference to enable remote registry is selected, the scanner will first connect to the service control pipe and attempt enabling the service.
- Connects to the remote registry pipe, queries for the registry keys we need to extract patch data, uninstall path data etc.
- Stops the service if the scanner were responsible for enabling it, leaving it running if it already was when the scanner connected.
- Some versions of Windows have a faulty implementation of this service which leaks memory and causes crashes after some time, this is the workaround for that.
Credential “selection” is generally done on a “first one that indicates it will work” basis.
- The order credentials are provided in defines the order they will be attempted to be used in.
- The first credential that indicates authentication success of any kind is the one that will be used, and latter ones omit. The definition of “success” varies by protocol.
  - For Remote Registry, it’s a credential that returned at least one registry value
  - For WinRM, it’s a credential that returned 'hello world' when instructed to run echo 'hello world'
  - For our SMB Powershell based connector, it’s a credential that managed to authenticate and login over the SMB pipe
- Failures from one credential will not be retried using another credential. This is done for performance reasons, and keeping all the data as originating from the same “source of truth”.

How the Scanner Interacts with a Typical Target During an Authenticated Windows Scan:

Step 1: Authenticated Portscan Phase

Authenticated portscan phase is only applicable if authenticated portscanning is enabled (quick / verify). This logs on to the machine and fetches ports that the target considers “open”, which are then optionally verified with an external portscan.

Check if WinRM credentials are provided. Try using all WinRM credentials, one by one in the order provided, exiting on first success. If all of these fail, move on to SMB.
Check that WinRM didn’t produce anything. Try using all SMB credentials, one by one in the order provided, exiting on first success. If all of these fail, consider authenticated port scanning failed.

Step 2: Determine SMB Credentials

Determine SMB Credentials runs in portscan phase. This step decides which SMB credentials that will be used for the rest of the scan, for both SMB and Remote Registry. This step does not determine WinRM credentials, as the selection of those are handled by the WinRM component (as it only has one more run from this point, whereas the SMB credentials will be used in several different components)

Assert that port 445 is in scope.
Iterate over the list of provided SMB Credentials (user, pass, domain). For each:
- Set up a SMBConnection targeted at *SMBSERVER via port 445, negotiating dialect as appropriate.
- Attempt a login over this connection. Only allow NTLMv1 if that preference is set for the scan policy.
- Set up a DCERPC transport with "ncacn_np:445[\pipe\svcctl]" over this connection. (That’s the service control manager, which is used to manage windows services on the target)
- Connect and bind to the service control manager.
If at any point an error was received, log it to the blueprint and continue with the next set of credentials. The first one that succeeds with connecting, logging in, and binding to the service control manager is used as the definitive SMB credential for the rest of the scan.

Step 3: Remote Registry

Remote Registry runs in scan phase.

Connect to the target using previously selected SMB credential (step 2), and if the preference for enabling this service is enabled, try enabling it via the service manager pipe.
Use an SMB client to try fetching all the registry values over a named pipe. Closes the service afterwards if the scanner started it.
Set remote registry authorization status based on whether results were obtained.

Step 4: WinRM Commands

WinRM commands runs in scan phase.

Check if WinRM credentials are provided. Try them, one by one in order, until one manages to successfully execute a echo 'hello world' command and get a literal “hello world" result. This indicates privileges enough to select that credential. Failed credentials will be logged in the blueprint as authentication failures.
Use this credential to attempt to execute all commands. Save their output.
If any output was received, log this to the blueprint. This will be used to determine whether SMB should run.

Step 5: SMB Powershell Commands

SMB Powershell commands runs in scan phase.

Check if WinRM was successful. If it got output, exit early since this would be duplicate work.
Using the previously (step 2) selected SMB credential, run our commands over our SMB Powershell implementation (general information, point 3)'
Save authorization results based on whether output was obtained

Frequently Asked Questions

How does the scanner behave when providing credentials in the WinRM/SMB tab in the scan policy?

The scanner uses the provided WinRM/SMB credentials in the order they are provided provided to attempt authentication with the target. In many cases there is a distinction between successfully authenticating with the target and being authorized to use the credentials to obtain anything of value. In general, we look for the first set of credentials that authenticate and seem to give us permissions to do what we need. WinRM is preferred over SMB, and when provided will be tried first. A failed WinRM will be followed by an equivalent SMB attempt.

What happens if the credentials does not work, or if the credentials and the service manager is not accessible for one of these services?

Early on in the process, the scanner attempts to verify SMB credentials and select one that has a likelihood of succeeding.
Provided credentials that fail to authenticate, or authenticate but without enough permission will not be selected as useful for the rest of the scan.
When verifying credentials that both authenticates and has enough permissions, they are selected and used for the rest of the scan.

The credential worked but got permission denied for the service manager log entry is created when a credential managed to authenticate, but received a RPC_S_ACCESS_DENIED error which indicates a lack of permissions to manage services using those credentials. This does not disqualify the scanner from attempting the next set of provided credentials.

If that failing credential was the only one, then no credentials will be used from that point on which results in an unauthenticated scan.

Why is there findings if WinRM is not enabled on the target and not expected to work?

Because WinRM credentials were provided and failed. The finding exists to indicate that WinRM authentication failed.

If the scan authenticate successfully and can access the service manager once logged in, will it still attempt the WinRM authentication?

If WinRM credentials exist they will always be tried first, and if they succeed SMB authentication and service managers will not be used. The fact that SMB credentials were tried indicate that WinRM either was not attempted or failed. In a SMB authentication-only scan, WinRM will not be tried. Note that an “SMB authentication-only” scan can only be done by setting the authentication on a target level instead of scan policy level.

I have both SMBv2 and SMBv3 enabled, which version and supported ciphers will be used?

We are using a SMB library to do a handshake which should handshake the best protocol and ciphers that both the client and server supports.
If the user wants control what ciphers are used, it is possible to configure that on the target server (according to best practice provided by Microsoft and compliance vendors). The requirement on our scanning components is to always protect customer data in transit with the best available ciphers.

When using WinRM over HTTP (port 5985) for authentication, are credentials exchanged in plain text?

It would not be plain text, it would be encrypted on a message level which is negotiated during the authentication. Furthermore, WinRM typically uses Kerberos for authentication, which also provides encryption. This means that even though it is not using TLS, the data transmitted over port 5985 is still encrypted and not sent in plain text.

Can I run a WinRM authenticated scan on port 5985 over HTTP?

No, to ensure that the data in transit is protected we only support using port 5986 over HTTPS along with an SSL certificate that matches the targeted machine.