Archive

Archive for the ‘Descriptions’ Category

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Decoding UAC Flags Values in events 4720, 4738, 4741, and 4742

April 28th, 2011 No comments

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

  • 4720 – user account creation
  • 4738 – user account change
  • 4741 – computer account creation
  • 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

  • PASSWD_NOTREQD 0x0020
  • LOCKOUT 0x0010
  • HOMEDIR_REQUIRED 0x0008
  • (undeclared) 0x0004
  • ACCOUNTDISABLE  0x0002
  • SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

 

Categories: Descriptions, HowTo Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 Comments off

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

Auditing Changes to Audit Policy

July 16th, 2010 No comments

Mitsuru, one of our support engineers in Japan, actually did some excellent research recently into exactly what our behavior is for auditing audit policy and I wanted to share that with you.

In Windows, we’ve always had auditing for changes to security policy.  Audit policy has always been one aspect of that policy.

However, it’s not so clear how to audit changes to audit policy.  The reason is, because the change itself might affect whether or not the audit is generated.  Usually in Windows, we generate audit after the operation that we are auditing, is performed.  When we generate audit, we always check audit policy to see if we need to generate an event.

So what would happen if you turned off the setting “audit changes to audit policy”?  Well, if we implemented it in the way we generally implement audit policy, nothing would happen- no event.  As described above, if we checked audit policy after we disabled audit policy, then the effective policy would say “don’t generate audit”.

But consider the case where a malicious audit or system administrator wants to cover their tracks.  One thing such a person might do, to not leave as much of a trace, is to disable audit policy before they do the bad thing, and re-enable it afterwards.  If we implemented audit normally, then there would be no trace of this.

To avoid this undesirable case, we changed around the instrumentation a little so that we always generate audit for certain audit policy change events.  This means that you might not get EXACTLY what you intended, but it also ensures that you can always find the significant events when someone disables  audit policy.

Anyway, to sum up, the following events are always audited when audit policy is disabled regardless of the “Audit Policy Change” subcategory setting in Windows Vista+:

4715 The audit policy (SACL) on an object was changed.
4719 System audit policy was changed.
4906 The CrashOnAuditFail value has changed.
4908 Special Groups Logon table modified.
4912 Per User Audit Policy was changed.

The following events are only audited when success auditing is enabled for the “Audit Policy Change” subcategory:
4902 The Per-user audit policy table was created.
4904 An attempt was made to register a security event source.
4905 An attempt was made to unregister a security event source.
4907 Auditing settings on object were changed.

Special thanks to Mitsuru for documenting this.

Categories: Descriptions, HowTo, Tips Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 Comments off

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented 🙂  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

XPath to generate a list of NTLM authentications on Windows Vista or Later

May 13th, 2010 No comments

Hi Everyone,


Sas sent me an email complaining that I am not posting as often as I should- sorry about that.  I am working on a different project now but I am still in close touch with the auditing team and I’ll try to do better.


Anyway a question that I hear regularly is, “how do I find all the NTLM authentications on my network”?


Other than running a network trace, the best way I have found (ok invented :-)  to do this is to look at the logon events in the audit log.


One of the changes we made to the logon events in Windows Vista (and therefore subsequent releases of Windows) was to include the NTLM protocol level in the logon events, if the NTLM auth package was used.


Now, with the new EventLog ecosystem, it’s easy to generate some XPath to find just these events.


Here’s the query:







*[System


   [Provider


     [@Name=’Microsoft-Windows-Security-Auditing’]


       and Task = 12544


       and (band(Keywords,9007199254740992))


       and (EventID=4624)


   ]


   and


   EventData


     [Data


       [@Name=’LmPackageName’] != ‘-‘


     ]



 ]


 


To use this in Event Viewer:



  1. Find the Security log under Windows Logs in the tree pane.

  2. Right-click the Security log, and choose “Filter Current Log…”

  3. Select the “XML” tab.

  4. Check the “Edit query manually” box.

  5. Replace the default query (“*”, or everything in the “<Select>” element), with the text in the box above.  I’ve formatted it for readability.

  6. Click OK

The event view will now be filtered and you’ll only see NTLM logon events.  Additionally, each filtered event will contain a “Detailed Authentication Information” section containing the protocol level (e.g. LM, NTLM, NTLM V2) in the “Package Name” field, and the session key length, if one was negotiated.







Detailed Authentication Information:
            Logon Process: NtLmSsp
            Authentication Package: NTLM
            Transited Services: –
            Package Name (NTLM only): NTLM V2
            Key Length: 128


 

Categories: Descriptions, Tips, Tools Tags:

Mapping pre-Vista Security Event IDs to Security Event IDs in Vista+

June 11th, 2009 No comments

I’ve written twice (here and here) about the relationship between the “old” event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the “new” security event IDs (4xxx-5xxx) in Vista and beyond.


In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.


The exceptions are the logon events.  The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096).  The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).


Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change).  These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent.  The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.


Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is “+4096” instead of something more human-friendly like “+1000”.  The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn’t know the version of Windows that produced the event.  We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.


So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4.  You can do this in your head.


However if you’re trying to implement some automation, you should avoid trying to make a chart with “<Vista” and “>=Vista” columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you’ll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

Mapping pre-Vista Security Event IDs to Security Event IDs in Vista+

June 11th, 2009 Comments off

I’ve written twice (here and here) about the relationship between the “old” event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the “new” security event IDs (4xxx-5xxx) in Vista and beyond.


In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.


