Re: Trojan of somesort - Update

[Harlan Carvey <keydet89 () yahoo com>]

Bob,

> There were no obvious suspicious connections in
> netstat, of course this 
> could be because the binary had been modified, but
> the machine is behind a load balancer. 

A couple of questions:
1.  Which binary are you referring to?  Netstat?  If
so, is there anything to suggest that WFP had been
disabled?  Did you compare an MD5 checksum of
netstat.exe to the copy maintained in the dllcache
directory?  My thinking is that it's easy to make a
statement such as "the binary could have been
modified", and it takes very little effort to confirm
this.

2.  If you were able to run netstat.exe, how about
fport.exe or openports.exe?
 
> Other than the ServU files and some sort of crude
> looking port scanner so 
> far I haven't been able to find anything else. 

That may be the case, and it may also be the case that
there isn't anything else on the box.  However, I have
seen boxes broken into by multiple "attackers" (either
individuals or worms) all using the same vector, and
all leaving their goodies behind.  I've followed the
thread pretty closely, and if you would like to talk
about it off-line, I can definitely assist you with a
methodology for taking a more comprehensive and more
efficient view of the system.  

> Does anyone know of a program 
> that can be used to scan for trojans offline, as I
> now of the machines disk 
> loaded into my forensics system. 

Interesting.  It's not really clear why you're doing
forensics.  Either way, I'm not aware of any databases
of checksums that you could refer to.

> I want to find out
> what other ports I need 
> to be suspicous of so that I can scan the rest of
> the network for them to 
> see if anything else looks compromised.

If you've got the drive mounted in a forensics system,
you're likely not going to find out what other ports
you should be looking for.  One way to approach that
is to run openports.exe on the (live) system. 
However, as the ports on Trojans are configurable (as
are the names of the files), one approach that I've
used in the past is to write a Perl wrapper around
openports/fport to automate the collection of
process-to-port mapping information.  

Look at it this way...you may think that it's quicker
to scan your entire infrastructure w/ nmap, but
remember, that when you do find something you're going
to have to run fport/openports anyway, in order to
find out which process is using the port, so you know
what files you're interested in.

> I plan at some point to try and 
> reboot the system connected to a standalone switch
> to see what services come 
> back up and see if I can track them to any
> interesting local files.

Good luck.  What you're talking about is very easy to
do, if you have the right tools...which I've already
mentioned.