I'm searching for keylogger detection. As far as I see, almost all of keyloggers created by tools are sending data to a host periodically, but the ones made by coders may send data non-periodically. Because it is easy to detect periodic events by listening traffic of a host, some professional hackers(code writers) does such a trick: create a random hour1 and min1 and after hour1:min1 send the first keystrokes data(or whatever it is sending to hacker). After sending first set of data, randomly create hour2 and min2 and after hour2:min2 send the next data and so on.

With this tecnic they are getting data non-periodically, but regularly. Is there any way/trick to find out that non-periodic but regular data upload?

Note: I'm not interested in Command and Control for now. I'm only interested in non-periodically data uploading keylogger detection? Ideas related to non-periodic and regular event detection would be appreciated.

Note2: Most of keyloggers are sending data over gmail or another mail server and some of them are using ftp server.

Note3: The detection is not going to be host based but network based detection.


2 Answers 2


Detecting a keylogger based on its periodicity seems like a strange way of doing it and using a random timer to thwart that detection seems strange as well. If I was writing a keylogger, it seems more natural to implement something like once the logfile reaches a certain size (say 50 kB), start a new one and transfer the old file, versus sending on a fixed tmier. There are plenty of data transfers that should occur at periodic intervals, so the mere fact that a transfer is periodic doesn't indicate much (e.g., backups to a local NAS, checking for updates, requests to fetch mail, etc.)

Really, the best way to detect is that unrequested network connections are being established by processes you are not using (e.g., in linux look at lsof -i -n or netstat -p -n -t) or haven't authorized. You can also use a tool like nethogs which will actively collect statistics on how much network activity each process uses.

  • Both size and fixed timer are used while creating a keylogger by a tool. All tools I have seen uses one of them. The things you have offered are both host based but we are more into network based security. In the case of keyloggers, connection is opened from the host to (let say) smtp.gmail.com then immediately after data is started to be sent. This may be a characteristic of keyloggers, isn't it? Do you think, we can follow this path/idea?
    – smttsp
    Feb 20, 2013 at 11:42

First, you need to distill the pattern of communication and some features. If you're lucky, the exfiltration stands out, e.g., due to unique destination address, small connection size, periodicity, etc.

For detection, Bro would be your best bet here. Here are two starting points:

  1. Inspect the connection logs. Bro has writes a file called conn.log which has a one-line summary for each connection. Like NetFlow on steroids. Grep for a specific host that made an outbound connection and analyze its timestamp and the number of bytes sent. This process could start like this:

    bro-cut ts id.orig_h id.resp_h id.orig_p id.resp_p local_orig orig_bytes < conn.log \
        | awk '$2 == compromised_host && $6 == "T" && $7 < max_bytes'

    But then you have to continue with the hard work and filter. This is an iterative process that converges when you have ground truth, i.e., have some examples of known bad traffic.

  2. Write a custom script. Bro comes with an asynchronous, event-driven, and Turing-complete scripting language. For example, you could write a script that hooks the new_connection event which is generated for each new seen TCP or UDP connection, installs a timer (say 1 hour) plus some state, and then checks again upon timer expiration if the conditions hold that you think constitute the exfiltration. If that's up your alley, give it a shot and don't hesitate to ask us on the Bro mailing list, we're happy to help!

You can still go deeper in the application-layer, e.g., if you know the keylogger uses HTTP. Then Bro offers host of hooks just for that protocol.

Overall, detecting sneakiness from the network-angle is a hard problem that involves tuning the parameters until you have practical false-positive rate.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .