This blog post is authored by Jon Shectman and Brian Delaney.
In this blog article, we’ll examine the Insecure Protocols Workbook (IP Workbook) and how, with minimal on-premise configuration, you can leverage its capabilities. In this article, I’ll provide the configuration instructions you need to successfully use 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.
Edit: when you're done here, pop over to the blog entry covering some recent functionality enhancements.
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). These protocols comprise a rich attack surface for adversaries and should be removed from your estate.
The IP workbook consist of detections for the following insecure protocols:
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.
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 establishing 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:
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:
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.
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
set-SmbServerConfiguration –AuditSmb1Access $true
$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 in-scope 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 SMB Log Collection
In the same area, navigate back up to the Collect events from the following event logs box. This time you will type in Microsoft-Windows-SMBServer/Audit. Note: this particular log does not autofill in the pull-down. This is ok - type it and and hit the Plus sign.
Choose INFORMATION and hit Save.
Stage 7: 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.
In this article, we briefly discussed the use case for the IP Workbook and how you can leverage it to identify insecure protocols for removal. We then covered how to configure your estate to log and display the exact sources of insecure protocols, setting you up for the best chance of successful removal.
I hope you've found this article useful and that you'll let us know how you've used the IP Workbook. Until then, happy auditing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.