Share via

Quick Overview of Object Access Auditing in Windows

  • Article

A lot of people are unhappy with object access auditing on Windows, because what they want to know is "who touched the object and what did that person do", but what Windows auditing tells you is actually "who touched the object and what did they ask for permission to do". The distinction is subtle, but if you are interpreting object access events as recording what changes were made to objects, then you're probably misunderstanding what the log is saying.

To that end, here's a brief overview of Windows Object Access auditing.

On all OS's since Windows NT 3.1 up to and including Windows Server 2003:

  • Event 560 is recorded when an attempt is made to open a handle an object, and the object has a System Access Control List (SACL) which matches the access attempt.
    • For successful accesses, the granted access mask is compared to the SACL for Access Control Entries (ACEs) which match the token used to request access, and if there is a match, the granted access mask is recorded.
    • For failed accesses, the requested access mask is compared to the SACL for ACE entries which match the token used to request access, and if there is a match, the requested access mask is recorded.
    • For more detail on access check and audit generation, read this:
  • Event 562 is recorded when a previously opened handle is closed.
  • Event 563 is recorded in the same manner as event 560, but when the object is a file opened with the FILE_FLAG_DELETE_ON_CLOSE flag.
  • Event 564 is recorded when a file handle opened for delete, is closed, and therefore the file is deleted.

Note that event 560 does not record what was done to the object, only what accesses were requested to the object. This is an important distinction.

On Windows XP and Windows Server 2003 a new feature "Operation-Based Auditing" was added:

  • Event 567 is recorded for the first instance of a specific access being performed against an open handle. The event records the access(es) that were performed against the handle.
    • Event 567 is only recorded for the first instance of any access against a given handle- if an application opens a file and writes to it a hundred times, only one WRITE_DATA event will be generated. If the same handle is used for a different access, then a new event will be generated with the new access. If more than one access is performed against a handle at the same time, the operation audit will include all accesses that were performed at that time.
    • Event 567 does not record the object name; it's necessary to correlate event 567 with the most recent event 560 (where 567.handle_id==560.handle_id) to determine the object name.
    • Event 567 does not record the results of changes to objects; that is, it doesn't record before & after values.
    • Due to a bug, remote accesses to files (via shares) do not cause event 567 until Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

On Windows Vista:

  • The event id numbers of all these events change by +4096. That is, 560 becomes 4656, 567 becomes 4663, etc.
  • Event 4663 (previously 567) records the object name; handle id correlation is no longer required.
  • For registry and DS objects, the old and new values of changed objects are recorded when practical.
  • Audit policy allows auditing to be enabled on a per-object-type (file, registry, etc.) basis vs. all-or-nothing.
  • Audit policy allows handle-based auditing to be disabled and only operation audits (event 4663) to be generated.

That's all for now! As always, comments are welcome!

Comments