Purging Old NT Security Protocols

Article
02/02/2012

Hi folks, Ned here again (with some friends). Everyone knows that Kerberos is Microsoft’s preeminent security protocol and that NTLM is both inefficient and, in some iterations, not strong enough to avoid concerted attack. NTLM V2 using complex passwords stands up well to common hash cracking tools like Cain and Abel, Ophcrack, or John the Ripper. On the other hand, NTLM V1 is defeated far faster and LM is effectively no protection at all.

I discussed NTLM auditing years ago, when Windows 7 and Windows Server 2008 R2 introduced the concept of NTLM blocking. That article was for well-controlled environments where you thought that there was some chance of disabling NTLM – only modern clients and servers, the latest applications, and Active Directory. In a few other articles, I gave some further details on the limitations of the Windows auditing system logging. It turns out that while we’re ok at telling when NTLM was used, we’re not great at describing which flavor. For instance, Windows Server 2008+security auditing can tell you about the NTLM version through the 4624 event that states a Package Name (NTLM only): NTLM V1 or Package Name (NTLM only): NTLM V2, but all prior operating systems cannot. None of the older auditing can tell you if LM is used either. Windows Server 2008 R2 NTLM auditing only shows you NTLM usage in general.

Today the troika of Dave, Jonathan, and Ned are here to help you discover which computers and applications are using NTLM V1 and LM security, regardless of your operating system. It’s safe to say that some people aren’t going to like our answers or how much work this entails, but that’s life; when LM security was created as part of LAN Manager and OS/2 by Microsoft and IBM, Dave and I were in grade school and Jonathan was only 48.

If you need to keep using NTLM V2 and simply want to hunt down the less secure precursors, this should help.

Finding NTLM V1 and LM Usage via network captures

The only universal, OS-agnostic way you can tell which clients are sending NTLMv1 and LM challenges is by examining a network trace taken from destination computers. Using Netmon 3.4 or another network capture tool, look for packets with a negotiated NTLM security mechanism.

This first example is with LMCompatibilityLevel set to 0 on clients. This example is an SMB session request packet, specifying NTLM authentication.

Here is the SMB SESSION SETUP request, which specifies the security token mechanism:

Frame: Number = 15, Captured Frame Length = 220, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-05-B4-44],SourceAddress:[00-15-5D-05-B4-49]

+ Ipv4: Src = 10.10.10.20, Dest = 10.10.10.27, Next Protocol = TCP, Packet ID = 747, Total IP Length = 206

+ Tcp: Flags=...AP..., SrcPort=49235, DstPort=Microsoft-DS(445), PayloadLen=166, Seq=2204022974 - 2204023140, Ack=820542383, Win=32724 (scale factor 0x2) = 130896

+ SMBOverTCP: Length = 162

- SMB2: C SESSION SETUP (0x1)

SMBIdentifier: SMB

+ SMB2Header: C SESSION SETUP (0x1),TID=0x0000, MID=0x0002, PID=0xFEFF, SID=0x0000

- CSessionSetup:

StructureSize: 25 (0x19)

VcNumber: 0 (0x0)

+ SecurityMode: 1 (0x1)

+ Capabilities: 0x1

Channel: 0 (0x0)

SecurityBufferOffset: 88 (0x58)

SecurityBufferLength: 74 (0x4A)

PreviousSessionId: 0 (0x0)

- securityBlob:

- GSSAPI:

- InitialContextToken:

+ ApplicationHeader:

+ ThisMech: SpnegoToken (1.3.6.1.5.5.2)

- InnerContextToken: 0x1

- SpnegoToken: 0x1

+ ChoiceTag:

- NegTokenInit:

+ SequenceHeader:

+ Tag0:

+ MechTypes: Prefer NLMP (1.3.6.1.4.1.311.2.2.10)

+ Tag2:

+ OctetStringHeader:

-MechToken: NTLM NEGOTIATE MESSAGE

- NLMP: NTLM NEGOTIATE MESSAGE

Signature: NTLMSSP

MessageType: Negotiate Message (0x00000001)

+ NegotiateFlags: 0xE2088297 (NTLM v2128-bit encryption, Always Sign)

+ DomainNameFields: Length: 0, Offset: 0

+ WorkstationFields: Length: 0, Offset: 0

+ Version: Windows 6.1 Build 7601 NLMPv15

Next, the server sends its NTLM challenge back to the client:

