SCCM Architecture and Why It Is a High-Value Target

▶ Watch (03:29)

SCCM is Microsoft’s on-premises solution for managing Windows hosts across corporate environments. Every byte of configuration passes through WMI classes on the site server before landing in a SQL database. Clients receive policy through management points and pull files from distribution points. That central database holds almost everything — accounts, policies, deployment commands — which makes the site server the single most valuable machine in any domain SCCM manages.

“STSM is a system where some malware can be defined on one computer but execute on another. It’s really breaks the kill chain.” — Alexander Rodchenko

Recon Techniques Against SCCM Infrastructure

▶ Watch (08:24)

SCCM installation extends Active Directory with a System Management container and MSS/SMS-prefixed classes. Any domain-joined machine can read that container. Attacker tools query it to locate the site server before touching a single endpoint.

Two more paths require no credentials. Management points answer HTTP with STM and POST options that reveal which clients connect. Distribution points expose SMB shares named with “SMS” or “SCCM.” An attacker watching either channel maps every managed host. Rodchenko’s summary: “It’s just recon.” The damage comes later.

Stealing the Network Access Account

▶ Watch (14:20)

PXE boot media embeds the Network Access Account because a bare machine has no OS identity. Download the TFTP media, extract it, recover the credential. Second path: any domain user can register up to 10 AD computer objects. Create one with a known password, request policy, receive the encrypted NAA blob, decrypt it. Fake objects are detectable. They carry no MAC address. Third path: read \Repository\OBJECTS.DATA via WMI and decrypt the blob with the machine key. The NAA should never appear in a console or RDP session, and no process should run under it.

Credential Extraction from the Site Database and Client-Push Abuse

▶ Watch (21:20)

The SCCM site database stores every password blob in SQL, and Mimikatz has a module that pulls them out and decrypts them using DPAPI keys from the same server. SQL account credentials, the NAA, and other service accounts all sit there. You need local admin on the database server to reach them, but once you have it, everything is readable. Build a list of every account SCCM uses and alert when any of them logs in interactively or spawns a process outside expected behavior.

Client-push installation makes this worse. SCCM flips its own client-server model: the site server reaches out to endpoints to force-install the client agent. That account either has domain admin by default or grants an attacker a direct escalation path. Rodchenko’s advice is blunt — disable client-push entirely.

Takeover and Domain-Wide Execution via SCCM

▶ Watch (23:43)

Takeover attacks use coercion (PetitPotam, EFS tricks) to force the SCCM site server to authenticate against an attacker-controlled service. One SQL request is all it takes to promote an unprivileged user to full site admin. Once there, an attacker can push any application or script deployment to every machine in the domain simultaneously. Microsoft even recommends disabling antivirus scanning on the SCCM scripts folder, meaning an attacker can deploy Invoke-Mimikatz domain-wide and no scanner fires.

“who of you see only one uh single uh security alert from SSM? Security alert from SSM server. For example, suspicious deployment created, suspicious script deployment created, suspicious account created, nobody.” — Alexander Rodchenko

SCCMInfo: WMI-Based Real-Time Detection Demo

▶ Watch (31:18)

SCCMInfo (sccminfo.exe) runs on the site server and subscribes to WMI instance-creation events. Each new deployment fires a callback the moment it lands — no poll cycle, no missed objects. SharpSCCM deployment captured live: SharpSCCM pushed a ping-to-Google application to all hosts, SCCMInfo fired immediately, enriched the event with the application name and target client list, and wrote it to the Windows Application log.

The SQL-diff alternative fails. A before-and-after dump from a single deployment produced SQL diff reveals half-megabyte delta for one command. The relevant command was buried inside an XML blob labeled “application management digest.” Unworkable.

Q&A

Can the network access account be hardened, and do co-managed or Intune-only environments face the same risks? Rodchenko confirmed the NAA can be hardened by blocking interactive and RDP logons and whitelisting the hosts it may authenticate from, but said he does not know whether co-managed or Intune-only environments are exposed. ▶ 40:58

Notable Quotes

STSM is a system where some malware can be defined on one computer but execute on another. It’s really breaks the kill chain. Alexander Rodchenko · ▶ 39:38

who of you see only one uh single uh security alert from SSM? Security alert from SSM server. For example, suspicious deployment created, suspicious script deployment created, suspicious account created, nobody. Alexander Rodchenko · ▶ 29:58

just because it’s really weird. So, uh seems everything working well. Alexander Rodchenko · ▶ 38:01

Key Takeaways

  • Disable SCCM client-push installation entirely — it inverts the client-server trust model and hands attackers a ready escalation path.
  • Monitor NAA usage at login and process-start time; any interactive or RDP logon under that account signals compromise.
  • Use WMI instance-creation subscriptions on the site server to catch malicious deployments in real time — SQL polling will miss ephemeral objects.

About the Speakers

Gleb Ivanov

My name is Gleb. I lead a team focused on researching targeted attacks. Previously, I worked in a Security Operations Center (SOC), where I was involved in threat research, incident response, and day-to-day operations. Today, my team and I are responsible for developing detection logic for EDR, improving telemetry coverage, and advancing our XDR capabilities. I’m passionate about both the technical side of cyberattacks and building effective detection and response processes.

Alexander Rodchenko

Rodchenko Alexander is a Senior SOC Analyst at the SOC Security Research Group at Kaspersky. He began his career at OJSC Rosneft, focusing on industrial safety, troubleshooting, and audits. Currently, he investigates industry events and trends with the primary goal of integrating these insights into monitoring and threat hunting practices. Leveraging his extensive expertise, Alexander advises customers and threat detection/hunting teams on the optimal response to emerging threats and trends. In addition to speaking at Positive Hack Days (twice) and BSides Zurich 2023, he has also been a speaker at CodeBlue 2024 and BlackHat MEA 2024.