Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Those strings don't appear in the packets; they come from Wireshark, which interprets the numerical value of the SMB request code.

But if all you want is to detect SMB1, and the auditing Graham Bloice mentions isn't possible (presumably domain controllers running newer software can tell you who's using SMB1) that's more than you need - you could try looking for any TCP packets to or from port 139 or port 445 in which the first byte of the TCP payload is 0 (a NetBIOS-over-TCP "session message", or a regular SMB-over-TCP message) and bytes 5, 6, 7 and 8 are 0xff 0x5e 0x4d 0x42:

(tcp port 139 or 445) and tcp[20:1] = 0x00 and tcp[24:4] = 0xff534d42

This won't handle packets with TCP options; to do that, the filter would have to fetch the data offset from the TCP header, multiply it by 4, and add it to the 20 and 24 in the TCP payload test.

Those strings don't appear in the packets; they come from Wireshark, which interprets the numerical value of the SMB request code.

But if all you want is to detect SMB1, and the auditing Graham Bloice mentions isn't possible (presumably domain controllers running newer software can tell you who's using SMB1) that's more than you need - you could try looking for any TCP packets to or from port 139 or port 445 in which the first byte of the TCP payload is 0 (a NetBIOS-over-TCP "session message", or a regular SMB-over-TCP message) and bytes 5, 6, 7 and 8 are 0xff 0x5e 0x4d 0x42:

(tcp port 139 or 445) and tcp[20:1] = 0x00 and tcp[24:4] = 0xff534d42

This won't handle packets with TCP options; to do that, the filter would have to fetch the data offset from the TCP header, multiply it by 4, and add it to the 20 and 24 in the TCP payload test.

test:

(tcp port 139 or 445) and tcp[((tcp[12:1] & 0xF0) >> 2):1] = 0x00 and tcp[((tcp[12:1] & 0xF0) >> 2) + 4:4] = 0xff534d42

(This reminds me - I really need to add string comparison, byte-string comparison, and a direct way to access the UDP and TCP payload to the capture filter mechanism in libpcap....)

Those strings don't appear in the packets; they come from Wireshark, which interprets the numerical value of the SMB request code.

But if all you want is to detect SMB1, and the auditing Graham Bloice mentions isn't possible (presumably domain controllers running newer software can tell you who's using SMB1) possible, that's more than you need; you don't need - you to look for particular SMB messages, you just need to look for SMB1 messages of any type.

You could try looking for any TCP packets to or from port 139 or port 445 in which the first byte of the TCP payload is 0 (a NetBIOS-over-TCP "session message", or a regular SMB-over-TCP message) and bytes 5, 6, 7 and 8 are 0xff 0x5e 0x4d 0x42:

(tcp port 139 or 445) and tcp[20:1] = 0x00 and tcp[24:4] = 0xff534d42

This won't handle packets with TCP options; to do that, the filter would have to fetch the data offset from the TCP header, multiply it by 4, and add it to the 20 and 24 in the TCP payload test:

(tcp port 139 or 445) and tcp[((tcp[12:1] & 0xF0) >> 2):1] = 0x00 and tcp[((tcp[12:1] & 0xF0) >> 2) + 4:4] = 0xff534d42

(The filter fetches the data offset from the TCP header, multiplies it by 4, and adds it to the 20 and 24 in the TCP payload test, so that it works even with TCP segments that have TCP options.)

(This reminds me - I really need to add string comparison, byte-string comparison, and a direct way to access the UDP and TCP payload to the capture filter mechanism in libpcap....)