Frame: Number = 16, Captured Frame Length = 447, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-05-B4-49],SourceAddress:[00-15-5D-05-B4-44]

+ Ipv4: Src = 10.10.10.27, Dest = 10.10.10.20, Next Protocol = TCP, Packet ID = 24310, Total IP Length = 433

+ Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=49235, PayloadLen=393, Seq=820542383 - 820542776, Ack=2204023140, Win=512 (scale factor 0x8) = 131072

+ SMBOverTCP: Length = 389

- SMB2: R - NT Status: System - Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED SESSION SETUP (0x1), SessionFlags=0x0

SMBIdentifier: SMB

+ SMB2Header: R SESSION SETUP (0x1),TID=0x0000, MID=0x0002, PID=0xFEFF, SID=0x0019

- RSessionSetup:

StructureSize: 9 (0x9)

+ SessionFlags: 0x0

SecurityBufferOffset: 72 (0x48)

SecurityBufferLength: 317 (0x13D)

- securityBlob:

- GSSAPI:

- NegotiationToken:

+ ChoiceTag:

- NegTokenResp:

+ SequenceHeader:

+ Tag0:

+ NegState: accept-incomplete (1)

+ Tag1:

+ SupportedMech: NLMP (1.3.6.1.4.1.311.2.2.10)

+ Tag2:

+ OctetStringHeader:

- ResponseToken: NTLM CHALLENGE MESSAGE

- NLMP: NTLM CHALLENGE MESSAGE

Signature: NTLMSSP

MessageType: Challenge Message (0x00000002)

+ TargetNameFields: Length: 12, Offset: 56

+ NegotiateFlags: 0xE2898215 (NTLM v2128-bit encryption, Always Sign)

+ ServerChallenge: 67F9C5F851F2CD73

Reserved: Binary Large Object (8 Bytes)

+ TargetInfoFields: Length: 214, Offset: 68

+ Version: Windows 6.1 Build 7601 NLMPv15

TargetNameString: CORP01

+ AvPairs: 7 pairs

The client calculates the response to the challenge, using the various available hashes of the password. Note how this response includes both LM and NTLMv1 challenge responses.

Frame: Number = 17, Captured Frame Length = 401, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-05-B4-44],SourceAddress:[00-15-5D-05-B4-49]

+ Ipv4: Src = 10.10.10.20, Dest = 10.10.10.27, Next Protocol = TCP, Packet ID = 748, Total IP Length = 387

+ Tcp: Flags=...AP..., SrcPort=49235, DstPort=Microsoft-DS(445), PayloadLen=347, Seq=2204023140 - 2204023487, Ack=820542776, Win=32625 (scale factor 0x2) = 130500

+ SMBOverTCP: Length = 343

- SMB2: C SESSION SETUP (0x1)

SMBIdentifier: SMB

+ SMB2Header: C SESSION SETUP (0x1),TID=0x0000, MID=0x0003, PID=0xFEFF, SID=0x0019

- CSessionSetup:

StructureSize: 25 (0x19)

VcNumber: 0 (0x0)

+ SecurityMode: 1 (0x1)

+ Capabilities: 0x1

Channel: 0 (0x0)

SecurityBufferOffset: 88 (0x58)

SecurityBufferLength: 255 (0xFF)

PreviousSessionId: 0 (0x0)

- securityBlob:

- GSSAPI:

- NegotiationToken:

+ ChoiceTag:

- NegTokenResp:

+ SequenceHeader:

+ Tag0:

+ NegState: accept-incomplete (1)

+ Tag2:

+ OctetStringHeader:

- ResponseToken: NTLM AUTHENTICATE MESSAGEVersion:v1, Domain: CORP01, User: Administrator, Workstation: CONTOSO-CLI-01

- NLMP: NTLM AUTHENTICATE MESSAGEVersion:v1, Domain: CORP01, User: Administrator, Workstation: CONTOSO-CLI-01

Signature: NTLMSSP

MessageType: Authenticate Message (0x00000003)

+ LmChallengeResponseFields: Length: 24, Offset: 154

+ NtChallengeResponseFields: Length: 24, Offset: 178

+ DomainNameFields: Length: 12, Offset: 88

+ UserNameFields: Length: 26, Offset: 100

+ WorkstationFields: Length: 28, Offset: 126

+ EncryptedRandomSessionKeyFields: Length: 16, Offset: 202

+ NegotiateFlags: 0xE2888215 (NTLM v2128-bit encryption, Always Sign)

