The SMB2 Header will either be ASYNC or SYNC, you need to look this up from the flags. SYNC is the most common header as this can be in the form of a request or a response, where as a ASYNC header will be used for responses to requests processed asynchronously by the server.
The Credit Charge field appears to be either 0 or 1 and will only be 0 on protocol negotiation (initial communication) after that it will be set to 1.
Credits appear to be a way for the client to control the requests being sent in that session, providing the client has credits remaining, it can continue to communicate. You would expect to see the ‘Credits Granted’ = 1 if the server is answering a request.
This will only be seen in responses and will give the status, or error, of the request. ‘STATUS_SUCCESS’ is as it sounds, and will typically be expected from a successful tree connection
Channel Sequence is explained by Microsoft as “In a request, this field is interpreted in different ways depending on the SMB2 dialect.”
…which is helpful…
This is reserved… no seriously, don’t use it. SMB’s version of the ‘evil bit’?
The command section will have one of the following commands within it:
The Flags field will be populated thus:
Microsoft refer to this field as “NextCommand” and say it must be offset from the first header. However every instance I have seen has this set to 0x00000000
This field is very useful as it identifies individual messages (conversations) within the SMB protocol. If you follow stream on an SMB conversation in Wireshark you will see a large number of messages, which can get confusing, this way you can see what the request and outcome was to each request.
Use the following filter in Wireshark
smb2.msg_id == ##
Where ## equals the message ID you want to track
The default value is 0x0000feff
When it is not set to default (or 0x00000000) it can be used to manage broken connections. For example if the server sends a pending response the client can decide send a cancel request to the server to stop that particular message from consuming resource.
Another useful field, within the Tree Connect Response this field will contain an identifier to a share. This means if you are investigating a lot of SMB2 traffic across many shares, this will help you keep track of a specific one.
smb2.tid == <hex value>
Where <hex value> is the hexidecimal value displayed in this field
The Session ID will help track a specific user session, similar in usefulness to Tree ID, it will allow you to see if a new username was used. It can also show failed logon attempts, as the value will change with each new authentication attempt.
This field will be set to 0 if the Signing Flag is set to not signed.
This appears to be used for verification and encryption. Most likely to be seen in environments that utilise SMB encryption
We have covered SMB v2 SYNC header. This was mostly based on Tree Connect and Response, as this was the original post!
Why do I care?
If you need to look at SMB on any modern system there are some good artefacts in the SMBv2 header.
I hope this helps, feel free to comment.