8.27. SMB Keywords
SMB keywords used in both SMB1 and SMB2 protocols.
8.27.1. smb.named_pipe
Match on SMB named pipe in tree connect.
Examples:
smb.named_pipe; content:"IPC"; endswith;
smb.named_pipe; content:"strange"; nocase; pcre:"/really$/";
smb.named_pipe
is a 'sticky buffer'.
smb.named_pipe
can be used as fast_pattern
.
8.27.3. smb.ntlmssp_user
Match on SMB ntlmssp user in session setup.
Examples:
smb.ntlmssp_user; content:"doe"; endswith;
smb.ntlmssp_user; content:"doe"; nocase; pcre:"/j(ohn|ane).*doe$/";
smb.ntlmssp_user
is a 'sticky buffer'.
smb.ntlmssp_user
can be used as fast_pattern
.
8.27.4. smb.ntlmssp_domain
Match on SMB ntlmssp domain in session setup.
Examples:
smb.ntlmssp_domain; content:"home"; endswith;
smb.ntlmssp_domain; content:"home"; nocase; pcre:"/home(sweet)*$/";
smb.ntlmssp_domain
is a 'sticky buffer'.
smb.ntlmssp_domain
can be used as fast_pattern
.
8.27.5. smb.version
Keyword to match on the SMB version seen in an SMB transaction.
Signature Example:
alert smb $HOME_NET any -> any any (msg:"SMBv1 version rule";
sid:1;)alert smb $HOME_NET any -> any any (msg:"SMBv2 version rule";
sid:2;)8.27.5.1. Matching in transition from SMBv1 to SMBv2
In the initial protocol negotiation request, a client supporting SMBv1 and SMBv2 can send an initial SMBv1 request and receive a SMBv2 response from server, indicating that SMBv2 will be used.
This first SMBv2 response made by the server will match as SMBv1, since the entire transaction will be considered a SMBv1 transaction.
8.27.5.2. Will smb.version
match SMBv3 traffic?
Yes, it will match SMBv3 messages using smb.version:2;, which will match SMBv2 and SMBv3, since they use the same version identifier in the SMB header.
This keyword will use the Protocol ID specified in SMB header to determine the version. Here is a summary of the Protocol ID codes:
0xffSMB is SMBv1 header
0xfeSMB is SMBv2 normal header (can be sync or async)
0xfdSMB is SMBv2 transform header. This is only valid for the SMB 3.x dialect family.
0xfcSMB is SMBv2 transform compression header (can be chained or unchained). These ones require the use of the 3.1.1 dialect.
The Protocol ID in the header distinguishes only SMBv1 and SMBv2 since they are completely different protocols with entirely different message formats, types and implementations.
On the other hand, SMBv3 is more like an extension of SMBv2. When using SMBv2 we can select one of the following dialects for the conversation between client and server:
2.0.2
2.1
3.0
3.0.2
3.1.1
We say we are using SMBv3 when we select a 3.x dialect for the conversation, so you can use SMB 3.0, SMB 3.0.2 or SMB 3.1.1. The higher you choose, the more capabilities you have, but the message syntax and message command number remains the same.
SMB version and dialect are separate components. In the case of SMBv3 for instance, the SMB version will be 2 but the dialect will be 3.x. Dialect specification is not available currently via keyword.
8.27.6. file.name
The file.name
keyword can be used at the SMB application level.
Signature Example:
alert smb any any -> any any (msg:"SMB file.name usage";
classtype:bad-unknown; sid:1; rev:1;)For additional information on the file.name
keyword, see File Keywords.