Password, hash, key, ticket, and certificate: Credential types and the place of DPAPI

1. Core mechanism

This lesson compares credential materials by the protocol capabilities they provide. It uses RFC 4120 for Kerberos ticket structure, RFC 5280 for certificate structure, and Windows API documentation for DPAPI protect/unprotect context. Detailed reuse paths in protocols such as NTLM and Kerberos remain outside this lesson.

Interfaces and specifications

• Password: a secret the user knows; depending on the protocol, it may become an input to a verifier or key-derivation function.
• Hash/verifier: a value derived by a specific algorithm; by itself, it does not prove knowledge of the plaintext password.
• Cryptographic key: secret or public key material for a particular algorithm and purpose; by itself, it proves neither identity nor policy acceptance.
• Kerberos Ticket: carries an open realm and sname alongside an enc-part protected with the target key; the ticket alone does not prove that the client possesses the session key.
• X.509 certificate: carries subject and public-key information, an issuer signature, validity, and extensions; it does not prove possession of the corresponding private key.
• CryptProtectData/CryptUnprotectData: protects application data as a DPAPI blob, or unprotects it, according to user or machine context.

Ask what the operation requires, not what the material is called

Calling material a credential does not make it usable in every protocol. A plaintext password may be input to a new derivation; a hash or verifier matters only to a protocol that accepts it or uses it in a calculation; a cryptographic key must be evaluated with its algorithm, direction, and intended use.

Presenting a Kerberos ticket requires an authenticator produced with the corresponding session key. A certificate may be public; proving possession requires its private key. A DPAPI blob is ciphertext, and its contents cannot be classified without understanding the application context.

A ticket carries encrypted data alongside open metadata

In the RFC 4120 Ticket structure, tkt-vno, realm, and sname are open fields; enc-part is EncryptedData protected by the target service key. The artifact demonstrates this distinction in a synthetic APPLICATION [1] TLV.

Copying a ticket alone is not enough to produce a valid AP-REQ. The client must also create an authenticator using the session key associated with the ticket. The artifact's dummy cipher bytes are neither decrypted output nor usable credential material.

Keep the certificate separate from the private key

An X.509 certificate carries subject and public-key information, an issuer signature, a validity interval, and extensions. It is a distributable public object; its presence does not show that the private key is available.

Certificate-based authentication requires private-key possession and acceptance of the chain, time, purpose, and mapping policy. Merely seeing a certificate file is not evidence of successful authentication.

DPAPI context cannot be inferred from the blob itself

CryptProtectData accepts a plaintext DATA_BLOB and returns an encrypted blob; the application does not supply an encryption key directly to the API. Default protection depends on the same logon credentials and usually the same computer context. If optional entropy was used, unprotect requires the same entropy.

When CRYPTPROTECT_LOCAL_MACHINE is selected, users on the same computer can unprotect the blob, so DPAPI does not always imply a single-user boundary. For domain users, the AD domain backup-key recovery path also enters the risk model. Whether the plaintext is a password, private key, or some other data is determined by application semantics, not by DPAPI.

State and data flow

1. The application supplies the plaintext and any optional entropy to CryptProtectData.
2. DPAPI obtains the required material from the user or machine context and derives a session key.
3. The DPAPI blob stores ciphertext, a description, and integrity information.
4. During unprotect, the required context and any previously used entropy must be supplied.
5. In a domain scenario, the domain backup-key recovery path may apply when the password-derived path is unavailable.
6. Whether the returned plaintext is credential material depends on the application's data semantics.

2. Exploitation

Broken trust assumption

The broken assumption is: every object labeled as a credential can be reused in the same way.

Technical prerequisites

• The material has actually been obtained; a filename or product label alone is insufficient.
• The target protocol accepts that material type.
• Any required companion secret is available, such as the session key for a ticket or the private key for certificate authentication.
• Validity period, target principal or service, and policy conditions are satisfied.
• For DPAPI, the appropriate user or machine context, any optional entropy, or a valid recovery path is available.

Exploitation mechanism

A plaintext password may support new derivations for protocols that accept it; a hash or verifier is useful only in the specific protocol calculation that consumes it; a ticket cannot produce an authenticator without its session key; a certificate cannot prove possession without its private key; and a DPAPI blob is not plaintext without the required context or recovery capability. The intersection of material type and target operation defines what is possible.

Copying is not use

Copying a ticket file or DPAPI blob does not automatically provide the required companion secret. Likewise, possessing the public certificate is not possession of its private key.

An assessment must record scope, validity, target, and policy conditions individually; 'credential found' is not a conclusion.

