Windows Security Logging and Other Esoterica : Tips

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

Eric Fitzgerald — Thu, 11 Jun 2009 02:09:00 GMT

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

Minimizing Directory Service Audit Event Noise

Eric Fitzgerald — Fri, 05 Sep 2008 00:51:00 GMT

I've written before on noise reduction in the Windows security event log. I've also written to describe how object access auditing works. But, I still get questions on how to reduce noise from object access events. The other day I got that question, specific to Directory Service objects, on an internal discussion list so I thought I'd clean up the answer a bit and share it with the world. In general the same is true for any type of object, although there are a few more knobs to control for DS objects.

Object access audit is generated when the system access control list (SACL) on the object matches the access that was performed on ALL of the following conditions:

Object - the object that was accessed must have either an explicit or inherited SACL. The access performed is compared against the ACEs in that SACL.
Success or failure of activity - every audit access control entry (ACE) in a SACL will be either of type AUDIT_SUCCESS or AUDIT_FAILURE. The access performed must match the access type of the ACE for the rest of the ACE to be considered.
User account - the accessing user's token is compared against each ACE matching the access type. If the user, or a group the user belongs to, matches the SID in the ACE, then an audit might be generated.
Access - the access being performed must match the audited accesses in the access mask in an otherwise matching ACE.

The specific auditing algorithm is discussed here.

So the way to reduce the number of audit events (566 on Windows Server 2003, 4662 on Windows Server 2008, or one of the new DS Change events on Windows Server 2008) is to cause one or more of those conditions to fail, except in the specific cases that you care about.

The SACL which will generate the most audit events is "Everyone:Success & Failure:All accesses" on the domain head with OI,CI (object inherit & container inherit flags) for all object types. This SACL matches all of the above conditions in all cases. (Incidentally I think that this is pretty close to the default SACL- with the exception of failures- for Windows 2000 Active Directory installations, and SACLs are not updated when DCs are upgraded from version to version. Windows Server 2003 has much more conservative SACLs for new installations of AD.)

To reduce noise, I offer the following suggestions, addressing each of the above conditions:

Audit only the objects that you care about. User accounts and groups already are well-audited with "Account Management" auditing, so don't audit them with DS access. Perhaps audit OUs, or other DS objects. Use the Object Type and attribute type restrictions that you have in DS Access auditing. Also, in Windows Server 2008, you can affect auditing on a per-object basis by adjusting the SearchFlags attribute in the AD schema for the object. SACLs are more easily reversed so are probably a more acceptable method of controlling audit for most organizations.
Audit successful accesses only. Failed accesses are common and are NOT indicative of any security problem; in fact many failures are not even explicit requests by the user but are just normal requests made by the OS, and the OS will re-try with less access if the operation fails. In my experience failure auditing is primarily useful for troubleshooting, not for security.
Audit the "Everyone" group. Although this matches any user, you will not accidentally miss any accesses that you care about due to failing to audit a user account who has access to the objects in question. The only time that you would NOT audit "Everyone" is if you had an application or service account which was very noisy; in that case you'd need to create a group with all accounts EXCEPT the noisy accounts, and audit that group.
Audit only the accesses that you care about. Specifically, read accesses occur much more often (in my experience, a conservative estimate is about a 100:1 ratio) than write accesses. If you restrict your auditing to "write" type accesses (including change, delete, change permissions, create, etc.) then you will end up generating far fewer events. Auditing for read access is very noisy. If you must audit for reads, consider auditing fewer objects, perhaps only auditing reads on the container object instead of the objects in the container, or on one "interesting" object in any given container as a "canary".

Tracking User Logon Activity Using Logon Events

Eric Fitzgerald — Thu, 21 Aug 2008 02:32:00 GMT

I get the question fairly often, how to use the logon events in the audit log to track how long a user was using their computer and when they logged off.

