USM Anywhere™

System Settings for Authenticated Scans

An authenticated scan is a vulnerability testing measure performed from the vantage of a logged-in user. The quality and depth of an authenticated scan depends on the privileges granted to the authenticated user account. The following table lists the recommended settings for creating a designated account on different operating systems (OSes). See Creating Credentials for information about creating credentials for authenticated scans in USM Anywhere.

Escalation Options for Authenticated Scans by OS
Operating System Methods and Credentials Escalation
Linux SSH Program to securely log into another computer over a network, execute commands in a remote machine, and move files from one machine to another through Secure Copy (SCP). password or public key authentication sudo, su

Microsoft Windows username and password through Microsoft Windows Remote Management (WinRM)


Requirements for Linux

You must have the following on the Linux host to perform an authenticated scan:

  • The OpenSSH server installed
  • Network connectivity between the USM Anywhere Sensor and the SSH port on the Linux host

Installing the OpenSSH Server

Refer to the vendor documentation for your Linux distribution for instructions on how to install and configure the OpenSSH server:

Requirements for Windows

For Microsoft Windows hosts, USM Anywhere uses Windows Remote Management (WinRM) to perform authenticated scans. Therefore, you need to have the following items on the Windows machine:

  • WinRM version 2.0 or later.
  • PowerShell version 5.1 or later. USM Anywhere performs some tests prior to running the authenticated scans to make sure that the scans can succeed. These tests require PowerShell 5.1 or later to be installed on your machine.

  • Port 5985 open on your firewall. WinRM listens for HTTP traffic at port 5985 by default. Make sure that your firewall allows incoming connections through this port.

  • The Windows Management Instrumentation (WMI) service enabled. WinRM supports WMI classes and operations. It also leverages WMI to collect data about disks, network adapters, services, or processes in your environment.

In addition, using the Group Policy Editor, go to Computer Configuration\Administrative Templates\Windows Components\Windows Remote Shell, and make these changes:

  • Enable Allow Remote Shell Access.
  • Set the MaxConcurrentOperationsPerUser parameter to at least 3, ideally 10 or 15.
  • Set the MaxMemoryPerShellMB parameter to 1024.

See Microsoft Documentation for more information on WinRM parameters.

Important: For a Windows server that is hardened according to the Center for Internet Security (CIS) benchmarks, such as the CIS Amazon Machine Image (AMI) for Windows Server 2016 available in the Amazon Web Services (AWS) Marketplace, there are local group policies that block these connectivity requirements. For these servers, you must open the port and re-enable WinRM and remote access on each boot of the server.

Creating a Windows Admin Account

AT&T Cybersecurity recommends that you create a designated admin account solely for the authenticated scans rather than using an established admin account or a guest account. The most important aspect about Windows credentials is that the account used to perform the scans should have privileges to access all required files and registry entries, which in many cases means administrative privileges.

When creating such an account, you must keep in mind the following:

  • This account must have write permissions.
  • This account must have remote and local log-on rights. See Setting Log-on Locally and the Security Policy for more information.
  • If using Active Directory (AD), assign user rights to either the Remote Management Users group or the Administrators group, because only these two groups can log in through WinRM. This authentication uses sAMAccountName, which is limited to 20 characters.

  • When configuring network access policy for this account, select Classic: local users authenticate as themselves.
  • If your machine is joined to a domain, a local account won't be able to log in. In this case, you must add a new registry named LocalAccountTokenFilterPolicy:

    Path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

    Value Name: LocalAccountTokenFilterPolicy

    Type: DWORD

    Value: 1

See Microsoft Documentation for a better understanding of Windows authentication for remote connections.

Setting Log-on Locally and the Security Policy

USM Anywhere enables you to add a WinRM credential. The account you use to log on to the target system must have remote and local logon rights.

Note: Set the local logon rights to avoid large numbers of processes and large amounts of memory usage.

Important: The vulnerability scan needs to be able to perform a local logon on the target device because it needs to create a "delegatable" identity token to access domain resources from its session on the target device. Although it is possible to run a scan without having the local logon privileges and without the correct token, the attempts to collect certain information can fail with errors, for example "Access Denied", which might impact the rule results.

To set the local logon rights1

  1. Select Start > All Programs > Accessories > Run and enter gpedit.msc to open the Local Group Policy Editor.

    Edit Group Policy

  2. In the console tree, select Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

    Local Group Policy Editor

  3. Click Allow log on locally to open its properties.

    The Log On Properties

  4. Assign the rights to your user.
  5. Click OK.
  6. Repeat the steps for Allow log on through Remote Desktop Services.