Separating Risks Arising from Credentials, Privileges, and Trust Relationships.

1. Core mechanism

This lesson classifies a finding according to the trust assumption it affects. The same event may provide evidence for all three risks, but the event alone does not prove all three.

Interfaces and specifications

• credential: authentication material such as a password, key, ticket, or certificate.
• privilege: the ability to affect an operation or object through a token, ACL, or delegation.
• trust: the boundary at which identity and authorization information is accepted between security authorities.
• authentication: verification of a principal's claim.
• authorization: the decision about requested access for an authenticated principal.
• telemetry: the limited record produced by the system observing an event; it is not the whole mechanism.

The risk class changes the question

For a credential finding, ask: 'Which secret or proof can be used, where is it protected, and what does rotation cut off?' For a privilege finding, ask: 'Which principal can make which change on which object with which right?' For a trust finding, ask: 'Which boundary accepts which authority's claim, with what filtering and scope?'

The presence of an SPN on a service account does not automatically indicate credential risk; password or key protection, ticket-acquisition conditions, and the possibility of offline use require separate examination. If the same account has broad WriteDacl, that is a privilege risk; acceptance of a SID from a trusted domain is a trust risk.

Do not substitute one piece of evidence for the class

A KDC issuing a ticket is one step in the authentication protocol. It does not show that the target service accepted access, that the resource ACL allowed it, or that trust filtering behaved correctly in every expected scenario.

Similarly, 4662 is a directory-operation record selected by a SACL. It is not synonymous with the presence of an ACE or with a compromised credential.

State and data flow

1. Name the assumption violated by the finding: credential, privilege, or trust.
2. Record the supporting artifact and the artifact's observation boundary.
3. State the additional authorization, network, and service preconditions required for impact.
4. Map remediation to the risk class: secret protection, least privilege, or boundary control.

2. Exploitation

Broken trust assumption

An assessor wants to label a finding as high impact; this lesson sets boundaries so that applicability is not inferred from a name or a single telemetry record.

Technical prerequisites

• For a credential claim, establish the material's exposure surface and either access to the secret/key/ticket or a verified credential-use path.
• For a privilege claim, the correct principal, object, and authorization right are verified in the same time window.
• For a trust claim, direction, scope, filtering, and the target side's acceptance conditions have been examined.

Exploitation mechanism

Misclassification produces the wrong remediation: password rotation alone does not close a broad ACL; fixing an ACE alone does not invalidate a leaked credential; trust filtering does not replace the resource ACL at either end.

Naming is the first line of the evidence chain

When a risk is reported as 'credential exposure', specify the material involved, its use window, and the verification boundary. When calling something 'privilege escalation', distinguish the directly granted right from the operation that is actually effective.

In a trust risk, compromise of the other domain and the way that compromise becomes effective on the target—through a SID, ticket, or authorization path—are not the same claim.

3. Defense & Detection

Telemetry scope

• Assign one primary risk class to every finding and, where applicable, a dependent secondary class.
• For credential findings, record the material type, storage or exposure surface, and rotation scope.
• For privilege findings, retain the trustee, target object, right, inheritance, and deny/allow context.
• For trust findings, retain direction, transitivity, filtering, and the boundary of target-resource authorization.

Events and relevant fields

• 4769 is an observation of a KDC service-ticket operation; it is not evidence of successful resource access or credential compromise.
• 4662 provides visibility into a directory operation only when the relevant SACL is configured; do not assume it covers every privilege change.

The same signal can open three separate investigation queues

The fixture identifies busra@OUTREASON.EXAMPLE as the requester and svc-reports as the target service account. A full SPN cannot be inferred from this ServiceName field; use separate directory/account evidence when needed. The KDC record starts the investigation; credential state, service acceptance and resource ACL outcomes need separate evidence.

This keeps event correlation from turning into the unsupported conclusion, 'I saw an event; compromise occurred.'

Detection logic · XPath

*[System[(EventID=4769)]]

Query assumptions

• The query selects only candidates for KDC service-ticket operations.
• Credential material, target-service acceptance, and the ACL result are not established by this event.

False positives

• Normal application access may generate 4769.
• A classification based only on EventID can conflate credential, privilege, and trust risks.

Hardening

• Assign separate owners and remediation validation to credential, privilege, and trust findings.
• Constrain privileged ACL delegation to task-based, object-specific rights.
• Assess trust-boundary changes together with filtering and a review of target-resource authorization.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4769</EventID><Version>2</Version><Level>0</Level><TimeCreated SystemTime="2026-10-01T09:14:11.0000000Z"/><EventRecordID>1302001</EventRecordID><Channel>Security</Channel><Computer>dc01.outreason.example</Computer><Security/></System><EventData><Data Name="TargetUserName">busra@OUTREASON.EXAMPLE</Data><Data Name="ServiceName">svc-reports</Data><Data Name="TicketEncryptionType">0x12</Data><Data Name="Status">0x0</Data><Data Name="IpAddress">192.0.2.24</Data></EventData></Event>

Two reality checks

Assumption: Seeing a service account or a 4769 record is evidence of credential compromise.

In fact: This data opens an investigation surface for the mechanism only; secret access, key hygiene, and actual use require separate evidence.

Assumption: A trust setting or privileged ACE completely explains a finding as a single risk class.

In fact: Trust boundaries, privilege authorization, and credential-verification material are different assumptions; remediation and validation must be carried out separately.

Sources

• Microsoft · 4769(S, F): A Kerberos service ticket was requested
  Account Name normalized/implicit UPN versus UPN attribute; Service Name target account/computer, not full SPN; updated Version2 field reference and KDC-side observation boundary.
• Microsoft · Best practices for securing Active Directory
  AD attack surface, privileged access, and recovery-boundary guidance.