Agentless endpoint access is achieved through the use of native remote management protocols like WMI, SMB, Remote Scheduled Tasks, and PSRemoting for Windows-based systems and SSH for Linux-based systems. This methodology is appropriate for centrally managed networks where you don't want to install permanent agents or don't want to make permanent changes to the systems (this bypasses most organizations’ more stringent Change Control processes since it isn't producing a change to the baseline of the system).
Agentless collection utilizes credentials that are defined in Infocyte’s Credential Manager. This requires a service account or administrative credential with Administrator-level rights on each of the target endpoints. SSH Credentials can be Key-based or Username/Password or both. The SSH account must be part of the sudo group (should not be the root account). These are encrypted using a server-side key by default but can also utilize a client-side encryption (AES Key) generated by the Controller to further protect the credentials.
Authenticated scans against remote systems require an administrator (or sudo for Linux) account or an account with Local Administrator privileges on each remote system you intend to scan. These account credentials are stored in the Console’s Credential Manager and can be entered in the Admin panel or during query creation.
Credentials stored by Infocyte’s credential manager are protected using strong industry-standard encryption, options for Client-side Encryption using an AES key generated by the Controller can also be utilized for further protection.
The simplest method is to create a Service Account for Infocyte with domain administrator privileges or sudo credentials / SSH keys for linux to perform scans.
UNDERSTANDING WINDOWS PERMISSIONS:
When scanning within a Microsoft Active Directory or LDAP Domain, Infocyte will require specific permissions that allow remote administration for endpoint survey deployment. Before beginning it is important to understand the different levels of “administrator” level permissions and what access they give when using it for authenticated scanning.
The following is a definition of each Windows Administrator roles:
Members of this group, like the built-in Administrator account (SID 500) or SYSTEM, have full control of the local system that they pertain to.
On Domain-Joined windows systems, the local Administrator account (SID 500) is disabled for remote authentication by default. Utilizing a Domain Account with membership in the Local Administrators group is recommended.
On Non-Domain (Unmanaged) systems, you may run into User Access Control (UAC) filtering which downgrades privileges when authenticating remotely. You can bypass this by using the built-in Administrator account (SID 500) or by flipping the LocalAccountTokenFilterPolicy.
Members of this group have full control over all systems within its respective domain. Systems may include: domain controllers, member servers, and workstations.
A common least privilege best practice for authenticated scans of this type is to create a domain account and place it within the Local Administrators group of the target systems you intend to scan via Group Policy. This will ensure appropriate remote access to the targeted systems while restricting the account from more sensitive domain administrator activities. When considering what permissions and configurations you will use, consult your network administrator for any local policies around least privilege and privileged accounts management.
On non-domain (unmanaged) assets, Local administrator accounts other than the built-in Administrator account (SID 500) may not have rights to manage a server remotely, even if remote management is enabled. The Remote User Account Control (UAC) LocalAccountTokenFilterPolicy registry setting must be configured to allow accounts of the Local Administrators group other than the built-in administrator account to remotely manage the server.
To disable UAC remote restrictions, change the registry value of "LocalAccountTokenFilterPolicy" to 1:
If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:
- Open regedit.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
- On the Edit menu, point to New, and then click DWORD Value.
- Type LocalAccountTokenFilterPolicy, and then press ENTER.