Auditing Changes To Your Auditing (Event ID 4907)

Here's another nice new security event that has been added to Vista - Event ID 4907. It has been tasked with recording every time an administrator or program changes the SACL on an object, typically a file or folder. What's a SACL, you ask? Let's have a brief primer on that subject.

Every securable object (e.g. file, folder, registry key, etc) in Windows has a Security Descriptor assigned to it. The security descriptor, among other things, specifies:

1.) the user owner of the object
2.) the group of the object (used by Unix apps that run under POSIX)
3.) the DACL (Discretionary Access Control List), and
4.) the SACL (System Access Control List)

When you use Windows Explorer or Group Policy to change who can access a file or folder, you are changing the DACL. Similarly, when you click the "Advanced" button in Windows Explorer on a file or folders property page, and visit the Auditing tab, you are changing the SACL.

The SACL is what the operating system uses to determine which users, groups, and identities cause auditing events to be generated in the Security log when said users perform various actions on files, folders, registry keys, etc.

So to summarize: When you change the users/groups that *can access* a file/folder, you are changing the DACL. When you change the users/groups who generate auditing events *when they access* a file/folder, you are changing the SACL.

Anyway, back to Event ID 4907. In Vista, this event gets logged any time an administrator changes how a file/folder is audited. Here's a sample of the event description:

Auditing settings on object were changed.

Subject:
Security ID: DOMAIN\Admin
Account Name: Admin
Account Domain: DOMAIN
Logon ID: 0x1f472

Object:
Object Server: Security
Object Type: File
Object Name: C:\Folder
Handle ID: 0x28c

Process Information:
Process ID: 0x690
Process Name: C:\Windows\explorer.exe

Auditing Settings:
Original Security Descriptor:
New Security Descriptor: S:ARAI(AU;OICISAFA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)


Reviewing the description of this event, we see that we can determine:

1.) Who changed the SACL (DOMAIN\Admin)
2.) What program they used to change the SACL (explorer.exe)
3.) The name and type of the object changed (c:\folder, file)
4.) A SDDL representation of the old Security Descriptor and new Security Descriptor.

So now, in Vista, you can track anyone who changes how a critical file/folder is audited, including how it was audited BEFORE the change, and how it will be audited AFTER the change. Again, this is great from an accountability standpoint in organizations governed by compliance regulations.

Oh, and if you're curious about how to translate the SDDL string into something meaningful, please read this article.

Auditing and Storage Requirements

One thing that admins tend to overlook when setting up a SEM or event log management package on their network is the amount of storage required to house all of the event log data.

Regardless of which vendor you choose (or even if you decide to attempt to do it in house with scripts), you need to keep in mind that the data output from native Windows event log files (e.g. EVT/EVTX files converted into database tables) will be greater in size than the native event log files themselves.

As mentioned briefly in this earlier post, EVT files contain references to other information not present in the log file itself. The resolution of those references into meaningful data is one reason behind the increase in data size after conversion.

Another factor that causes data size expansion is the field structure of the database itself. The number of bytes allocated for certain fields, as well as the use of UNICODE strings (e.g. two bytes per character) can both further contribute to this phenomenon.

A while ago, we wrote a freeware utility that does a nice job estimating the storage required to maintain your log data in various formats over time. You can download our Auditing Volume Analyzer tool here.

One final caveat: some SEM vendors in the marketplace attempt to take the log storage issue out of the equation by providing their own "black box" or appliance for accumulated log data. In general, we frown upon that approach here as it has the potential to hold your data captive. Should an audit or other incident arise - the last thing you want is data held captive in a proprietary storage system. For more on this topic and our general philosophy on event log management, please read this article.

Who's that user changin' that key? It's me! It's me!

The gang at Microsoft did quite a number on auditing in Microsoft Vista and Longhorn Server. In addition to making legacy auditing events more granular in the Vista security log (e.g. containing more information), they've also added completely new events which will be well-received by administrators and compliance officers.

