Password Filters (T1174): Live Discussion on Detection Challenges and Strategies

UPDATE: We’ve embedded the recording of our December 7 Atomic Friday presentation about Password Filters at the end of this post. 

The first time I ever heard about Password Filters was in 2013, when I read Rob Fuller’s blog post describing the technique for creating and executing a password filter. The MITRE ATT&CK™ team has also compiled a lot of great background on Password Filters (T1174). So with all this information out there, why are we talking about this technique nearly five years later?

For one, the technique is still highly effective. The industry may not be talking about it as much because adversaries began using Mimikatz as the go-to method for stealing credentials. Some security products pick up the password filter, and the additional features in Mimikatz make it a more attractive tool.

The Password Filters technique came up recently when my colleague Michael Haag and I began looking for examples of unsigned DLLs that can load into the lsass.exe and ntoskrnl.exe process. This technique rose to the top of our list of interesting ways to achieve that.

In this post, we will:

• Describe what the Password Filters technique is
• Present some examples and code
• Discuss detection challenges and strategies

What is the Password Filters technique?

Password Filters are a known and documented pattern for developers to use. You can read more about how they work on this MSDN page. Following approved patterns for developers is a great way to develop security tooling. And that means that the technique is more difficult to detect and there is likely no patch coming.

The basic premise of this technique is that you can set up a DLL in the registry that loads into lsass.exe on startup and remains resident. This gives adversaries the twofold advantage of establishing persistence and allowing them to catch local password changes. For Domain password changes, you would need to install this on several Domain Controllers, which is kind of grim if you are going for stealth.

Either way, it’s a really cool technique to dive into because the code is clean, simple, and reliable.

Examples of the Password Filters Technique

In order to configure this, you first need local admin rights. Once you have gained these privileges, you can then set up the registry to load your password filter.

The registry modifications might look like this:

This code enumerates the existing Password Filters and appends the new one to the list.

Here is the registry key prior to the configuration change:

Here is the output from the installation test script and how the registry looks after it has been installed:

Note that it is the name of the DLL without the “.dll” extension on the end. It will also write the original settings to a file so you can recover if you need to revert.

Once this is complete, next time the system reboots, it will load our unsigned, unverified, unknown DLL into lsass.exe. Which is a pretty good place to be. 😉

What does the code look like?

Rob Fuller’s aforementioned blog post provides an example of collecting passwords and posting them to a URL as well as logging locally.

For this Atomic Test, we leveraged Rob’s code with a few modifications.

As you can see, it is roughly 30 lines of code to set up and log all local password changes.

And hardly any antivirus products pick up on this particular DLL as malicious.

Let that sink in for a moment…

This is the detection rate for an unsigned DLL, loaded into lsass.exe, that logs all local password changes in clear text. It’s not an easy problem to address.

How can you detect it?

From a detection perspective, things get really interesting. Detecting this technique is one of the main areas that we wanted to bring forward to the community to have honest discussions and dialogue. Again, I have more questions than answers here.

Some questions we will pose and discuss on Atomic Friday include:

• How would you detect this registry change?
• How would you validate whether or not one is already persisting?
• How often does it change?
• How often do unsigned DLLs load into lsass.exe?
• What processes write DLLs into System32?
• How can you detect if this technique is being used?

Conclusion

In the end, the Passwords Filters technique is a devastatingly simple DLL to write and install. What do you need in order to detect this? Would you be able to? We look forward to a community discussion around what it might take to be prepared to face an adversary that leverages this technique. Talk to you Friday!