Authentication vs Authorization: The Decisive Boundary in DFIR

Fundamental Forensic Axiom

A successful authentication NEVER proves that a malicious action was authorized or executed.

Authentication strictly verifies cryptographic identity proof. Authorization determines whether that verified identity possesses permission to touch an object. A DFIR investigation must validate both phases independently:

Authentication (Who?) ≠ Authorization (Allowed?) ≠ Access (Touched?) ≠ Action (Modified/Exfiltrated?)

Concept

In the Windows NT and Active Directory security architecture, two sequential and strictly distinct mechanisms operate:

1. Authentication (AuthN) — “Who are you?”: The process by which a security principal proves its identity to an authority (local SAM or Kerberos KDC) via a shared secret (password), cryptographic key, or certificate. Success results in a Logon Session and the issuance of an Access Token.
2. Authorization (AuthZ) — “What are you allowed to do?”: The process by which the operating system’s Security Reference Monitor (SRM) compares the SIDs and privileges inside the caller’s Access Token against the Discretionary Access Control List (DACL) of the target object (file, registry key, service, network share).

---

Why This Matters in DFIR

Conflating authentication and authorization generates severe false positives and flawed incident scopes:

• The Illusion of Host Compromise: Observing an Event ID 4624 (Logon Type 3 - Network) on a financial database server proves the adversary authenticated to the network stack. It does not prove database compromise. If the folder DACL denies the account, all file access requests terminate in STATUS_ACCESS_DENIED.
• Misinterpreting NetExec Results: As detailed in Doc 23: NetExec: What Do the Results Actually Prove?, a green [+] indicates successful authentication, whereas the Pwn3d! badge denotes administrative authorization on administrative shares (ADMIN$, C$).
• Active Directory Trusts: Establishing a trust enables cross-domain authentication, but grants zero default resource permissions on trusting domain hosts (see Doc 13: Active Directory Trust Fundamentals).

---

How It Works

[User / Client]
         │
         │ 1. Submits Credentials (Kerberos AS-REQ or NTLM Negotiate)
         ▼
[Security Authority (DC / SAM)] ───────► Authentication (AuthN)
         │                                 Issues: Logon Session + Access Token
         │ 2. Resource Access Request (\\FS01\Finances)
         ▼
[Security Reference Monitor (SRM)] ──► Authorization (AuthZ)
         │                             Compares: Token (SIDs + Privs) vs DACL
         ├─► Access Granted (STATUS_SUCCESS) ────► Events 4624 + 5140/5145
         └─► Access Denied (STATUS_ACCESS_DENIED) ─► Events 4624 + 5145 (Failure)

1. Identification: The client presents principal identity CORP\alice.
2. Authentication: The KDC validates cryptographic proof and inserts group SIDs into the PAC.
3. Token Creation: The target server transforms the PAC into a local kernel Access Token.
4. Authorization: The SRM checks the token SIDs against the resource’s DACL.

---

What Is Possible

• Being Authenticated with Zero Access Rights: A guest or standard user from a trusted foreign domain can authenticate (Event 4624) without permissions to list shares or read files.
• Being Authorized Without Administrator Rights: An account can have Full Control on a specific database folder without belonging to local administrative groups.
• Failing Authorization Continuously within an Active Session: Network sessions remain open while dozens of unauthorized file read requests generate access denied errors.

---

What Is Not Possible

• Authorization Without Prior Authentication: The Windows SRM rejects unauthenticated callers seeking access to securable objects (outside null sessions).
• Modifying ACLs Without Ownership or WRITE_DAC: Altering permissions requires either object ownership (Owner) or explicit WRITE_DAC rights.

---

Forensic Artifacts

Stage	Security.evtx Event ID	Meaning & Telemetry Value
Authentication Success	Event ID 4624	Session creation (LogonType, TargetUserName, TargetLogonId).
Authentication Failure	Event ID 4625	Invalid password, locked or disabled account (Status / SubStatus).
Share Authorization Attempt	Event ID 5140	Network share accessed (ShareName).
Detailed Object Authorization	Event ID 5145	Granular check (AccessMask, RelativeTargetName). Indicates Access Granted or Access Denied.

---

Key Takeaways

1. Authentication validates identity proof; authorization validates operational rights.
2. Event ID 4624 records network or interactive logon, NOT file tampering or theft.
3. Authorization evaluation occurs locally on the target host via the Security Reference Monitor.
4. NetExec [+] denotes authentication; Pwn3d! denotes administrative authorization.

---

Cross References

• Doc 06: Windows Access Tokens and Security Context
• Doc 08: NTFS Permissions, Share Permissions and ACLs
• Doc 23: NetExec: What Do the Results Actually Prove?