As I have written about previously, this method of user activity tracking is unreliable. It works in trivial cases (e.g. single machine where the user doesn't have physical access to the power switch or power cord), and it works most of the time in simple cases where there is good network connectivy and the user is not trying to evade detection. If the user has physical access to the machine-- for example, can pull out the network or power cables or push the reset button-- and if the user is actively trying to evade time tracking, then the only reliable solution is to surreptitiously put a video camera (subject to local laws) in a place that can monitor the user's presence in front of the keyboard (yes I am aware of research done to track sound of keyboard clicks, etc.).

There is no way to instrument the OS to account for someone who just backs away from the keyboard and walks away. The screen saver, if configured, will come on after a configurable delay since the last keypress or mouse movement. Yes, if you know the SS delay then you could just work that into your calculations. However the workstation does not lock until the screen saver is dismissed (some of you might have noticed that when you bump the mouse to dismiss the screensaver, sometimes you see your desktop for a fraction of a second- that’s because your machine isn’t locked while the screen saver is being displayed). And the events don't tell you whether the workstation was locked or auto-locked so you don't really know whether to add in the screen saver delay factor. Plus, prior to Windows Vista, there is no workstation lock event at all, only an unlock event, which is constructed in a way which makes it difficult to correlate with the original logon event.

So the bottom line is, I don't advocate or recommend this method for tracking the time a user spends at the keyboard. If I were hypothetically called as an expert witness, I would testify that such a method is unreliable and trivially circumvented. You have been warned, I've beaten that dead horse enough I guess.

Given that you are disregarding all my contrary advice, how are you going to accomplish this?

First, we need a general algorithm.

Use time (for a given logon session) = Logoff time - logon time

Now, what about the cases where the user powers off the machine, or it bluescreens, or a token leak prevents the logoff event from being generated, etc.? We can use the BEGIN_LOGOFF event to handle token leak cases. We can use the shutdown event in cases where the user does not log off. And in case of crashes, the only event we can use is the startup event. Note that each of these introduces increasing levels of uncertainty.

Logoff time = (logoff time | begin_logoff time | shutdown time | startup time)

This is good, but what about the time the workstation was locked?

Workstation lock time = unlock time - lock time
Total workstation lock time (for a given logon session) = SUM(workstation lock time)

How about remote desktop & terminal server sessions, and fast user switching? You can connect and disconnect from logon sessions, during which time the user technically isn't using the computer.

Session idle time = session connect time - session disconnect time
Total session idle time (for a given logon session) = SUM(session idle time)

How about times when the machine was idle? We can estimate that by looking at the time the screen saver was in place and adding the screen saver timeout.

Console idle time = (screen saver dismiss time - screen saver invoke time + screen saver delay)
Total console idle time = SUM(console idle time)

Putting all of this together and modifying our original formula, we get:

Use time (for a given logon session) =
   Logoff time - logon time
      - SUM(workstation lock time)
      - SUM(session idle time)
      - SUM(console idle time)

When we expand it, it is not quite so pretty:

Use time (for a given logon session) =
   ( (logoff time | begin_logoff time | shutdown time | startup time) - logon time )
      - SUM(unlock time - lock time)
      - SUM(session connect time - session disconnect time)
      - SUM(screen saver dismiss time - screen saver invoke time + screen saver delay)

You have to be very careful that you only look at events that are properly contained chronologically between two other appropriate events, to avoid accidentally pairing the wrong logon and logoff events, or pairing a lock workstation event from one logon session with a different logon session. The best correlation field is the Logon ID field, the next best are timestamp and user name. At various times you need to examine all of these fields.

Now, which event IDs correspond to all of these real-world events?

They are all found in the Security event log. The pre-Vista events (ID=5xx) all have event source=Security. The Vista/WS08 events (ID=4xxx) all have event source=Microsoft-Windows-Security-Auditing.

512 / 4608 STARTUP
513 / 4609 SHUTDOWN
528 / 4624 LOGON
538 / 4634 LOGOFF
551 / 4647 BEGIN_LOGOFF
N/A / 4778 SESSION_RECONNECTED
N/A / 4779 SESSION_DISCONNECTED
N/A / 4800 WORKSTATION_LOCKED
* / 4801 WORKSTATION_UNLOCKED
N/A / 4802 SCREENSAVER_INVOKED
N/A / 4803 SCREENSAVER_DISMISSED

* prior to Windows Vista, there was no event for locking the workstation. Unlocking the workstation generated a pair of events, a logon event and a logoff event (528/538) with logon type 7. These events had the same user name as the "original" logon session and were completely enclosed chronologically by the logon/logoff events for the "real" logon session, but did not contain the Logon ID of the original logon session or other unambiguous correlator. This makes correlation of these events difficult.

All of these events are generated in the Logon/Logoff audit policy category, although on Windows Vista and Windows Server 2008 they are scattered among the various subcategories in this audit policy category. The audit event spreadsheet that Ned wrote has all the policy subcategory mappings as well as the event descriptions.

Sorry that this is more of a do-it-yourself than a solution-in-a-box, but this is pretty difficult to script and so far I haven't worked on a project that required this.

Eric

Ned on Auditing

Eric Fitzgerald — Sun, 20 Apr 2008 06:14:00 GMT

I often talk about Ned, who is the current subject matter expert in Microsoft product support for the auditing feature in the US (Fadi is your guy in the Middle East and we have a couple of guys in Europe). Well, Ned has a blog and I thought I'd point you guys there. His recent posts on auditing include a description of how to deploy the special groups logon auditing feature with group policy.

You learn something new every day- Logon Type 0

Eric Fitzgerald — Tue, 26 Feb 2008 23:49:00 GMT

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.

Why does Windows XP generate so many logon failure events?

Eric Fitzgerald — Sat, 10 Nov 2007 02:23:00 GMT

I got the question last week, why there are so many logon failure events on Windows XP when it is not domain joined.

The short answer is, by design. (Yes, bad design.)

The longer answer is that the shell team is working around the fact that there is no "tell me if this user account has a blank password" API.

When in a workgroup (not domain joined), Windows XP displays a welcome screen that has little pictures (called "tiles") for each user who is permitted to log on to the computer.

The shell team wanted the experience that when you click on a tile, that you will immediately be logged on if your password is blank (we have good data that a large percentage of home users have blank passwords). They only want you to be prompted for a password if you actually have a password. Fair enough, and it also helps with accessibility for people for whom typing is challenging.

The XP Welcome Screen, when it is initialized each time it is to be displayed, attempts to log on each user for which a tile will be displayed, using a blank password. Users with non-blank passwords will cause failures in this case (other users will cause logon success events followed by logoff success events). [2007-11-21 correction]

The Welcome Screen uses the result of these logon attempts to decide whether to display a password box when you select a user's tile. If the user has a blank password, they will be logged on instead of being prompted for a password.

Why are they logging on the account? Well it turns out to be the easiest way to tell if your password is blank. We don't have a "is your password blank" API- that would be a security disaster- and we would prefer that the shell team not go mucking about in the SAM, retrieving hashes and computing the blank password hash for each account so that it could compare them.

I asked for this behavior to be changed prior to XP's release. Specifically I asked that the blank password check be moved from Welcome screen initialization to tile selection- this would still cause logon failures but many fewer of them. I was declined. I asked for fixes to it in SP1 and SP2 and was declined. At this point we will not be revisiting this "feature"; the Welcome Screen was redesigned to eliminate this problem.

The shell team who designed the Welcome Screen did not feel that auditing was a common scenario for workgroup machines, and I didn't (and still don't) have any business case to dispute that.

