Leveling up with osquery for Workloads: Check for weak authentication types (LM/NTLM)

Audit and Remediation provide direct access to osquery functionality within the VMware Carbon Black Cloud console to enable security, compliance, and IT teams to query over 2,000 individual attributes across endpoints and workloads. osquery can help teams with gathering information at scale across environments for IT and help desk operations, compliance and M&A reporting, incident response, and security investigations.  

Audit and Remediation allow administrators to ask questions about the environment across hardware, software, and network variables at scale. VMware Carbon Black Cloud Workload customers have access to the full Audit and Remediation capabilities. In this blog series, we’ll be laying out relevant queries for VMware Carbon Black Cloud Workload customers to use to achieve a variety of use cases. All queries are available in the VMware Carbon Black Cloud console, or in the VMware Carbon Black User Exchange.  

Requirements:  

This blog series is intended for readers that have a basic understanding of SQLite and have an osquery test environment. If neither of these things is true for you, please take a moment to read the Audit and Remediation Best Practices Guide before reading the rest of the blog.  

Resources  

• Audit and Remediation Best Practices Guide  
• https://osquery.io/schema/ (Refer to the Best Practices guide to determine the version currently installed)  
• VMware Carbon Black Query Exchange (*Requires you sign up for a free account in the VMware Carbon Black User Community unless you are a customer) 

The NT LAN Manager (NTLM) authentication protocol is used for network logons between endpoints and servers. Windows systems should only be using NTLMv2 or higher, as earlier versions are easily cracked and prone to attack. For more information on NTLM please refer to this site. In this blog we will show auditors, compliance teams, and security teams how to easily identify this weaker protocol within their environments at scale. The setting to determine which protocol is used is found in the Windows registry. osquery gives you full access to the Windows registry, making it easy to query for this type of data.  The registry key we need to look at is: 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel.  

This key has the following possible values: 

With this data in mind, we want to ensure that the registry key is set to ‘5’. Let’s take a look at a query for the registry key: 

osquery> select * from registry where path = 'HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\Lsa\\LMCompatibilityLevel'; osquery> 

You’ll notice we have no results, that is because according to Microsoft, this key is not there by default. If our query returns no results that could be confusing to someone running it for the first time. In these cases, I like to use a CASE statement to be more definitive with the results.  

select 
    case count(*) 
        when 0 then "FALSE" 
        else "TRUE" 
    end "NTLMv2 Only Enabled" 
from registry 
where path='HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel' 
    and data != 5; 
+---------------------+ 
| NTLMv2 Only Enabled | 
+---------------------+ 
| FALSE               | 
+---------------------+ 

With this CASE statement we are counting the number of results when we query that key for anything other than a value of ‘5’. In querying this way, we account for instances where the key does not exist. If there is a result and the key is set to ‘5’ the query will return TRUE. 

We can make this query even better by adding another CASE statement that provides details on the current setting: 

osquery> select 
    ...>     case 
    ...>         when data = '5' then 'TRUE' 
    ...>         when count(*) = 0 then 'FALSE' 
    ...>         else 'FALSE' 
    ...>     end 'NTLMv2 Only Enabled', 
    ...>     case 
    ...>         when data = '0' then 'Send LM & NTLM responses ONLY' 
    ...>         when data = '1' then 'Send LM & NTLM – use NTLMv2 session security if negotiated' 
    ...>         when data = '2' then 'Send NTLM response only' 
    ...>         when data = '3' then 'Send NTLMv2 response only. LM, NTLM, and NTLMv2 authentication still accepted' 
    ...>         when data = '4' then 'Send NTLMv2 response only. Refuse LM' 
    ...>         when count(*) = 0 then 'Registry key does not exist' 
    ...>         else 'N/A' 
    ...>     end 'details' 
    ...> from registry 
    ...> where path='HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel'; 
+---------------------+---------+ 
| NTLMv2 Only Enabled | details | 
+---------------------+---------+ 
| TRUE                | N/A     | 
+---------------------+---------+ 

In the first CASE statement, we are looking at the data when it is ‘5’ and return ‘TRUE’. We account for the empty result with the count() line, and finally any other value returns ‘FALSE’. The additional CASE statement looks at the key value and returns the setting description to enable the analyst to understand the results. 

This blog post has shown how we can give definitive results for cases when the query does not return any data to a query to make it more powerful, and enable help desk analysts, security teams, system administrators, and auditors to quickly and at scale weak authentication protocols in use. 

This query is available as a recommended query in Live Query on the VMware Carbon Black Cloud.  

To learn more about how Audit and Remediation capabilities can help you gather data at scale across your environments, check out the resources below and read the other blogs in this series: 

• Carbon Black Cloud Workload TestDrive  
• VMware Carbon Black Tech Zone: Mastering Audit & Remediation  
• Query Exchange (Carbon Black User Exchange)  
• Leveling Up with osquery for Workloads blogs