Chapter 7
Object Access Events

You can use the Object Access Security log category to audit any and all attempts to access files and other Windows objects. In addition to tracking files, you can track Success and Failure access attempts on folders, services, registry keys, and printer objects. The only auditable objects not covered by this category are AD objects, which you can track by using the Directory Service Access category.

The way in which you define the Audit object access policy and the format of information that the Security log records for this category are closely related to the structure of the Access Control Lists (ACLs) that all objects use to define who can access the object and how. When you enable the Audit object access policy for a given computer, Windows doesn’t immediately begin auditing all Object Access events for all objects; if it did so, the system would immediately grind to a halt.

Activating Object Access auditing is a two-step procedure. First, enable the Audit object access policy on the system that contains the objects that you want to monitor. Second, select specific objects and define the types of access you want to monitor. Make these selections in the object’s audit settings, which you’ll find in the object's Advanced Security Settings dialog box shown below.

Object Access has 11 subcategories. The two primary subcategories are File System and Registry, which track access events for the file system and registry, respectively.

Object Access Subcategories	Comment
File System	Track files and folders.
Registry	Track access to registry keys and values.
Kernel Object	We did not find any events associated with this subcategory.
SAM	Track objects in the local Security Account Manager.
Certification Services	Built-in Certificate Authority and PKI-related events.
Application Generated	Application reports events to Security log.
Handle Manipulation	We presently classify these events as noise.
File Share	Logs the first time a share is accessed.
Filtering Platform Packet Drop	Shows packets blocked by firewall and filtering platform.
Filtering Platform Connection	Shows applications and connections allowed or denied by filtering.
Other Object Access Events	Miscellaneous object events include Scheduled Tasks, DNS, and Plug&Play.

Two other types of objects—Kernel and SAM objects—have their own subcategories, which will be discussed later in this chapter. Finally, any remaining object types (e.g., services) that are not covered by specific subcategories are reported in the Other Object Access Events subcategory.

Note that all five of these categories share the same event IDs for object open, access, close, and delete events. Therefore, it’s important that you filter events based not just on event ID but on subcategory as well. Object Access events are one of the few Security log areas in which more than one subcategory can generate an event ID. Additional subcategories address other areas of security activity, including Windows Firewall events and Certificate Services.

Event ID	Title
4656	A handle to an object was requested
4658	The handle to an object was closed
4660	An object was deleted
4663	An attempt was made to access an object

Object Access Auditing

Using the "Advanced Security Settings" dialog box in the screenshot above you can limit auditing according to the user or group that is accessing the object (the Name column), the permissions that are requested (the Access column), and whether the access attempt failed or was successful (the Type column). Windows evaluates an object’s audit policy much as it evaluates the object's permissions. When a user attempts to access an object (e.g., when Fred tries to open budget.xls), Windows determines whether to report the attempt to the Security log. Windows analyzes all the audit entries that apply to the user who is attempting to access the object. If the object’s audit policy contains entries for several groups, and if the user who is attempting to access the object belongs to two or more of those groups, then Windows will log the event if any of the applicable entries match (i.e., if the user requested one or more of the permissions that are flagged for auditing and the outcome of the attempt matches the Success or Failure criteria of the audit entry).

Suppose that Alice has Modify access to the Accounting Data folder and its files, which include budget.xls. Write Data is among the permissions that Modify access comprises. Alice uses Excel to open and write to budget.xls. Windows matches Alice's action to the second entry in the folder’s Object Access audit policy. Alice is a member of the Everyone group, her permissions to the accessed file include Write Data, and her attempt to write to the file was successful. Windows would not match an attempt by Alice to open the file simply to view it: Such an attempt would successfully use Read Data permissions, which aren't specified for auditing. Now suppose that Fred, who has no access to Accounting Data, is snooping around the network and attempts to list the files in Accounting Data. Windows matches this failed access attempt to the first entry in the folder’s audit policy and trigger an Object Access event in the Security log.

The table below provides a complete list of permissions, the corresponding names used by Object Access events in the Security log, and an explanation the permission as applied to folders and files.

Permission	Name in Object Access Events	Explanation
		Folder	File
