This blog post is authored by Jon Shectman and Brian Delaney.
In this blog series, we’ll examine the Insecure Protocols Workbook and how, with minimal on-premise configuration, you can leverage its capabilities. In this first blog, I’ll provide a mostly “bare bones” instructional configuration set that you can follow in order to use the IP Workbook. In the coming months, we’ll examine each protocol, the attack vectors it comprises, and how you can finally remove it by leveraging the IP Workbook.
If you’re not familiar with the IP Workbook, that’s ok. However, for the purposes of this blog entry, I’m going to presume a general familiarity with Azure Sentinel and with Workbooks.
Stage 0/Background: the Sentinel IP Workbook
The Azure Sentinel IP Workbook allows you to gain insights into insecure protocol traffic by collecting and analyzing security events from Microsoft products. You can view analytics and quickly identify sources of legacy protocol traffic, like NTLM and SMBv1. You will also have the ability to monitor use of weak ciphers as well as legacy authentication to Azure AD (like IMAP and POP).
The IP workbook consist of detections for the following insecure protocols and procedures:
NTLMv1
SMB1
wDigest
Unsigned LDAP Binds
Weak ciphers being used in the Kerberos stack
Legacy authentication against Azure AD
Important Note: If you do not have sources of every kind of log present, or if you elect not to audit every one, that is perfectly fine. The workbook will simply not display that data; all other protocol collections remain unaffected. For example, if you are not using or collecting Azure AD Sign-in logs, you would still be able to view on-premise logs for protocols like NTLM and SMB.
Let’s take a brief look at the IP Workbook – brief because in future blog entries we’ll delve into great detail.
In the screenshot above, the estate has 258 Insecure LDAP connections logged in the last seven-day period; note the TimeRange filter is configurable. Right away, it becomes apparent that the most significant protocol in this particular estate is Insecure LDAP. Drilling down further, I can click on any one of the bars to filter to just that timeframe.
With this simple filter, a story emerges – On Feb 20, there were four insecure LDAP binds during the 4am hour. This particular filter is important for establish patterns across the estate, as well as tracking remediation progress over time. To identify sources of the traffic, I would scroll down to the Insecure LDAP section of the workbook.
This is one example among many in the IP Workbook. For now, let’s turn our attention to how you can get data flowing into the IP Workbook and start mitigating your estate’s insecure protocols.
Stage 1: Enable AD Auditing (On-prem/IaaS)
The first step to setting up the Insecure Protocols dashboard is to ensure you are auditing the correct events in your Domain Controller Security logs. We’ll configure auditing for these events through Group Policy and verify them.
Note: This guide assumes that you are using Advanced Audit Configuration policies, as these policies are newer and offer more precision (and less over-collection) through granular subcategories. You may achieve the required level of auditing using only older auditing policies, but that auditing is much less granular.
To verify that you have enabled Advanced Audit Policy Configuration, navigate to this value in the winning GPO for your Domain Controllers:
Computer Configuration\Policies\Security Settings\Local Policies\Security Options
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings
This setting should be set to Enabled.
Next, you’ll need to set (or ensure that you have set) the following Advanced Audit Policies to log some specific events. These settings must apply to all servers you want to audit (DCs). You may add them to an existing DC GPO or create a new one.
Navigate to:
Computer Configuration\Policies\Security Settings\Advanced Audit Policy Configuration:
- Under Account Logon, set the following audit settings to Success, Failure
- Audit Credential Validation
- Audit Kerberos Authentication Service
- Audit Kerberos Service Ticket Operations
- Under Account Management set the following audit settings to Success, Failure
- Audit Security Group Management
- Under Logon/Logoff set the following settings to Success, Failure
- Audit Logon
- Account Lockout
- Audit Other Logon/Logoff Events
The settings should look like this:
Once you have set the GPO settings and performed a GPO update, you can verify the settings using auditpol:
On a DC, launch an elevated CMD prompt and type
auditpol /get /category:*
The output for other items will vary, depending on what else is being audited.
Ensure the following settings appear as expected:
Note: Settings for other items will vary, depending on the existing configuration.
These audit settings will produce the following discrete Event IDs in the Security Log of the Domain Controllers in scope:
- 4776 – Non-Kerberos Authentication
- 4771 – Kerberos Pre-auth Failure
- 4740 – Account Lockout
- 4624 – Successful Logon
- 4625 – Failed Logon
- 4768 – TGT request
- 4769 – TGS request
- 4627 – Group membership change
Stage 2: Enable Logging of Unsigned LDAP Binds
An important step to setting up the Insecure Protocols dashboard is to ensure you are auditing insecure LDAP traffic in your Domain Controller (or ADLDS) Directory Service Log.
We’ll set these events and verify them through Group Policy (GPO). Specifically, we’re going to log EventID 2889: The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing.
We’ll need to enable LDAP Logging on each DC. This is a registry setting.
From an elevated CMD prompt, this can be performed simply with:
Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
/v “16 LDAP Interface Events” /t REG_DWORD /d 2
Note: The above is a single command, line-wrapped for readability
As shown in Regedit below:
Environments with many DCs should utilize Group Policy Preferences to set this value through a linked Group Policy.
In the policy object, open Computer Configuration, Preferences, Windows Settings, and click Registry.
Right-click Registry and choose New -> Registry Item
Set the properties as shown.
Action: Replace
Hive: HKEY_LOCAL_MACHINE
Key Path to:
Value Name to: 16 LDAP Interface Events
Value type: REG_DWORD
Set the Value data to: 2
Ensure to check the box on the Common tab for “Remove this item when it is no longer applied.”
Close the GPO and run GPUPDATE on one DC to verify application.
- Once you set this registry key, you should start receiving Event ID 2889 in your Directory Service log whenever un-secured LDAP binds occur, on each Domain Controller.
Note: Depending on the volume of unsigned LDAP data in your environment, you may need to increase the size of your Directory Service event log on your DCs to ensure all events are captured.
Stage 3: Enable SMB1 Auditing
Note: this setting is only available on Windows Server 2012 R2 and newer OSs
- On each target server, run the following PowerShell command:
set-SmbServerConfiguration –AuditSmb1Access $true
- To use PS Remoting to run this against multiple servers:
$computers = Get-Content “c:\SMBservers.txt”
foreach ($computer in $computers) { Invoke-Command -ComputerName $computer -ScriptBlock {set-smbserverconfiguration -auditsmb1Access $true -Force } }
Where C:\SMBservers.txt is an export of all server names that you wish to target.
Stage 4: Configure Security Events Data Connector Settings
In Azure Sentinel, navigate to Data Connectors and then choose the Security Events connector and click Open connector page.
On the blade that opens, scroll down to the Configuration section and choose All Events.
Note: if the choices are greyed out (as mine are in this example), pay special attention to the alert on this page:
Also, note that the Security Events Data connector requires the MMA agent to be installed on your servers. You may download it under Configuration.
Stage 5: Configure the Directory Services log in Log Analytics
In the Azure portal, navigate to the Log Analytics workspace. Click on Advanced settings. On the blade that opens up, choose Data and then Windows Event Logs.
In the box under Collect events from the following event logs, type Directory Service and click the Plus sign. When the log is added to the list, check INFORMATION. In the upper-left-hand corner, click Save.
Stage 6: Configure Azure AD Sign-in Logs Data Connector Settings
Navigate back out to the Data connectors blade in Azure Sentinel and choose Azure Active Directory and Open connector page.
On the blade that opens, navigate to Configuration and next to Azure Active Directory Sign-in logs, click Connect.
Note: My data connector has already been connected and looks a bit different – as evinced by the Disconnect button. If you haven’t yet connected, this button will say Connect before you click it.
Stage 6: Implement the IP Workbook
On the main blade of Azure Sentinel, navigate to Workbooks and Insecure Protocols, and click Save. In the box that opens, choose an appropriate location and click OK.
You are now ready to begin using the IP Workbook by clicking View saved workbook.
Tune in next month where we’ll continue this series by delving deeper into one of the insecure protocols, and how you may leverage the IP Workbook to mitigate it.
Until then, happy auditing.