Strange UDP(137) connection attempts

My firewall logs become stranger and stranger. I have had a lot of connections attempts for 2-3 weeks on my port 137 with UDP from several differents IPs. Obviously, there is always this sort of connection attempts on this port, usually 5 or 6 times each hours, but as you can view my logs of a little connection today, it's far more than usual things.
I have a simple dial-up connection, my port 137 is closed and I use strong rules for my firewall. I have some hypothesis but I want to hear your opinions about this. Thanks.

22/12/2002 15:54:45 Connection request 4.47.88.206 UDP(137)
22/12/2002 15:53:54 Connection request 200.44.115.74 UDP(137)
22/12/2002 15:52:12 Connection request 200.161.197.32 UDP(137)
22/12/2002 15:51:46 Connection request 62.139.144.195 UDP(137)
22/12/2002 15:51:26 Connection request 61.38.150.24 UDP(137)
22/12/2002 15:50:33 Connection request 219.167.6.87 UDP(137)
22/12/2002 15:50:00 Connection request 219.112.80.190 UDP(137)
22/12/2002 15:49:00 Connection request 81.50.88.169 UDP(137)
22/12/2002 15:48:40 Connection request 212.96.198.65 UDP(137)
22/12/2002 15:45:29 Connection request 218.162.109.195 UDP(137)
22/12/2002 15:45:09 Connection request 200.65.89.230 UDP(137)
22/12/2002 15:44:30 Connection request 219.118.18.50 UDP(137)
22/12/2002 15:39:44 Connection request 64.163.22.38 UDP(137)
22/12/2002 15:38:49 Connection request 61.220.40.10 UDP(137)
22/12/2002 15:35:39 Connection request 195.34.229.114 UDP(137)
22/12/2002 15:24:18 Connection request 210.66.61.104 UDP(137)

I'm guessing it is from the bugbear virus.

Incidents.org seems to think so as well. There are several other recent virii which will attempt to affect other machines via network shares like bugbear does, klez for one.

http://isc.incidents.org/analysis.html?id=170

http://[email protected]

http://[email protected]

I agree with IchNiSan, some type of worm. The W32/OpaServ.serv worm has mutated several times in the last few months which also does this type of scan.

Quote:

---

Significant NetBIOS traffic (UDP) is caused by this worm. One of the early indications of this worms activity was the increase in port 137 hits on firewalls. This traffic is caused by the worm issuing WINS queries across contiguous IP ranges. The spreading mechanism observed in testing is outlined below:

the worm issues WINS query (to retrieve NetBIOS name).
the worm then tries to establish a NetBIOS session to the remote machine.
if successful the worm attempts to spread via connecting to \\%machinename%\C using SMB (Server Message Block) commands (ie. requiring open 'C' share on remote machine). This worm can infect password-protected shares if the security patch is not installed.
Please Note: if this patch is installed, but the share is not password protected, the worm will still spread to the machine.

---

Thanks for those links. I had suspected something like this but I was not sure. This infection seems really important (in the point of view of my logs at least). I ask me why the mass media have not already made headlines about those "new evil internet virii"? I remind only some articles about BugBear on specialized sites.

Bugbear got a little play on CNN, msn, etc. when it first appeared. I think the news people are getting tired of reporting every "boring" virus as it shows up. Iloveyou and Codered wore them out I think..

It is just normal Window Netbios normal sharing process .

It is probably a worm (like nimda, bugbear, or the other myriad of worms) or it could be people attempting to send those annoying windows messenger popup ads. The best thing to do is to setup a session with a sniffer to look at the content of those packets, then it would be very very clear what is going on.

/nebulus

nebulus200 > I thought it was a worm cause I don't know how an attaker could easily retrieve me after each connection if I'm not infected by something (I use a dial-up account) and how he could obtain any interesting results spoofing all those IP adresses.
Those captures seems to be clear. All the time the same sort of packets (NetBios names queries) from differents IPs. It's an infection.
An infection which also concerns my isp's routers (I have just discovered this looking the source of the second packet)!



20:28:48.748666 194.249.140.136.1027 > dragon.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 113, id 49357, len 78)
20:31:49.294505 bordeaux-1-a7-62-147-59-43.dial.proxad.net.1033 > dragon.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 127, id 11220, len 78)
20:34:21.308808 r200-40-215-32.adsl.anteldata.net.uy.1085 > dragon.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 109, id 24737, len 78)
20:38:14.753941 cable94mol.cybercable.net.mx.1026 > dragon.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 105, id 52883, len 78)

Do you have the packet dump (packet contents) of the request? There are lots of things that can cause a netbios name request to be issues, not all of them are nefarious. With M$ it is sometimes hard to tell exactly what is going on, I guess I was expecting to see a little more than just it asking for your netbios name (think of it like mickysoft DNS), it could be just the beginning of something more, like for example checking to see if it has netbios running, then if it did, something more would happen. Really hard to say, if you still can't find answers, you might want to offer a sacrificial lamb out there to see what they are up too (just pay very very very close attention to the box to make sure it is not abused).

Perhaps if you have some old equipment, install a M$ OS with everything patched, but turned on, allow access to it via netbios, let them do whatever, and then watch what was done, that might help out a little bit and be a little easier...

/nebulus

PS if you do post the verbose contents of the snoop, please sanitize to remove your IP/sensitive info.

As I have turned off all my NetBios sharing before removing my firewall protection, my computer didn't send any answer, that's why the comunication stopped at this point without providing more information. And as I have not a lot of equipment, I can't make the experience to watch what happens exactly with NetBios sharing turned on. Sorry.
But it would probably be some commands to install and run the worm.

Hard to say what exactly it is trying to do (other than the obvious name query), but if you have netbios turned off and a firewall on, then you should be more than fine, at least for the time being.

The question I posed was more out of curiousity, and for things like that I always keep an old PC laying around (like my current old one is a PII-200) that I can use in a manner I described, can be pretty interesting to watch people hang themselves if you give them enough rope :) (Either by sticking a sacrificial lamb out there or by doing something liek starting a proxy server on that port and then confusing the script/person enough to have them try it anyway since they got an answer on their portscan, but I guess if you don't have a spare PC that wouldn't work either (unless your firewall could proxy the connection).

However, if you can't do that, then your options are pretty limited other than making sure it is blocked from the getgo.



Thanks for the updates,

/nebulus

EDIT: Wish I could have been more helpful, but as far as I can tell your options seem to have run out (aside from blocking it).