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.

1. 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.
2. Make sure the computer is joined to the domain.
3. 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:

• Top Active Directory Security Tools
• Living Off the Land Attacks: LOTL Definition & Prevention
• Cybersecurity Agencies Release Guidance for PowerShell Security

The post A PowerShell Script to Mitigate Active Directory Security Risks appeared first on eSecurity Planet.

Between Active Directory for Windows and Azure, Microsoft dominates the market for identity and access management (IAM) tools with a greater than 50% market share, including about 95% of the Fortune 1000, so there are few targets for hackers that deliver richer results.

Here we’ll look at how to check several critical Active Directory components for signs of compromise, important steps to add to your Active Directory security best practices.

See the Top Active Directory Security Tools

Looking to improve AD compromise detection? This article’s sponsor, Semperis, developed Purple Knight and Forest Druid to discover indicators of exposure and indicators of compromise in AD, Azure AD/Entra ID, Okta, and the tier 0 perimeter. Learn how these free tools make the whole audit easier!

Looking for Signs of an Attacker

Threat actors with the savvy to reach your Active Directory environment may also be savvy enough to do so without leaving any evidence, making it impossible to determine whether Active Directory was compromised.

An attacker could, for instance, join the Domain Admins group, engage in hacking activities, and then leave the group. If monitoring is enabled, you can check the membership of privileged groups by monitoring them. If you discover a member who belongs to a privileged group but is not on the list of designated admins, you can either remove the admin or investigate how that user came to be a member of the privileged group.

Much depends on the attacker’s speed and ability. It is possible for an attacker to employ attack strategies that would prevent any events from being recorded in the event logs. To look for signs of an attack, you can’t keep checking the event logs on every domain-joined computer or domain controller. Checking the status of crucial Active Directory components should be the first step in your strategy for determining whether or not Active Directory has been compromised.

Note that adversaries will try to attack Active Directory components that are not easily known and touched by Active Directory administrators. You must verify that each of these components is in its default state and determine whether any of them have been changed from that state. Despite the fact that there are a lot of components you should examine, this article only focuses on the “critical” ones. We will examine AdminSDHolder, Default Group Policy Objects, PrimaryGroupIDs, and Domain Controllers. Although the list in this article isn’t sufficient to determine whether your Active Directory has been compromised or not, the items mentioned above are typical things that an attacker would try to touch in order to access Active Directory.

AdminSDHolder Object and Privileged Accounts

Every Active Directory domain contains a unique container called AdminSDHolder under the System container. When an Active Directory domain’s first domain controller is deployed, the AdminSDHolder container is also created. Maintaining permissions that will be used by privileged accounts is the responsibility of the AdminSDHolder container.

The SDProp process copies the permissions from the AdminSDHolder container to all the privileged accounts after verifying the permissions that have been applied to the container. An ordinary user won’t interact with the AdminSDHolder object. However, an attacker who has enough privileges can change the permissions set for AdminSDHolder and gain access to Active Directory.

To check whether the AdminSDHolder container was modified by someone you can check its “WhenChanged” attribute by going to the Attribute Editor as shown in the screenshot below:

The AdminSDHolder container was created on 3/23/2023 (when the domain controller was deployed) and modified on 5/28/2023, as seen in the screenshot above. When someone modified it, they most likely added permissions to the Security Tab, which you can check and then remove if they are no longer required. Administrators do not need to touch the AdminSDHolder object after the Active Directory domain has been deployed.

Group Policy Objects: A Major Target for Hackers

You should be aware that attackers now primarily target GPO (Group Policy Objects). GPO is a powerful Active Directory object. Because GPO has so many settings, once a hacker has access to it, he or she can change them and apply them to the target computer or run a malicious code via a scheduled task on the target computers. Your target computers could be users’ accounts, domain controllers, or computer accounts.

Note that Active Directory implements two default Group Policy Objects: Default Domain Policy and Default Domain Controllers Policy. These two GPOs are untouched after deployments except Default Domain Policy. Your company’s password policy requirements may require you to modify the Account Policies in the Default Domain Policy, but that change will also be made permanently.