+ Version: Windows 6.1 Build 7601 NLMPv15

+ MessageIntegrityCheckNotPresent: 6243C42AF68F9DFE30BD31BFC722B4C0

DomainNameString: CORP01

UserNameString: Administrator

WorkstationString: CONTOSO-CLI-01

+ LmChallengeResponseStruct: 3995E087245B6F7100000000000000000000000000000000

+ NTLMV1ChallengeResponse: B0751BDCB116BA5737A51962328D5CCD19EEBEBB15A69B1E

+ SessionKeyString: 397DACB158C9F10EF4903F10D4CBE032

+ Tag3:

+ OctetStringHeader:

+ MechListMic: Version: 1

The server then responds with successful negotiation state:

Frame: Number = 18, Captured Frame Length = 159, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-05-B4-49],SourceAddress:[00-15-5D-05-B4-44]

+ Ipv4: Src = 10.10.10.27, Dest = 10.10.10.20, Next Protocol = TCP, Packet ID = 24312, Total IP Length = 145

+ Tcp: Flags=...AP..., SrcPort=Microsoft-DS(445), DstPort=49235, PayloadLen=105, Seq=820542776 - 820542881, Ack=2204023487, Win=510 (scale factor 0x8) = 130560

+ SMBOverTCP: Length = 101

- SMB2: R SESSION SETUP (0x1), SessionFlags=0x0

SMBIdentifier: SMB

+ SMB2Header: R SESSION SETUP (0x1),TID=0x0000, MID=0x0003, PID=0xFEFF, SID=0x0019

- RSessionSetup:

StructureSize: 9 (0x9)

+ SessionFlags: 0x0

SecurityBufferOffset: 72 (0x48)

SecurityBufferLength: 29 (0x1D)

- securityBlob:

- GSSAPI:

- NegotiationToken:

+ ChoiceTag:

- NegTokenResp:

+ SequenceHeader:

+ Tag0:

+NegState: accept-completed (0)

+ Tag3:

+ OctetStringHeader:

+ MechListMic: Version: 1

To contrast this, consider the challenge response packet when LMCompatibility is set to 4 or 5 on the client (meaning it is not allowed to send anything but NTLM V2). The LM response is null, while the NTLMv1 response isn't included at all.

Frame: Number = 17, Captured Frame Length = 763, MediaType = ETHERNET

+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-05-B4-44],SourceAddress:[00-15-5D-05-B4-49]

+ Ipv4: Src = 10.10.10.20, Dest = 10.10.10.27, Next Protocol = TCP, Packet ID = 844, Total IP Length = 749

+ Tcp: Flags=...AP..., SrcPort=49231, DstPort=Microsoft-DS(445), PayloadLen=709, Seq=4045369997 - 4045370706, Ack=881301203, Win=32625 (scale factor 0x2) = 130500

+ SMBOverTCP: Length = 705

- SMB2: C SESSION SETUP (0x1)

SMBIdentifier: SMB

+ SMB2Header: C SESSION SETUP (0x1),TID=0x0000, MID=0x0003, PID=0xFEFF, SID=0x0021

- CSessionSetup:

StructureSize: 25 (0x19)

VcNumber: 0 (0x0)

+ SecurityMode: 1 (0x1)

+ Capabilities: 0x1

Channel: 0 (0x0)

SecurityBufferOffset: 88 (0x58)

SecurityBufferLength: 617 (0x269)

PreviousSessionId: 0 (0x0)

- securityBlob:

- GSSAPI:

- NegotiationToken:

+ ChoiceTag:

- NegTokenResp:

+ SequenceHeader:

+ Tag0:

+ NegState: accept-incomplete (1)

+ Tag2:

+ OctetStringHeader:

- ResponseToken: NTLM AUTHENTICATE MESSAGEVersion:v2, Domain: CORP01, User: Administrator, Workstation: CONTOSO-CLI-01

- NLMP: NTLM AUTHENTICATE MESSAGEVersion:v2, Domain: CORP01, User: Administrator, Workstation: CONTOSO-CLI-01

Signature: NTLMSSP

MessageType: Authenticate Message (0x00000003)

+ LmChallengeResponseFields: Length: 24, Offset: 154

+ NtChallengeResponseFields: Length: 382, Offset: 178

+ DomainNameFields: Length: 12, Offset: 88

+ UserNameFields: Length: 26, Offset: 100

