Update: UDP 770 Potential Worm

From: Byrne Ghavalas (security@gzone.org)
Date: 03/02/02 

From: "Byrne Ghavalas" <security@gzone.org>
To: <incidents@securityfocus.com>
Date: Fri, 1 Mar 2002 23:16:53 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,

Since my last posting, I have managed to analyse the packets and
have attached a copy of my results for your comments.

(Filename: Analysis.txt)

I still believe that the packets may be the result of some kind of
worm / trojan, with the goal of knocking machines off the network.
My analysis revealed that the final destination of these strange
packets
was UDP 138, however I was not fortunate enough to sniff any of
these packets and so am not sure of the payload of these final
packets.

I have included samples of the raw packets in the attached file,
should you wish to assist me in resolving this problem.

I would appreciate any insights or suggestion you may have.

FYI, below is a copy of my original message to this list:

===Original Message===

Hi All,

I have gone through the archives and searched the 'Net, but am
unable to locate any further information with regards to these
strange packets - perhaps you fine people could be of
assistance. :-)

1. I was called in to analyse a customer's network. They couldn't
understand why network connections kept failing and machines
dropped out the network. They eventually found that by removing
the MS-Proxy server from the network, the problems were
'resolved'.

2. They rebuilt the server using a different machine and clean
media from original CDs. A day and a half later, the problem
re-appeared - again corrected by unplugging the machine from
the network.

3. I analysed the machine, but found nothing obvious. I decided
to sniff the TCP/IP traffic from the Proxy server and found:

3.1 Intermittently, 5 UDP packets were sent with Source port of
770 and consecutive destination ports, with a directed-broadcast
address as the destination.

3.2 The starting destination port number would be different for
each burst of packets. For example, first burst would have
destination ports as follows: 63451, 63452, 63453, 63454,
63455; the next burst would be 37201, 37202, 37203, 37204, 37205.

3.3 The payload was always 28 bytes.

3.4 I noticed that the packets were always sent after a legitimate
UDP packet had been sent by the host, and the destination address
of these UDP packets was always that of the legitimate UDP packet.
For example, if a BROWSER announcement was sent out to the
directed-broadcast address, then the UDP:770 packets would be
sent out (to the same broadcast address). [I later found that this
pattern also applied when the destination was a specific IP
address - the UDP:770 packets were also fired off at the specific
IP address.]

3.5 When the proxy is plugged on to the network, I noticed that
it ARP'ed for it's own IP address, after which a barrage of packets
hit the network. (I was sniffing a switched network, plugged in to
a
hub - so only saw local traffic and the broadcast traffic.) After a
few
minutes, machines started to drop off the network!

3.6 I had baselined the network prior to plugging the proxy in
and found no evidence of these strange UDP packets - they only
started when the box was plugged in to the network. Also, as
soon as the box was unplugged, UDP activity appeared to
cease - almost immediately!

3.7 Some of the machines appeared to have a 'conversation'
between themselves and the broadcast address.

This is pretty much what I have so far. (I don't think that it
makes any difference - but you may like to know that the proxy
server was acting as a caching proxy and sits behind a firewall.)

I would appreciate any comments / suggestions, and useful
insights. If you require any further information, let me know and
I will see what I can do.

Kind regards,

Byrne Ghavalas

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPIAL16IdD3l9/MFwEQJPeACglQIdL5O0yH+h+uNl8sPpDsMi7ZUAoPjJ
VWXCnnYdl/zPWVlbAIJaSv3V
=PSwk
-----END PGP SIGNATURE-----

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com

Relevant Pages

  • Re: Update: UDP 770 Potential Worm
    ... > I still believe that the packets may be the result ... with the goal of knocking machines ... the network immediately after the 'attack', ... destined to port if you haven't sniffed it somehow? ...
    (Incidents)
  • Re: Mysterious file - WINXPINIT.EXE
    ... then it seems to keep the machines from getting re-infected. ... > Although I have not found this file on any machines on my network, ... I ran Ethereal and captured the packets ... > before and after plugging the server into the isolated network. ...
    (microsoft.public.security.virus)
  • RE: unusual 1.11.0.0/16 outbound traffic
    ... "The last 10 years of Internet usage has disproven ... We have been seeing an increasing amount of unusual network activity ... The activity began 2004-08-10 with 4 machines trying to send packets out ... No packets with "data" appear to be making it out. ...
    (Incidents)
  • Re: Ethernet issue: works one way but not another
    ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
    (freebsd-questions)
  • Re: Mysterious file - WINXPINIT.EXE
    ... >> Although I have not found this file on any machines on my network, ... When I plugged our W2K Server into ... The server was sending out tcp packets to random adddresses ...
    (microsoft.public.security.virus)