Traverse Folder/Execute File	Execute/Traverse	Folder traversed while browsing file system; permits movement through folders to reach other files or folders, if the user has no other permissions to the folders being traversed; has no effect unless the user lacks the Bypass traverse checking user right, which is assigned to Everyone by default	Script or .exe file executed
List Folder/Read Data	ReadData (or ListDirectory)	Names of subfolders and files queried by Explorer, dir command, or application	Actual content of file read
Read Attributes	ReadAttributes	Attributes (Read Only, Archive, System, Hidden) queried by Explorer, attrib command, or application
Read Extended Attributes	ReadEA	Extended attributes (as defined by applications) queried by Explorer, attrib command, or application
Create Files/Write Data	WriteData (or AddFile)	New file created in the folder	Content of file changed
Create Folders/Append Data	AppendData (or AddSubdirectory or CreatePipeInstance)	New subfolder created in the folder	Content appended to end of file
Write Attributes	WriteAttributes	Attributes (Read Only, Archive, System, Hidden) modified by Explorer, attrib command, or application
Write Extended Attributes	WriteEA	Extended attributes (as defined by applications) modified by Explorer, attrib command, or application
Delete Subfolders and Files	DELETE	Object deleted; allows or denies deletion of subfolders and files even when the user lacks Delete permission on the specific subfolder or file
Delete	DELETE	Object deleted; overridden by Delete Subfolders and Files permission on the parent folder
Read Permissions	READ_CONTROL	Object's ACL queried
Change Permissions	WRITE_DAC	Object's ACL modified
Take Ownership	SeTakeOwnershipPrivilege	Owner of object changed

Although you can limit auditing for a given object to specific groups or even individual users, we recommend sticking with the Everyone group. Singling out specific groups or users for monitoring puts you at risk of creating an incomplete audit trail and might expose you to claims of unfairness or raise questions as to the integrity of your information. Also be careful when specifying the type of access to monitor and when choosing whether to audit for Success or Fail types. You can easily create too inclusive an audit policy and deluge the Security log with useless noise. In particular, think twice about enabling Success auditing of Read Data, Read Attributes, Ready Extended Attributes, Read Permissions, and Execute permissions, which legitimate users use so frequently during the course of work.

In addition to the Type, Name, and Access columns, an object’s Advanced Security Settings contain an Apply To column. You can specify values for this column for container objects such as folders, thereby controlling whether and how Windows propagates the audit entry to child objects. The Apply To value defaults to This folder, subfolders and files but can be changed to any combination of the three. You can use the Apply To setting to fine-tune your audit policy so that it ignores file or folder access events that are irrelevant to your audit needs, thus eliminating some noise from the Security log. For instance, you might need a record of who is accessing sensitive files in a certain folder but have no interest in folder-level access, such as folder listings or creation of subfolders and files. In that case, you can enable auditing for the appropriate permissions but change the Apply To value to Files only. If you’d like to restrict the behavior of Apply To to child objects but prevent an audit entry from propagating to grandchild objects, you can select the Apply these auditing entries to objects and/or containers within this container only check box.

To properly use the Apply To setting, you must understand the dual meaning of certain permissions. Note that some auditable permissions have a different meaning for files than for folders. For instance, Create Folders/Append Data for a folder means that the user can create new subfolders within the folder; for a file, the permission means that the user can append data to the end of the file. Likewise, List Folder/Read Data for a folder lets users only list the names of files and subfolders within the folder; for a file, the permission lets users read the actual data contents of the file. What if you want to audit one of these dual meaning permissions for the folder only, not for the files within the folder? Or what if you need to audit access to the files within the folder but not access attempts to the folder itself? In such cases, use the Apply To setting.

When viewing an object's audit policy, you can determine where each audit entry is defined by consulting the read-only Inherited From column. In the example below, both entries are explicitly defined on the immediate folder, so this column reads <not inherited>. If you need to break the flow of inherited permissions at a certain level in your folder hierarchy and block those permissions from propagating down to a particular subfolder, you can clear the Include inheritable auditing entries from this object’s parent check box.

Object auditing is basically the selective logging of the access control decisions that Windows makes. Before enabling and configuring an object’s Object Access audit policy, know exactly what you mean to accomplish. Several common audit goals have corresponding audit settings.

Goal	Audit Settings
	Type	Access
Audit trail of changes to a file	Success	Write Data Append Data
Know when someone tries to access an object that they shouldn’t	Failure	All Permissions
Audit trail of access control changes to a folder	Success	Change Permission
Audit trail of deletion of a folder or of any file in the folder	Success	Delete Subfolders and Files Delete

Operation-Based Auditing

Event ID 4656 logs the permissions that are requested by the application that's trying to open a handle to the audited object. But that doesn’t mean that the application actually exercised those permissions before closing the object. For instance, a user might successfully open an object for Read and Write access but close the file without every changing its content.

In Windows, after a user successfully opens a handle to an object and then exercises one or more permissions, Windows logs event ID 4663. This event, which is a big improvement over earlier methods, lists the Handle ID that was originally logged by event ID 4656, as well as the exercised permissions. Any subsequent uses of the same permissions do not trigger duplicate instances of event ID 4663; Windows simply logs event ID 4663 the first time that the user exercises a given permission between the opening and closing of the object. (Event IDs 4656 and 4658 are still necessary to show when the object was open and when it was closed.)

We aren’t sure why the event ID 4663 description specifies “access attempted.” This event is always a Success event and shows the permission that was actually used.

Windows handles object deletions a little differently than it handles other Object Access events. In addition to logging event ID 4656, Windows logs event ID 4660 (Object Deleted), which lists the Handle ID that was originated in event ID 4656. When successful Delete access has been enabled for auditing on an object, Windows logs event ID 4660 when that object is deleted. To determine the name of the deleted object, you must correlate the Handle ID with other events (i.e., event IDs 4656, 4663, and 4658). Event 4660 will be in close proximity to these events, but be aware that a process can open an object for Delete access much earlier than the process actually deletes the object.

It would be easier if Windows logged the object’s name in instances of event ID 4660 (Object Delete), but you must connect event ID 4656 and the subsequent event ID 4660 by using the Handle ID field. Such multiple-event correlation or pattern recognition is beyond the ability of most current event-log software, but we expect that to change as interest in the Security log continues to increase. Microsoft is getting better at providing information in the actual events as they occur but a need to see a pattern will always remain.

Sometimes, when you install new updates to Windows, the installer is unable to replace existing files because they are in use by the operating system. The common approach in such situations is to instruct NTFS to delete the object the next time the system boots but before the file is put into use. Windows should log such deferred deletions in event ID 4659 (A handle to an object was requested with intent to delete). Microsoft documentation describes this event as an attempt to open an object with the intent to delete it. Note: Event ID 4659 is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified in Createfile(). This flag is the only way to delete files that were opened exclusively by another program. However, as of the date of this publication, we have not been able to produce this event.

File System

The File System subcategory tracks access to file system objects. To set SACLs for file system objects in Windows Explorer, right-click the file or folder object, choose Properties, Security tab, click Advanced, and go to the Auditing tab to access the object’s Advanced Security Settings. Click Edit to change the auditing or see the details.

Event ID	Title
4656	A handle to an object was requested
4658	The handle to an object was closed
4660	An object was deleted
4663	An attempt was made to access an object
4685	The state of a transaction has changed
4985	The state of a transaction has changed

The Logon/Logoff and Detailed Tracking categories provide both an initialization and termination event ID that correspond to the beginning and end of a logon session or process. Likewise, the Object Access category generates event ID 4656 (Handle to object requested) when an object is opened and event ID 4658 (Handle to object closed) when the object is closed, along with other events in between, depending on what the application does with the open object. These events' Handle ID description field serves the same purpose as the Logon ID and Process ID fields in Logon/Logoff and Detailed Tracking events. To determine how long a file was open, simply look for an instance of event ID 4658 that has the same Handle ID as the preceding event ID 4656.

Object Access events reflect the interaction between Windows and an application—not between a user and the application. For instance, when Carol uses Microsoft Word to open memo.doc, edits a paragraph, and then closes the file, you might expect to find an instance of event ID 4556 followed by event ID 4658. Actually, unbeknownst to Carol, Word opens and closes the file multiple times in connection with her actions, and you’ll find events reflecting all this activity. In addition, Word creates a second, temporary file while a document is open. This file is saved periodically and acts as a backup while the file is being edited. Under normal conditions it is deleted when the file is closed. However, it may remain if a system crashes and Carol is unable to save it. When the file is opened again in Word the program allows Carol to choose which document she wants to save.

