This question also applies to clipboard monitoring.

Imagine you are planning to deploy 100,000 copies of a Windows trojan with keylogger functionality. (For the record, I'm not talking about myself here.) Your trojan is going to send you megabytes of user input every day, 99.999% of it irrelevant. How do you find passwords in this flood of text and what can your victims do to mitigate the threat?

I see but one possibility: You have to intercept only the text entered after a known bank/email/etc page became active in a browser. But to tell it did?

1a) Monitor the titles of browser windows for known pages.

Mitigation: Use a browser with bank mode that does not reveal page name in its window title.

1b) Break into the address space of a browser to see what it is actually working with.

Mitigation: Impossible apart from relying on your antivirus. However, this approach is highly sophisticated and used mostly in government-made malware in targeted attacks on political opponents. A simple guy like me is not likely to run into this.

2a) Monitor DNS requests for known domains with WinPcap and such.

Mitigation: Don't have WinPcap installed.

2b) Monitor DNS requests with a custom firewall-type driver.

Mitigation: Same as 1b.

Overall, from the common user's perspective a browser with bank mode plus the absence of WinPcap plus an antivirus for general safety seems to be a sufficient protection against keyloggers. Did I miss anything?

  • 3
    If you are talking about something that is browser based ... why not just monitor entry into the password field? Like password managers do? – schroeder Aug 4 '19 at 19:46
  • Nowadays many if not most of the usernames are email addresses. If I had to manually go through such data, I'd start by search @. Would get me at least somewhere, and if it's an actual email password, I could use it to "I forgot my password" the rest. There's no particular reason to automate this in order to be efficient. – Esa Jokinen Aug 5 '19 at 2:53
  • Note that password would not be super-relevant without the username and the place where this password was entered. If user clicked a bookmark (or browser restored last session), then you won't be able to tell where the password is used (which is half of its value) – Xenos Aug 5 '19 at 16:31

I'll confess to not having any practical experience with keyloggers, but I don't see why a keylogger would care about the title of a web page, or would monitor DNS or TCP traffic. What's the point? Filtering based on the title of a page is not terribly useful: sure, a keylogger would be more interested in a page that's called “login”, but on many sites login is done as a widget on the front page or on any page, not on a separate page. And the keylogger needs to examine the content of the page: it isn't going to find the credentials in the title. So why would it filter based on the page title? Monitoring DNS traffic only reveals which sites the user accesses, misses requests that takes advantage of the local cache, and cannot easily be correlated to individual HTTPS requests (other than through the IP address, in which case you might as well filter on that).

The most obvious way to write a browser keylogger is to hook into the browser itself (1b). This is not a “highly sophisticated” approach. There are many ways to do this: via a browser extension, modify the browser binary, inject a library, run the browser in a debugger, modify the kernel, … None of these methods are so sophisticated that they'd only be used by governments. All it takes is a few lines of code. The sophistication in malware is not so much in how they grab information, but in how they avoid detection.

Browsers already contain logic to detect passwords and offer to store them. A keylogger can just hook into that. Do note that despite the name “keylogger”, software keyloggers and especially browser keyloggers don't typically work by paying attention to what the user types, but at a higher level. For a browser “keylogger”, the natural level of interaction is in forms and POST requests.

The only way to protect against keyloggers is not to have a keylogger on your machine. Once an attacker can run code on your machine, you've lost. Changing the title of web pages is completely irrelevant. Not having winpcap installed doesn't protect you: if the attacker wants to have it (useless for a keylogger, but useful to infiltrate a network), they'll bring their own copy. An antivirus may help somewhat to keep other malware out, but no antivirus is foolproof.

| improve this answer | |

It's a kind of X-Y-problem. If you let untrusted software run on your computer, you have lost. Especially if it runs with administrative privileges.

How can you tell that there's no DNS redirection going on, if you have a process running with administrative privileges? Can you at that stage trust your operating system to tell you? No, you can't.

The mitigation to key loggers is to avoid having key loggers installed on a computer. Another mitigating factor is 2FA, which ensures that a password by itself is not enough.

