Windows Security Log Event ID 560
| Operating Systems |
Windows Server 2000
Windows 2003 and XP
|
|
Category | Object Access |
|
Type
|
Success
Failure
|
Corresponding events
in Windows
2008
and Vista |
4656
|
560: Object Open
On this page
Events of this category allow you to track failed and successful attempts to access files and other Windows objects.
Event 560 is logged whenever a program opens an object where:
- the type of access requested has been enabled for auditing in the audit policy for this object
- the result (success/failure) has been enabled for auditing for this object
- the account the program is running under is included in the users and/or groups specified for auditing in the audit policy for this object
In Windows, a program first opens an object - requesting certain types of access (i.e. read and/or write). Windows compares the objects ACL to the program's access token which identifies the user and groups to which the user belongs. The open may succeed or fail depending on this comparison. Regardless, Windows then checks the audit policy of the object. If the policy enables auditing for the user, type of access requested and the success/failure result, Windows records generates event 560.
In the case of failed access attempts, event 560 is the only event recorded. Note that the accesses listed include all the accesses requested - not just the access types denied. If the access attempt succeeds, later in the log you will find an event ID 562 with the same handle ID which indicates when the user/program closed the object.
One action from a user standpoint may generate many object access events because of how the application interacts with the operating system. This especially true with Windows Explorer and MS Office applications.
Event 560 is logged for all Windows object where auditing is enabled except for Active Directory objects. Windows objects that can be audited include files, folders, registry keys, printers and services. To audit access to Active Directory objects such as users, groups, organizational units, group policy objects, domains, sites, etc see event IDs 565 for Windows 2000, and both 565 and 566 for Windows 2003.
Object Type: specifies whether the object is a file, folder, registry key, etc.
Object Name: identifies the object of this event - full path name of file.
New Handle ID: When a program opens an object it obtains a handle to the file which it uses in subsequent operations on the object. You can link this event to other events involving the same session of access to this object by the program by looking for events with the same handle ID.
Operation ID: unkown
Process ID: matches the process ID logged in event 592 earlier in log. Prior to W3, to determine the name of the program used to open this object, you must find the corresponding event 592.
Image File Name: full path name of the executable used to open the object. W3 only.
Primary fields: When user opens an object on local system these fields will accurately identify the user. When a user at a workstation opens an object on a server (such as through a shared folder) these fields will only identify the server program used to open the object on behalf of the remote user. See client fields.
Client fields: Empty if user opens object on local workstation. When user opens an object on a server from over the network, these fields identify the user.
Logon IDs: Match the logon ID of the corresponding event 528 or 540.
Access: Identify the permissions the program requested. This includes both permissions enabled for auditing on this object's audit policy as well as permissions requested by the program but not specified for auditing. The accesses listed in this field directly correspond to the permission available on the corresponding type of object.
In the case of successful object opens, Accesses documents the types of access the user/program succeeded in obtaining on the object. However event 560 does not necessarily indicate that the user/program actually exercised those permissions. For instance a user may open an file for read and write access but close the file without ever modifying it. Prior to XP and W3 there is no way to distinguish between potential and realized access. Starting with XP Windows begins logging operation based auditing. See event 567.
Write_DAC indicates the user/program attempted to change the permissions on the object.
Free Security Log Resources by Randy
- Object Server:
- Object Type:
- Object Name:
- New Handle ID:
- Operation ID
- Process ID:
- Primary User Name:
- Primary Domain:
- Primary Logon ID:
- Client User Name:
- Client Domain:
- Client Logon ID:
- Accesses
- Privileges
Windows 2003 fields:
- Object Server:
- Object Type:
- Object Name:
- New Handle ID:
- Operation ID:
- Process ID:
- Primary User Name:
- Primary Domain:
- Primary Logon ID:
- Client User Name:
- Client Domain:
- Client Logon ID:
- Accesses
- Privileges
- Restricted Sid Count:
- Access Mask:
Setup PowerShell Audit Log Forwarding in 4 Minutes
Object Open:
Object Server:Security
Object Type:File
Object Name:C:\ConfidentialFiles\ ProjectPlan.doc.txt
New Handle ID:1468
Operation ID:{0,1023441}
Process ID:1688
Windows Server 2003 adds this field:
Image File Name:C:\WINDOWS\ system32\ notepad.exe
All versions of Windows log these fields:
Primary User Name:administrator
Primary Domain:ELMW2
Primary Logon ID:(0x0,0x804C2)
Client User Name:-
Client Domain:-
Client Logon ID:-
AccessesDELETE
READ_CONTROL
ReadAttributes
Privileges-
Windows Server 2003 adds these fields:
Restricted Sid Count:0
Access Mask:0x10080
Top 10 Windows Security Events to Monitor
Free Tool for Windows Event Collection