Cyber attackers frequently use legacy technology as part of their attack strategies, targeting organizations that have yet to implement mitigations or upgrade obsolete components. In an Active Directory environment, one such component is legacy protocols, which attackers can use to gain access to Active Directory.
While patching (or even virtual patching) might help address obsolete components, most legacy components have been thoroughly evaluated by adversaries to determine whether they should be replaced with a newer version or disabled entirely. That’s the case with Active Directory legacy protocols, so to help you secure your Active Directory environment, we’ve created a script to help you ensure that legacy protocols are disabled.
Your primary goal in securing Active Directory infrastructure is to reduce the attack surface. There are numerous other issues that must be considered in order to reduce the attack surface for Active Directory, but legacy protocols is an important one identified recently. We’ll explain legacy protocols in Active Directory and then look at how to check whether they are disabled or not on all domain controllers in an Active Directory forest.
Also read: How to Tell if Active Directory is Compromised
What AD Legacy Protocols Should Be Disabled
Credential theft remains relatively easy to accomplish if legacy protocol exposure isn’t reduced, as most attackers will try to exploit vulnerabilities associated with legacy protocols and their components. Microsoft has advised that the following legacy protocols be disabled in newer versions of operating systems:
- TLS Version 1.1
- NTLM Version 1.1 or LAN Manager
- SMB Version 1
Considerations Before Disabling Legacy Protocols
It is important to understand that Active Directory applications use these protocols, so be sure to perform a thorough evaluation of Active Directory applications that use these protocols before disabling any of them. If an important application is still using any of these protocols, do not disable it unless you understand the consequences. And before disabling support for legacy protocols, you must upgrade all devices and applications to use newer protocol versions. We explain how to do so below.
Disabling TLS Version 1.1
TLS is a nearly two decades old protocol and has been identified as vulnerable to attacks like BEAST and POODLE mechanisms. There are several disadvantages associated with the TLS 1.1 protocol:
- As is the problem with all the legacy protocols, TLS 1.1 supports weak cryptography, which is a security risk as there are tools available to decrypt packets with weak cryptography.
- TLS 1.1 also doesn’t help in rendering modern connections securely.
- TLS 1.0 has the flaw of supporting insufficient cryptography. TLS 1.2 has surpassed TLS 1.1 in most software implementations, making the latter relatively uncommon. However, from the standpoint of an attacker, any use of TLS 1.1 becomes a potential weapon in their arsenal.
Azure tip: It should be noted that Microsoft has already disabled PowerShell’s support for the TLS 1.1 protocol. If you attempt to run a PowerShell script to connect to Azure, an error message will appear indicating that the TLS 1.1 protocol must be disabled before the script can be executed. More information about the TLS disabling statement can be found here: Enable TLS 1.2 support as Azure AD TLS 1.0/1.1 is deprecated – Active Directory | Microsoft Learn.
Identifying if devices and applications still use TLS Version 1.1
It is difficult to determine which .NET applications are using the TLS 1.1 protocol in your environment unless you use a combination of techniques such as enabling Secure Channel logging on the domain controller, using a packet capture tool, or most likely using Wireshark.
To determine whether any of your .NET applications are still using the TLS 1.1 protocol in your environment via the Secure Channel method, enable Secure Channel logging on domain controllers. Look for Event ID 36880 after enabling Secure Channel logging, which will log the protocol version used to establish the connection. To understand the IP of the client that attempted to negotiate the lower version of the TLS 1.1 protocol, you will need to correlate multiple events.
In most cases, you can check with the application vendor to see if the application is still using the TLS 1.1 protocol. If the application is designed in-house, check with the development team to disable TLS 1.1 support and use the newer version for better security.
Disabling NTLM Version 1.1 or LAN Manager
When doing Active Directory security assessments for customers, I often find out that customers still utilize the legacy NTLM Version 1 protocol for their applications, or they have just left it enabled even if the applications in their environment are not using the NTML Version 1.0 protocol at all.
The NTLM protocol is mostly used by the devices and applications running in your Active Directory environments. Note that NTLM was designed to perform authentication based on the challenge/response-based authentication system in which a client sends the plaintext username to the domain controller. The domain controller, when receiving the plaintext username from the client, generates a random number called a “challenge” and sends it back to the client. The client uses password hash to encrypt the challenge and sends it back to the domain controller as a “response.”
The catch here is that if a client is using NTLM 1.1, the client takes the “challenge” received from the server as is, adds the client nonce, encrypts it using DES encryption, and sends it back to the server. On the other hand, if the client uses NTML version 2.0, the client adds other parameters, such as client nonce + server nonce + timestamp + username + target. The difference between NTML Version 1 and NTLM Version 2 lies in the parameters used when sending the response back to the domain controller. These additional parameters can help you protect the conversion between a client and a server.
The domain controller queries the SAM database and compares the “challenge” stored in the database and received from the client. If the data matches, then the client is allowed to authenticate.
Identifying if devices and applications still use NTLM version 1.0
To check if any of your devices and applications are still using the NTLM Version 1.0 protocol in your environment, look on domain controllers for Event ID 4624 – An account was successfully logged on. Open the event and find the section “Detailed Authentication Information” in which you can see the “Authentication Package” that is in use. If the “Package Name” says “LM or NTLM v1,” that means the device or application that authenticated to the domain controller used the NTLM Version 1.0 protocol. That device or application needs to be upgraded to NTML Version 2.0 for better security.
Disabling SMB Version 1.0
Another legacy protocol that must be disabled in an Active Directory environment is SMB Version 1.0. SMB 1.0 is an old protocol that was designed to allow devices to communicate with one another across various networking layers. To access SMB shares, for example, an SMB client can connect to a server running SMB.
It is important to note, however, that SMB 1.0 is a 30-year-old protocol that has seen many improvements over the SMB protocol family. We now have SMB 3.0, which supports encryption and signing using weak hashing methods. Because of increasing cybersecurity threats and Active Directory being the primary target for attackers, it is recommended that domain controllers disable SMB 1.0 completely and use SMB 2.0 or higher. However, before disabling SMB 1.0, devices that are still communicating over the SMB 1.0 protocol must be identified.
Identifying if devices/applications still use SMB 1.0 protocol
You must examine SMB sessions on all of your domain controllers to determine which version the client is using when connecting to the domain controllers via SMB. The SMB version used between the client and the domain controller (server) will be the most recent version that both support. For example, if a Windows 8 machine communicates with a Windows 2012 server, the SMB 3.0 protocol will be used, whereas if a lower version of Windows client communicates with a Windows server and SMB 1.0 is enabled, the SMB 1.0 protocol will be used. Log on to the Domain Controller and then run the Get-SmbConnection command to check the SMB sessions. All connections and “Dialect” will be listed by the Get-SmbConnection command. The “Dialect” field indicates whether clients are requesting connections via SMB 1.0, SMB 2.0, or SMB 3.0.
PowerShell Script to Check for Legacy Protocols on Domain Controllers
The PowerShell script below can be used to verify that all of the above-mentioned protocols are disabled on domain controllers. When the PowerShell script is finished, it generates a CSV file with the status of all domain controllers for each protocol, which can be seen in the respective protocol column.
Script Requirements: Please ensure that you meet all of the requirements listed below before running the script.
- Run the script using a Domain Admin account, as the script will connect to each domain controller in an Active Directory domain to check registry entries and then report the status of the protocols.
- Make sure the computer is joined to the domain.
- Make sure the C:\Temp directory exists on the computer where the script is executed.
$ResultFile = "C:\Temp\LegacyProtocolsStatus.CSV"
Remove-Item $ResultFile -ErrorAction SilentlyContinue
$STR = "Domain Controller, Connection Status, TLS 1.1 Status, SMB 1 Status, NTLM Status"
Add-Content $ResultFile $STR
$GDCList = "C:\Temp\AllDCs.TXT"
Remove-Item $GDCList -ErrorAction Continue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName, Domain, Forest, IPv4Address, Site
foreach ($Item in $R)
{
Add-Content $GDCList $Item.HostName
}
Foreach ($ItemName in Get-Content "$GDCList")
{
$TLStatus = "Unknown"
$SMBStatus = "Unknown"
$NTLMStatus = "Unknow"
Write-Host "Checking Connection for Domain Controller: $ItemName"
$Error.Clear()
$ConnectionCheck = Get-WMIObject Win32_Service -computer $ItemName
IF ($Error.Count -ne 0)
{
$STR = $ItemName + ",Connection Error" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
Add-Content $ResultFile $STR
}
else
{
Write-Host "Connection Success!
Write-Host "Checking TLS 1.1. Status..."
$result = Invoke-Command -ComputerName $ItemName -ScriptBlock {
$supported = [Net.ServicePointManager]::SecurityProtocol
[PsCustomObject]@{
SystemDefault = [bool]($supported -eq 0)
Tls11 = [bool]($supported -band 768)
}
}
$TLStatus = $result.Tls11
Write-Host "Checking SMB 1.0 Status..."
$ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters"
$ThisRegEntry = "SMB1"
$Error.Clear()
$dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\LANManServer\Parameters' -Name "SMB1" }
IF ($Error.Count -eq 0)
{
$CheckValue = $dbs.SMB1
IF ($CheckValue -ne "0")
{
$SMBStatus = "Enabled"
}
else
{
$SMBStatus = "Disabled"
}
}
else
{
IF ($Error.Exception.Message -match "Property SMB1" -or $Error.Exception.Message -match "Cannot find path")
{
$SMBStatus = "Enabled"
}
else
{
$SMBStatus = "ConnectionError"
}
}
Write-Host "Checking NTLM Status..."
$ThisRegKey = "HKLM:\SYSTEM\CurrentControlSet\Services\Lsa"
$ThisRegEntry = "LmCompatibilityLevel"
$Error.Clear()
$dbs = Invoke-Command -ComputerName $ItemName -ScriptBlock { Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Lsa' -Name "LmCompatibilityLevel" }
IF ($Error.Count -eq 0)
{
$CheckValue = $dbs.LmCompatibilityLevel
IF ($CheckValue -ne "5")
{
$NTLMStatus = "Enabled"
}
else
{
$NTLMStatus = "Disabled"
}
}
else
{
IF ($Error.Exception.Message -match "Property LmCompatibilityLevel" -or $Error.Exception.Message -match "Cannot find path")
{
$NTLMStatus = "Enabled"
}
else
{
$NTLMStatus = "ConnectionError"
}
}
$STR = $ItemName + ",Connection Ok" + $TLStatus + "," + $SMBStatus + "," + $NTLMStatus
Add-Content $ResultFile $STR
}
}
When the above script completes, you will see a report file in “C:Temp LegacyProtocolsStatus.CSV” containing the status of all protocols, as shown in the screenshot below.
Please keep in mind that if any of the protocols are enabled, you must check the domain controllers and take steps to disable the protocol in order to mitigate security risks in your Active Directory forest.
Bottom Line: Disabling Legacy Protocols in Active Directory is Critical
Active Directory and Azure Active Directory (now Microsoft Entra ID) comprise roughly 60% of the identity and access management (IAM) market and are the primary target of hackers, so shoring up Active Directory security is critically important for protecting an organization’s assets. Disabling legacy protocols is an important step toward better Active Directory security. Hackers are looking for these vulnerabilities, so you should be too.
Further reading:
