InfoSec Handlers Diary Blog

Over the weekend a reader, Infinite, wrote to us and commented on "Bling.exe" with a pointer to TrendMicro write-ups of two new SDBot variants. Thanks Infinite! (Bling.exe is a component of these Trojan's spreading mechanism, the "TFTP server .. attempts to send this worm to other systems as the file "BLING.EXE").

Whats notable is that these SDBot variants have a sniffer with a list of strings they filter for. (Although there are two earlier bot variants, described by Sophos, that use Bling.exe, they are not reported to have a sniffer component). If the trojans described by Trend can successfully transmit the filters packet captures back to the owner they are going to cause problems well beyond typical bot infestation issues. It is my understanding that the filter will only work when it matches a string exactly.

The addition of the sniffer also brings up the question of "What are the intended targets of these particular trojans?" (my favorite malware question!). Are they after the usual SDBot stuff, ... after all ... building a SDBot variant is trivial, or is the trivial use of SDBot just camouflage for attacks on critical systems resulting from the harvest of the sniffer's filter? If you'd care to contribute to an answer to this question ("if you got bling") and care to share the sniffer's impact, privately or publically, please write us at;

fwiw, if your network is vulnerable, while researching the history of the use of sniffers by Trojans and Backdoors, in "Malware: Fighting Malicious Code" by Handlers Ed Skoudis and Lenny Zeltser, there's a recommendation for finding sniffers, the book refers to;

This forwards log messages from sshd containing "Failed password for root from (host)" and "Illegal user (user) from (host)" to the program /usr/local/sbin/sshd-blacklist. This is a simple shell script:

It's not perfect, but will block anyone trying to hack the machine for a while (the duration will depend on how often the chain is cleared) after their first failed attempt. If you have a separate whitelist which gets accepted before the blacklist chain is executed, you can ensure that a failed password won't cut you off from the host.

The downside is that this could theoretically be used to slow your host down if someone launched the attack from a huge number of IP addresses, causing the blocking chain to become very long. A more robust /usr/local/sbin/sshd-blacklist might help there, if it did some more checking before adding the hosts on the blacklist.

There may be better ways, and if anyone has any, I would be interested to know too."

Some initial feedback was that "key based authentication will be even better" and "the approach will not help against lucky shots that hit the right password on the first try, and against more distributed scans".