All the Little Things

Detecting Password Filter changes

tedhardy — Tue, 09 Aug 2016 09:26:42 GMT

Part 3 of the Event type series will continue next week, with the ProjectSauron released I sped this through the blogging pipeline since it's relevant for defenders. Password Filters are designed to enable organizations to enforce custom password constraints when users change a password. These are just DLLs that are registered with the LSASS process so that the LSA will present the cleartext password to the filter for additional checks. Like any tool, something that can be used for good can be used for evil. The recently discovered ProjectSauron (https://cdn.securelist.com/files/2016/07/The-ProjectSauron-APT_research_KL.pdf) uses a password filter to gain access to user's cleartext passwords when they are changed on compromised machines. Note that there can be multiple Password Filters, so an intruder can add a new filter that just listens for new password changes without interfering with the existing password filter operations. So how do you detect this? Simple, there's a security event (Security/4614) that is logged whenever a Password Filter (also known as a Notification Package) is loaded. These would be logged upon startup. If you expect the Security/4614 event to be logged but it isn't showing up in the Security channel, make sure that the "System/System Security Extension" Subcategory is enabled for success audit event. If you want to double-check the Password Filter configuration or detect when a new Password Filter is registered (before it is loaded on next reboot) you have to look in the registry and be comfortable in setting Registry SACLs. According to: https://msdn.microsoft.com/en-us/library/windows/desktop/ms721766(v=vs.85).aspx the registry key that holds the configuration for what Password Filter(s) are loaded is here: HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Lsa The Notification Packages registry name value contains the DLL file names located in the system32 that will be notified when a password has been changed. Since Registry Auditing can be configured at the Registry Key level, not the Registry Name within the Registry Key, to select only the event you want you need to include the Registry Name in your filter so that other changes are not selected. A note about Registry Auditing: As is said elsewhere, SACLs can be very noisy, so it is critically important to only include the specific Permissions use for which you want to be notified. In this case, the operation is "Set Value" and no other Permissions. When you set a Registry SACL (and enable the "Object Access/Registry" audit subcategory for Success events) when you change any name or value under the registry key with the SACL you'll see a few events generated: Security/4656 - Handle requested to object Security/4663 - An attempt was made to access the object Security/4657 - A registry value was modified Security/4658 - The handle to an object was closed In plain language these amount to (keep in mind that the LSA logs the Security Events so the perspective is from the LSA's view): Security/4656 - Someone want to access this thing. Here's a list of permissions how they said they want to access the thing. Security/4663 - The person accessed the thing using a specific permission (they read it, changed it, created it, or destroyed it) Security/4657 - The thing changed, and here's what changed. Security/4658 - The person is done with the thing. Of the four events, Security/4657 is the most interesting since it tells you:

The account requesting the change
The Registry Key and Registry Name that changed
The Process ID and program Name that requested the change
The Operation type (was a value changed, deleted, or added?)
The Old value (prior to change) and the new value (after the change)

Since these are all separate properties in the event payload you can filter on any or all of them. Using this knowledge you can create a filter looking for changes made to the Lsa Registry key, but specific to the Notification Packages registry name only. This event filter snippet looks for events that have all of the following:

Event ID = 4657
Registry Key = HKLM\System\CurrentControlSet\Control\Lsa (redirected to ControlSet001 from CurrentControlSet)
Registry Name = Notification Packages

Note that given that the Notification Packages registry data type is a multi-line string value, to store and display properly this transform is used - this is also noted in the rendered event description but it is good to note if you are processing the XML data in a backend without rendering the event description: New lines are replaced with *. A * is replaced with **

The Good, the bad, and the ugly: Part 2 - Legacy API

tedhardy — Fri, 05 Aug 2016 09:40:16 GMT

In the previous post I described the current, manifested event provider system that was introduced in Vista. The legacy method of logging Windows Events goes back to Windows 2000. An "Event Source" is what most people refer to when they are describing "what application generated this event?" I'll use "Event Source" when talking about the legacy system and Event Provider when referring to the modern, manifested system for logging Windows Events. In those days, instead of writing a manifest and then registering it with the Eventlog Sevice, you register a machine-local, unique event source name (e.g., "Service Control Manager") for a particular event log ("System") and as part of that registration include a path to a file(s) to render the events (EXE or DLL, in this example: "C:\Windows\Services.exe") - this file is called the "EventMessageFile." An Event Source can also optionally include a ParameterMessageFile and a CategoryMessageFile, both described below. All of this event source registration is stored in the machine's registry, under:

HKLM\System\CurrentControlSet\Services\EventLog

There is a folder for each event log name (e.g., "System"), and underneath that a is sub-folder for each event source name (e.g., "Service Control Manager"). Within the event source name sub-folder you'll find the path to the EventMessageFile ("C:\Windows\Services.exe") That message file contains the event descriptions for rendering events. An event source can also define specific strings, these strings are usually localized which is why they aren't part of the message description. Replacement strings appear as numbers preceded by two percent-signs like this: %%142 or %%827. When rendering the message in the event viewer this Event Viewer these values in the event payload data are replaced with the localized text strings. Oh, to make things a little more complex, Replacement Strings can be part of the EventMessageFile or in a separate file referenced by the ParameterMessageFile registry value (if it is defined) for the Event Source. This allows flexibility for the developer but for you the person interested in reading events with machines, makes things a little more difficult since you need to pre-gather values ahead of time for reference later. CategoryMessageFile defines the localized names of the defined Category values. Categories are for grouping like events together - this was implemented in the days before XPath filtering of events was possible so think of it as a form of filtering for the legacy event log. The Category model has been replaced in the modern system by Task and OpCode (aka Operation Codes - a more granular task ) so you can continue this style of grouping of events (Backwards Compatibility!) So you might have a Task for "DataStore Operations" with OpCodes for "Connect", "Query", "Update", "Disconnect" to enable filtering on specific operations within the larger task. Taking just a moment, I just want to point out the model shift between the legacy and modern event logging API:

Legacy: Start with an event log, create a source in that eventlog and log all events there.
Modern: Start with the event provider, define events, and for each event specify event log the event will be logged.

The modern system gives much more flexibility to developers and since the manifests are centrally stored, you (the event consumer) also have one single place to search for "Where do I look for this particular event?" Win-win. Now back to the task at hand: Since events logged using Event Source are using a legacy API, they are limited to Event Logs that the legacy API can access, sometimes called "Classic event logs" - this includes the usual suspects: System, Application. It's not quite clear-cut that "if you look in the System event log, you'll only see legacy events" - since the modern API is backwards compatible and can log events there too. There also isn't the concept of a specific Event Schema for an Event Source + Event ID combination, so that when a vendor ships new code, it's left up to you to figure out that the event schema has changed (if it has) and what changed in it. (You'll see in the older-style events that there is no System/Version element present.) This is likely where many event processing vendors got the idea "I need to know the Windows Version to know how to parse the events coming from it." It's not entirely without merit but for modern, manifested events, having to know the Windows version isn't a requirement since you can just check the Provider + Event ID + Version to know the event payload schema. Since the Eventlog Service has no intrinsic information on the schema of an event logged using the legacy Event Source system, the event payload just logs a list of elements for an event's payload. Compare that to the manifested event where an event payload property has a Name attribute. To show the difference between the Manifested and Legacy event payload, here's how the payload data for Windows Defender would be logged:

Legacy	Modern
%%827 4.10.14393.0 1.225.2493.0 1.225.2471.0 NT AUTHORITY SYSTEM S-1-5-18 2 %%801 2 %%804 1.1.12902.0 1.1.12902.0	%%827 4.10.14393.0 1.225.2493.0 1.225.2471.0 NT AUTHORITY SYSTEM S-1-5-18 2 %%801 2 %%804 1.1.12902.0 1.1.12902.0

Immediately you can see in the Modern event that some properties are unused and you can safely ignore them. The modern, manifested event is far easier to comprehend and track if there are changes made in the event schema (which would also show up as a new number as well.) So, what does this mean for you, who want to read the events and understand their meaning? Put simply, the above means that if you want to understand the data in events logged using the legacy you (unfortunately) need to retrieve the messages, category, and parameter values from the event source referenced binaries if you want to either fully render them, know what each payload property means, or know if an event payload schema has changed.

The Good, the bad, and the ugly: A 3 part series about Windows Event Log schemas

tedhardy — Fri, 27 May 2016 11:02:00 GMT

One question that comes up frequently is a frustration with event schemas. Common statements I've heard include:

"Windows Events have no set schema!"
I need to know the OS version to know what the event schema
There's only a list of events for the Security channel.