+ WorkstationFields: Length: 28, Offset: 126

+ EncryptedRandomSessionKeyFields: Length: 16, Offset: 560

+ NegotiateFlags: 0xE2888215 (NTLM v2128-bit encryption, Always Sign)

+ Version: Windows 6.1 Build 7601 NLMPv15

+ MessageIntegrityCheck: 2B69C069DD922D4A841D0EC43939DF0F

DomainNameString: CORP01

UserNameString: Administrator

WorkstationString: CONTOSO-CLI-01

+ LmChallengeResponseStruct: 000000000000000000000000000000000000000000000000

+ NTLMV2ChallengeResponse: CD22D7CC09140E02C3D8A5AB623899A8

+ SessionKeyString: AF31EDFAAF8F38D1900D7FBBDCB43760

+ Tag3:

+ OctetStringHeader:

+ MechListMic: Version: 1

By taking traces and filtering on the NTLMV1ChallengeResponse field, you find those hosts that are sending NTLMv1 responses and determine if you need to upgrade them or if they simply have the wrong LMcompatibility values set through security policy.

Finding LM usage via Netlogon debug logs

If you just want to detect LM authentication and not looking to spend time in network captures, you can instead enable Netlogon logging on all DCs and servers in the environment.

Nltest /dbflag:2080ffff
net stop NetLogon
net start NetLogon

This creates the netlogon.log in the C:\Windows\Debug folder and it can grow to a maximum of 20 Mb by default. At that point, the server renames the file to netlogon.bak and a new netlogon.log file started. At 20Mb, the server deletes netlogon.bak, renames the netlogon.log to netlogon.bak, and a new netlogon.log file started. To make these log files larger, you can use a registry entry or group policy:

Registry

Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value Name: MaximumLogFileSize
Value Type: REG_DWORD
Value Data: <maximum log file size in bytes>

Group Policy

\Computer Configuration\Administrative Templates\System\Net Logon\Maximum Log File Size

You aren't trying to capture all data here - just useful samples - but if they wrap so much that you're unsure if they are accurate at all, increasing size is a good idea. As an alternative, you can create a scheduled task that runs ONSTART or a computer startup script. Either of them can use this batch file to make backups of the netlogon log by date/time and the computer name:

REM Sample script to copy the netlogon.bak to a netlogon_DATETIME_COMPUTERNAME.log backup form every 5 minutes

:start
if exist %windir%\debug\netlogon.bak goto copylog

:copylog_return
sleep 300
goto start

:copylog
for /f "tokens=1-7 delims=/:., " %%a in ("%DATE% %TIME%") do (set DATETIME=%%a-%%b-%%c_%%d-%%e-%%f)
copy /v %windir%\debug\netlogon.bak %windir%\debug\netlogon_%DATETIME%_%COMPUTERNAME%.log
if %ERRORLEVEL% EQU 0 del %windir%\debug\netlogon.bak
goto copylog_return

Periodically, gather all of the NetLogon logs from the DCs and servers and place them in a single folder. Once you have assembled the NetLogon logs into a single spot, you may then use the following LogParser command from that folder to parse them all for a count of unique UAS logons to the domain controller by workstation:

Logparser.exe "SELECT TO_UPPERCASE(EXTRACT_SUFFIX(TEXT,0,'returns ')) AS ERR, TO_UPPERCASE (extract_prefix(extract_suffix(TEXT, 0, 'NetrLogonUasLogon of '), 0, 'from ')) as USER, TO_UPPERCASE (extract_prefix(extract_suffix(TEXT, 0, 'from '), 0, 'returns ')) as WORKSTATION, COUNT(*) FROM '*netlogon.*' WHERE INDEX_OF(TO_UPPERCASE (TEXT),'LOGON') >0 AND INDEX_OF(TO_UPPERCASE(TEXT),'RETURNS') >0 AND INDEX_OF(TO_UPPERCASE(TEXT),'NETRLOGONUASLOGON') >0 GROUP BY ERR, USER, WORKSTATION ORDER BY COUNT(*) DESC" -i:TEXTLINE -rtp:-1 >UASLOGON_USER_BY_WORKSTATION.txt

UASLOGON_USER_BY_WORKSTATION.txt contains the unique computers and counts. LogParser is available for download from here.

FIND and PowerShell are options here as well. The simplest approach is just to return the lines, perhaps into a text file for later sorting in say, Excel (which is very fast at sorting and allows you to organize your data).

