Using a Microsoft-Tool for Software- and patch-distribution can’t be wrong, can it? I have tried a while to come up with a couple of good reasons to use SCCM, but after this mental exercise I just feel less inclined to recommend it.
The Redmond company has invested many a Dollar in making randomness part of our operating systems. As a test, start off with three computers, same build and model, identically configured and install the OS on them at the same time, only to see that the automated (non SCCM-driven) update-process for each of them takes a different turn – a wonderful proof of the randomness in Microsoft enhancing our dull lives with the IT equivalent of a one-way, dead-end street ever so often.
The same company brings us a wonderful patch- and release-management tool:
“SCCM is a platform that allows for an enterprise to package and deploy operating systems, software, and software updates. It allows for IT staff to script and push out installations to clients in an automated manner. You can kind of think of it as a customizable, scriptable WSUS.” -Matt Nelson, Veris Group
SCCM operates in a “Client-Server” architecture by installing an agent on workstations/servers that will check in periodically to its assigned site server for updates. On the backend, SCCM uses a SQL database and WMI classes to store and access various types of information. (Source)
In a perfect world, such an institution would increase the health, security and availability of our systems.
As it turns out, the world we live in is not exactly what we can call perfect. Not even close. This is, where the randomness comes as a bit of an additional hindrance to arrive at the level of health, security and availability we desire for our systems – especially in a case, where we are not dealing with a red team in a Red Team engagement, but with real organization data predators. We do replace the update randomness by installing an even more worrisome vulnerability.
In short this is the risk: “If you can gain access to SCCM, it makes for a great attack platform. It heavily integrates Windows PowerShell, has excellent network visibility, and has a number of SCCM clients as SYSTEM just waiting to execute your code as SYSTEM.”
Think about what a malicious actor in an IT-service organization could do after getting access to SCCM. Think about inserting payloads. Check out PowerShellEmpire for more information.
For any attacker that has gained domain admin to a network, using any centralized administration software that is part of the Microsoft universe and is actively participating in it, is like finding the golden pot at the end of the rainbow. An attacker can find nodes and map out the network, see where users spend most of their time and find critical assets.
So it didn’t take long before someone came up with some smart ideas on how to deploy payloads and manipulate the assets by using SCCM. In order to interact with SCCM, you need to have administrative rights on the SCCM server, however you do not need to have domain administrative rights on the network. SCCM is a cornerstone for an attacker to stay under the radar in a Red Team situation, e.g. to persist in the network after elevated access is achieved. PowerSCCM is one of these nifty developments Red Team members came up with (in this case, check out enigma0x3 – you might actually find more than you expected).
It takes a few steps to deploy malicious packages/scripts to clients through SCCM, and offensive manipulation/deployment is only currently supported through WMI SCCM sessions. SCCM deployments need three parts- a user/device collection of targets, a malicious application to deploy, and a deployment that binds the two together.
As a countermeasure, the easiest one is avoiding SCCM in critical environments completely and instead opt for a tool that does not participate in the wonderful, rainbow-colored world of Microsoft for patch-, release and disaster-recovery. By doing so, you might find out, that you are at the same time saving quite a bit of project-management time and cost.