Jun 28 2022 | Duane Michael

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

TL;DR — Stop Using Network Access Accounts!

If a Windows machine has ever been an SCCM client, there may be credential blobs for the network access account (NAA) on disk.

If an Active Directory account has ever been configured as an NAA, there may be credential blobs for that account on Windows hosts in the environment.

Stop using NAAs and transition to Enhanced HTTP. That’s not enough! The credentials may persist on former clients. The NAA accounts should be disabled/removed from Active Directory!

Previous Work and Credit

Matt Nelson (@enigma0x3) originally wrote about offensive SCCM back in 2016 and released his PowerSCCM project, along with Will Schroeder (@harmj0y), Jared Atkinson (@jaredcatkinson), and Matt Graeber (@mattifestation).

Chris Thompson (@_Mayyhem) took inspiration from Matt et al. and ported PowerSCCM functionality to C#. He also did a ton of novel SCCM research with more on the way! Chris has continued to inspire and push me every day. He planted the seed for digging into network access accounts. Thanks, Chris!

Will Schroeder (@harmj0y) was super helpful and patient while I nagged him with DPAPI and C# programming questions. Thanks, Will!

Others in the offensive security space are putting out great work as well, such as Phil Keeble and his MalSCCM project.

What is the Network Access Account?

Microsoft’s Configuration Manager, also known as System Center Configuration Manager (SCCM), uses various accounts in a deployment. One of the accounts it uses is called the “Network Access Account” or NAA. The NAA serves a simple role in SCCM: allow a non-domain-joined computer to retrieve software from the SCCM distribution point.

Typically a domain-joined client would simply use its machine account to achieve this. However, there may be a scenario where an additional account is needed, such as the client is not domain joined (yet?) or is in an untrusted domain.

The NAA does nothing on the host. It simply accesses resources over the network. Therefore, the account should be configured with the least privilege necessary to access the content on the distribution point. It should also be configured such that it does not have interactive logon rights. But we know how things can be misconfigured…

Is the NAA even necessary?

Well, no. Microsoft recommends using Enhanced HTTP which eliminates the need for an NAA completely.

So how do we retrieve these credentials?

The SCCM server sends the NAA policy which includes the credentials for the account to every SCCM client. As Roger Zander alluded to several years ago, the NAA policy gets stored on the client and protected by DPAPI. Specifically, the credentials are protected by the system’s DPAPI master key then stored as blobs in the “CCM_NetworkAccessAccount” class of the “rootccmpolicyMachineActualConfig” WMI namespace. We can manually query these blobs from a high-integriy PowerShell process:

Get-WmiObject -namespace “rootccmpolicyMachineActualConfig” -class “CCM_NetworkAccessAccount”

or programmatically in C# (as is done in SharpDPAPI and SharpSCCM).

We’ve automated the retrieval and decryption by adding the SCCM command to @harmj0y’s SharpDPAPI project. This command will check if it’s running as high integrity, query the WMI class for the DPAPI blobs, parse the blobs, retrieve the system’s DPAPI masterkeys, and decrypt the blobs with the appropriate key.

Figure 2 — SharpDPAPI Retrieval and Decryption of NAA Credentials

TL;DR — If you can escalate on a host that is an SCCM client, you can retrieve plaintext domain credentials.

Who cares?

As red teamers, we often seek cleartext credentials so we can do things like runas /netonly and proxy our Windows tooling into a target environment. With an NAA configured, we have a trivial path to plaintext credentials (as long as we can escalate locally!)

You’re probably thinking…

this feature isn’t necessary
there’s a simple fix
companies will just remove their privileged NAA and replace it with something unprivileged
companies will just remove the NAA entirely…

Great! They should. I hope they do. Unfortunately, we’re still seeing NAAs in most environments.

Remember earlier how I mentioned that you can query the DPAPI-protected blobs using PowerShell and WMI? Well, that’s not the only way you can recover the blobs…

WMI stores data in the CIM repository located at C:WindowsSystem32wbemRepositoryOBJECTS.DATA. This is a binary file that contains all CIM entities. This means that when the NAA policy is sent to the device and stored in a WMI class, the blobs are actually stored in this file on disk. I won’t cover the CIM repository in detail in this blog post, but for more information, please see the fantastic WMI research from Matt Graeber (@mattifestation), William Ballenthin, and Claudiu Teodorescu (@cteo13)located here.

The DACL on the file makes it world-readable, so any unprivileged user can simply run strings (or open the file in notepad) to retrieve the DPAPI-protected blobs.

Figure 3 — World-readable DACL on the WMI database file

So what? We still need to be an admin to retrieve the masterkey…. Yes, you are correct but this allows NAA credentials to be recovered even after SCCM has transitioned to Enhanced HTTP. The underlying issue of the CIM repository being world-readable may also expose additional sensitive data…

Interesting Scenarios…

NAAs have been a known issue for years and I tweeted about how to retrieve and decrypt them with a single keystroke several weeks ago.

However, while studying NAAs in my lab, we noticed a few interesting findings…

Scenario 1: SCCM Client Uninstalled

When the SCCM client is uninstalled on a host, the blobs can no longer be retrieved via WMI. But what happens to the data stored within the binary WMI database file? One would assume that SCCM cleans up this data when the client is uninstalled.

Wrong.