List of Windows Server 2003 Events

Eric Fitzgerald — Fri, 12 Oct 2007 21:45:00 GMT

So a long time ago, back in my days of providing technical support for Windows NT 4.0, I published "Security Event Descriptions". This article was the "schema" so to speak, for the Windows NT 4.0 security event log events.

Technically Windows events are not schematized until Windows Vista; or put another way the schema is implicit based on the instrumentation in the code- since the event is raised by some function in the code, the "schema" could be interpreted as the parameter order in the call to that function.

Anyway security monitoring types love that article, but I hate it. It's just better than nothing. It doesn't state which events map to which audit policy categories. It does tell you whether the event is a succss or failure event but it doesn't alert you to the cases where the same event is used for success and failure (e.g. event 560).

When Windows 2000 came around and we added two new audit policy categories (DS Access and Account Logon [which was a huge naming blunder]), I wrote an article for the Windows 2000 security events. However it was so large I broke it into two articles.

I didn't write an article for Windows Server 2003. At first I didn't think it was necessary because we propagated all the WS03 events to the Technet Events & Errors Message Center web site. I wrote custom content for the top 30 or so events by volume of searches

(On a side note, did you ever wonder what happens when you click the "More Information" link at the bottom of the Event Viewer event description? We send the event source, event ID, OS version and so forth to the Technet E&E site and display the content that is returned. We count the number of hits for each OS Version/Source/Event ID combination and then our writing teams pester the component owners to populate that content.)