But a key logger can trivially be expanded in scope to steal cookies, take screenshots and so forth, effectively leaking secrets from accounts it can't access directly.

So in short; I don't see where you're going with the list of mitigations...

| improve this answer | |
  • Your approach is based on the assumption of an all-powerful piece of malware that can do absolutely anything. Of course, in this threat model no defense is possible - not even 2FA since such a godlike trojan would be able to synchronize across devices and/or invade the source of the OTP. :) What I am talking about is real, in-vivo malware which is quite limited in scale. – sigil Aug 4 '19 at 20:37
  • Which key logger can intercept keyboard strokes, but not take screenshots? And 2fa will protect against password theft. A properly made smart card can't be convinced to give away it's keys by software for instance. – vidarlo Aug 4 '19 at 20:42
  • I fail to see how the DNS redirection you mentioned is related to taking screenshots. – sigil Aug 4 '19 at 20:45
  • You pose a software that can utilitize winpcap, read the memory of the browser and so forth. That software can take screenshots as well if it wants. Either you're placing artificial constraints for fun, or you don't understand the question you're asking. If your keylog author behaves by your rules, then yes; your rules work. But the rules you rules doesn't change the real world. – vidarlo Aug 4 '19 at 20:49
  • I explicitly mentioned in my question that the malware able to analyze the memory of a browser is not something a simple guy like me is going to run into. It is way too expensive to develop; the last thing FBI/CIA/whatever want is to make it widespread and let the antivirus companies to add it to their databases. – sigil Aug 4 '19 at 20:57

Keyloggers tend to capture control sequences, like tabs and clicks. So the keylogger can dump anything longer than 30 chars without a control sequence, for instance, as not being interesting.

But keyloggers also tend to be context-aware. Switching to new windows, for instance. They can look for entry into password fields, especially if you are talking about browser-based keyloggers. In fact, it would be easier not to log keystrokes but simply capture whatever is sent in the password field on a webpage.

Title of the page is not necessary when you can simply read the URL or the content of the page.

| improve this answer | |
  • Could you please specify the APIs the keylogger would use to capture the contents (or just presence) of the password field, browser page or URL? Because I would expect the virtual desktop of the browser in bank mode to block most GUI spying tricks. Let's talk Windows 7 SP1 and Chrome to be specific. – sigil Aug 4 '19 at 22:20

The last time I dealt with keyloggers, and it's been many years, they were just that -- keyloggers, as in only keystrokes were captured.

The general defense was to use a virtual keyboard, a graphical keyboard that was selected with the mouse rather than using the physical keyboard.

Actually the keyloggers were scancode loggers. Keyboards don't send keys, they send scancodes, these are keyboard position codes that must be interpreted for keyboard type, country, and language. Backspaces and deletes and cursor movements are themselves scancodes so


could easily be recorded as

"P[backspace]pss[left arrow][left arrow][delete][delete]assW[backsspace]wordd[left arrow][delete]."

No attempt to identify the meaning of the keys took place in the keylogger, all keys strokes were captured. Interpretation was a post dump analysis.

While this may seem impractical at first blush, consider that most full length Novels are less than 1 Megabyte of text, and that's without compression. A trivial amount of memory can record boatloads of keystrokes.

| improve this answer | |

Assuming you want to mitigate a keylogger that only records keys, you have the following possibilities:

  • Use password manager so you don't type the password (plain simple). That could even be a plain text file containing your password and you copy/paste then to the relevant browser field
  • Type dumb stuff outside the password field during your password typing (click the password field, type half of the password, put focus elsewhere, type variable stuff of variable length with variable durations [ie: post a reply on securityexchange for instance] then go back to the password field and type the rest.
  • Use non-keyboard inputs (like banks love to do... which is dumb IMO but that's another debate), or visual keyboards, or speech-to-text stuff etc so your keylogger has no key to log
  • Shuffle (randomly) the mapping between your keyboard keys and the actual entered text (I bet UX will drop down by doing so!) if keylogger records only the keystroke

But that's assuming the keylogger only records keyboard pressed keys, which seems like a very weak assumption.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.