DFIR Triage: 'Does this account exist, where did it originate, and what can it access?'

The Golden Rule of Initial Triage

During incident response, never begin by asking: “What was this user trying to do?”

First answer the three foundational questions of forensic identity qualification:

1. Does this account physically exist, and in which database? (Local SAM, local domain, child domain, partner forest).
2. Where did the authentication proof originate? (KDC issuing the TGT, Netlogon channel, or local machine LSA).
3. What is its technically permitted scope of access? (Target DACLs, transitive group memberships, OS privileges).

Concept

When an EDR or SIEM detection flags suspicious activity attributed to a security principal (e.g., CORP\svc_deploy, DESKTOP-89A\admin, or S-1-5-21-98765-1105), the DFIR investigator must systematically resolve three forensic dimensions:

1. Existence and Architecture: Is the principal a human user, machine account ($), managed service account (gMSA), local SAM account, or a synthetic ghost identity generated via ticket forgery?
2. Authority and Authentication Path: Was identity proof validated by the local SAM, the local domain KDC, a remote forest authority across a trust, or was it never validated by a central authority at all (Silver Ticket)?
3. Effective Access Scope: Do the actions taken correspond to legitimate group permissions, or do they indicate privilege escalation and unauthorized token manipulation?

---

Why It Matters in DFIR

This triage discipline prevents critical diagnostic errors under incident pressure:

• Differentiating Local vs Domain Accounts: Resetting or disabling a domain account named Administrator does nothing to halt an adversary moving laterally using the local .\Administrator credential across member servers.
• Uncovering Ghost Principals: If an account name appears in Event ID 4624 but cannot be resolved in Active Directory (Get-ADUser throws non-existent object errors), the investigator is facing a forged Golden Ticket or an unsynchronized machine.
• Containing Multi-Domain Intrusions: If the account originates from an external subsidiary domain across a trust, isolating the account in the local domain is insufficient; the trust perimeter must be evaluated.

---

How It Works

Forensic Identity Qualification Matrix

Account String from Logs: "TargetDomainName\TargetUserName"
                                  │
      ┌───────────────────────────┴───────────────────────────┐
      ▼                                                       ▼
TargetDomainName == ComputerName           TargetDomainName == AD Domain
      │                                                       │
      ▼                                                       ▼
[ LOCAL SAM ACCOUNT ]                                  [ DOMAIN ACCOUNT ]
- Database: Local SAM (%SystemRoot%\System32\config)   - Database: ntds.dit on DCs
- SID: Machine Prefix (S-1-5-21-M-RID)                 - SID: Domain Prefix (S-1-5-21-D-RID)
- DC Logs: ZERO telemetry on DCs                       - DC Logs: Events 4768 / 4769 / 4776
- Lateral Spread: Local Pass-the-Hash                  - Lateral Spread: Kerberos / NTLM

The 3-Step Qualification Workflow

1. Existence Verification:
   • Query the local domain controller: Get-ADUser -Identity <TargetUserName>.
   • If not found: query the Global Catalog (-Server <GC>:3268) to verify if the principal belongs to another domain within the forest.
   • If still not found: query the local SAM on the endpoint (Get-LocalUser).
   • If not found in any database: suspect a Golden Ticket forged with a synthetic username.
2. Origin Identification:
   • Review Event 4624 on the target host: inspect LogonProcessName (Kerberos vs NtLmSsp).
   • If Kerberos: verify which DC recorded Event 4768 (TGT) and Event 4769 (TGS).
   • If NTLM: check DC Event 4776 and Event 8004 to identify which DC processed the Netlogon validation.
3. Effective Rights Mapping:
   • Enumerate actual AD group memberships: Get-ADPrincipalGroupMembership <Account>.
   • Compare with group SIDs inside the user’s Access Token (Event ID 4627 - Group Membership Information).
   • Any SID in the token absent from Active Directory reveals token injection (sIDHistory or PAC forgery).

---

What Is Possible

• Instantly Confirming Account Database Origin: By matching the principal’s SID prefix against the local host machine SID versus domain SID.
• Unmasking Golden Tickets at Triage: Detecting Kerberos network logons lacking matching Event 4768/4769 KDC records, or accounts that do not exist in LDAP.
• Pinpointing Client Source IP and Hostname: Extracted reliably from IpAddress and WorkstationName in Event 4624.

