We’ll emphasize this point throughout the post, which will likely read as a ‘duh’ to many people: if a database is unlocked, the key material likely has to be somewhere in the process space, so we can probably extract it.

We don’t really view this as an attack on KeePass specifically, as memory manipulation key recovery attacks are likely applicable to any other password managers by nature of an attacker operating in the same security context as the program. There’s no CVE here and there’s no universal fix for this type of approach (though we do cover a few mitigation approaches in the Defenses section). Note: this write-up does not cover any ‘vulnerability’ in KeePass or a KeePass database/deployment and we are not claiming that we “broke” KeePass. This method also doesn’t need administrative rights nor a keylogger, and is also indifferent to the secure desktop protection. The Exfiltration Without Malware – KeePass’ Trigger System section shows simple ways to dump all password entries on a database unlock without malware. If the database isn’t opened, see the Persistently Mining KeePass section of this post which details ways to execute this logic whenever KeePass launches. Lee and I dove back into KeePass during the few days following the post’s release and came up with an additional approach that a) doesn’t need administrative rights, b) doesn’t require a keylogger, and c) negates the secure desktop protection (assuming the database is unlocked). This post hopes to address all of those points. Other responses centered around the misconception that you need administrative access to perform most of these actions, that “ all of this basically relies on getting the password from a keylogger “, or that the secure desktop setting negates everything mentioned. As professional pentesters/red teamers we’re highly interested in post-exploitation techniques applicable to enterprise environments, which is why we started looking into ways to “attack” KeePass installations in the first place.

Our counterpoint to this is that protecting your computer from malicious compromise is a very different problem when it’s joined to a domain versus isolated for home use. Some comments centered around the mentality of “ if an attacker has code execution on your system you’re screwed already so who cares “. This generated an unexpected amount of responses, most good, but a few negative and dismissive.

The other week I published the “ A Case Study in Attacking KeePass ” post detailing a few notes on how to operationally “attack” KeePass installations. Note: this post and code were co-written with my fellow ATD workmate Lee Christensen ( ) who developed several of the interesting components of the project.

Keepass composite key invalid