Anyway, I was making excu^h^h er, explaining why I didn't write the KB articles for Windows Server 2003 security events. So I thought the E&E message center would be all that anyone needed. It didn't strike me as that important that you had to have seen the event (or at least know it exists) before you could use the site. However since then I have received a large number of requests for the event definitions, mainly from people who were creating security event management solutions.

So here's what I have for you, courtesy of Ned, one of the audit log posse here at Microsoft. If you want a complete list of WS03 security events, then I suggest you look at chapter 4 of the Windows Server 2003 Security Guide. This documents the event IDs of all the security events on Windows Server 2003. Plus, it groups them by policy category, in case you ever wanted to know what you are in for if you enable one of the categories for audit. If you want the layout of the event (what data is in the description field, and in what order) then just look for that specific event on the Technet E&E site or click the link in the bottom of the event description in Event Viewer.

I've already described how the Vista and Windows Server 2008 (and subsequent releases) event systems are self-documenting, so I won't go into that further here.

One last tip: If you own Microsoft System Center Operations Manager 2007, then you can search for a file called EventSchema.xml on the media. It is an XML document that describes one possible normalization all the security events from Windows 2000 forward, and the semantic content of the normalized events.

2007-10-31 UPDATE: There is also an event-id-to-audit-policy-category map here.

Help! Someone has deleted events from my Windows event log!

Eric Fitzgerald — Sat, 11 Aug 2007 01:59:00 GMT

From time to time I hear this, and it usually turns out not to be the case.

I'll begin with a little background.

First, The eventlog service does not have (and never did have) any public or private API to delete individual events- there is a log clear API but nothing else. The eventlog team thought about implementing selective delete for Vista (there were some internal groups asking for it) but a lot of us security types yelled at them and nothing came of it. Logs are logs, not databases- if you want selective delete, export the events you want to a database and have at it.

Second, there is no getting around the 10 Immutable Laws of Security, particularly law #6 (a computer is only as secure as the administrator is trustworthy) and law #2 (if a bad guy can alter the operating system on your computer, it's not your computer anymore).

What this means is that, no matter if we implemented the most advanced, coolest, 1337est event-signing/real-time-exporting/writing-to-optical-media-and-a-line-printer-too event system, IT DOESN'T MATTER IF THE ATTACKER IS THE ADMINISTRATOR- all we do is reduce the window of time that that person has to do his dirty work. Now I will admit there is value in those features, but if such an evil person were to use his powers of debugging to open the services.exe process (where eventlog lives) and inject a thread which alters the eventlog data structures in memory in real time, prior to commit to disk, then none of that stuff would help us. As a matter of fact such tools exist, they are not theoretical. I haven't seen the Vista versions yet but there's no technical reason why such a tool could not be built for Vista.

However, the cases I've seen of apparent gaps in event logs have a much more mundane explanation: the "Retain X days" event retention policy. This is an evil setting; if people truly understood it they wouldn't use it. Prepare to truly understand it.

Imagine you have a finite space S to store resources of type R. You get a constant incoming stream of R's, and put each of them into S. Now imagine that S is full and a new R arrives. You have two choices:

1.       Throw the new R away.
2.       Remove one or more of the old R's from S (enough so that the new R can fit into S) and put the new R into S.

When selecting which old R's to discard, the generally accepted best practice is that you should throw away the oldest R first- in other words freshness is a priority. Of course if you wanted to optimize for space you could just pick the smallest old R equal to or larger than the new R, but that would cause ordering problems if you wanted to maintain sequential access. You could even pick one or more old R's at random but that would be too arbitrary for most structured purposes like logging.

Now imagine that you had an additional constraint: you can throw away old R's, but only if they're more than X days old.

Now your choices are:

1.       Throw the new R away, or
2.       Throw away one or more of the old R's, if and only if there are enough R's that are older than X.

If there are no R's older than X, you may not discard any old R's and since you have a fixed size buffer S and there is no room for the new R, you MUST choose option 1- throw away the new R. You have no other choices.

This is the situation with event log. "Retain X days" actually CAUSES event loss (as does "Overwrite as needed"). However, Overwrite as needed causes predictable event loss (oldest events gone). Retain X days causes unpredictable event loss (if the log is full and there are no events older than X days, then NEW events are thrown away until there are some events older than X days).

Detecting gaps in your log

Can we detect if someone has deleted events out of your log?

