Auditing Changes To Permissions (Event ID 4670)

Last week, I mentioned that Vista had a neat new event (Event ID 4907) that told you when the SACL (e.g. the list of users/groups who generate security events *when they access* a file/folder/securable object) was changed. Well, there is another new event that you could say is the twin brother to Event ID 4907.

Event ID 4670 gets logged when anyone changes the DACL (Discretionary Access Control List) on a file, folder, or securable object. For more information on DACLs and SACLs, you can refer to this post below, but as a reminder, the DACL of a file/folder/object is the list of users/groups that *can access* or are *denied access* a file/folder. In other words, that file or folder's permissions.

Prior to Vista, you had to root around in the description field of Event ID 560 or 566/567 and check the Accesses granted to a user that touched a file to see if they could have (or actually did) change the permissions on a file. Now in Vista, Event ID 4670 will tell you immediately if the permissions get changed, who changed them, what they used to look like, and what they look like now. Here's a sample of how the event looks:

Permissions on an object were changed.

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

Object:
Object Server: Security
Object Type: File
Object Name: C:\financials.txt
Handle ID: 0xf50

Process:
Process ID: 0x50c
Process Name: C:\Windows\explorer.exe

Permissions Change:
Original Security Descriptor: D:AI(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)
New Security Descriptor: D:ARAI(A;;0x1e01bf;;;WD)(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)


So, you can see it looks a lot like its brother, Event ID 4907, even down to using the same SDDL strings to indicate the changes to user/groups who have permissions on the file. Very cool stuff.

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.

Tip of the hat to Eric at Microsoft

Many kudos to Eric Fitzgerald, the head of Microsoft's Windows Auditing Team, for his very candid explanation on the transposing of security event ids in Vista. He writes:

Doriansoft noticed that there's a relationship between our pre-Vista security event IDs and our Vista-era security event IDs.

For most security events:VistaEventId = PreVistaEventId + 4096

Why is this?

We needed to differentiate the Vista events from the pre-Vista events, because we were significantly changing the event content and didn't want to break automation. However we wanted to preserve the knowledge that security professionals already had in their heads about security events, so we wanted to make sure that there was a relationship between old and new event IDs.

We decided to offset the old IDs by some constant to get the new IDs. I wanted to offset them by a decimal number (say 6000, so 528 would become 6528, etc.). However event IDs are declared in hex in the source code and are all 3 digits long (528 = 0x210), and Raghu, my developer, wanted to conserve effort, and he won that battle so we added 0x1000 (4096) to the existing event IDs.

For what it's worth, I think Eric's initial approach would have been best, as I think most non-developers can deal with Base 10 offsets in their head much more easily than Base 16. Still, his candor in addressing the issue is refreshing, and is much appreciated.

Crash ... Into Me

Many of our high-security clients must enable the CrashOnAuditFail setting on their servers, as per government policy. In case you're not familiar with this setting, open up your Registry Editor, and visit the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

One of the values under this registry key is "CrashOnAuditFail" ... By default, this value is set to 0. If you set it to 1 (and I don't recommend you do, unless you have a test machine you're tinkering with), your system will Blue Screen as soon as the security log fills up, provided you have also prevented your workstation or server from overwriting events automatically in the security log. At that point, only an Administrator can log back on to the machine after a restart to clear the security log and reset the CrashOnAuditFail flag.

The purpose of this special setting is to prevent a computer from being used (e.g. logged into) by anyone other than administrators unless auditable events can be recorded in the security log. Thus, it is a very important setting in high-security networks.

Interestingly enough, Vista adds a new event related to this special registry value. In Vista (and presumably Longhorn server as well), Event ID 4621 gets logged when an administrator successfully recovers the system from a crash related to the Security log filling up. From a documentation and accountability standpoint, this is a nice new event that Vista brings to the table.

4096 Security Events Lane

What's a big difference in the Vista security log? Here's your clue ...

2^12
1000 in Base 16/Hex
1000000000000 in Base 2/Binary
4096 in Base 10

If you scan through your security log in Vista, you're going to see some very unfamiliar Event IDs.... 4616 (System Time Changed), 4624 (Successful Logon), etc.

Let's do some quick math:

4616 - 4096 = Our old friend Event ID 520
4624 - 4096 = Our old friend Event ID 528

For fun (I'm sure they had a more legitimate reason, right?), Microsoft decided to add 4096 to quite a few of the old well-known Security Event IDs in Vista. Now bear in mind this "subtract 4096" trick doesn't work for every event, and also understand that some of your favorite Event IDs have gone missing.

Missing Event IDs? Sure.

Like 540 (Successful Network Logon) ... he's been forced to reside with his first cousin 528 (Successful Logon) at 4624 No Caps Lock Drive.

Don't feel bad for 540 though. Just ask those naughty logon failure IDs of yesteryear, like 530 (Account Logon Time Restriction Violation) and 535 (The account password has expired). They - and several of their siblings - now have to live at 4625 Fat Fingers Boulevard.

For all those folks out there using scripts for security log management ... you have some updating to do.