Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Testing and validation

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

Casey Smith
Originally published . Last modified .

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:

Password Filters Technique: Registry modifications

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:

Password Filters Technique: 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:

Password Filters Technique: output from installation test script

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. 😉

Password Filters Technique: System Reboot

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.

Password Filters Technique: example of code

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…

Password Filters Technique: no detections

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!

 

 

Emu-lation: Validating detections for SocGholish with Atomic Red Team

 

Emu-lation: Validating detection for Gootloader with Atomic Red Team

 

Safely validate executable file attributes with Atomic Test Harnesses

 

Find security bugs in web application routes with route-detect

Subscribe to our blog

 
 
Back to Top