KeePass stalking or the power of debugging

Just a PoC of an idea I had some days ago. Software like KeePass, to name one, have gone to great lengths in order to protect the sensible data on disk or even memory.
But everything has a weak link…

The idea is a small “post-exploitation” program which allows you to stalk debug the KeePass.exe module, attaching to it and waiting for an user action (copy an username/password to the clipboard.)

I found that between calls to the Win32 Clipboard API, the cleartext of the credentials is placed in a predictable place on the stack. A small “debugger” program attached to it can therefore pause execution at the corresponding function call and read the password from the stack :)

This isn’t in any way a robust solution, rather something I coded “quick and dirty” in Python, using PyDbg (what else?) but it should be easy to code a small Win32 program with exactly the same functionality.
Don’t forget that after all PyDbg is kind of a wrapper around the Win32 debugging API…

And using the douchey expression “without further ado”, here is a demo video.

KeePass Live Debugging from Carlos Garcia Prado on Vimeo.

The code can be downloaded here: (remove the .pdf ending after downloading)

319 828 534 116


9 thoughts on “KeePass stalking or the power of debugging

    1. @ Fancy
      LOL, you’re right. Next time I will use some “Inception” music or alike, that would fit perfectly in this case.

  1. Good Job Carlos.
    In your Opinion, what would be the best way (if there’s one) to evade the circumstance that the cleartext is at a predictable Space in the stack in terms of programming a password safe?


    1. Hi Simon,

      I must say I’m not familiar with the internals of this program, but *off the top of my head* I guess that the cleartext (copied to the clipboard) has to be passed as an argument to a function, and therefore placed on the stack. The point here is that a function call in a normal execution will take microseconds, afterwards the stack will be rewinded and these values cleared. So in a normal (not debugged) scenario this isn’t a big deal. Using the debugging API we can stalk, stop, read and resume execution in no time and that’s the power of this approach.
      But as I said, this is just a small PoC ;)

  2. Please correct me if I’m wrong (haven’t tried it myself) but isn’t it easier to just monitor the clipboard? That way you wouldn’t need to debug the program, and it draws less attention.

    Another question, did you try to extract the password for KeePass itself? That would be far more interesting… :)

    1. Hi Mario,

      I did this a couple of years ago so everything is kind of blurry in my mind but if I recall correctly there is no such thing as a system wide clipboard. Instead this is implemented by marking selected areas of memory inside the “copying” processes and pointers on the system to these areas. That’s why in some implementations if you kill the process, the data “in the clipboard” is lost. But as I said, this is just of the top of my head, may be incorrect.

      The master password? That would be interesting, indeed… just for educational purposes ;)

      1. I’m pretty sure you’re getting it mixed up with Linux, on Windows there is a system clipboard and things copied to the clipboard are not gone when the process dies (in fact KeePass has to explicitly delete the passwords from the clipboard).

        Monitoring the clipboard is part of the Windows API itself, check this out:

        Unless KeePass is not using the standard clipboard but something else (?) in that case I’ve no idea how to hook it :D

        For the master password, I suppose one could inject a DLL and wait for the user to type it when opening a KeePass file. Maybe with some reversing you could find the password in memory, but I wouldn’t count on it being directly in plaintext, but rather in some other (still useful but harder to find) form.

        Again, I haven’t implemented any of these ideas myself, so they could be completely off the mark! ;)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s