At the end of the day, the event log is an ordered list of data structures (called event records), with each having a pointer to the next. There is also a unique, monotonically increasing sequence number associated with each event record.

A clever attacker will have disabled the instrumentation that causes the event to be raised; eventlog will never have been involved so there will be no gap (but no event).

A less clever or less resourceful attacker who deletes an event from the log, probably will not go fix up the sequence numbers for the rest of the log (in fact the attacker might not even fix up the pointers, causing the eventlog service to crash or hang).

We can use this priciple to our advantage. By examining each event and looking at its sequence number, we can look for gaps in the stream and, although we can never be sure that there was no tampering, we can often tell when there was tampering.

Here's a VBScript that demonstrates this concept. I don't provide VBScript support; you're on your own on this one.

'EventLogGapDetector.vbs

' (c) 2007 Microsoft Corporation, All Rights Reserved

'

strComputer = "."

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2")

Set colItems = objWMIService.ExecQuery( _

    "SELECT * FROM Win32_NTLogEvent ",,48)

iPrev = 0

first = true

gapdetected = false

newgapdetected = false

currlogfile = ""

oldlogfile = ""

For Each objItem in colItems

    iCurrent = CInt(objItem.RecordNumber)

    currlogfile = objItem.Logfile

    if ((iCurrent <> (iPrev-1)) and (not (first)) and currlogfile=oldlogfile) then newgapdetected = true

    if (newgapdetected) then Wscript.Echo "Gap detected, log file = " & currlogfile & ", last record = " & iPrev & ", current record = " & objItem.RecordNumber

    if (newgapdetected) then gapdetected = true

   iPrev = CInt(objItem.RecordNumber)

    first = false

    newgapdetected = false

    oldlogfile = currlogfile

Next

if not (gapdetected) then Wscript.Echo "No gaps detected."

Eric

The information provided in this post is provided "AS-IS" with no warranty, and confers no rights.

Documentation on the Windows Vista and Windows Server 2008 Security Events

Eric Fitzgerald — Wed, 01 Aug 2007 00:36:00 GMT

I'm hearing lots of complaints that we don't have KB articles on these yet. Doriansoft has a blog post complaining that the "add 4096" rule doesn't work because we collapsed the logon events into a single success event and failure event (from 2 success events [528, 540] and 10 failure events [529-537, 539]).

Well, In Vista and beyond the event log is self-documenting. From an elevated command prompt (one with admin privileges), type the following:

wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true

This example dumps only the 360 or so unique security event messages (publisher=Microsoft-Windows-Security-Auditing); other publishers can be enumerated with the ep switch of wevtutil.

Event messages can be formatted as XML using the /f switch, see the command-line help.

As a side note, this is, in slightly different format, the same information we publish in the KB, and a KB article is in the works.

Why did we renumber the events? As explained in my earlier post, we changed the internal detail of each event so much (to improve understandability, readability, consistency, etc.) that we would have broken essentially all existing automation anyway. By renumbering the events we made the automation break in as obvious a way as possible, and also made it as clear as possible that THESE ARE DIFFERENT EVENTS.

The "add 4096" rule is not meant to imply that the events are the same, but rather allows you to find the new equivalent event, if you have knowledge of the old event. Simply renumbering your automation will not make it work. It's a mental aid for you, the Windows security professional.

[2007-10-12 Update: changed tags]

The Trouble With Logoff Events

Eric Fitzgerald — Tue, 08 May 2007 23:37:00 GMT

A lot of you guys probably are using your SEM/SEIM systems to record logon and logoff activity without much of a second thought.

I just thought I'd bring one problem to your attention.

Logoff events are not strictly reliable.

From an engineering sense they are deterministic. However like many audit events, if you don't really think about how they work you might make assumptions that aren't correct. And you know what they say about assumptions...

Anyway, here's the problem. There is nothing that requires a client to notify you when the client decides to stop using your services. So for network logon sessions, the "logoff" event often just means "I got tired of waiting with reserved resources allocated for the client, so I reclaimed the resources. I'll give the client more resources if they come back (and can authenticate)". In other words- timeout.

