While everyone's looking at the WiFi outage and the expired NDES certificates, I'm reading the registry.

The flurry of emails around the Intune problem showed me exactly where the NDES servers are. And who has admin access to them.

Turns out the admin on SCCM is also the admin on NDES. Easier that way, right? Same account everywhere. I already have those credentials from the SCCM compromise.

Local admin on the NDES server. I open HKLM\software\microsoft\cryptography\mscep\.

The registry hive that tells NDES which templates to use for enrollment. Let me see what we're working with.

EncryptionTemplate and SigningTemplate point to default templates. Simple client auth. User template. Authenticated Users can request it.

That's not a secure choice. That's an invitation.

I read the NDES service certificate's private key. I'm admin, that's readable. I modify the registry to point to the user template instead of the defaults. I grant my account read permissions on the service certificate's private key — I need to use it.

IIS restart. Nobody's monitoring service restarts on the NDES box. The service comes back up, reads the new registry configuration, and now I control what template it uses.

Now I do something different than what Intune does.

NDES is a registration authority. It holds two special certificates: one to decrypt enrollment requests, one to co-sign them on behalf of someone else. When Intune sends a SCEP request through NDES, NDES uses that co-signing certificate to say "I vouch for this request. Issue the cert."

The magic is that NDES doesn't validate what's in the request. It just signs it. The CA trusts NDES, so the CA trusts whatever NDES signs.

I request certificates directly from the NDES server. I ask for authentication certificates with subject names matching every domain admin account in the environment. Normal names and privileged account names. I use NDES's own RA certificate to enroll on behalf of each one.

NDES signs the requests. The CA issues the certificates. They're cryptographically valid domain admin authentication certificates.

I now have Kerberos credentials for every domain admin in the organization, issued by their own certification authority.

I change the registry back. I put the service certificate ACLs back the way they were. I restart IIS again.

Then I leave a calling card. New registry key in HKLM: HKLM\software\Hiro_was_here.

Everything else looks normal. The NDES server is responding correctly. The templates are where they should be. The service certs are where they should be. Nobody knows I was there until they search the registry.

But I have domain admin credentials that the organization's own PKI issued.

If you're a defender, here's what just happened.

The chain of compromise

  1. Cross-admin privilege consolidation. The same account is admin on SCCM and NDES. Compromise one, you have both.
  2. Weak template design. A user template with Authenticated Users enrollment, simple client auth. Accessible to anyone in the domain.
  3. Unmonitored registry configuration. The NDES registry hive is writable by local admin. Changing which template NDES uses requires local admin, but nobody's watching for it.
  4. Private key ACL exposure. The NDES service certificate's private key is readable by local admin. If you're admin, you can use it.
  5. No monitoring on service restart. IIS restart is a normal operation. No alert when it happens.
  6. RA certificate authority without validation. NDES signs whatever you ask it to sign. It doesn't validate the subject name in the request. It just says "NDES approves this" by co-signing it. The CA trusts NDES's signature more than it trusts the actual subject value.
  7. No audit trail. Nobody's watching who requests certificates through NDES or what names they ask for.

Each one of these is a known gap. Together, they let an attacker with local admin issue authentication certificates for any account in the domain.

What to check this week

Look at your NDES deployment:

  • Who has admin on the NDES server? Is it the same account that has admin on SCCM, or backup servers, or DNS? Reduce overlap. Tier the admins.
  • What template is NDES using? Not the defaults. Audit the template. It should not allow Authenticated Users to enroll.
  • Monitor registry changes. The NDES configuration is in HKLM. Alert on writes to HKLM\software\microsoft\cryptography\mscep\. If the registry changes, know about it immediately.
  • Monitor service restarts. IIS restart on an NDES server should trigger an alert. Unexpected restarts are a tell.
  • Monitor certificate requests through NDES. Log every certificate that gets enrolled through the NDES service. Match the requester to the subject name. If they don't match, something's wrong.
  • Monitor RA certificate usage. The NDES service certificate should only be used by the NDES service. If something else is reading its private key, that's a compromise.

The closing principle

The registration authority is powerful because the CA trusts its co-signature. But the CA only trusts it because NDES is supposed to be protected. If NDES is running under a standard admin account, if the registry is writable, if the templates are weak, if there's no monitoring — then NDES is not protected.

The RA certificate becomes a credential that grants certificate issuance. Protect it like you protect the CA itself.

Most organizations don't.

Hiro out.