6.1 Automated Account Discovery, Detection Rules & Pending Accounts

6.1 Automated Account Discovery, Detection Rules & Pending Accounts

Quick Answer: The CyberArk Account Discovery engine uses the Central Policy Manager Scanner (CACPMScanner.exe) to periodically scan enterprise environments—including Active Directory domains, Windows subnets, Unix/Linux endpoints, and cloud infrastructure (AWS, Azure, GCP)—to identify unmanaged, privileged, and shadow accounts. Discovered credentials are automatically onboarded into production Safes via Automatic Onboarding Rules or staged in the PVWA Pending Accounts queue for review. Onboarding rules evaluate machine address, username patterns, and privileged group memberships to assign target Safes, platform policies, and reconcile accounts, enforcing continuous PAM hygiene without manual intervention.

---

The Account Discovery Engine & Scanner Architecture

Privileged account discovery defends against credential drift and unmanaged administrative sprawl. Administrators frequently provision local administrator accounts, emergency credentials, or test service identities that bypass central governance, creating an unmonitored attack surface for lateral movement.

The core of CyberArk's automated discovery framework is the Central Policy Manager Scanner, executing as a native Windows service named CyberArk Central Policy Manager Scanner (binary: CACPMScanner.exe). Installed on the CPM host, the Scanner operates as an independent background engine governed by parameters in Vault.ini and Scanner.ini.

The CPM Scanner follows an asynchronous pull-and-dispatch operational cycle:

• Task Retrieval: The Scanner queries the Digital Vault over TCP port 1858 to retrieve scan schedules, target subnet ranges, directory search roots, and scan account credentials.
• Probe Execution: The Scanner initiates scan probes against target subnets, Active Directory domain controllers, or cloud APIs using native authentication protocols.
• Vault Staging: Discovered account records are transmitted over TCP port 1858 into an internal staging repository known as the Pending Accounts queue (residing in PasswordManager_Pending).
• Rule Processing: The Vault evaluates discovered metadata against active Automatic Onboarding Rules. Matching accounts are committed to target production Safes under CPM management; non-matching accounts remain queued for review.

In contrast to the continuous CPM Scanner, CyberArk Discovery & Audit (DNA) is a standalone, agentless executable used ad-hoc by auditors to generate static spreadsheets of privileged credential sprawl. While DNA provides point-in-time visibility, the CPM Scanner delivers continuous enterprise detection and immediate lifecycle onboarding.

---

Discovery Sources & Target Protocols

The CPM Scanner leverages four primary discovery vectors across enterprise infrastructure:

1. Active Directory Domain Discovery

Active Directory discovery identifies privileged domain users, service principals, and directory hierarchies. The CPM Scanner connects via LDAP/LDAPS over TCP port 389/636 to Domain Controllers using a dedicated read-only discovery account to enumerate:

• Privileged Group Memberships: Accounts in high-value directory groups, such as Domain Admins, Enterprise Admins, Schema Admins, Account Operators, and Server Operators.
• Account Metadata: Attributes including sAMAccountName, userPrincipalName (UPN), distinguishedName (DN), pwdLastSet, and lastLogonTimestamp.
• UserAccountControl Flags: Flags indicating security states such as DONT_EXPIRE_PASSWORD, ACCOUNTDISABLE, or SMARTCARD_REQUIRED.

2. Windows Network Discovery

Windows discovery identifies local accounts, services, and tasks across IP ranges and organizational units (OUs):

• Protocols: Connects via SMB over TCP port 445, RPC over TCP port 135, and WMI/WinRM over TCP ports 5985/5986.
• Local Administrators: Scans local Security Accounts Manager (SAM) databases to identify members of local Administrators and Remote Desktop Users groups.
• Service Dependencies: Inspects the Service Control Manager (services.exe), Task Scheduler, and IIS application pools to identify embedded service accounts running critical services.

3. Unix & Linux Discovery

Unix/Linux discovery connects to Linux distributions, Unix servers, and network appliances over SSH via TCP port 22:

• Account Enumeration: Scans /etc/passwd and /etc/shadow to detect local accounts, UID 0 root aliases, and active login shells.
• Sudoers Enumeration: Parses /etc/sudoers and drop-in configuration files in /etc/sudoers.d/ to identify non-root users granted unrestricted NOPASSWD or full root delegation privileges.
• SSH Key Trust: Identifies .ssh/authorized_keys and private keys to discover unmanaged trust relationships.

4. Cloud Asset & IAM Scans

Cloud connectors scan AWS, Azure, and GCP over TCP port 443 (HTTPS) using REST APIs to discover IAM users, access keys, console accounts, and ephemeral virtual compute instances (such as Amazon EC2, Azure VMs, and GCP Compute Engine).

---

Evaluation Criteria for Discovered Accounts

When scans conclude, discovered accounts are evaluated against critical risk criteria:

• Privileged Group Membership: Accounts with local administrative rights or directory administrative memberships are prioritized for immediate onboarding.
• Password Age (pwdLastSet): Identifies credentials unchanged for 90, 180, or 365+ days, or flagged with non-expiring passwords, signaling high vulnerability to credential harvesting.
• Account Inactivity (lastLogonTimestamp): Compares last logon activity against current time. Accounts unlogged for 90+ days are flagged as dormant or orphaned accounts.
• Service Dependencies: Differentiates loosely coupled interactive user logins from tightly coupled service accounts running background services or scheduled tasks.

---

The Pending Accounts Queue in PVWA

Accounts that are discovered but not automatically onboarded are staged in the Pending Accounts queue (PVWA: Accounts -> Pending Accounts):

• Attribute Inspection: Administrators inspect account names, network addresses, discovered platforms, privileged group memberships, and detected service dependencies.
• Manual Onboarding: Administrators select pending accounts, click Add Account, and assign them to a production Safe, platform policy, and linked reconcile account.
• Queue Hygiene: Administrators can mark accounts as Ignore (adding them to an exclusion list to prevent rediscovery) or Delete (purging them until the next scan cycle).

---

Automatic Onboarding Rules & Filtering Logic

Automatic Onboarding Rules (PVWA: Administration -> Automatic Onboarding Rules) eliminate manual intervention by programmatically moving discovered accounts into production Safes:

• Machine Address Filter: Matches targets by IP subnets (CIDR notation), Active Directory computer OUs, or FQDN wildcards (*.corp.example.com).
• Account Name Pattern: Uses regular expressions or wildcard patterns (e.g., adm-*, *_admin, svc_*).
• Privileged Status Filter: Filters exclusively for accounts belonging to designated privileged groups (e.g., local Administrators or Domain Admins).
• Target Safe & Platform Assignment: Specifies the destination Safe and target platform policy governing password complexity and rotation frequency.
• Reconciliation Binding: Automatically associates a pre-configured Reconcile Account so the CPM can reset out-of-sync credentials immediately without administrative intervention.

---

Onboarding Strategy: Direct Production vs. Review Queue

Determining whether to onboard directly or route to the Pending Accounts queue is a fundamental PAM governance decision:

Local administrator accounts on standardized endpoints should be onboarded directly via Automatic Onboarding Rules to enforce instant password rotation. Service accounts with dependencies must be staged in the Pending Accounts queue until all service instances and scheduled tasks are mapped to prevent service outages.