The fact that Object Access events reflect lower-level, application-to-operating system activity doesn’t render the category useless, but it means that the category generates many more events than you might expect or want, making analysis more complex. Some objects (e.g., files) are never kept open for very long. Operations such as listing a folder or deleting a file or folder are single, atomic actions—but they still generate the open and close instances of event ID 4656 and event ID 4658 in the Security log. Event ID 4656 provides many description fields that cover the object accessed, the user and program involved, and the permissions requested. This event is a big improvement over the Windows Server 2003 Object Open event 560. In Windows Server 2008 and later, the subject fields eliminate having to look in two different places for which account was used.

Field	Explanation
Subject	The user and logon session that performed the action
Security ID	The SID of the account
Account Name	The account logon name
Account Domain	The domain name or—in the case of local accounts—computer name
Login ID	A number that is unique between reboots and that identifies the logon session
Object	The object upon which the action was attempted
Object Server	Always “Security”
Object Type	“File" for file or folder, but can be other types of objects (e.g., Key, SAM, SERVICE OBJECT)
Object Name	The name of the object being accessed
Handle ID	A number that is unique between reboots and that allows you to correlate other events (i.e., event IDs 4656, 4658, and 4663)
Process Information	The process that Windows uses to access the object
Process ID	The process that is specified when the executable started, as logged in event ID 4688
Process Name	The program name and path
Access Request information	Information that is requested at the time the object is accessed; some programs request more access than will actually be used
Transaction ID	Use unknown
Accesses	The permissions that are requested
Access Mask	The bitwise equivalent of Accesses
Privileges used for Access Check	Privilege used to gain access (e.g., SeTakeOwnershipPrivilege)

This event’s Process Name field identifies the full path name of the executable that was started. For instance, if a user opens Notepad, the event will show something similar to C:\Windows\System32\notepad.exe as the process name. To uniquely identify each process during a system boot session, Windows uses a Process ID. Event ID 4688 (as discussed in Chapter 6) also lists the process ID of a new process in the New Process ID field and the Creator Process ID field.

Now that you understand the File System subcategory, let’s look at some Object Access auditing events from the other 10 subcategories. Many events are duplicated in several subcategories.

Registry

When Object Access auditing is enabled, the Registry subcategory is enabled by default. You can also use Auditpol to set the subcategory auditing individually. To set the SACL, open Regedit, right-click the object, choose Permissions, click Advanced, and go to the Auditing tab.

Many of this subcategory’s events are also logged by the File System subcategory. In addition, the new event ID 4657 documents creation, modification, and deletion of registry values. This event is logged between event IDs 4656 (open) and 4658 (close) events for the registry key in which the value resides. See the Operation Type field in event ID 4657 to find out whether the value was created, modified, or deleted.

Event ID	Title
4656	A handle to an object was requested
4657	A registry value was modified
4658	The handle to an object was closed
4660	An object was deleted
4663	An attempt was made to access an object

A big plus to this new event: it also tells you the old type/value prior to modification. Some possible types are listed in the chart below.

Type	Explanation
REG_SZ	String value
REG_BINARY	Binary value
REG_DWORD	Double word 32-bit value
REG_QWORD	Quad word 64-bit value
REG_MULTI_SZ	Multi-string value
REG_EXPAND_SZ	Expandable string value

Kernel Object

Auditing events in the Kernel Object subcategory are probably of interest only to developers. An example of a kernel object is a security token.

Event ID	Title
4658	The handle to an object was closed
4660	An object was deleted
4661	A handle to an object was requested
4663	An attempt was made to access an object

SAM

Events in the SAM subcategory allow you to track access to objects in the SAM in which local users and groups are stored on non-DC systems.

Event ID	Title
4658	The handle to an object was closed
4660	An object was deleted
4661	A handle to an object was requested
4663	An attempt was made to access an object

Certification Services

Certificate Services is the built-in Certification Authority and related Public Key Infrastructure (PKI) functionality in Windows Server. The Certifications Services subcategory events provide exhaustive auditing of related activity.

Event ID	Title
4868	The certificate manager denied a pending certificate request.
4869	Certificate Services received a resubmitted certificate request.
4870	Certificate Services revoked a certificate.
4871	Certificate Services received a request to publish the certificate revocation list (CRL).
4872	Certificate Services published the certificate revocation list (CRL).
4873	A certificate request extension changed.
4875	Certificate Services received a request to shut down.
4876	Certificate Services backup started.
4877	Certificate Services backup completed.
4878	Certificate Services restore started.
4879	Certificate Services restore completed.
4880	Certificate Services started.
4881	Certificate Services stopped.
4882	The security permissions for Certificate Services changed.
4883	Certificate Services retrieved an archived key.
4884	Certificate Services imported a certificate into its database.
4885	The audit filter for Certificate Services changed.
4886	Certificate Services received a certificate request.
4887	Certificate Services approved a certificate request and issued a certificate.
4888	Certificate Services denied a certificate request.
4889	Certificate Services set the status of a certificate request to pending.
4890	The certificate manager settings for Certificate Services changed.
4891	A configuration entry changed in Certificate Services.
4892	A property of Certificate Services changed.
4893	Certificate Services archived a key.
4894	Certificate Services imported and archived a key.
4895	Certificate Services published the CA certificate to Active Directory Domain Services.
4896	One or more rows have been deleted from the certificate database.
4897	Role separation enabled.
4898	Certificate Services loaded a template.
4899	A Certificate Services template was updated.
4900	Certificate Services template security was updated.

Application Generated

The Application Generated subcategory provides a way for applications to report audit events to the Security log and is related to Authorization Manager.

Event ID	Title
4665	An attempt was made to create an application client context.
4666	An application attempted an operation.
4667	An application client context was deleted.
4668	An application was initialized.

File Share

Windows logs event ID 5140, the sole event in the File Share subcategory, the first time you access a given network share during a given logon session. This event records the share name. Be aware that Windows Server logs off network logon sessions even sooner than past versions of Windows do. When a user closes all open files on a server, the server seems to immediately log off the user. To correlate events, this event provides the logon ID, IP address, and username.

Event ID	Title
5140	A network share object was accessed.

Filtering Platform Packet Drop and Filtering Platform Connection

The Filtering Platform Packet Drop and Filtering Platform Connection subcategories log events associated with packets and network connections that are permitted or blocked by Windows Firewall and the lower-level Windows Filtering Platform. Windows Filtering Platform subcategory appeared in Windows 2008. We aren’t sure why these events are logged under the Object Access category; perhaps because Windows Filtering Platform actually audits system services rather than network-level services.

Filtering Platform Packet Drop events

Event ID	Title
5152	The Windows Filtering Platform blocked a packet.
5153	A more restrictive Windows Filtering Platform filter has blocked a packet.

Filtering Platform Connection events

Event ID	Title
5031	The Windows Firewall Service blocked an application from accepting incoming connections on the network.
5154	The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections.
5155	The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections.
5156	The Windows Filtering Platform has allowed a connection.
5157	The Windows Filtering Platform has blocked a connection.
5158	The Windows Filtering Platform has permitted a bind to a local port.
5159	The Windows Filtering Platform has blocked a bind to a local port.

Other Object Access Events

The Other Object Access Events subcategory is a hodgepodge of miscellaneous Object Access events. The most valuable events in this category are the ones that allow you to monitor changes to scheduled tasks and file deletion.

Event ID	Title
4656	A handle to an object was requested.
4658	The handle to an object was closed.
4659	A handle to an object was requested with intent to delete.
4660	An object was deleted.
4663	An attempt was made to access an object.
4664	An attempt was made to create a hard link.
4691	Indirect access to an object was requested.
4698	A scheduled task was created.
4699	A scheduled task was deleted.
4700	A scheduled task was enabled.
4701	A scheduled task was disabled.
4702	A scheduled task was updated.

Bottom Line

Have a plan. As mentioned earlier in this chapter, simply auditing everything, for every access and for everyone, will make a system grind to a halt. Instead, use a targeted approach. Think about the most important objects you have and which access you are looking for. Then, begin selectively auditing objects. How will the event be used? Is it just for historical purposes, or do you want to take action as soon an event occurs? The possibilities are endless. As with any powerful tool, object auditing can accomplish a great deal if it is carefully understood and controlled.