full-disclosure - Backdoor not recognized by Kaspersky

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4047EA00.13722.5DD33A4@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Backdoor not recognized by Kaspersky

"Larry Seltzer" <larry@...ryseltzer.com> wrote:

> I'm really not clear how this could work on a DHCP client, which the
> overwhelming majority of compromised systems must be. Please don't just
> tell me it's magic and works. 

Well, cable and DSL clients tend to get the same IPs over and over and 
even if they don't between restarts, within a "session" (and these tend 
to be "always on" devices, so a "session" can be days to weeks long) 
they definitely tend to retain the same IP.  Thus, setting yourself up 
as a server tends to "work" -- spray out a bunch of IMs, or Emails that 
look as if they are from the victim to everyone in the victim machine's 
address book "Get this cool screensaver I made with my party photos.  
It's on my personal web site <IP-based_URL>".  Get one more victim 
before the fist victim's ISP kills his account and you have a 
successfully _maintaining_ spread mechanism...

And, of course, there is always the "high-rotation rate round-robin DNS 
pointing to a port redirector", which we have already seen used to 
obfuscate the "real" location of the spammer's web site.  Sure, it 
probably needs an army of several dozen to several hundred compromised 
machines but we've seen it used successfully several times.

Oh, and even if a victim machine's IP is the not very stable because of 
DHCP oddities, that often need not matter -- in the IM example, the 
"bot" need only  keep checking its IP before sending each message (or 
batch) and again, the very low "useful" success rate means it need not 
care if 50% (or probably even 90%) of its potential victims do not 
actually see or otherwise have a chance to react to one of its messages 
before its host IP changes...

And, of course, we are talking about machines where all bets are off 
because the bad guys have already got some code to run, so they can 
include address notifier code in their bots to "phone home" their 
changing network addresses if they do suffer from such yet can still 
viably perform their intended functions (a lot of IRC bot-net agents 
already do this...).

Regards,

Nick FitzGerald