Share via

Detecting Password Filter changes

  • Article

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:

  1. The account requesting the change
  2. The Registry Key and Registry Name that changed
  3. The Process ID and program Name that requested the change
  4. The Operation type (was a value changed, deleted, or added?)
  5. 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:

 

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

 

<QueryList> <Query Id='0' Path='Security'> <Select Path='Security'>*[System[(EventID=4657)]] and (*[EventData[Data[@Name='ObjectName']='\REGISTRY\MACHINE\SYSTEM\ControlSet001\Control\Lsa']]) and (*[EventData[Data[@Name='ObjectValueName']='Notification Packages']])</Select> </Query> </QueryList>

 

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 **