An example of one such new event is 4657 (Registry Value Changed). In Vista, if you set your audit policy correctly, you can tell Windows to log an event every time one or more values underneath a specific registry key are changed. Here's a sample of what the event looks like when it is logged:

A registry value was modified.

Subject:
Security ID: DOMAIN\SomeUser
Account Name: SomeUser
Account Domain: DOMAIN
Logon ID: 0x11b8ffd

Object:
Object Name: \REGISTRY\MACHINE\SOFTWARE\AppVendor\ProgramName
Object Value Name: AdminEmail
Handle ID: 0x2e8
Operation Type: Existing registry value modified

Process Information:
Process ID: 0xb40
Process Name: C:\Windows\regedit.exe

Change Information:
Old Value Type: REG_SZ
Old Value: adminold@domainXYZ.com
New Value Type: REG_SZ
New Value: adminnew@domainABC.com

Taking a look at the meat of the event, we can ascertain 1.) who changed the value, 2.) with what program, 3.) the name of the value, 4.) the old value data, and 5.) the new value data.

Pretty impressive. However, this does raise an interesting paradox. If certain registry data is so valuable that you want audit access to it, do you want that same data splashed into the event log? Yes, you can control access to the log, but having the data in the log to begin with raises some issues.

It might be cool if Microsoft had a tweak for this event that allowed it to be audited with everything BUT the value data included. Just a thought.

Backing Up Your EVT Files

Occasionally, we have admins send us EVT files that they have restored from live server backups (or recovered from the hard disk of a server that crashed) that cannot be opened in the Microsoft Event Viewer. This often generates a substantial amount of concern on their part, and so it merits discussion here.

When a Microsoft Windows NT, Windows 2000, Windows XP, or Windows 2003 Server is running, the EventLog service maintains an open handle to each of the active event logs on the system. From what we understand, each active event log is treated like a memory-mapped file. Simply performing a live backup of the event log files in the \system32\config folder, even if the backup software can work with open file handles, is ineffective. The linked data structures in the active event log file may not be "finalized" so that they can be read by the OpenBackupEventLog function, and so attempts to read these logs as if they were properly saved may fail.

Here's a quick way to test this sort of behavior. On your workstation, navigate to the \Windows (or Winnt)\System32\Config folder using Windows Explorer. Copy the active security event log file (e.g. SecEvent.evt) to your desktop. Then, open the Microsoft Event Viewer, and try and open the SecEvent.evt file you copied onto your desktop. The Event Viewer will tell you that the file is corrupt.

So that being said, how is it that you can still read active event log files via the Microsoft Event Viewer when the computer is online? Simple - the request to read the file is made directly to the EventLog service, as opposed to trying to read the data directly out of the active file itself. The EventLog service, in addition to logging new records to active event logs, also acts as a proxy "log record fetcher" for the benefit of authorized users that need to read the contents of the active logs.

A very interesting phenomenon can be observed, however, if you attempt to read an "active" event log file from the \system32\config directory on a hard disk partition when the operating system is not loaded. If the operating system located on that partition was shutdown properly (e.g. it didn't crash), the EVT files in this directory should be able to be read by the Microsoft Event Viewer as saved event log files. It would appear that the EventLog service, when shut down normally, makes sure that the linked data structures in the file are organized properly before the file is closed.

What can we learn from this?

1.) Normal backup software, even software that can backup open files, is not a reliable way to archive your EVT files should you need to access them in the future.

2.) Likewise, trying to read EVT files in the \system32\config folder on a hard disk partition where the last operating system session crashed, or where the computer was shut down dirty, may fail.

3.) The EVT files in the \system32\config folder on a hard disk partition where the last operating system session was shut down properly can most likely be read as saved EVT files in the Microsoft Event Viewer. So, provided the machine was shut down normally before the hard disk was removed (e.g. in a forensic examination for instance), chances are good the log data will be accessible.

To combat these sorts of issues, we introduced our Event Archiver(tm) software many years ago. Event Archiver can archive EVT files correctly via the EventLog service on multiple computers, so that they will be accessible for review many years down the road. Of course, this is one small aspect of its feature set, but is a very important feature nonetheless.