Re: strange windows behaviour.

[Harlan Carvey <keydet89 () yahoo com>]

Peter...
 
> What I found were a few processes listening on funky
> network ports that
> I didn't recognize.  hunting led me to find that
> they were the windows
> auto update client, the windows application layer
> gateway (still a
> little confused on this one), and epmap.

Okay, this is a good start.  Please bear with me, as
I'd like to try to get a little clarification.

What are the "funky network ports"?  And what kind of
"hunting" did you do?  I ask, b/c there are several
good process-to-port mapping tools available (I'm
partial to DiamondCS's openports) that will take care
of the "hunting" for you.

I hesitate to do this, but I'd like to ask if you have
specific information about these processes?  What
tools did you run?  What operating systems are we
talking about?  Did you get the full paths of the
executable images?
 
> I'm still thinking that it's possible that whatever
> this thing is (and
> it *is* something, these students have a hard enough
> time writing a two
> page paper in a week, there's no way they're
> originating out 100,000
> emails in a day), it's smart enough to turn itself
> off if there's no network connection.

That could be...however, there will still be a process
running.
 
> Standard virus scanners found nothing too crazy. 
> Lots of tracking
> cookies in the registry, a couple of garden variety
> macro worms.  That's about it.

"Tracking cookies"?  Sounds like you ran more than a
virus scanner...maybe some spyware detection stuff as
well?
  
> The methodology was to basically look for
> applications listening on some
> network port and investigate the origin of the
> application.  

Okay, good.  However, it's important to understand
"how" you're doing this.  From the scant info you've
been able to provide, I can only guess that you're not
using any kind of process-to-port mapping tool...maybe
I'm assuming too much, but I would think that if you
had, you would have mentioned this.  Such tools are
incredibly useful.  Also, tools that give you a better
view of processes, such as pslist, handle, listdlls
(from SysInternals) or tlist (from the MS Debugging
tools).  Using a few simple tools, investigating the
origin of an application is trivial.

> Also
> hunting in the Run portion of the registry to see
> what's started at boot time.  

Always an excellent choice.

> Using netstat -A -o I was able to get a list
> of the listening
> network daemons, and I correlate them to actual
> process names with the
> task manager (client was running xp pro) and I used
> regedit to get a look at the registry. 

Ah, okay, here we go!  I strongly suggest that you
download a couple of tools and burn them to CD.  

> I've not heard replacing the
> netstat binary on
> windows as happens so often with rooted unix boxes,
> but I wouldn't rule it out.  

On XP, netstat is protected by WFP.  That should be
enough info for you to make a suspected-Trojaned (not
a word, I know) netstat an extremely remote
possibility.

> Unfortunately, I didn't have any other tools at my
> disposal.

Sure you do.  
 
I understand that getting the info from these systems
can be an issue, but there are ways for you to collect
and correlate information in a much more efficient
manner.  The first thing you need to do is realize
that your methodology (and it's good that you have
one) can be improved.

If you're interested in doing so, contact me off list
and I'll provide you with information.

Harlan


---------------------------------------------------------------------------
----------------------------------------------------------------------------