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 private 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

Note: Additionally, the user account performing the authenticated scan must have permissions to connect to the host via SSH server.

Installing the OpenSSH Server

Refer to your Linux distribution vendor documentation 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.

    Note: Permitting WMI access over the Distributed Component Object Model (DCOM) network is not necessary to perform authenticated scans for USM Anywhere.

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 each time you boot the server.

Note: In addition, you must have the Windows Remote Registry service enabled on each asset you want to scan. When not in use, this service stops after 10 minutes and authenticated scans will not be able to scan Windows registries while service is stopped. To prevent the service from stopping when idle, the following registry needs to be set to 1 on the Windows endpoints:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry\DisableIdleStop

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.

Warning: While any account that is a member of the "Remote Management Users" group can perform some of the required actions, AT&T Cybersecurity strongly recommends using an admin account with all of the attendant privileges. While some operations will work without explicit admin rights, other operations require admin-level privileges and will return an "unknown", "error", or "fail" message without them.

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

  • This account needs to be able to create temporary files and temporary registry values.
  • This account must have remote and local logon 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 then 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 these steps for Allow log on through Remote Desktop Services.

Enabling Remote Registry on an Asset

USM Anywhere requires that the Windows Remote Registry service is enabled on every asset you intend to scan. While the scan will run without Remote Registry enabled, it will be an incomplete scan as some definitions may not be evaluated.

Note: These instructions are to enable Windows Remote Registry on one asset. Enabling Remote Registry from group policy is possible, but those instructions will depend on your environment. See these steps for an example of that process, though your environment may require different steps.

Enabling Remote Registry on an Asset

  1. Open the Control Panel on the asset you intend to scan.

  2. Select Administrative Tools.

  3. Select Services.

  4. Right-click the Remote Registry Service, and then select Properties.

  5. Under Startup Type, use the drop-down menu to select Automatic.