[SNORT-SIGS] NETBIOS Oddities (nulls and NT4/Samba differences)

Al a.hood at ...314...
Thu Jan 24 08:38:05 EST 2002


All

I've started looking at some NetBios sigs to help with the documentation 
drive, but found that some of them are different from my observations -

- SID 530 doesn't match any null share captures I've seen - I've looked 
through sample transactions (by eye, admittedly, under ethereal) and can't 
work out what the pattern is meant to represent, under NT4 or Samba.  Am I 
missing something (eg is it W2K or some dialect of SMB, or am I just being 
packetblind)?  Also, isn't it the same in concept as SID 537?  Does anyone 
get any hits with this rule?

- SID 532 - my captures show the string as containing additional nulls (a 
Unicode thing?), and the service name differs depending on whether you're 
connecting from NT4 or Linux - | 00 41 3a 00 | ie A: is | 3f 3f 3f 3f 3f | ie 
????? under Samba/Linux.  Alternative/additional sig could therefore be | 5c 
00 41 00 44 00 4d 00 49 00 4e 00 24 00 00 00 | followed by | 41 3a 00 | for 
NT4 attacker or | 3f 3f 3f 3f 3f 00 | for Samba/Linux attacker.  Again, does 
anyone see this rule report ADMIN$ connects accurately?

- SID 533 - as for 532, extra nulls in my packet captures that might cause a 
false neg.  Alternative sigs seem to be | 5c 00 43 00 24 00 00 00 | then 
either | 41 3a 00 | for NT4 or | 3f 3f 3f 3f 3f 00 |for Samba/Linux.

- SID 536 - more nulls.  Amended sigs would be | 5c 00 44 00 24 00 00 00 | 
then either | 41 3a 00 | for NT4 or | 3f 3f 3f 3f 3f 00 | for Samba/Linux.

- SID 537 - ditto.  The sig is \\IPC$|00 41 3a 00|  - I see | 5c 00 49 00 50 
00 43 00 24 00 00 00 3f 3f 3f 3f 3f 00 | for both NT4 and Samba/Linux (ie the 
service name doesn't differ on this one - go figure!).

This null business is bugging me - maybe my test server is requesting Unicode 
or whatever, and the one used for the original sigs didn't.  Any other ideas?

Individual packet caps are attached for NT4->NT4 and Samba->NT4, if you want 
the whole streams let me know. (I didn't capture 536 D$ as it's conceptually 
identical to 533 C$).

All ideas gratefully received - when I'm sure I'm not losing the plot, I'll 
submit the issue descriptions for the database.

Cheers
Al
-- 
The above correspondence is solely informal, and does not
constitute the views or advice of QinetiQ in any way
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 533.nt4-nt4.cap
Type: application/octet-stream
Size: 355 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 532.nt4-nt4.cap
Type: application/octet-stream
Size: 175 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 533.linux-nt4.cap
Type: application/octet-stream
Size: 174 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 532.linux-nt4.cap
Type: application/octet-stream
Size: 182 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 537.linux-nt4.cap
Type: application/octet-stream
Size: 163 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 537.nt4-nt4.cap
Type: application/octet-stream
Size: 274 bytes
Desc: not available
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20020124/fc819dc4/attachment-0005.obj>


More information about the Snort-sigs mailing list