[Dshield] Windows UDP Packet Sending Process
cbrenton at chrisbrenton.org
Thu Jul 3 08:48:48 GMT 2008
On Wed, 2008-07-02 at 19:27 -0400, Jon Kibler wrote:
> I have a Windows XP/SP2 Pro box that sends out a single UDP packet every
> 2 to 7 minutes.
Target IP(s) it's trying to reach? Target port? Do you have a packet
decode? This can go a long way to helping you diagnose what is going on.
> Even running netstat in a continuous loop never sees the
You would have to get extremely lucky to have netstat kick off at the
precise moment the UDP packet is getting transmitted. At least with TCP
there is some latency as the handshake is completed. Not so with UDP.
> so I have been having problems trying to find what process is
> sending the packet. Also, TCPView has been of no help.
I agree with Mike that procmon is probably your best bet. It can
generate a lot of log info but if the transmission is that regular it
should not be too bad. Of course this assumes the process is not hidden.
> Whereas there is a good chance this box is rooted, and I would never be
> able to find the process originating the packet,
> for now, I want to
> presume it has not been compromised.
> (Why such an assumption? 1: The box would take over a man-week to
> rebuild and would require outside vendor support to do so.
lol! Doesn't Murphy's law dictate the opposite would be true. ;-)
> 2: The box
> owner has been known to load unauthorized software, and there is a good
> chance that is what we are dealing with.
You could also argue that loading unauthorized software also increases
the chance the box is rooted.
> 3: Have run several
> anti-rootkit packages, and they have found nothing.)
If it's a kernel level kit, chances are high you would not find anything
unless you pulled the drive and checked it from a known to be clean
system. Did you run the tools from within the suspected compromised
environment or actually check from a known safe system?
> Question: Is there a 'netflow-like' tool that will run on XP at log
> every single flow originating from the box, including PID? If not, how
> would you go about finding the process sending packets?
Again, I would start with the decode. Good chance with what you have
described that the box is whacked. Packets on the wire will give you the
cleanest view of what's going on.
More information about the list