 Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3
 ·Shaw
| A Day and a Night with PortPeeker and UDP port 137 So what can PortPeeker tell you about UDP port 137 scans? First it will tell you that there are a LOT of them, but if you look at PortPeeker carefully it will tell you that not all UDP port 137 scans are created equally. You can see that there are actually a couple of worms out there and some scripts that are being used. First some stats. This is a quick view of traffic from about a 30 hour period which resulted in just over a thousand UDP port 137 scans. The typical scan was an Opaserv type scan. Source port greater then 1023 and less then 1034 (approx). Note the packet contents:
12.84.14.68 : 1024 : MD5 = 331B8E512CF50EF273121C9B356383DC
--- 4/27/2003 14:08:53.102
0000 01 00 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
Second we have scans where the source port is much larger, usually over 10,000 and more likely in the 20,000 range. Note the contents and how they differ in this small sample:
80.36.122.88 : 27829 : MD5 = 78C1D1393257788EAB27452285EA351B
--- 4/28/2003 06:13:43.985
0000 00 22 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .".......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
80.59.214.187 : 25396 : MD5 = 669FCAEBD75E9D36FA58FA199791A81D
--- 4/28/2003 08:59:45.780
0000 00 52 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .R.......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
208.17.72.24 : 25524 : MD5 = 052584A19E07157CF7249DCEBA6191D2
--- 4/28/2003 09:08:00.261
0000 00 2A 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .*.......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
Note the second character in the text string is different and is different for a number of the events in this Source Port range. The events where the source port was in the Opaserv port range had no difference at all in the packet contents.
The third group are likely a script as the source port is always 137 and usually occurred in groups of three and about 1.5 seconds apart which would be somewhat indicative of a DOS script, for example:
68.144.35.22 : 137 : MD5 = 3D421D702857DEEC908E0155DE6E2830
--- 4/27/2003 23:54:43.867
0000 D7 66 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .f.......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
68.144.35.22 : 137 : MD5 = 5819D2FC8A221FD1D252E7FE58E9DFC0
--- 4/27/2003 23:54:45.369
0000 D7 70 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .p.......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
68.144.35.22 : 137 : MD5 = EF9CB4363DC0A1DCC3BB47AB5C93C211
--- 4/27/2003 23:54:46.871
0000 D7 78 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 .x.......... CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
Note also that the second character in the text string changes for each event.
I used to think that the events with the high source port had a high source port just because they were behind a firewall, but given the difference in the packet contents I'm not so sure that is the reason every time, as I'm starting to think that this could be part of a worm's signature (mode of operation). The cycling of the second character in the packet is typical of NetBIOS functionality.
Anyone know which worm scans UDP port 137 from such a high source port range?
Next adventure is to have PortPeeker return bogus information which indicate to the scanning system that open shares exist and see what happens then, who goes for the kill and how.
Blake |
|
pslossPremium
join:2002-02-24
Alpharetta, GA | Re: A Day and a Night with PortPeeker and UDP port Here's a screen grab from my database; the udp/137 packets that aren't obvious Opaserv are fairly rare. The highlighted entry is different, but the two nearby are the canned packet with the transaction ID of 1. I'll run a quick query on the different udp/137 packets to see what the breakdown is...
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org |
|
|
|
pslossPremium
join:2002-02-24
Alpharetta, GA | reply to Link Logger
OK, here are two charts. The top one is based on all the repeated udp/137 packets I've received, which is around 38000 since the end of last October.
The second chart is just the repeated udp/137 packets where the remote port was greater than 10000; that was only about 6000 out of the 38000 total packets. It has a slightly different distribution, but still dominated by Opaserv...
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org |
|
Link LoggerPremium,MVM
join:2001-03-29
Calgary, AB
kudos:3 Reviews:
·Shaw
| Perhaps I should explain a bit about why the first couple pieces of the UDP probe are different on some packets. Since the protocol of the probe is UDP its connectionless, meaning if I send a bunch of these out at once then I need something to identify each probe/instance as typically the source and destination port are the same (ie 137 -> 137) for all of them and there is no FOFB (first out, first back) ordering. For example note this sequence of probes:
192.168.168.3 : 137 : MD5 = 36152315F6AFB81838B18D05F30A32C5
--- 4/30/2003 00:08:02.524
0000 87 94 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = 56975D2735ACE2DF63DC5D4BAD9EB038
--- 4/30/2003 00:08:04.026
0000 87 96 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = C89A7453808D464FC26120C91043BAD3
--- 4/30/2003 00:08:05.528
0000 87 98 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = 6492AA71BBC106D7A7EBABA7B5162C29
--- 4/30/2003 00:08:09.644
0000 87 9A 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = FC1D88324A25B0DD18F511D29A7A455A
--- 4/30/2003 00:08:11.146
0000 87 9C 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = F9CE14458117DA5DB3B7B7B46E604B73
--- 4/30/2003 00:08:12.638
0000 87 9E 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = 34243DECED5AC2D7D0B52C5517386574
--- 4/30/2003 00:08:16.043
0000 87 A0 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = 526288A3F8077EAF28AE10A26FBEA2EF
--- 4/30/2003 00:08:17.545
0000 87 A2 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
192.168.168.3 : 137 : MD5 = FEE7EE3BF5732B560F858FE6756C4082
--- 4/30/2003 00:08:19.048
0000 87 A4 00 10 00 01 00 00 00 00 00 00 20 43 4B 41 ............ CKA
0010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
0020 41 41 41 41 41 41 41 41 41 41 41 41 41 00 00 21 AAAAAAAAAAAAA..!
0030 00 01 ..
So in effect the first couple of pieces of information are a counter (which is incremented by two each time so you can get a bit of an idea how many systems the scanner has scanned) for this example ranging from 8794 - 87A4. The Opaserv worm doesn't use NetBIOS, but only send out a NetBIOS like packet and since its threaded and uses different ports it is not concerned about having a unique identifier in each scan as the port is unique and why it's (and other worms like it) use a static packet (also performance is a factor as a static packet is faster/easier to use). This also explains why in Philip's examples posted above (thanks) show such a large percentage of one type of packet (MD5 hash) as anything that is using NetBIOS to make the probe would have a different hash each time as the counter increases. So if you were to create a signature for this probe in an signature based IDS like Snort then you would only use part of the packet contents if you wanted to catch all the nbtstat type probes, but you could use the whole packet as the signature for a Opaserv scan and most of the time you would be right (this is also displayed by Philip's charts above).
So the end result of this is perhaps the higher Source Port probes are really a script or worms that uses NetBIOS to do the probe and its the firewall which creates the appearance that the port is from a higher range (port translation which I posted about some time ago). This bears out on my experimentation that showed that most of these high source port cases were hiding behind a firewall.
I need to do these writeups at a different time of the day when I'm not so tried (but I don't have any form of regular hours so time of day isn't really an indication of if I should be tired or not). Is anyone even interested in these sorts of analysis or I'm just wasting bandwidth on these little ventures into network forensics?
Blake |
|
 catseyenuAck PfftPremium
join:2001-11-17
Fix East | said by Link Logger:
Is anyone even interested in these sorts of analysis or I'm just wasting bandwidth on these little ventures into network forensics?
Blake
Forensic posts by you L.B. and PSloss are some of the reasons I even read this forum.
The bleeding edge isn't easy but it sure is interesting. 
--
"Parched, dry and thirsty...Knee deep in the river of life." |
|
| reply to Link Logger
These threads, though short on the usual replies of "What's the best AV software", do interest me at least. |
|
Reviews:
·Shaw
| reply to Link Logger
Please do continue with such posts. They are both interesting and informative, and hopefully as a result of your efforts and explanations I may someday be able to make a meaningful contribution...well at least understand more of what I am reading.
[text was edited by author 2003-04-30 10:41:39] |
|
pslossPremium
join:2002-02-24
Alpharetta, GA | reply to Link Logger
said by Link Logger:
...So in effect the first couple of pieces of information are a counter (which is incremented by two each time so you can get a bit of an idea how many systems the scanner has scanned) for this example ranging from 8794 - 87A4. The Opaserv worm doesn't use NetBIOS, but only send out a NetBIOS like packet and since its threaded and uses different ports it is not concerned about having a unique identifier in each scan as the port is unique and why it's (and other worms like it) use a static packet (also performance is a factor as a static packet is faster/easier to use). This also explains why in Philip's examples posted above (thanks) show such a large percentage of one type of packet (MD5 hash) as anything that is using NetBIOS to make the probe would have a different hash each time as the counter increases...
Just to note the reference for this, NetBIOS over TCP/IP was "kind of" documented in RFC 1001/1002; here's the part that Blake is talking about:
»ubiqx.org/cifs/rfc-draft/rfc1002···s4.2.1.1
The number that is varying is the transaction ID, which is a two byte value; here's the description from RFC 1002:
"Transaction ID for Name Service Transaction. Requestor places a unique value for each active transaction. Responder puts NAME_TRN_ID value from request packet in response packet."
As Blake wrote, Opaserv uses a "canned" transaction ID of 1 (0x0001 hex); in fact, the whole packet is "canned," which is of course why the MD5 hash is the same.
The response to this request -- the request being the infamous "node status request" (a.k.a. "nbtstat -a/-A") -- includes the target's NetBIOS name table and the MAC address for the adapter.
This request/response is used by some security software to do a "backtrace" -- BlackIce comes to mind.
In the case of Opaserv, it needs to know one of the names in order to continue its naughty work.
said by Link Logger:
Is anyone even interested in these sorts of analysis or I'm just wasting bandwidth on these little ventures into network forensics?
Thumbs up from me -- thanks for sharing your data. I collect lots of data here, and your posts usually give me an excuse to share, also.
Philip Sloss
--
Feedback? e-mail: stuff@lupwa.org |
|
