The Windows Security Log Revealed

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.

Next Chapter

Back to top

Setup PowerShell Audit Log Forwarding in 4 Minutes

 

 

Upcoming Webinars
    Additional Resources