Artifact Analysis: Object & Share Access Events (4663, 5140, 5145)

Note

Executive Summary: Object Access events within the Windows Security log provide the most granular level of audit visibility available on the operating system. They answer precisely “Who accessed this specific file, what process did they use, and what action did they perform?” Because logging every file operation would instantly overwhelm any SIEM, this is an opt-in feature requiring a surgical, two-step configuration involving Group Policy and System Access Control Lists (SACLs). When deployed correctly on “crown jewel” assets, it yields the highest-fidelity indicators of compromise (IOCs) in incident response.

1. The Prerequisite: Two-Step Configuration

If an analyst searches a standard Windows machine for Event ID 4663 and finds nothing, it is not an error; it is the default configuration. Generating these events requires a deliberate, two-step setup.

1. Enable the Global Audit Policy (GPO): Administrators must enable the Advanced Audit Policies via GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access
   • Set Audit File System to Success and Failure.
   • Set Audit File Share to Success and Failure (for Events 5140/5145).
2. Configure the SACL (The Surgical Strike): Even with the GPO enabled, Windows does not know which files are important. Administrators must apply a System Access Control List (SACL) to the specific target (e.g., C:\Secrets\passwords.txt).
   • Right-click the file → Properties → Security → Advanced → Auditing.
   • Specify the Principal (e.g., Everyone) and the specific access types to log (e.g., Read, Write, Delete).

2. Anatomy of Event 4663 (File System Access)

When a SACL-monitored file is interacted with, Event ID 4663 (An attempt was made to access an object) is generated. Parsing this XML record reveals the complete context of the action.

• Subject: The Security ID and Account Name of the user performing the action.
• Object Information: The Object Name (absolute file path) and Object Type (File or Key).
• Process Information: The Process Name (e.g., C:\Windows\System32\notepad.exe). This is critical for correlating the file access with Event ID 4688 (Process Creation) to understand the parent lineage.
• Access Request Information: The specific permission requested, such as ReadData (reading the file) or WriteData (modifying the file).

3. Network Share Access (Events 5140 & 5145)

When adversaries move laterally or exfiltrate data, they frequently access administrative or corporate file shares over the network.

Event ID 5140

A network share object was accessed. This logs the initial connection to the root of the share (e.g., \\SERVER\SYSVOL). It provides the Source Address (the attacker’s IP), making it an excellent pivot point for network tracking.

Event ID 5145

A network share object was checked to see whether client can be granted desired access. This is highly granular. It logs access to specific files inside the share. Notably, it logs the Relative Target Name. As detailed in the article on Named Pipes, if the accessed share is IPC$, this event logs the exact name of the Named Pipe the attacker is connecting to.

4. DFIR Investigation Scenarios

Deploying SACLs everywhere is a catastrophic operational mistake. DFIR teams use Object Access auditing strategically.

A. The Honeytoken (Deception Strategy)

The most elegant use of Event 4663 is deception. Create a fake, highly enticing file (e.g., C:\Users\Administrator\Desktop\Q4_Financial_Passwords.docx) and apply a SACL monitoring ReadData by Everyone. Since no legitimate user should ever open this decoy file, any Event 4663 targeting it is a 100% confirmed intrusion alert with zero false positives.

B. Guarding the Crown Jewels (Credential Dumping)

On a Domain Controller, the Active Directory database (ntds.dit) is the ultimate target. By applying a SACL to this file, analysts can monitor for credential dumping. If Event 4663 shows any process other than the legitimate lsass.exe attempting to read ntds.dit, an attacker is executing a DCSync or local extraction attack.

C. Ransomware Behavioral Detection

During a Ransomware Investigation, Event 4663 provides a distinct behavioral signature. A single user account (via a single process like cmd.exe or a custom binary) generating thousands of Event 4663 logs with WriteData and DELETE access rights within a few seconds is the undeniable signature of a mass-encryption routine.

5. Threat Hunting Queries

Deploy these queries to hunt for high-risk access patterns in your SIEM.

KQL (Ransomware Behavior)

hunt_mass_file_modification.kql

// Detects potential ransomware behavior by identifying excessive file modifications (Event 4663)
// by a single process in a short time window.
SecurityEvent
| where EventID == 4663
| where AccessList has "%%4417" // %%4417 translates to WriteData
// Group events by Process, Account, and a 1-minute time bin
| summarize ModifiedFiles = dcount(ObjectName), FileList = make_set(ObjectName) by bin(TimeGenerated, 1m), Computer, Account, ProcessName
// Threshold: More than 100 distinct files modified in 1 minute
| where ModifiedFiles > 100
| project TimeGenerated, Computer, Account, ProcessName, ModifiedFiles
| sort by TimeGenerated desc

Splunk (ntds.dit Access)

hunt_ntds_unauthorized_read.spl

# Detects unauthorized access to the Active Directory database
index=windows sourcetype="WinEventLog:Security" EventCode=4663
| search Object_Name="*\\ntds.dit"
# Exclude the legitimate System process
| search NOT Process_Name="*\\lsass.exe"
| table _time, host, Account_Name, Process_Name, Accesses

---

References & Further Reading

• Microsoft Security: Audit Object Access
• Related Artifact: Event ID 4688 & Process Lineage
• Related Artifact: The parent lineage
• Related Artifact: Named Pipes & SMB Lateral Movement
• Related Playbook: Ransomware Investigation Playbook