---

What Is Not Possible

• Validating NTLM User Intent Without SMB Signing: In relay attacks, the authenticated identity was coerced or relayed without the genuine user’s knowledge.
• Reviewing Local SAM Activity on Domain Controllers: Local authentications remain entirely confined to endpoint security logs.
• Determining NTFS File Permissions from the DC: Active Directory domain controllers hold identity and group definitions; NTFS permissions are evaluated locally on resource servers.

---

Common DFIR Confusions

Frequent Confusion	Verifiable Forensic Reality
”The account shows DOMAIN\Admin, so it is a domain administrator.”	Inspect TargetDomainName and TargetUserSid. If the domain name matches the machine hostname, it is a local account.
”Because the account exists in AD, the genuine employee initiated the session.”	Successful authentication merely proves credentials (password, hash, ticket) were presented.
”The account has zero domain rights, so it poses no operational risk.”	A standard domain user can be nested into the local Administrators group of specific servers without having any rights in Active Directory.

---

Concrete Forensic Example

SOC Alert: An account named sql_admin executed vssadmin delete shadows on database host DB01. The responder executes the 3-question triage:

1. Does it exist?
   • Get-ADUser sql_admin $\rightarrow$ Error: Cannot find an object with identity: 'sql_admin'.
   • On DB01: Get-LocalUser sql_admin $\rightarrow$ Present, provisioned 3 years ago by a contractor.
   • SID: S-1-5-21-44332211-1004 (Matches DB01 machine SID prefix).
2. Where did it originate?
   • Event 4624 on DB01: LogonType: 3, LogonProcessName: NtLmSsp, Workstation Name: LAPTOP-DEV, IpAddress: 192.168.20.45.
   • Finding: Local SAM authentication over SMB from a developer laptop.
3. Where can it go?
   • sql_admin is an administrator on DB01. It possesses zero permissions across domain controllers or other member servers.
4. Immediate Containment: Isolate 192.168.20.45 and disable the local account on DB01. Active Directory krbtgt keys remain entirely unaffected.

---

Key Forensic Artefacts

1. Target Workload Event Logs:
   • Event ID 4624: TargetDomainName, TargetUserName, TargetUserSid, LogonProcessName, IpAddress.
   • Event ID 4627: Complete group SIDs embedded in the token during logon.
   • Event ID 4672: Privileges granted to the session.
2. Domain Controller Event Logs:
   • Event ID 4768: TGT request (confirms domain account Kerberos authentication).
   • Event ID 4776: NTLM credential validation.

---

Investigation Methods

1. Compare TargetDomainName Against Local ComputerName: Determine immediately whether the transaction was local (SAM) or enterprise (Domain).
2. Match SID Sub-Authority Prefixes: Compare the SID against (Get-ADDomain).DomainSID to distinguish domain from local principals.
3. Correlate Workload Event 4624 with KDC Event Logs: Confirm whether the DC issued tickets for that specific session or if the session is orphaned.

---

Investigative Tooling

• PowerShell AD Module:

  # Compare Domain SID with principal SID
  $DomainSID = (Get-ADDomain).DomainSID.Value
  $SuspectSID = "S-1-5-21-987654321-1001"
  if ($SuspectSID -like "$DomainSID*") { "Domain Principal" } else { "Local or Foreign Principal" }

• PsGetsid:

  psgetsid TARGET-HOST

---

Key Takeaways

• Never rely exclusively on usernames: only SIDs provide unambiguous authority verification.
• If TargetDomainName == ComputerName, the session is local and the DC is completely uninvolved.
• A Kerberos logon lacking matching Event 4768 KDC records indicates a forged ticket (Golden/Silver Ticket).
• Effective rights are governed by target object DACLs and the groups encapsulated in the Access Token (Event 4627).

---

References & Further Reading

• Microsoft Learn: Active Directory Security Groups and SIDs
• Card 01 — Windows Identities: Local Accounts vs Domain Accounts
• Card 02 — SID, RID and Windows Identity
• Card 05 — Authentication vs Authorization: The Decisive Boundary in DFIR
• Card 21 — NTLM vs Kerberos: Fundamental Differences in DFIR Investigations