Posts Tagged ‘windows xp sp3’

Wireshark: Eliminating NBNS

March 14, 2011 Leave a comment

If you work with wireshark its good to sniff around on all your vlans once and then. You might be surprised what you’ll find. Today I checked some student vlans and found alot of machines that were very “chatty”.  Also with server names that do not exist anymore in the network.

It seems like alot of NBNS packets on the wire. The NetBIOS Name Service (NBNS) translates human-readable names to IP addresses (much like DNS) and in modern networks its not needed anymore. Since we are running a Windows 2008 R2 network with Windows XP SP3 workstations and do NOT have applications that depend on it we are going to eliminate it.

On the workstations

In the advanced properties of the network card you can change the NetBIOS value.

By default its Enabled and controlled via the DHCP scope. Lets disable this value and add an extra option to the DHCP scopes. You need to add option 001 to the scope with a value of 0x2.

On the server side

If you are absolutely sure that you don’t need NetBIOS/WINS and you do not have any applications that rely on it you can elimate NetBIOS by changing the NetBIOS property on the Nics. When completed you can fire up Wireshark again and check if any NBNS traffic is still on the wire.


Landesk : Scanning for custom registry changes on clients with LDMS SP2

February 19, 2011 Leave a comment

Today I am playing around with our Landesk LDMS 9 SP2 system and I was wondering if it was possible to scan for custom registry keys on the client machine. In my case I needed to know if all Windows XP SP3 machines were configured to allow NTLMv2 traffic only (info here). The key we are looking for is :

HHEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa….     with value: lmcompatibilitylevel

This is the correct procedure to implement this:

1. On the Landesk Core server browse to and open <servername>\Program Files (x86)\LANDesk\ManagementSuite\ldlogon\LdAppl3.Template

2. Go to the [Registry Info] section and add the following entry and save the file:

KEY=HKLM, SYSTEM\CurrentControlSet\Control\Lsa, lmcompatibilitylevel, Custom Data – Network – LmCompatibilityLevel

3. Start the Landesk Management Console and go to: Tools – Reporting/Monitoring – Manage Software List

4. Click on: Make available to clients to ensure that the Landesk Core server makes this change available to the clients

5. In the Landesk Management Console go to: Configure – Services

6. Click on the Inventory tab and choose Unknown Items

7. Click on the Computer.Custom Data.Network.LmCompatibilityLevel rule and click on: Allow

8. Now you will get a message that the Inventory Service should be restarted. Select: Yes

9. Now you can force an inventory scan on the client or just wait for the automatic scheduled scan.

10. If the scan is complete you can Rightmouseclick on the client machine and select inventory. Browse to the newly created entry.

There is another great tool that can be usefull as well. Its called LDMS_Client and created by Droppedpackets and can be found here. I hope you found this usefull and feel free to comment.

Wireshark: Determining a SMB and NTLM version in a Windows environment

February 3, 2011 4 comments

The last few days I am playing around with wireshark and I must say I enjoy working with this program. It has saved the day for me a couple of times by giving me information that is only retrieved by looking at packet level. In this article I was looking at SMB and NTLM traffic in a windows environment. I noticed that our XP based network was running NTLMv1 that is considered unsecure. Let’s change this fast !


NTLM over a Server Message Block (SMB) transport is one of the most common uses of NTLM authentication and encryption. Kerberos Protocol Extensions (KILE) is the preferred authentication method of an SMB session in Windows Server operating system and Windows Client operating systems. However, when a client attempts to authenticate to an SMB server using the KILE protocol and fails, it can attempt to authenticate with NTLM.

The NT LAN Manager (NTLM) Authentication Protocol is used in Microsoft Windows Networks for authentication between clients and servers.  NTLM is used by application protocols to authenticate remote users and, optionally, to provide session security when requested by the application. There are two major variants of the NTLM authentication protocol: the connection-oriented variant and the connectionless variant. Each of these variants has three versions: LM, NTLMv1, and NTLMv2.  In addition to authentication, the NTLM protocol optionally provides for session security—specifically message integrity and confidentiality through signing and sealing functions in NTLM. For more in depth information I urge you to read this Microsoft NTLM documentation. The following picture will show a protocol flow of NTLM and Simple and Protected Generic Security Service Application Program Interface Negotiation Mechanism (SPNEGO) authentication of an SMB session.

Step 1 and 2 – The SMB protocol negotiates protocol-specific options using the SMB_COM_NEGOTIATE request and response messages. The client will send its supported dialects and the server will respond with the highest possible dialect. The following dialect values are possible (older dialects are excluded here):

