Re: strange windows behaviour.

[Peter Moody <peter () ucsc edu>]

> You've said that you've gone and looked at some of the machines...what
> did you find?  I know you didn't find the proxy stuff you were looking
> for...but what *did* you find?  The traffic has to be coming from
> somewhere, right?  One would think that there would have to be a
> process of some kind generating the traffic.

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.

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.

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.

> What is the os of the clients you're dealing with?  What is your IR
> (or as you mentioned, forensics) methodology?  What data are you
> collecting, and how are you collecting it?  Do you have any process
> information that others can view...or the output of process-to-port
> mapping tools?

The methodology was to basically look for applications listening on some
network port and investigate the origin of the application.  Also
hunting in the Run portion of the registry to see what's started at boot
time.  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.  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.  Unfortunately, I didn't have any other tools at my disposal.

I've been trying to get out and look at more of these machines (I think
we have 3 now who've been turned off and are awaiting cleansing/approval
before being re-enabled) but that requires coordination with a couple of
different departments and it takes a while.

-Peter

-- 
Peter Moody                             <peter () ucsc edu>
Information Security Administrator      831/459.5409
Communications and Technology Services. http://mustard.ucsc.edu/pubkey
UC, Santa Cruz.
:wq

Attachment: signature.asc
Description: This is a digitally signed message part