As you probably guessed from the title, there are three scenarios for how event schemas are defined. I'll explain the different definition methods, their benefits and limitations, and provide some utilities to for you to use to collect the event definitions for individual event analysis or use in your own automation. Event Log Schema overview Before we get into a specific event or event provider/event source's events, lets talk a bit about the event log format. Starting in Windows Vista, the event log was completely re-written (though it includes backwards compatibility) down to the file format - it wasn't just adding an "X" to the file extension for the log file (previously was EVT, now is EVTX.) Practically everything you knew about the event log changed but if you were a developer you didn't have to change due to backwards compatibility in place. I'll cover the differences in more detail in future posts. One change was an XML schema being defined for event format. The schema is publically available in the Windows SDK, you'll find it under the SDK path under [OS Version]/include/um/Event.xsd - it shows the required fields for an event. This has the definition for not only Event Log events but also Event Tracing for Windows [ETW] events, since the API between the Event Log and ETW was unified in Vista. However, don't read it expecting to find the schema for every possible event, it's just the rules about a general schema for event structure. Each event provider/event source defines the detailed event schema. Long story short, events in the Event Log will have a element and either a or element - those last two are the event payload, which include specific fields and values for the event. N.B: When I use "Event Provider" that will refer to a modern (Vista+), manifested event provider, which is covered below. An "Event Source" will refer to a legacy (pre-Vista) event source. What defines an event? When you talk to most people, they focus on the Event ID alone. In reality, event ID is not globally unique across the event log or even within a single event channel. You need to include the Event Provider (formerly known as the Event Source) and the Event ID to define an event. Manifested providers, introduced in Windows Vista and covered below, go one step further - the event has a version for the payload (the or element) so that for a modern event provider you need to specify the Provider + EventID + Version to determine the event schema. All of this is included in the event element so just by looking at those fields you can determine what the event schema should be. The Good: Manifested event providers A manifested event provider starts with an Instrumentation Manifest, which includes a list of events, event keywords, event descriptions, destination event channels, and event templates that the application will generate. While manifests were not introduced in starting in Vista but the new instrumentation manifest centralized all of an event provider's information in one place in a standard format. Previously this event provider information did have a format but it was not enforced and therefore different developers implemented their own mechanism for storing keywords, channels, event descriptions in an event source's resource DLL. In short, it was a bit of a mess. While the new method is not perfect, it does help you (the analyst or operator) have a single place to go for an event's information. Now if you have a modern event provider you're interested in, you can query for all events, their descriptions, event templates, event levels (information/warning/Error) quite easily. Event Providers also turned on aspect of the legacy Event Source on its head. For an Event Source, you registered the event source for a single event log. A Manifested Event Provider doesn't do that - it is event log agnostic. Meaning, that at the event level the developer can specify what event log the event will go to. Fortunately that is defined in the event manifest so it's not a mystery where events are being logged. Let's start with an example: Say you're interested in Security Audit events. You can use the PowerShell Get-WinEvent cmdLet to get the Security provider information. First you need the provider name, it's not the event log name "Security" so - where do you get the provider name? It's actually in the first field of the event element, here are the first few lines of an event:

4688 2 0 Etc… The Name value is what you want to use for with Get-WinEvent: [Note - None of the following commands need to be run from an elevated PowerShell session. You're just looking at event provider data, not the actual events itself. Unless I specifically call it out, you cannot change anything by running these commands.] PS C:\> Get-WinEvent -ListProvider Microsoft-Windows-Security-Auditing


Name     : Microsoft-Windows-Security-Auditing
LogLinks : {Security}
Opcodes : {win:Info}
Tasks   : {SE_ADT_SYSTEM_SECURITYSTATECHANGE, SE_ADT_SYSTEM_SECURITYSUBSYSTEMEXTENSION, SE_ADT_SYSTEM_INTEGRITY, SE_ADT_SYSTEM_IPSECDRIVEREVENTS...}

PS C:\> In itself, not very interesting but the detail is one level deeper, specifically under the Events property.


PS C:\> $SecEvents = Get-WinEvent -ListProvider Microsoft-Windows-Security-Auditing
PS C:\> ## get count of events for the provider
PS C:\> $SecEvents.Events.Count
443

Now we know there are 443 events for the "Microsoft-Windows-Security-Auditing" provider. If you're interested in the Process Create event generated by the Microsoft-Windows-Security-Auditing provider (I abbreviate events like this: Security/4668 or where I need to be completely unambiguous: Security/4688/2 to include the event schema version.)


PS C:\> $SecEvents.Events | where-object {$_.ID -eq "4688"}

[Wall of text omitted] On a Windows 10 system, this will return 3 event definitions. While three are defined, only one is actually generated. Actually you don't need to know what OS the event came from, it tells you the version of the event definition, right below the Event ID. Here's the command to get the schema for the Process Create event that matches the version above.


PS C:\> $SecEvents.Events | where-object {$_.ID -eq "4688" -and $_.Version -eq "2"}

Id : 4688 Version : 2 LogLink : System.Diagnostics.Eventing.Reader.EventLogLink Level : System.Diagnostics.Eventing.Reader.EventLevel Opcode : System.Diagnostics.Eventing.Reader.EventOpcode Task : System.Diagnostics.Eventing.Reader.EventTask Keywords : {} Template : Description : A new process has been created. Creator Subject: Security ID: %1 Account Name: %2 Account Domain: %3 Logon ID: %4 Target Subject: Security ID: %10 Account Name: %11 Account Domain: %12 Logon ID: %13 Process Information: New Process ID: %5 New Process Name: %6!S! Token Elevation Type: %7 Mandatory Label: %15 Creator Process ID: %8 Creator Process Name: %14!S! Process Command Line: %9!S! Token Elevation Type indicates the type of token that was assigned to the new process in accordance with User Account Control policy. Type 1 is a full token with no privileges removed or groups disabled. A full token is only used if User Account Control is disabled or if the user is the built-in Administrator account or a service account. Type 2 is an elevated token with no privileges removed or groups disabled. An elevated token is used when User Account Control is enabled and the user chooses to start the program using Run as administrator. An elevated token is also used when an application is configured to always require administrative privilege or to always require maximum privilege, and the user is a member of the Administrators group. Type 3 is a limited token with administrative privileges removed and administrative groups disabled. The limited token is used when User Account Control is enabled, the application does not require administrative privilege, and the user does not choose to start the program using Run as administrator.

The Template property is the definition for the event's element. The Description property is the text message that will be displayed in the Event Viewer when the event is rendered, and the numbers are the replacement strings used by the EvtFormatMessage function to display the text. For a decoder-ring for the symbols in the Description property (for example, the above event has !S! in a few replacement values.) Look at the Remarks section under FormatMessage. There you have it, there's a start of how to get an event's schema, at least for manifested event providers. I've written some PowerShell scripts to enumerate all events on a system and generate a file that can be imported into easily into Excel or SQL or used as a Hadoop mapping file. Check it out here: https://github.com/tedhardyMSFT/EventLogUtilities - the manifested providers is the Get-ProviderEventMessages.ps1 file. Next up, Legacy Event Sources!

Hello World!

tedhardy — Wed, 18 May 2016 09:41:56 GMT

Well, Hello there! I guess this is the obligatory first post where I introduce myself and tell you all a bit about what this blog is for. I’m Ted Hardy and I’ve worked for Microsoft for about 16 years, most of that in the security space – on the preventative and detective side. Looking back, most of that time has been focusing on the Windows Event Log, starting with the ACS (Audit Collection Services) system when we were deploying it internally somewhere around the 2003 timeframe. I initially piloted the use of Windows Event Forwarding internally before it was picked up by IT and deployed broadly. Windows Event Forwarding (wow, that’s a mouthful – I’ll just use WEF like normal people do) made the job of collecting different types of events (read: Not just events from the Security event log) from many Windows systems easy. Now the real work could focus on what all is in the windows event log. From there I started looking at not just what was being generated by systems, but what could be generated by a Windows system. That’s really where the fun begins. (If you’re like me, that’s fun!) So, what can you expect from this blog? 1) Code samples to help you with your analysis 2) Interesting notes about specific events, Windows Event Forwarding, or the Windows Event Log itself (it has a long history – dating back to the old NT3.x days.) 3) Detection scenarios and how you can use the Windows Event Log in those scenarios and what the limitations are. I’ll start with the last one – I wrote a white-paper on how you can use WEF to help guide using WEF with intrusion detection scenarios, sizing your implementation, deployment GPO settings, and finally some sample event filters to use. In the end WEF is just a pipeline, and this will be a primer of how to set it up and (more importantly) what to put in it. https://technet.microsoft.com/en-us/itpro/windows/keep-secure/use-windows-event-forwarding-to-assist-in-instrusion-detection See you next week! Ted