Stopping Password Theft By Keyloggers - You Can't


RSnake had a link to an article on fooling keyloggers. RSnake had a couple of problems with it, but there's one that seems to have escaped everybody - if an attacker has enough access to your machine to install a keylogger, they can do more than just install a keylogger.

With most of the 'sploit kits I've looked at, the bots didn't only send keystrokes, they sent the window to which it was applied - so if the caret moves widgets, you get a notification before the keystrokes. In the lesser of these, only the window name is recorded, but the ability is there to record caret focus changes.

Also, if an attacker can get a keylogger working, they can certainly install browser plugins to record form information prior to the form being posted. The simplest (but probably least effective) means is to install a local MITM proxy and set the browser's proxy to that. However, that would require breaking SSL.

So long story short, if an attacker has enough access to your machine to install a keylogger, the keylogger is the least of your concerns. If I have that kind of access to your machine, I don't want the keys you pressed, I want the data you're sending and receiving.


  1. Well, if they have enough access to install a keylogger and a web proxy, they can also install a new root CA and they don't need to break SSL at all.

  2. The user would still receive a warning, however, that the CN on the certificate the proxy presented doesn't match the hostname of the host requested - unless, of course, the attacker decided to go all the way and set up their own phishing site with SSL (preferably) in which case, the attacker doesn't need the keylogger at all anymore.

    Yes, they could install their own root CA, but the hostname of the requested site has to match the CN of the requested site. Not impossible for the proxy to look at the browser address bar to determine the host (the proxy won't know the desired host until SSL has been negotiated), but a real pain in the tail.