BI.ZONE SOC reports that Microsoft Configuration Manager (SCCM) is deployed in 25% of Russian organizations, primarily large enterprises. Due to its centralized control over servers and workstations, a compromise of SCCM often grants an attacker full control over the company's infrastructure, including administrative privileges and the ability to execute arbitrary code on any managed device.
Security risks often stem from configuration errors. Experts recommend isolating Site Server, SMS Provider, and Site Database Server roles in the most secure network segment (Tier 0) and using jump hosts for administrative operations. It is advised not to combine these roles on a single server with roles that interact directly with clients, and to use dedicated servers in the DMZ for external devices.
Database security is critical as the site database stores system parameters and secrets in the SC_UserAccount table. A separate SQL instance for the SCCM database is recommended, with strictly limited access for users, including those with sysadmin rights, to prevent unauthorized privilege escalation to infrastructure administrator level.
The Network Access Account (NAA) presents a significant vulnerability because its password is stored on managed devices and can be decrypted by local administrators using tools like Mimikatz. The primary recommendation is to disable NAA in favor of HTTPS or Enhanced HTTP. If NAA must be used, it should be a dedicated service account with minimal privileges and restricted login rights.
Client Push Accounts used for automatic agent installation should also be isolated. It is recommended to use separate service accounts for different security tiers (e.g., workstations vs. servers) and avoid adding these accounts to Domain Admins. Instead, security groups should be used to grant local administrator rights via Group Policy.
Finally, the site server computer account should be audited to remove excessive privileges, such as membership in Domain Admins or Enterprise Admins. For OS deployment task sequences, separate accounts should be used for different security boundaries, and domain-joining accounts should be restricted to specific temporary Organizational Units (OU) with limited permissions.
