Last updated
Last updated
The first step when attacking SCCM is to get a feel for the deployment topology, which devices are being managed, and who the administrative users are. Throughout this chapter, we'll use the tool. Given a foothold on a machine, we can begin by finding the management point and site code that it is linked to. This does not require any special privileges in the domain, in SCCM or on the endpoint.
This enumeration uses WMI under the hood, which could be done manually.
We can also check the DACL on the CN=System Management container in AD for machines that have Full Control over it (as this a pre-requisite of SCCM setup in a domain).
This can really impact your view (as an attacker) of how SCCM is configured. For example, if we enumerate all the collections as bfarmer, we can see that both DEV and CYBER exist as well as their member counts.
However, if we run the same enumeration as jking, a member of DEV\Support Engineers, we only see the DEV collection.
This is because even though DEV\Developers are only "Read-Only Analysts", the role is scoped to both collections. DEV\Support Engineers are "Full Administrators" over the DEV collection but they have no roles that are scoped to the CYBER collection.
So when enumerating SCCM, you may only see a small slither based on the user you're running the enumeration as.
Administrative users can be found using get class-instances SMS_Admin.
This allows us to see what is reflected in the Configuration Manger GUI above. Members of these collections can be found using get collection-members -n <collection-name>.
Even more information on each device can be obtained using get devices. There are some good ways to filter the output, such as searching by device name, -n, and only displaying the properties specified by -p.
You can also use SCCM as a form of user hunting, since it records the last user to login to each managed computer. The -u parameter will only return devices where the given user was the last to login.
However, take these results with a grain of salt because this information is only updated in SCCM every 7 days by default.
Enumerating users, groups, computers, collections, and administrators, etc, does require some level of privilege in SCCM and cannot be done as a standard domain user. SCCM employs an RBAC security model - the lowest role is "Read-Only Analyst" and the highest is "Full Administrator". Lots of other roles exist such as "Asset Manager", "Infrastructure Administrator", and "Software Update Manager". A description of each can be found . Furthermore, the "scope" of these roles can be restricted to individual collections as needed by the administrative user. For example, computers from the DEV and CYBER domains have been grouped into their own collections.
