After studying different vendors’ approaches, here is our summary of how to do SMB OS detection right.
- With either SMBv1 or SMBv2, both “Session Setup Request “and “NTLMSSP_NEGOTIATE requests” shall be sent;
- Especially for SMB v1, if only “Session Setup AndX Request” is sent, but not a “NTLMSSP_NEGOTIATE” request, some higher version of Windows Server (most likely higher than 2012) will not respond with OS information;
- With SMB v1, a clear text response with OS information can be obtained from both NativeOS and NativeLanMan. However, we recommend using the result from the NativeLanMan field rather than NativeOS to determine your OS; otherwise, there is a chance you falsely recognize Linux as Windows.
- With SMB v2, there is no clear text of OS version in the response, you can get the build version of NT kernel from “ntlmssp.verion”.
- Don’t use ntlmssp.verion to determine the server is windows;
- The following fields (Wireshark) in v2 reponse usually contains server and NetBIOS name. When its value is WIN-218****LQHR，DESKTOP-L3***F, it’s highly likely that the target is Windows.
- If you are able to use the banner information on other ports to determine the target is Windows, you should then be able to use ntlmssp.version (Kernel build version) to derive the Windows Edition version.
- Always try to use SMB v1 request whether the server side supports it or not; as from v1’s reponse, you can get the OS information in clear text directly; if SMB v1 fails, then try to send v2 requests;
- No matter if it’s SMBv1 or SMBv2, you shall always parse responses and obtain values in key fields.
OS recognition is such an important first step of a pentest or vulnerability scanning. We hope sharing this information can make your development work easier and help you reduce false positives.