The exceptions are the logon events.  The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096).  The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).


Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change).  These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent.  The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.


Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is “+4096” instead of something more human-friendly like “+1000”.  The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn’t know the version of Windows that produced the event.  We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.


So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4.  You can do this in your head.


However if you’re trying to implement some automation, you should avoid trying to make a chart with “<Vista” and “>=Vista” columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you’ll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

Mapping pre-Vista Security Event IDs to Security Event IDs in Vista+

June 11th, 2009 No comments

I’ve written twice (here and here) about the relationship between the “old” event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the “new” security event IDs (4xxx-5xxx) in Vista and beyond.


In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.


The exceptions are the logon events.  The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096).  The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).


Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change).  These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent.  The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.


Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is “+4096” instead of something more human-friendly like “+1000”.  The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn’t know the version of Windows that produced the event.  We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.


So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4.  You can do this in your head.


However if you’re trying to implement some automation, you should avoid trying to make a chart with “<Vista” and “>=Vista” columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you’ll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

Mapping pre-Vista Security Event IDs to Security Event IDs in Vista+

June 10th, 2009 No comments

I’ve written twice (here and here) about the relationship between the “old” event IDs (5xx-6xx) in WS03 and earlier versions of Windows, and between the “new” security event IDs (4xxx-5xxx) in Vista and beyond.


In short, EventID(WS03) + 4096 = EventID(WS08) for almost all security events in WS03.


The exceptions are the logon events.  The logon success events (540, 528) were collapsed into a single event 4624 (=528 + 4096).  The logon failure events (529-537, 539) were collapsed into a single event 4625 (=529+4096).


Other than that, there are cases where old events were deprecated (IPsec IIRC), and there are cases where new events were added (DS Change).  These are all new instrumentation and there is no “mapping” possible- e.g. the new DS Change audit events are complementary to the old DS Access events; they record something different than the old events so you can’t say that the old event xxx = the new event yyy because they aren’t equivalent.  The old event means one thing and the new event means another thing; they represent different points of instrumentation in the OS, not just formatting changes in the event representation in the log.


Of course I explained earlier why we renumbered the events, and (in the same place) why the difference is “+4096″ instead of something more human-friendly like “+1000″.  The bottom line is that the event schema is different, so by changing the event IDs (and not re-using any), we force existing automation to be updated rather than just misinterpreting events when the automation doesn’t know the version of Windows that produced the event.  We realized it would be painful but it is nowhere near as painful as if every event consumer had to be aware of, and have special casing for, pre-Vista events and post-Vista events with the same IDs but different schema.


So if you happen to know the pre-Vista security events, then you can quickly translate your existing knowledge to Vista by adding 4000, adding 100, and subtracting 4.  You can do this in your head.


However if you’re trying to implement some automation, you should avoid trying to make a chart with “<Vista” and “>=Vista” columns of event ID numbers, because this will likely result in mis-parsing one set of events, and because you’ll find it frustrating that there is not a 1:1 mapping (and in some cases no mapping at all).


Eric


 


 


 

Categories: Descriptions, Tips, Tools Tags:

Windows Server 2008 Security Events Posted

April 17th, 2008 Comments off

Fadi, Ned and Brian of the auditing team have documented all the auditing events by audit policy category and subcategory for your reference.


Check it out in the Knowledge Base.


Even better, they documented all the events in spreadsheet format, and that’s propagating to the Microsoft Download Center.  I’ll publish the link when it’s online.


2008-04-17 UPDATE:  Brian just sent me the link: here is the spreadsheet.


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

Windows Server 2008 Security Events Posted

April 17th, 2008 No comments

Fadi, Ned and Brian of the auditing team have documented all the auditing events by audit policy category and subcategory for your reference.


Check it out in the Knowledge Base.


Even better, they documented all the events in spreadsheet format, and that’s propagating to the Microsoft Download Center.  I’ll publish the link when it’s online.


2008-04-17 UPDATE:  Brian just sent me the link: here is the spreadsheet.


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

Windows Server 2008 Security Events Posted

April 17th, 2008 No comments

Fadi, Ned and Brian of the auditing team have documented all the auditing events by audit policy category and subcategory for your reference.


Check it out in the Knowledge Base.


Even better, they documented all the events in spreadsheet format, and that’s propagating to the Microsoft Download Center.  I’ll publish the link when it’s online.


2008-04-17 UPDATE:  Brian just sent me the link: here is the spreadsheet.


2010-04-01 UPDATE:  Here is the link to the updated spreadsheet for Windows 7 and Windows Server 2008 R2.

Categories: Descriptions, Tools Tags:

You learn something new every day- Logon Type 0

February 26th, 2008 No comments

Today I encountered something new in the logon event- I thought that was old hat and I knew all there was to know about that but I guess I was wrong.


The logon event (528/540 prior to Windows Vista, 4624 in Vista and Windows Server 2008) has a field called a Logon Type.  This is a code that is passed into the logon API that tells the authentication system in Windows which policy to check the logon against.  Windows has separate policy checks for network logons, interactive logons, etc., so that you can allow users to access a system in some ways but not in others.


The logon type code is, in C/C++ parlance, an enumerated value- it’s an ordered list of numeric values, each with an associated name, and these are defined in a publicly available file in the source code (ntsecapi.h).  In the source code, the values are always referenced by name.


Today on one of the internal aliases someone actually found a logon event with a logon type of 0- I have never personally seen one of these before and 0 is not defined in the SECURITY_LOGON_TYPE enumeration, so I would have assumed that it was a bug- but it turns out that we are aware of this case and use it occasionally for system logons.


So there you are.

Categories: Descriptions, Tips Tags: