Event ID 4663: An attempt was made to access an object

Event 4663 covers four audit subcategories: File System, Kernel Object, Registry and Removable Storage. It is written when a process uses an access right on an object that has a system access control list entry matching both the account and the type of access. Microsoft is blunt about the default state: no audit events are generated for the default file system SACLs. That one sentence explains most forum threads titled "event 4663 not logging". Turning the subcategory on is half of the job, and placing a SACL on the folder or key you care about is the other half.

The sibling event matters for what 4663 cannot do. Event 4656 is logged when a handle is requested and has both Success and Failure forms. Event 4663 is logged when the right is used and has no Failure form at all. If you want to see someone probing for files they are not allowed to open, the evidence is a 4656 failure, not a 4663. And 4658, the handle closed event, only appears if you also enabled Audit Handle Manipulation. HandleId is the field that lets you stitch the three together.

The fields are short. The Subject block names the account and its SubjectLogonId. ObjectServer is Security. ObjectType says what kind of object it was: File, Key, Directory and Process are common values. ObjectName is the path. ProcessId is hexadecimal and matches the new process ID in a 4688 on the same host, and ProcessName is the executable that did the work. ResourceAttributes arrived in version 1 with Windows Server 2012 and Windows 8; it shows a "-" when the object has none.

AccessMask is a sum, which trips people up. In Microsoft's own sample the value is 0x6, and the AccessList names WriteData and AppendData: 0x2 plus 0x4. For file objects the building blocks are ReadData or ListDirectory 0x1, WriteData or AddFile 0x2, AppendData 0x4, ReadEA 0x8, WriteEA 0x10, Execute or Traverse 0x20, DeleteChild 0x40, ReadAttributes 0x80, WriteAttributes 0x100, DELETE 0x10000, READ_CONTROL 0x20000, WRITE_DAC 0x40000, WRITE_OWNER 0x80000 and SYNCHRONIZE 0x100000. For registry keys, ReadData means query key value, WriteData means set key value and ReadEA means enumerate subkeys. When a mask looks odd, subtract the largest block that fits and repeat.

Reads are plentiful and rarely worth an alert outside a few crown-jewel paths. Microsoft's monitoring advice for this event points at WriteData, AppendData, WriteEA, DeleteChild, WriteAttributes, DELETE, WRITE_DAC and WRITE_OWNER, which is the list of rights that change or destroy something. For kernel objects the same page says the events have little to no security relevance and are hard to parse, so scope your SACLs to File and Key objects on named paths.

ProcessName is where the sample earns its keep. It shows 7za.exe running from a user's Temp folder and reading a payroll export, one right (ReadData, 0x1), one file. A single event like that is weak. The pattern is stronger: an archiver or sync client launched from a writable user path against a protected folder is what data staging looks like (MITRE T1005, Data from Local System). Microsoft suggests comparing ProcessName with the process you expect for that object, flagging executables outside System32 and Program Files, and matching restricted substrings such as mimikatz or cain.exe.

Over a network share, 4663 loses the client address. Microsoft's comparison of the audit subcategories notes that Audit File System leaves out information that Detailed File Share records, the client's IP address being the example. On a file server, pair 4663 with 5145 for the source and use SubjectLogonId to land on the 4624 network logon that created the session. Volume is entirely a function of your SACLs, so start with one sensitive path, watch a day of traffic, then widen.

Registry keys follow the same rules. Put a SACL on a persistence location such as a Run key and a Set key value from an unknown process shows up as WriteData against ObjectType Key, with the key path in ObjectName. The Removable Storage subcategory is the quiet member of the family. With it enabled, copying files from a laptop to a USB stick leaves reads on the source files and writes to the device, which can document a manual exfiltration that no network sensor would ever see.

Most 4663 traffic is legitimate software doing its job: backup agents, antivirus scanners, search indexers and EDR sensors reading files all day, each under a stable ProcessName. Opening a document in Explorer can also produce several events in a row for a single human action. The first piece of tuning is a per-path baseline of ProcessName values. Once you know which executables normally touch the finance folder, the unexpected one is easy to isolate, and that works far better than any threshold on event counts.

Four shapes are worth a rule. The first is an unfamiliar process, especially one running from a user-writable folder, reading or writing a protected path. The second is fan-out: one process under one SubjectLogonId touching hundreds of distinct ObjectName values inside a minute, with WriteData or DELETE in the mask. That is the footprint of mass encryption or of a staging script walking a share. The third is DELETE (0x10000) on audit trails, logs or shared documents by an account that does not own them, which maps to indicator removal, T1070. The fourth is WRITE_DAC or WRITE_OWNER on a sensitive folder, where someone is rewriting the permissions that would otherwise stop them.

When one fires, work outward from the process. ProcessId leads to the 4688 for that process, which gives you the parent and command line. SubjectLogonId leads to the 4624 and tells you whether the session was interactive or a network logon. If the logon was a network one, the share events carry the source address. Check the file's last-known hash and the signer of the executable before you decide it is a backup agent you have not seen before.

Be honest about what the log cannot show. It reports the right that was used, so a handle opened and then abandoned may leave nothing behind, and denied attempts are invisible unless you also collect 4656 failures. A SACL that was edited away leaves no 4663 at all, so alert on the permission change itself (event 4670) for the paths you care about. Treat silence as missing data until you have proven the SACL is in place, by touching a test file and finding the event.