3. Defense & Detection

Telemetry scope

• This lesson focuses on attempts involving auditable protected data within Audit DPAPI Activity: 4694 protect and 4695 unprotect. Success/Failure configuration and the call’s audit conditions matter.
• The same subcategory also covers 4692 master-key backup and 4693 master-key recovery attempts. Distinguish master-key operations from directly protecting/unprotecting data.
• For 4694, the CryptProtectData call requires CRYPTPROTECT_AUDIT and a non-empty description.
• These events are not connected to the object SACL.
• Microsoft documents these records primarily for troubleshooting; they are weak standalone attack signals.

Events and relevant fields

• The 4694/4695 documentation describes the Subject fields: Security ID, Account Name, Account Domain, and Logon ID.
• The Protected Data section describes Data Description, Key Identifier, Protected Data Flags, and Protection Algorithms.
• The Status Information section describes Status Code.
• Because the Microsoft pages do not publish sample Event XML or EventData Name values, this lesson does not invent named XML fields.

Do not treat missing telemetry as evidence of absence

4694 requires a specific audit flag and a non-empty description. Its absence therefore does not prove that CryptProtectData was unused.

Even when the event is present, it does not reveal the plaintext type. Review the application, process, file access, and account context together.

Detection logic · XPath

*[System[(EventID=4694 or EventID=4695)]]

Query assumptions

• The expression selects only the Event IDs; it does not add named-field XPath.
• Separate Success from Failure only after verifying the backend's System/Keywords mapping.
• The query was not run on the actual Windows system or SIEM; there is no data set and threshold.

False positives

• Legitimate application protect and unprotect operations are routine.
• Most DPAPI use can occur without CRYPTPROTECT_AUDIT; the absence of these events does not show that DPAPI was unused.
• Successful unprotection does not show that the returned plaintext is a credential.
• This event family is too weak to distinguish abuse on its own.

Hardening

• Do not treat a DPAPI blob as plaintext or as secure by itself; evaluate the application's ACL and execution context.
• Choose CRYPTPROTECT_LOCAL_MACHINE only when machine-wide access is genuinely required.
• If optional entropy is used, consider a design that does not store it beside the blob.
• Protect domain DPAPI backup keys and DC/AD backups as high-value secrets.
• Enable Audit DPAPI Activity for troubleshooting or in a pilot scope; do not use it as a standalone attack alert because of its low analytical value.

Read the examples

61 61 30 5f a0 03 02 01 05 a1 11 1b 0f 49 59 45
4c 41 42 53 2e 45 58 41 4d 50 4c 45 a2 27 30 25
a0 03 02 01 02 a1 1e 30 1c 1b 04 63 69 66 73 1b
14 46 53 30 31 2e 69 79 65 6c 61 62 73 2e 65 78
61 6d 70 6c 65 a3 1c 30 1a a0 03 02 01 12 a1 03
02 01 03 a2 0e 04 0c a5 5a a5 5a 01 02 03 04 05
06 07 08

Two reality checks

Assumption: A certificate is secret proof of identity; possessing the certificate is enough to authenticate.

In fact: A certificate carries a public key and an issuer-signed identity binding. Authentication also requires proof of possession of the corresponding private key and acceptance of the purpose, chain, time, and mapping policy.

Assumption: A DPAPI-protected blob can be opened only when the user's password is known.

In fact: Default protection depends on the logon credentials and usually the host context; machine scope, optional entropy, and domain backup-key recovery change the model. The blob itself is not plaintext.

Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.3 Ticket, §5.2.9 EncryptedData, §3.2.2–3.2.3 and §5.5.1 AP-REQ/authenticator.
• RFC 5280 · Internet X.509 Public Key Infrastructure Certificate Profile
  §4.1 and §4.1.2.7; certificate structure and subject public-key information.
• Microsoft · CryptProtectData function
  Introduction, dwFlags, and Remarks; default context, LOCAL_MACHINE, and audit conditions.
• Microsoft · CryptUnprotectData function
  Parameters and Remarks; optional entropy and integrity behavior.
• Microsoft · CNG DPAPI backup keys on AD domain controllers
  Domain backup-key recovery mechanism and rotation boundary.
• Microsoft · Audit DPAPI Activity
  Events List and audit scope.
• Microsoft · 4694(S, F) Protection of auditable protected data was attempted
  Event Schema and the CryptProtectData audit trigger condition.
• Microsoft · 4695(S, F) Unprotection of auditable protected data was attempted
  Event Schema and Recommendations.