Sophos Managed Risk: Configure credentials for authenticated scans

During an authenticated internal vulnerability scan, the scanner signs in to the target system. This allows it to inspect local files, registry entries, installed software, and configurations that are not visible to a scan without credentials. It therefore usually finds more vulnerabilities. An unauthenticated scan remains useful, however: it more closely reflects what an external attacker without an account could reach.

The safe procedure consists of four steps:

Prepare a dedicated scan account with the permissions required for the intended checks.
Make the target operating system accessible over SMB/WMI or SSH.
Create the appropriate credential type under Managed Risk > Settings > Credentials > Add credential.
Assign the credential to an internal vulnerability scan with Scan type: Authenticated and validate the result in the next scan.

Prepare target systems before using Sophos Fusion

Preparation takes place directly on the Windows, macOS, or Linux target and is separate from entering the credentials later in Sophos Fusion. Even a correctly completed Fusion form cannot compensate for missing shares, services, or permissions on the target.

Windows

For Windows endpoints and servers other than domain controllers, use a dedicated local account in the local Administrators group. Domain controllers, by contrast, require a domain administrator and belong in a separate scan with their own credentials. This prevents the more powerful account from being used on member servers or clients.

Check the following before assignment:

Security policies such as Deny access to this computer from the network and Access this computer from the network, other local policies, endpoint protection, and IPS/IDS must not block the intended credential checks.
Some local checks require PowerShell 5.0 or later.
The scanner requires SMB and WMI access. The host firewall must allow connections from the IP address of the Managed Risk scanning appliance; TCP ports 139 and 445 are relevant for File and Printer Sharing. Ports for other services to be checked must also be reachable from the scanner.
The administrative shares IPC$, ADMIN$, and C$ must be available.
Remote Registry must be running or must be startable with the administrative permissions used for the scan.
For the documented Windows account scenarios, Network access: Sharing and security model for local accounts must be set to Classic - local users authenticate as themselves. This applies both to a domain account used for local audits and to a local account; signing in as a guest is not sufficient for local security checks.
For local accounts, UAC must not filter the remote administrator token. The documented options are to disable UAC or set the DWORD value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy to 1. Make such a security change only through the internal change process and limit it to the affected systems.
For WMI, enable the predefined inbound rules Windows Management Instrumentation (ASync-In), Windows Management Instrumentation (WMI-In), and Windows Management Instrumentation (DCOM-In). Where possible, restrict the rules to the scanning appliance’s IP address.

Do not replace these requirements with a broad firewall rule open to arbitrary sources. If the scanning appliance and a target are in different VLANs, the scan specification requires the appliance to have full bidirectional access to all ports and protocols in the target VLAN. Routing and intermediate firewalls must permit that access; restrict the rules to the appliance and the intended target ranges.

macOS

macOS targets are checked over SSH, either with a key pair or with user credentials and sudo or su. For complete local checks, the scan account must be a member of the administrator group and have Full Disk Access. Fewer permissions can still allow individual checks, such as determining the patch level, but not the same depth of inspection. The dedicated account must use the same username on every intended macOS target; prefer key-based access over user credentials where possible.

The following prerequisites apply before the scan:

Enable Remote Login and allow the dedicated scan account.
In the Remote Login system setting, enable Allow full disk access for remote users. Also grant Full Disk Access under Privacy & Security to both documented processes: /usr/libexec/sshd-keygen-wrapper and /Library/NessusAgent/run/sbin/nessus-service.
For Kerberos, sshd must support Kerberos, use the gssapi-with-mic interaction method, and have working reverse DNS.
The SSH server and scanner must share a supported cipher. The documented ciphers are blowfish-cbc, aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc, and AES-CTR. Do not broadly enable obsolete encryption just for the scan; first check for an existing secure common option.
For key-based access, place the public key in authorized_keys for the dedicated account and provide the private key to the scanner only in protected form.

Linux

Linux targets are also checked over SSH, with either a key pair or user credentials and sudo or su. For the greatest possible depth of inspection, the account must be able to run commands with root privileges. A less privileged account can provide partial results but cannot fully cover configuration and file checks.

Check the following before the scan:

Create a dedicated SSH user with exactly the same name on all intended targets. For key-only authentication, the account must have no valid password; place the public key in authorized_keys, and keep the private key protected on the scanner.
Allow the SSH connection and intended privilege elevation from the scanning appliance’s network.
For Kerberos, sshd must support Kerberos, use gssapi-with-mic, and have working reverse DNS.
The scan account’s shell configuration requires a PS1 variable of at least four characters. A very short prompt such as PS1='$ ' can significantly slow the scan.
The documented SSH cipher options are the same as for macOS. Use existing secure common algorithms and do not expand the host configuration unnecessarily.

General SSH host preparation may support more modern key types. In Managed Risk > Settings > Credentials, however, Public Key currently accepts only RSA and DSA keys in OpenSSH format. A key type not supported there therefore cannot be made usable by changing the target system.

Create a credential in Sophos Fusion

Under Managed Risk > Settings, open the Credentials tab and select Add credential. In Create credential, first select the type. Plaintext authentication is not supported.

SNMPv3

SNMPv3 is intended for network devices using SNMP version 3. Complete the following fields:

Credential type: SNMPv3.
Credential name: a unique name, for example snmpv3-core-switches.
Description: an optional note about the intended device scope.
Username: the SNMPv3 account user.
Port: 161 by default; change it only if the target provides SNMPv3 on another port.
Security Level: Authentication and privacy. This combination of authentication and encryption is currently the only option.
Authentication algorithm: SHA-256, SHA-384, or SHA-512, matching the target configuration.
Authentication password: the SNMPv3 account’s authentication password.
Privacy algorithm: AES-256 or AES-256C, matching the target configuration.
Privacy password: the SNMPv3 account’s privacy password.
Select Create to save.

Windows

For Credential type: Windows, first enter a unique Credential name and, optionally, a Description. Then select one of the three options under Authentication method:

Kerberos: enter Username, Password, Domain, Key Distribution Center (KDC), KDC Port (default 88), KDC Transport (TCP or UDP), and Realm.
NTLM Hash: enter Username, Hash, and Domain. Treat an NTLM hash like a password and never include it in diagnostic material.
Password: enter Username, Password, and the optional Domain if required.

Select Create to save. For local accounts, the user must match the relevant target; for domain controller scans, use the domain administrator credentials reserved for that purpose.

SSH for Linux and macOS

For Credential type: SSH, enter a unique Credential name, optionally a Description, and then select the Authentication method:

Kerberos: enter Username, Key Distribution Center (KDC), KDC Port (default 88), KDC Transport (TCP or UDP), and Realm.
Password: enter Username and Password. Select Elevate privileges with only if the prepared target configuration requires it.
Public Key: enter Username. Under Private key, use Add File to upload the private key file or paste the key directly. Only RSA and DSA keys in OpenSSH format are supported. For a protected key, also enter the Private key passphrase.

For Public Key, select Nothing or sudo under Elevate privileges with. For sudo, also enter sudo user and, if required, sudo password. The account and selected elevation must match the prepared configuration on the target.

Optionally, enter hostnames, IP addresses, or CIDR blocks under Targets to prioritize this public-key credential for those targets. Separate multiple values with commas or spaces. This prioritization replaces neither the scan’s target definition nor the credential selection in the scan.

Select Create to save.

VMware ESX SOAP API

This type is intended for VMware ESX/ESXi hosts:

Credential type: VMware ESX SOAP API.
Credential name: a unique name.
Description: an optional note about the intended hosts.
ESX SOAP API Authentication Method: Username and Password. This is currently the only option.
Username: a VMware account with administrative access to the ESX/ESXi host.
Password: the password for this account.
Select Create to save.

For comprehensive checks, this account requires administrative access to the host. The credential is intended for VMware virtualization environments, not for Windows or SSH targets inside the VMs.

Assign the credential to an authenticated scan

Saved credentials do not trigger a scan by themselves. Under My Products > Managed Risk > Scans > Internal, create an internal vulnerability scan and configure it on the Create Vulnerability Scan page as follows:

Under Select scanner, select the connected scanning appliance.
Under Configure scan details, enter a name and description.
Set Scan type to Authenticated.
Under Select credentials, select the appropriate credentials. Each scan can use no more than ten credentials.
Under Add scan targets, enter the intended IP addresses, CIDR ranges, or hostnames and select Add. Confirm individually entered values with Enter; pasted lists must be comma-separated.
Under Schedule the weekly scan, set the day, time, and time zone, and then select Save in the upper-right corner.

Separate credentials by operating system, trust zone, and protection requirement. In particular, a domain administrator credential does not belong in a broad scan of ordinary Windows clients. If more than ten credentials are required, divide the target scope into understandable scans instead of merging credentials or extending permissions.

Test the Windows credential before the next scan

The documented credential tests currently apply only to Windows. Run them from a Windows system in the same subnet as the scanning appliance and with exactly the same credentials. This reproduces the scanner’s network conditions as closely as possible.

Open Command Prompt or PowerShell as an administrator. In the example, 192.0.2.25 is a documentation address and must be replaced with the target system’s internal IP address. LAB-SRV-025\svc_mrisk is an example local account; for a domain account, use the DOMAIN\User format with your own values instead.

Check IPC$ and ADMIN$

net use \\192.0.2.25\ipc$ /user:LAB-SRV-025\svc_mrisk *
net use \\192.0.2.25\admin$ /user:LAB-SRV-025\svc_mrisk *

Enter the password at the masked prompt after each command. The command completed successfully confirms the credentials and the respective SMB access for this test. Success for ADMIN$ also shows that the account has administrative share access.

Check Remote Registry

reg query \\192.0.2.25\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir

A registry line for ProgramFilesDir confirms that Remote Registry is reachable over the existing session. For The network path was not found, first check the service, SMB path, and firewall; for Access is denied, check account permissions, the UAC remote token, and the identity actually in use.

Check WMI

wmic /node:"192.0.2.25" /user:"LAB-SRV-025\svc_mrisk" /password:* os get name

Enter the password only at the prompt. An operating system name under Name confirms WMI access for this test. If wmic is unavailable on the Windows version in use, do not use an untested replacement command. Instead, check the WMI firewall rules and host preparation, and perform the actual validation in the next Managed Risk scan.

Always clean up sessions

After the test, remove both connections even if an intermediate step failed:

net use \\192.0.2.25\ipc$ /delete
net use \\192.0.2.25\admin$ /delete

Then use net use to confirm that no connection to the test target remains listed, and close the administrative terminal.

Validate the result in the next scan

After the next scheduled run, check under Managed Risk > Report History whether the internal vulnerability report was created. Authenticated results are generally more detailed than unauthenticated results. A particular number of findings is not a success criterion, however: the operating system, open ports, installed software, plugins used, and scan type all affect the result.

For a reliable check:

Confirm that Scan type: Authenticated and the intended credentials are selected in the scan.
Ensure that the target systems are within the scan scope and reachable from the scanning appliance.
For Windows, first check the four areas IPC$, ADMIN$, Remote Registry, and WMI.
For Linux and macOS, check SSH reachability, key or Kerberos configuration, and the intended privilege elevation.
Check host and intermediate firewalls for traffic blocked from the scanning appliance’s IP address.
Only then change credential fields and validate them again in the next scan.

If the results still resemble an unauthenticated scan or remain unexpectedly incomplete, create a request for the Managed Risk team under Threat Analysis Center > Cases > Create case > Managed Risk service request. Include the scan name, time window with time zone, scanner name, target type, credential type, affected anonymized targets, observed result, and checks already performed. Do not attach passwords, hashes, private keys, or complete sensitive console output.

Edit or delete credentials

To edit a credential, go to Managed Risk > Settings > Credentials, open the three-dot menu in the Actions column, select Edit, adjust the fields, and select Update to save. Validate the change in the next intended scan.

Before deleting a credential, first check every scan configuration that uses it. Then select Delete from the same three-dot menu and permanently delete it by selecting Confirm in the dialog. Deletion removes the credential from all scan configurations in which it was used and can affect their future authenticated runs. Then open each affected scan, check the remaining credential selection, and assign a prepared replacement credential if necessary.

The refresh icon in the upper-right corner reloads the credential list. It confirms that the list view has been updated, but not that a credential works on a target; only the test or the next scan provides that evidence.