You cannot, with protocols, force a client to notify you that they're done. Nice clients will if they can. Sometimes they physically can't notify you (this could be what we used to call the "backhoe and a beer" problem in my years in product support that is completely beyond the client's control). Sometimes they just choose not to notify you. I myself have designed software which just tore down the network connection when done or at the first sign of trouble, and started over again from scratch, rather than go through sophisticated "goodbye" or "fault" semantics. A robust server can handle the situation and will notice fairly quickly, reclaiming any reserved resources and generating any necessary audit trail. However I have seen software that has such expensive connection set-up that they hang on to connections for dear life long after everyone else would have turned out the lights and gone home. The funny thing is that half the time they don't realize that their client crashed, lost its state (that they were depending on for reconnection) and rebooted, and has reconnected with a new session. But I digress.

For interactive logon sessions, there is no guarantee of a logoff event either. There is no law of physics that forces a logoff audit if I pull the power cord out while I'm plugged in.

Plus, I've talked about token leaks before haven't I? Maybe not?

Windows logon events technically mean that we have created a data structure called a logon session. Associated with a logon session are one or more data structures called tokens. Each token has a number associated with it called a reference count, which is just a count of how many processes are using it at any given time. The reference count starts at 1 and goes up whenever a new process starts and down when the process terminates. It also goes up when a process specifically asks for a reference to a token and goes down when the process releases that reference. When the last process (your shell program, Explorer) releases its reference to your token, the token's reference count drops to zero. When the reference count drops to zero we destroy the token and the logon session associated with the token; the logoff event means the logon session was destroyed. For network logons we use a thread token that is given back to the service that asked to log you on; that token is usually assigned to a thread that does work on your behalf. It's all a little more complex than this in real life but this is basically how it works.

Anyway many applications, particularly server applications, request references to tokens, and then forget to release the references. This causes the reference counts to never drop to zero, and prevents us from generating the logoff event as a result.

To work around this we added the "Begin logoff" event (551) in Windows Server 2003, which can be interpreted as a logoff event, but this doesn't cover all cases. There are still some cases where logoff events are not generated due to poorly behaving applications. We fix all known instances of this in the operating system before we release Windows, and we test it rather thoroughly, but we can't promise that your applications will not leak tokens. If you encounter this you can troubleshoot by isolating each application until the token leak goes away, and then working with that application vendor.

Eric

Enumerating Stuff in AD when all you see is GUIDs in Audit Records

Eric Fitzgerald — Thu, 03 May 2007 23:19:00 GMT

A lot of things in Active Directory audit events show up as GUIDs but are not translated. Why is that?

Well, the Event Viewer in Windows only translate one kind of AD guid, the objectGUID. However AD uses GUIDs in several ways. For instance, group policy objects have a common name (CN) which is a string-ized GUID. Control Access Rights have a rightsGuid.

If you, my intrepid log analyzer, want to build your own reference charts so that you can translate these, you can use the "LDP" tool. This utility is in the Windows 2000 Server Resource Kit and the Support Tools for Windows XP and Windows Server 2003, and it's built into Windows Server 2008.

Complete instructions on how to use LDP are beyond the scope of this post. However the basic procedure is this:

1. "Connect" to a domain controller.
2. "Bind" to the DC by entering your credentials (in WS08, LDP.EXE lets you bind with your current logged-on account's identity without providing credentials). For our purposes an ordinary user account is fine, we're just going to query.
3. Use "Search" from the browse menu to find the stuff you're interested in; it will print out in the right-hand pane.

Here are some things you can enumerate, and the Search settings you'll use in LDP.

Control Access Rights
Base DN: CN=Configuration,DC=yourdomain,DC=com
Filter: objectClass=controlaccessright
Scope: subtree
Options/Attributes: name;rightsGuid;

Then just click the "Run" button- Voila! You can cut & paste the results into a text file that you can use whenever you need to look up a CAR.

Schema Objects (properties, etc.)
There are too many schema attributes to enumerate them all (well you can with a lot of custom search settings like increasing buffer sizes and timeouts but I'm not going to advise you to beat up your AD). So here is how to look up a particular property.
Base DN: CN=Schema,CN=configuration,DC=yourdomain,DC=com
Filter: schemaIDGUID=bf967a8d-0de6-11d0-a285-00aa003049e2 <-- your property GUID goes here
Scope: subtree
Options/Attributes: name;schemaIDGUID;

Group Policy Objects
For some reason group policy objects have a common name which is a GUID, even though all AD objects already have GUIDs. This seems really weird to me (I would use a different word than weird but our company values include being respectful). Anyway if you want to find out the "friendly" name of a GPO, here's what you do.
Base DN: DC=yourdomain,DC=com
Filter: CN={6ac1786c-016f-11d2-945f-00c04fb984f9} <-- your GPO name goes here, complete with curly braces
Scope: subtree
Options/Attributes: displayName;cn;distinguishedName;

Anyway with these examples you should be well on your way. You can always change the attribute list that the search returns to "*;" (yes, add the semicolon) to tell you all the properties of each object, but I've tried to show you how to list only the most interesting ones. Microsoft Press has a book on Active Directory schema that's part of the MSDN Active Directory Developer's Reference Library, but it's dated (pre-Windows 2000 RTM) and all the material is available on MSDN if you do a little searching.

[2009-06-12 Updated to describe LDP in Windows Server 2008 and clarification of GUID translation]

Where do I get my information on Windows auditing?

Eric Fitzgerald — Wed, 07 Feb 2007 01:12:00 GMT

You might want to know where I go to get my information on audit events and so forth.

Mostly I go to the source code or one of our developers. For continuity-of-employment reasons I won't be posting a link to that here ;-) We have some old specs and some new specs but sometimes the code doesn't function quite like the spec says it should so I usually go to the code instead of the spec.

However you can download the Windows Platform SDK for free, and it includes all the header files which define all the Windows error codes and so forth.

I also search my email with Outlook 2007's Instant Search feature (yes that was a blatant plug). A lot of times I find that I answered a question or had a discussion about something a long time ago. This has become less useful lately as the legal guys are making us delete all our old email. I am trying to capture some of this kind of content in this blog since hopefully it will outlive my email :-) Maybe I will write a book.

I use the Technet Events & Errors web site. This is the site where Event Viewer goes for content when you click the link in the bottom of an event. Not all events are populated (actually only a small percentage have hand-written content).

I use Windows Live Search or sometimes that other search engine to search the internet for content, but only rarely. Sometimes I go to Randy Smith's web site, Ultimate Window Security.

Anyway these are all my primary sources.

2007-02-08 Updated Platform SDK download link per PSDK group advice

Determining Whether a User Logged on Using A Smart Card

Eric Fitzgerald — Tue, 06 Feb 2007 03:40:00 GMT

I get asked the question pretty regularly how to determine from the security log whether a user logged on using a smart card or not.

The short answer is, you can't be absolutely certain. The longer answer is, well, you can be pretty certain for the time being, especially if you're not running any non-Microsoft Kerberos code.

First you need to know that you can only log on using a smart card in Windows when you authenticate to a domain using the Kerberos protocol. There is a cached logon mechanism in Windows XP so you can log on using your smart card when a domain controller is unavailable but Windows will attempt to acquire domain credentials automatically for you, under the hood, when you log on this way, and you won't be able to touch any other machine on the network using domain authentication until you authenticate to the DC.

Now for you guys that are not Kerberos gurus, there are three phases to Kerberos authentication:

1. Authentication Service Request (AS-REQ) & Reply, where the client presents credentials to a KDC and obtains a ticket-granting ticket.

2. Ticket-Granting Service Request (TGS-REQ) & Reply, where the client presents a TGT to a KDC and obtains a service ticket.

3. Application Request (AP-REQ or just normal application traffic), where the client presents a service ticket to an application and requests service.

In Windows, #1 generates security event ID 672 on the DC (on Windows 2000 the failure event is 675 but in Windows Server 2003 the failure event is the same as the success event, 672). Event 672 records who requested the ticket, their IP address, etc., and also includes the kind of credentials they used, called the "patype" or "preauth type", short for "pre-authentication type". Preauth types are discussed in the Kerberos RFC, RFC 4120 in section 7.5.2.

In Windows, #2 generates security event ID 673 on the DC (on Windows 2000, the failure event is 676, in WS03, it's 673)

In Windows, #3 causes a logon event (528 or 540) on the machine that is accessed, if the "application" is the machine itself, that is to say that the "service" is "host\machinename".

OK, now that the background is out of the way, back to the question. How do I know if it was a smart card logon?

Well, as mentioned, the preauth type is listed in event 672. Smart cards use public keys for pre-authentication (patype = PKINIT, which is 14, 15, 16, or 17 we learn from RFC 4120). So if you see one of these preauth types in this event on the DC, you know that it was a smart card logon- WRONG! You know actually just that it was a PKINIT logon.

However, currently the only logons built into Windows that use PKINIT preauth type over Kerberos, are smart card logons. So for the time being you can make the assumption.

Trustworthiness of Information in Audit Records

Eric Fitzgerald — Wed, 20 Sep 2006 20:57:00 GMT

I get asked quite often "why is the Workstation name missing from some events?" I've explained that elsewhere. But this raises another issue that many of you might not have considered, and I want to take a few minutes to explain.

The Windows Security event log is designed to be as trustworthy as possible, and meets all the Common Criteria audit requirements for audit in our security target in the Controlled Access Protection Profile for EAL4+.

Basically that means that we log all the events that CC says to log with the information that CC says has to be in those events, that we have access controls in place to the log, that we detect log failure conditions and can be configured to prevent auditable activity in those cases, and that our design and development methodologies conform to the relevant CC requirements.

We have several basic strategies for ensuring the trustworthiness of the security log and the data in it:

Access control on both the APIs used to log events to the security log, and on the log itself for log access and log management.
A trusted path from the security subsystem (LSASS.EXE) to the security event log. By this I mean that we spent significant effort to protect the log from casual tampering; only a determined attacker with administrator credentials could cause the auditing system to malfunction in such a way as to prevent, alter or spoof events.
Default access control on the audit APIs to only allow audit generation by code that is isolated from user accounts.
Drawing on trusted sources such as system state whenever possible rather than relying on information passed in from APIs that could be called by a non-privileged user.

I want to address the last two points.

It is the case that most auditors (users of the security event log) want the events to be as "high-level" as possible. I know that you want events that say:

"Eric used Excel to change the executive compensation spreadsheet"

and not

"process ID 1289 running in context S-1-5-21-1235-6780-501 performed a WRITE_DATA on \dosdevices\c\shared files\exec_comp.xls".

However the isolation requirement causes us to instrument not in Excel, where we could indeed capture the menu and toolbar actions the user takes, but rather way down deep in the file system, where that information isn't available.

Look at it this way- if Excel could write to the log file, that means that the user running Excel could write to the log file, which means that the log file is no more trustworthy than the user. Obviously this is not desirable if you suspect the user of violating your business policy; the user might just take some action to cover their own tracks.

The sacrifice is that the audit is from the system's point of view, not the user's. This makes it harder to interpret, especially when you have an app like Word or Explorer which has unusual file access semantics. But we source all the information from in the file system where it's trustworthy; we don't depend on anything in the user's context telling us what to put in the audit record.

We often log events that were caused by remote activity. In remote logon cases the Common Criteria require us to include a "station name", if applicable, where the logon request originated. This poses an unusual problem for us. In order to log the remote station name, we need to know it. However we authenticate the user's credentials, not the workstation's, during a user logon event, and Windows supports multiple authentication protocols that can be transported across multiple network protocols.

It is often the case that the network protocol can't tell us the authenticated name of the machine at the other end of the connection (for example, IP). It is also often the case that the authentication protocol has no facility for transporting the station name (for example, Kerberos) or that the authentication protocol doesn't transport the station name securely (for example, NTLM). It's also the case that when we depend on the logon request to carry the station name, and the name is unauthenticated, that the station name is spoofable by a knowledgable attacker at the other end of the connection.

The bottom line is that sometimes to meet the "station name" Common Criteria requirement we were forced to include unauthenticated information ("workstation name") in the audit record.

Another problem is that many of you asked me, quite emphatically, to add IP addresses to Window Security events so that you can correlate these events with network device logs and other information about the network. When I proposed this for Windows Server 2003 there was a very vigorous debate internally because many people on the team were reluctant to add unauthenticated, spoofable information to the security event log.

The utility of the information, coupled with the number and intensity of the requests, won out in the end.

Also, I pointed out that IP address is not very spoofable in authentication traffic. Since the traffic is encrypted, requires a response by the client back to the server, and that response depends on the server's response to the client's initial request, and since all our authentication protocols travel over TCP, the spoofability is very low- an attacker must be in the same collision domain as one of the endpoints or must control an intervening router.

That's just some food for thought.

A good 3rd-party reference to the Windows security event log

Eric Fitzgerald — Mon, 20 Mar 2006 21:31:00 GMT

Randy Franklin Smith has a site with a very good reference to security event log events. Randy also does training on Windows security log analysis.