SCCM Misconfigurations Expose Organizations to Full Infrastructure Takeover
Microsoft Configuration Manager, commonly known as System Center Configuration Manager (SCCM), is widely deployed across Russian enterprises and serves as a high-value target for attackers. According to BI.ZONE SOC data, the platform operates in 25 percent of Russian organizations, predominantly large ones managing thousands of devices. Successful compromise typically grants full infrastructure control, enabling administrative privilege acquisition, lateral movement, user and device reconnaissance, persistence through arbitrary code execution, and policy manipulation.
Core Principles for Secure SCCM Deployment
Proper infrastructure planning at the deployment stage significantly reduces the attack surface. Site Server, SMS Provider, and Site Database Server roles must reside in the most protected Tier 0 network segment. Clients should never interact directly with these roles. Separate servers in a DMZ are required for external clients, and administrative operations should be performed exclusively via jump hosts.
Active Directory tiering must be respected: a single SCCM hierarchy should never manage assets from multiple forests or security tiers. Separate isolated SCCM infrastructures are recommended for Tier 0 assets such as domain controllers and hypervisors.
Least Privilege for SCCM Service Accounts
The Network Access Account (NAA) should be decommissioned wherever possible. Its credentials are stored encrypted on every managed client and can be extracted by local administrators using SharpSCCM, SharpDPAPI, or mimikatz. Organizations are advised to switch to HTTPS or Enhanced HTTP on distribution points and disable all previously used NAA accounts in Active Directory.
When NAA cannot be removed, the account must be a dedicated service account with minimal rights, interactive and remote desktop logons disabled, and monitored via Event ID 4624/4625 type 3 entries originating only from distribution point servers.
The Client Push Account used for forced client installation must also follow strict controls. Separate accounts should be created for different security tiers, added only to necessary local administrator groups via Group Policy, and never placed in Domain Admins. Source IP monitoring is required to detect anomalous usage.
Computer accounts of site servers and accounts used for domain join operations during operating system deployment sequences require similar restrictions. Domain join accounts must receive delegated rights only on temporary organizational units and must never reside in privileged groups.
Common Misconfigurations and Remediation
Absence of network isolation for PXE deployments remains one of the most critical vectors. Attackers who can boot devices over the network can extract credentials from task sequences or boot images. Database access must be limited to a dedicated SQL instance with the smallest possible number of sysadmin users, as the SC_UserAccount table stores recoverable secrets.
Administrative access to the SCCM console should be granted only to named accounts with appropriate security roles, avoiding generic service accounts that complicate incident investigation.
Related articles
Critical Vulnerability in ASUS Control Center Enterprise Allows Remote Root Access Without Authentication
ASUS has disclosed a severe vulnerability in its terminal management software ASUS Control Center Enterprise (ACC) that could allow unauthenticated remote attackers to obtain root privileges. The issue, tracked as CVE-2026-75754, stems from a combination of hardcoded credentials, missing authentication on critical functions, and server-side request forgery flaws. Attackers can retrieve encryption keys via unauthenticated HTTP requests and then enable SSH on TCP port 2222 using the hardcoded credentials to log in as root. The flaw affects managed devices across an organization, potentially leading to data leakage, tampering, deletion, and full remote control. ASUS released a security advisory on September 4, 2026, and strongly recommends immediate updates. The vulnerability was reported by Security NEXT on September 7, 2026.
Top 10 Security Stories: Critical Flaws in PaperCut NG/MF, Chrome, WatchGuard and Others Dominate Week
Security NEXT has published its weekly ranking of the ten most-read articles between August 30 and September 5 2026. The list is led by a critical vulnerability in PaperCut NG/MF that is already being exploited in the wild. Google Chrome received two separate updates addressing 38 vulnerabilities, including two rated Critical and one zero-day. WatchGuard Fireware OS, SonicWall SMA 1000, Cisco IOS XR and Apache Tomcat also received urgent patches for severe flaws. Three real-world incidents made the top ten: a customer-data breach at 01 Bank, a ransomware infection at Hands HD and a suspected cloud leak at Corona. The ranking reflects strong reader interest in both newly disclosed vulnerabilities and confirmed exploitation cases.
CVE-2026-85046 Exploited in Chromium V8 Engine, Affecting Chrome, Edge and Other Browsers
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added CVE-2026-85046 to its Known Exploited Vulnerabilities catalog after confirming active exploitation in the wild. The flaw resides in the V8 JavaScript engine of Chromium and stems from a type confusion issue that can allow arbitrary code execution inside the sandbox when a crafted HTML page is processed. Google released a patch for Chrome on September 3, 2026, while the vulnerability carries a CVSS v3.1 base score of 8.8 and is rated High severity. Because numerous browsers including Microsoft Edge, Opera, and Vivaldi are built on Chromium, they are potentially exposed until their respective vendors issue updates. Security teams are advised to verify that all Chromium-based browsers in their environments have been updated to the latest versions containing the fix.
Gmail Address Variants Bypass String Comparison and Enable Multiple Registrations
A single user created four separate accounts using valid Gmail address formats that all deliver to the same inbox: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, and IVAN.PETROV@gmail.com. Simple string comparison in the registration code treated these as distinct entries, allowing circumvention of new-user promotions, free-tier limits, and one-application-per-person rules. The root cause lies in three Gmail-specific behaviors: case-insensitive local parts, plus-addressing that ignores everything after the + symbol, and dots that carry no semantic meaning in the local part. Additional risks arise from IDNA homograph domains that visually mimic legitimate addresses but encode to different Punycode strings. Proper mitigation requires storing both the original email for delivery and a domain-aware normalized form for uniqueness checks, combined with explicit IDNA validation on registration.