We discovered that the NAA blobs persisted in the CIM repository after the SCCM client was uninstalled.

In Figure 1, we can see that our Windows host is an SCCM client with an NAA policy deployed. We can query the blobs via WMI:

NetworkAccessPassword :
<PolicySecret Version="1"><![CDATA[0601000001000000D08C9DDF0115D1118C7A00C04FC297EB010000007A048A2301E4584CB69064BFEED26777000000000200000000001066000000010000200000002FB37C6CE939F27E3F437B16AEBC5B5223312CC6B180819BDAFB5DF24FAECB83000000000E8000000002000020000000EC7040E8246F2579D6D81C0375996EBC86DDC1BEAD1B16FBC9F46703A432096D30000000A94A1099899DDE0F8C7945D1B63F1B5BC63703782F8882CCF1E7C64DDF9E095C03E75F55517E4C97C37898275ED4B16340000000E65693B9C7E095360EC5A43AFDE02569F5EC2DFA1944CA64740B1C0C82F46F01CB4A6534B23FF6EFB4ADEF01F7B7B4B961C1DC0CEABF51D1A58F900A4695375A]]></PolicySecret>
NetworkAccessUsername :
<PolicySecret Version="1"><![CDATA[0601000001000000D08C9DDF0115D1118C7A00C04FC297EB010000007A048A2301E4584CB69064BFEED26777000000000200000000001066000000010000200000007233FEFB255EE03E9DCF10C34CC173A816813F5C6D7BE921E1C83B9732D1B7A3000000000E8000000002000020000000D1739D10CD4E841EB8257975C3C1683078DF742876DF5AEEB7EF91A58D40115530000000426DAFEC954A99406F8D3F966C8A2D41B07F3BC2AE5B9D2ED32B9F6A83E4944988AA99DA012BFB0B0C08300A3397DF1D4000000057DACB638E6519F0B0D26BDA600B9CFF32E5084FE99511582AB20D24819EB75A9499F9E50428DB9FE66171EC50DEEB7B1DF6A2C22E20C79C377DF18E166A642F]]></PolicySecret>

which decrypts to:

THANGORODRIMCM_NAA
NetworkAccessYeah!

Now we’ll uninstall the SCCM client on the host and reattempt the query:

Figure 4 — SCCM Client Uninstalled and WMI Objects Removed

If we inspect the CIM repository in a text editor, we can see that the blobs persist client uninstallation, reboot, etc.

Figure 5 — Credential Blobs Persist After Client Uninstallation

TL;DR — If a client has ever been an SCCM client, there may be domain credentials on disk.

This particular finding was impactful with a client who used SCCM to image laptops which were then removed from the domain and shipped off to personnel in the field.

Scenario 2: Changes to the NAA

Maybe a company accidentally configured its NAA to be a privileged account. With security researchers looking into SCCM and NAAs lately, maybe that company has changed the NAA from the privileged account to an unprivileged account. Surely SCCM must handle the cleanup and removal of the old NAA credential blobs from the WMI database…

Wrong.

Now we’ll change the NAA account on the SCCM server and update the policy on our Windows host. A simple way to prove that the NAA account has changed is to run SharpDPAPI.exe SCCM again.

Now we can see that the configured NAA is THANGORODRIMBACKUP_NAA. Let’s inspect the CIM repository in a text editor again…

Figure 7 — Credential Blob in CIM Repository

Note that this blob is different from the one above because it was encrypted with a different DPAPI masterkey. No matter, SharpDPAPI will triage all system masterkeys for us. We’ll do some manual work to decrypt this blob, as we have not yet completed the code to automate this part:

Now we’ve verified that THANGORODRIMCM_NAA, the original NAA account used, is still on disk in the CIM repository, despite the NAA account being changed in SCCM.

Figure 9 — Current SCCM Lab NAA Configuration

TL;DR — If an account has ever been configured as an NAA, its credentials may be on disk.

These scenarios effectively negate the transition away from NAAs to Enhanced HTTP unless the NAA accounts are removed or disabled in Active Directory.

After these discoveries, we stumbled across the Flare-WMI repository from Mandiant’s FLARE team, also associated with the previously cited WMI research. They discuss the possibility of recovering a deleted WMI object’s data from the CIM repository, which is exactly what we’ve discovered here with the NAA.

Mitigation Guidance

First of all, determine if you’re using an NAA in your SCCM environment. Transition to Enhanced HTTP, per Microsoft’s recommendations. As I outlined above, eHTTP won’t matter if the NAA credential blobs are still valid. After transitioning away from NAAs, disable or remove the NAA accounts in Active Directory.

Disclosure

We are disclosing this research in keeping with our commitment to transparency.

We disclosed both the world-readable CIM repository file and the historic NAA artifacts to Microsoft on March 3, 2022. We followed up on the case on April 11, May 4, and May 17 but never received any response.

Future Work

It is clear that this is an access control issue with the WMI database itself so we think there’s more to look at there. What other applications store sensitive data in WMI? Additionally, we’re working on code to automate retrieval of these blobs from the file which will be implemented in SharpSCCM.

I’m sure there’s a lot more to be covered here. If I missed anything, made any errors, or if you’d like to collaborate, please reach out on Twitter (@subat0mik) or BloodHound Gang Slack!

The Phantom Credentials of SCCM: Why the NAA Won’t Die was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.