Typically, you will create a new GPO if you want to apply organization-specific or security settings to users and computer accounts in your environment. By visiting Attribute Editor or by using the PowerShell command below, you can always check the modification time for both the default domain policy and the default domain controllers policy. This PowerShell command will list all GPOs in the domain and their modification time:

• $AllGPOs = Get-GPO -All -Server $ThisDomain | Select-Object DisplayName, ModificationTime

• $AllGPOs

If the Active Directory deployment date and the modification time for the default domain policy and default domain controller policy differ, someone may have altered these GPOs to gain access to Active Directory.

PrimaryGroupID: An Easier Target

These days, the PrimaryGroupID attack is increasingly common because it requires less work before an attacker can take over Active Directory.

All Active Directory user accounts are initially assigned to the “Domain Users” default security group, which becomes the user’s PrimaryGroupID. The PrimaryGroupIDs for the user accounts are 513, the PrimaryGroupIDs for the computer accounts are 515, and the PrimaryGroupID for the domain controller is 516.

A user’s or computer’s PrimaryGroupID can be changed by an attacker, who can then change Active Directory’s default behavior. For instance, altering a user’s PrimaryGroupID so that they belong to the Domain Admins group would grant the attacker privileged access to the Active Directory.

You must use a PowerShell script to check all user, computer, and domain controller accounts to make sure their PrimaryGroupIDs haven’t been changed. If you notice any changes, it means that someone attempted to alter the objects’ default membership in order to access Active Directory.

Domain Controllers and Their Default Location

Once implemented, domain controllers will continue to be located in their default location, “OU=Domain Controllers, DC=Domain>, DC=local>”.

Due to its default location in Active Directory, the domain controller is guaranteed to receive the group policy settings from the Default Domain Controllers Group Policy, which are intended specifically for protecting domain controllers.

Domain controllers will not receive those settings if they are moved from their default locations; instead, they may receive settings that are coming from a different Group Policy Object. For example, if they have the right permissions, an attacker could transfer one or more domain controllers to a different organizational unit with a different GPO applied to it, and that GPO could contain a scheduled task that would execute malicious code. You should always run a quick PowerShell script or make use of the security assessment tools to verify that each domain controller is located in their default organizational unit.

Here’s a small PowerShell script that can help you check the location of all domain controllers in an Active Directory forest. The script gets all domain controllers from the Active Directory forest and then checks their computer account location one by one in Active Directory. The result will be displayed on the screen if any of the domain controllers is not located in its default organizational unit.

$ComputersList = "C:\Temp\DCList.TXT"
Remove-Item $ComputersList -ErrorAction SilentlyContinue
$R = (Get-ADForest).Domains | % { Get-ADDomainController -Discover -DomainName $_ } | % { Get-ADDomainController -server $_.Name -filter * } | Select HostName
foreach ($Item in $R)
{
   $ThisDC = $Item.HostName
   Add-Content $ComputersList $ThisDC
}
Foreach ($ComputerItem in Get-Content "$ComputersList")
{
   $NameOne, $NameTwo = $ComputerItem.Split(".")
   $Error.Clear()
   $RNow = Get-ADComputer $NameOne -Server $ComputerItem
   $DCName = $RNow.DistinguishedName
   $CurLocName = $DCName
   $RemovedComma = $CurLocName.replace(",", " ")
   $DCT1, $DCT2, $DCT3 = $DCName.split(",")
   IF ($DCT2 -eq "OU=Domain Controllers")
   {
   }
   else
      {
         Write-Host "WARNING: Domain Controller is not located in its default OU"
      }
}

Bottom Line: Securing Active Directory from Hackers

Checking the status of critical Active Directory components to look for signs of a compromise should be a regular best practice for admins. We discussed the default location of the computer account for the domain controller, the AdminSDHolder container, Default Group Policy Objects, and PrimaryGroupID, along with techniques for detecting compromise, but there are additional components and Active Directory best practices that we’ll cover in future articles.

Also read:

• Cybersecurity Agencies Release Guidance for PowerShell Security
• Living Off the Land Attacks: LOTL Definition & Prevention

The post How to Tell if Active Directory is Compromised appeared first on eSecurity Planet.