This article is written by Jon Shectman and Brian Delaney, Microsoft.
Have you read about the elevation of privilege vulnerability that exists when an attacker establishes a vulnerable Netlogon secure channel connection to a domain controller? An attacker who successfully exploited the vulnerability could run a specially crafted application on a device on the network. If you haven't, you can read about the vulnerability here a and learn how to manage the changes here. Those articles give an excellent overview of the issue, so I won't repeat it in detail here. In short, we are addressing this vulnerability in a two-part rollout by modifying how Netlogon handles the usage of Netlogon secure channels.
Phase one, deployment, began on Aug 11. In this phase, secure Remote ProtoCol (RPC) is enforced for machine, trust and domain controller accounts. This phase also includes a new group policy object (GPO) and a registry key to manage configuration, and five new Event IDs.
These Event IDs are important for auditing and understanding of the issue. They are as follows:
Machine Events
5827 - Connection denied
5829 - Non-compliant (allowed during Deployment phase)
5830 - Allowed by policy
Trust Events
5828 - Connection denied
5831 - Allowed by policy
Phase two, enforcement, is slated to begin Feb 9, 2021. In phase two, non-compliant machine connections will be denied by default and an Event ID 5827 will be logged. It's entirely possible to set the new GPO "Domain controller: Allow vulnerable Netlogon secure channel connections" and to simply allow the vulnerable connections. However, that is not recommended. Rather, you should use the new tab in the Insecure Protocols Workbook to detect and understand the five new Event IDs and take appropriate action to address the vulnerable Netlogon sessions prior to the enforcement phase. If you're new to the Insecure Protocols Workbook, we recommend checking out the getting started guide and then come back here.
To populate the Workbook, take two steps:
1. On your domain controllers, apply the relevant update from CVE-2020-1472.
2. In Azure Sentinel, go to Settings, Workspace Settings, Advanced Settings, Data, Windows Event Logs, and add (or make sure you already have added) Errors and Warnings from the System Log.
Once you have data flowing, it's time to start using the Insecure Protocols Workbook. The first addition you'll notice is a new tab, Vulnerable Secure Channel.
The most efficient way to describe how to use this tab is to simply show it - as in the GIF below.
ā
At the top of the tab is a counter (tile) for each of the five new Event IDs. In our lab, for example, we have eight instances of Event ID 5830. That's the tile I clicked on to filter to that event ID. Next, I "painted" a timebrush slice to filter the queries below to a particular time; then I simply clicked on a Machine Account to show the Machine Account Connections. The result is a highly actionable data set, showing us exactly where we need to research vulnerable secure channel connections.
Once you know where to look, you'll need to upgrade all Netlogon clients. However, there's an additional point to consider. Though we expect it to be a rare finding, vulnerable secure channel connections can come from not only machines, but also from trusts (most likely Realm trusts). This configuration may result in significantly increased exposure (Event ID 5828) and may require more planning to remediate.
In this article, we briefly discussed the exposure in vulnerable secure channel connections, how they are logged during the first phase of CVE-2020-1472, and how to audit them with the Insecure Protocols Workbook.
A brief sidenote: If you ever feel your perspectives don't matter or that your opinions aren't good enough, we urge you to think again. This workbook enhancement came directly from a conversation on Twitter where multiple folks made the case for it. If you have concepts to add, functionality you'd like to see added, or ideas for improvement, please reach out on Twitter (@shectonsecurity), find us on LinkedIn, or use the comments section. We are all ears.
Thanks for reading and, as always, happy auditing. š
Microsoft
