Government Security
Network Security Resources

Jump to content


Something Trying To Use Udp Port 137

- - - - - network tools firewall
  • Please log in to reply
12 replies to this topic

#1 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 05:06 AM


My firewall is logging one of the XP pro machines on the network as trying to creat an outbound connection via UDP port 137.

I know this is Netbios so i'm a bit concerned.

I've installed microsofts port report and port parser and logged traffic for a while.However I can't see this event in the port Report logs.

Now I find out that port report doesn't log traffic sent from a UDP port to another UDP port.

So, what to do?

Heres the log from my firewall:

02/02/2005 11:43:38.272 UDP packet dropped, 137, LAN, 137, WAN NetBios

I ran a whois on teh remote ip and it looks like its somethnig to do with the Internet Assigned Numbers Authority.

Still, seems strange.Are there any other tools I can use to easily find out whats trying to get out?

Thanks very much.

#2 Guest_relax_*

  • Guests

Posted 02 February 2005 - 05:10 AM



Copyright 1998-2004 Mark Russinovich
Last Updated: August 9, 2004 v2.34


TCPView is a Windows program that will show you detailed listings of all TCP and UDP endpoints on your system, including the local and remote addresses and state of TCP connections. On Windows NT, 2000 and XP TCPView also reports the name of the process that owns the endpoint. TCPView provides a more informative and conveniently presented subset of the Netstat program that ships with Windows. The TCPView download includes Tcpvcon, a command-line version with the same functionality.

Posted Image


#3 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 06:05 AM

THanks very much, exactly what i'm after.

I also just found out about netstats -b switch.Thanks, again

#4 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 07:31 AM

ok, i think i've got it.well, getting closer anyway.

TCPview lists the proccess behind the outbound udp packets as system:4

heres the log line from TCPview -

System:4 UDP *:*

What the hell is system:4 ?

I've searched arround for it and found a few forum posts linking it to Netbios and the messenger service, but we have other xp machines with messenger enabled and they aren't behaving in this way.

Any ideas?
Thanks again and again......

#5 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 07:37 AM

one more thought.

Do I need to actually catch this thing in the act?
I mean, once it's tried to connect then will the port close or stay open for a certain amount of time?


#6 Guest_relax_*

  • Guests

Posted 02 February 2005 - 07:48 AM

based on my use of the program i think (*thank*) the connections show up as system when ever the app has just closed or the socket just closed, one of them heh...

its realtime, so the app needs to be doing something on the net for it to show up in tcpview...

#7 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 07:56 AM


ok i'm going to do a :

netstat -o -p UDP 2

I'll log it and see what comes up.

#8 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 08:44 AM


I just saw one of these udp packets get dropped by the firewall.I checked the log from the netstat and theres nothing there!!!!1

Why is nothing logging these packets?
The closest I've got is TCPview showing that the port has been recently used.

please help, someone!

#9 Killaloop


    Sergeant First Class

  • Members
  • 677 posts

Posted 02 February 2005 - 09:03 AM

the dropped udp packets are nothing to worry about
and the remote address seems to be your gateway.
machine is prolly misconfigured and tries to get some information from the remote host.
maybe nameservices or what ever.
the process that sends the packet for sure is system if tcpview says so.
to be more exact its a thread that runs as system context.
you should get a decent tasklister and take a look what threads are running (not processes)
I have not seen a port explorer that is able to map open ports and lan activity to threads.
only to processes, which seems to be not enough nowadays (running your code in the memory of another process, execute your thread as remote thread within another process ...)
problem with this is with regular port explorers you will never see what process really calls the activity you will only see what process opens the tcp/udp handle.
(same for dll injection, but its very easy to catch).

anyways this was just for information how difficult it can be to find out what program causes this.
especially concerning UDP

#10 babaton


    Private First Class

  • Members
  • 83 posts

Posted 02 February 2005 - 09:11 AM

ok.i'm relieved you think its nothing to worry about but how did you identify the remote as my gateway?

Also, could you reccommend a decent tasklister?

#11 ash^


    Private First Class

  • Members
  • 72 posts

Posted 02 February 2005 - 02:02 PM

Advance Process Manipulation ( APM )-


#12 cool_one



  • Members
  • 182 posts

Posted 05 February 2005 - 06:01 PM

hey man udp 137 is the netbios name service port, this is what your comp uses to find and tell others about workgroups

the system process is also responsible for a lot on net stuff as well as system stuff

firewalls for windows won't kill this either because they have been hardcoded not to, otherwise your network connections might get (filtered).

btw, if you wanna write a trojan, figure out how to take control of that port and send crap there because of this pusedo-flaw

#13 KeKeTTe



  • Members
  • 8 posts

Posted 12 February 2005 - 07:23 AM

try Open Ports ! it's command line tool for view port open and exe files :)

Also tagged with one or more of these keywords: network, tools, firewall