Rooting out Risky SCCM Configs with Misconfiguration Manager

tl;dr: I wrote a script to identify every TAKEOVER and ELEVATE attack in Misconfiguration Manager.

Ever since Garrett Foster, Duane Michael, and I released Misconfiguration Manager at SO-CON last month, we’ve had tons of great conversations with people interested in finding and fixing configurations that leave an SCCM environment vulnerable to attack, including those that allow complete takeover of a default hierarchy with a remote site database in two commands.

Although we detailed how to carry out, mitigate, and detect each of these attacks in the knowledge base, we soon realized from our discussions with defenders and SCCM administrators that not everyone has the bandwidth, privileges, or permission to demonstrate these attacks to their organization. The best advice we could give at the time was to ask someone with SCCM privileges to manually review the environment for misconfigurations… until now!

Introducing MisconfigurationManager.ps1, a PowerShell script that can be executed to identify exactly where these issues may exist. Currently, the script can be run with any Security Role in SCCM (including Read-only Analyst) on or against any SMS Provider to identify every TAKEOVER and ELEVATE technique in Misconfiguration Manager (except for TAKEOVER-9, for now).

TAKEOVER Techniques Identified by MisconfigurationManager.ps1

I have plans to add support to identify configurations that allow the CRED attacks and that pesky last TAKEOVER technique, and I’d like to publish MisconfigurationManager.ps1 in the PowerShell Gallery at some point, but I wanted to get this tool into the community’s hands sooner rather than later after getting it this far.

Under the hood, the script uses WMI to query the local or specified SMS Provider and interacts with WMI, the registry, and service control manager on site systems. The script runs in two phases to identify issues:

1. TAKEOVER checks: First, it uses the Read-only Analyst (or higher) SCCM privileges to query the SMS Provider to find out what site system roles exist on the site server and which are hosted remotely. The list of possible issues is created using this information.
2. Mitigation checks: Next, the script connects to the remotely hosted site systems with local admin privileges to see if these NTLM relay mitigations are in place:

• SMB signing is required
• Extended protection for authentication (EPA) is required
• WebClient is not installed
• The central administration site server computer account is not an admin on the child site server that extended the hierarchy

Using the information from step 2, the script removes false positives from the possible issue list created in step 1.

Therefore, to identify potential issues and remove false positives if mitigations are in place, run it with local admin privileges and network connectivity to RPC and SMB on site systems for the most accurate and complete results.

I’ve tested the script in one lab with a central administration site, two primary sites, and a secondary site, as well as a second lab with a standalone primary site. The console output logic is pretty in the weeds, so if I didn’t account for a certain architecture and you’re not seeing expected results or you’re seeing errors or false negatives, please let me know by opening an issue.

Here’s how to use it:

./MisconfigurationManager.ps1 [-SMSProvider <SMS_PROVIDER>] [-Timeout <int>] [-Verbose]

When using the -Verbose option, the script prints information as checks are performed and warns the user when any potential issues are identified:

Verbose Output

After collection is finished and the results are analyzed, MisconfigurationManager.ps1 prints a visual representation of the hierarchy, including which site systems may be impacted by ELEVATE or TAKEOVER attacks:

Hierarchy Visualization

Note that the script errs on the side of false positives. For example, if it does not have local admin privileges on the site systems or if connections time out, it will recommend you manually check for any potential issues that have not been ruled out.

It’s not perfect, as it doesn’t take every possible mitigation into consideration (e.g., firewall rules, policies/registry entries that block NTLM authentication, domain controller and AD CS configurations, etc.) and therefore makes some assumptions, but it will very quickly identify risky configurations that are worth looking into further. If you know of any mitigating factors the script doesn’t account for that can reasonably be checked for with PowerShell, notice any issues with the script, or would like to see additional features added to it, I look forward to your pull request 😀 (or feedback)!

I hope that MisconfigurationManager.ps1 makes your life easier and helps you identify potential issues in your environment without needing to conduct manual reviews. If you have any questions or feedback as you go, please reach out to me on Twitter or in the #sccm channel in the BloodHound Slack. Thanks for reading!