I'll wager someone in the comments will take on the rather boring challenge of exactly duplicating what LogParser does. I didn't have the energy this time around. :)

Final thoughts

Microsoft stopped using LM after Windows 95/98/ME. If you do find specific LM-only usage and you don't have any (unsupported) Win9X computers, this is a third party application. A really heinous one.

All supported versions of Windows obey the LMCompatibility registry setting, and can use NTLMv2 just as easily as NTLMv1. At that point, analyzing network traces just becomes useful for tracking down those hosts that have applied the policy, but have not yet been rebooted. Considering how unsafe LM and NTLMv1 are, enabling NoLMHash and LMCompatibility 4 or 5 on all computers may be a faster alternative to auditing. It could cause some temporary outages, but would definitely catch anyone requiring unsafe protocols. There's no better auditing that a complaining application administrator.

Finally, do not limit your NTLM inventory to domain controllers and file or application servers. A comprehensive project requires you examine all computers in the environment, as even a Windows XP workstation can be a "server" for some application. Use a multi-pronged approach, where you also inventory operating systems through network probing - if you have Windows 95 or old SAMBA lying around somewhere on a shop floor, they are almost guaranteed to use insecure protocols.

Until next time,

- Ned “and Dave and Jonathan and Jonathan's in-home elderly care nurse” Pyle

Comments

Anonymous
February 03, 2012
The comment has been removed
Anonymous
February 03, 2012
If I understand this post correctly the only way to detect if NTLMV1 is in use is to use network captures whereas LM usage can be detected through the netlogon.log. Have I got that right or am I just confused?
Anonymous
February 03, 2012
Correct, unfortunately. We could not find any indicator of NTLMv1 in the netlogon log instrumentation. And we tried like the dickens...
Anonymous
February 03, 2012
If only Microsoft would let us set the min. length password to 15; then LM couldn't be used in the env at all. (silly backwards-compatability)
Anonymous
February 03, 2012
The comment has been removed
Anonymous
February 03, 2012
Indeed...
Anonymous
February 03, 2012
Does communication fail if the client is set to send NTLMv2 only(refuse LM&NTLMv1) and the server is set to only handle LM&NTLMv1? Would it be correct to say the client/server negotiation takes the lowest available Mechanism of the Client? Does it fail at the point of negotiation? Is it the client then that terminates the connection?
Anonymous
February 03, 2012
LA - No, because you cannot configure a server to ignore NTLMv2. There are two parties to any authentication "session" -- the one doing the authenticating and the one being authenticated to. Regardless of whether the OS is a workstation or server, we can call the first party the client and the second party the server, and it is possible for the same computer to fulfill both roles at different times, ok? With that in mind, it is helpful to think of the first four LM authentication levels as "client only." 0 - Send LM & NTLM responses 1 - Send LM & NTLM - use NTLMv2 session security if negotiated 2 - Send NTLM response only 3 - Send NTLMv2 response only Theses levels control what type of response is sent in answer to a server's challenge. At these levels, the behavior of the server doesn't change -- it will accept any of the responses as valid -- LM, NTLM, or NTLMv2. Only the behavior of the client is changed, by controlling what types of responses the to the challenge will be calculated and returned to the server. When the LM Authentication level is set to one of these first values on a particular Windows machine, the behavior of Windows when it acts as an authentication client will be affected, but the behavior of Windows when it is the authentication server will not. Clear? The last two LM authentication levels do affect the behavior of the server: 4 - Send NTLMv2 response only. Refuse LM 5 - Send NTLMv2 response only. Refuse LM & NTLM These last two settings combine the client behavior of level 4, plus the control what types of responses a server will accept. At level 5, if the client does not include an NTLMv2 response then authentication to the server would fail. Does this help? Jonathan
Anonymous
February 03, 2012
That clears it up. It helped when you seperated the levels out by client and client/server. Nice work guys, thanks.
Anonymous
March 26, 2012
The comment has been removed
Anonymous
March 29, 2012
Hi Mike, Unfortunately not - we don't log the LM (the packages you describe are NTLM only versus Negotiate, which might mean NTLM or Kerberos or others, depending on how negotiation resulted). But I'm not sure what the "-" would be in this case. I'm travelling right now but I'll take a look in source when I get back in the office last week. If I forget come find me. :)

Share via

Purging Old NT Security Protocols

Comments

Additional resources