Step 3 – The client sends an SMB_COM_SESSION_SETUP_ANDX request message. Assuming that NTLM authentication is negotiated, within this message an NTLM NEGOTIATE_MESSAGE is embedded.

Step 4 – The server responds with an SMB_COM_SESSION_SETUP_ANDX response message within which an NTLM CHALLENGE_MESSAGE is embedded. The message includes an 8-byte random number, called a “challenge”, that the server generates and sends in the ServerChallenge field of the message.

Step 5 – The client extracts the ServerChallenge field from the NTLM CHALLENGE_MESSAGE and sends an NTLM AUTHENTICATE_MESSAGE to the server (embedded in an SMB_COM_SESSION_SETUP_ANDX request message). If the challenge and the response prove that the client knows the user’s password, the authentication succeeds and the client’s security context is now established on the server.

Step 6 – The server sends a success message embedded in an SMB_COM_SESSION_SETUP_ANDX response message.


This article will only show how to find out which SMB and NTLM versions are used on your windows servers and windows clients while using Wireshark. This is very useful to know because it has a great impact on your security. There are many documents on the internet that show that LM and NTLMv1 are insecure these days therefore we need to ensure that these authentication methods are not allowed inside the windows network. Thus we need to ensure that NTLMv2 only is allowed. This behavior can be changed on windows servers and clients at the following registry key:


REG_DWORD Valuename: lmcompatibilitylevel

The following values can be used:

So you’re actually configuring a minimum security level here. Now let’s take a look which values are used by default per OS type:

We can conclude that if we have an XP client and a windows 2008 R2 server with default settings it will always use NTLMv1. If we use an Windows 7 or Vista client and a windows 2008 R2 server it will use NTLMv2. Lets fire up Wireshark and take a look what’s happening “on the wire”.

Windows XP client and Windows 2008 R2 server (default settings)

In this scenario a Windows XP client ( tries to connect to a Windows 2008 R2 Server ( share. Let’s take a look at the SMB negotiate protocol request:

The highest possible dialect that the Windows XP client can speak is NT LM 0.12. Thus SMB v1.0. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of SMB v1.0 (NT LM 0.12) and this is used to access the share. Let’s take a look which version of NTLM it uses by looking at the Session setup andX request: NTLMSSP_AUTH packet.

There is no NTMLv2 section here so it is using NTLMv1. Thus insecure !!

Windows 7 client and Windows 2008 R2 server (default settings)

In this scenario a Windows 7 Client ( tries to connect to a Windows 2008 R2 Server ( share. Let’s take a look at the SMB negotiate protocol request:

The highest possible dialect that the Windows 7 client can speak is SMB 2.???. Thus SMB v2.0 Wildcard. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of 0x02ff (hexadecimal value for SMBv2.0 wildcard). You can also see that the protocol column switches from SMB to SMB2. Now the Windows 7 clients needs to know which SMB2 version will be used for communication. . Let’s take a look at the new SMB2 negotiate protocol request:

The highest possible SMB2 dialect that the Windows 7 client can speak is more specific now. It can use 0x0202 or 0x0210. Thus SMB v2.002 or SMB v2.1. Let’s take a look how the Windows 2008 R2 server will respond:

The Windows 2008 R2 server responds its capable of 0x210 (hexadecimal value for SMBv2.1) and this is used to access the share. Let’s take a look which version of NTLM it uses by looking at the Session setupRequest, NTLMSSP_AUTH packet.

The picture clearly shows that there is an NTLMv2 response.

Is there a quicker way to determine NTLMv1 or NTLMv2 authentication? Yes. We can do this by entering ntlmssp.ntlmv2response into the filter field. Wireshark will filter out ntlmv2 traffic only.

Back to our little problem. We have a network running with XP clients and windows 2008 R2 server with default settings on GPO level. We saw that NTLMv1 will be used for authentication and thus insecure. We need to change this so the XP machines will authenticate by using NTLMv2. We can achieve this by change the Lmcompatibilitylevel value to 5. The best way to achieve this is by placing all Windows XP clients into an OU and configure a computer GPO policy.

Before you change the server side to Lmcompatibilitylevel value 5 you must be absolutely sure that every Windows XP Client uses NTLMv2 or your phone will start ringing very often. You can achieve this by changing the default domain controllers policy or by placing a GPO on an OU with servers. When the server and client side are changed to NTLMv2 you have achieved the highest NTLM authentication possible. Thus the most secure NTLM form possible. This ends my article about Determining a SMB and NTLM version in a windows environment. I hope it’s useful somehow and feel free to comment.

%d bloggers like this: