Here's a digest of my understanding of #CVE-2020-1472 for the Microsoft Netlogon secure channel vulnerability and what you need to do to protect yourself. Thread. ⬇️
Firstly, what's the issue? Well it seems an attacker could essentially become a domain admin, without needing to authenticate to the DC. They just need line-of-site. Yikes.
What is netlogon? Domain-joined systems use the Netlogon Remote Protocol (MS-NRPC) for secure communications between a client machine and a DC for things such as DC discovery, authentication, password changes, etc. Is is also used for trusts between forests.
This vulnerability exists somewhere in this protocol. It *appears* that the issue exists only when using RPC, not secure RPC. A crude analogy would be to think of HTTP vs HTTPS. You cannot exploit this issue if you are using secure RPC (HTTPS), only with non-secure RPC (HTTP)
Installing the patch alone doesn't 'fix' this vulnerability. You have some work to do before that happens. To be properly fixed, requires that the domain controller no longer service netlogon requests over non-secure RPC ('HTTP' in my previous analogy).
What the patch does do, is stop known Windows domain-joined devices from being able to negotiate a netlogon session by falling back to non-secure RPC ('HTTP').
Windows has supported secure RPC ('HTTPS' in my previous analogy) for a long time, so this is a non-issue for any Windows operating system in the last, I don't know 15-20 years?
Windows uses secure RPC by default. You are not turning something 'on' or forcing them to do something they are not already doing by installing this patch.
To cause a problem with Windows machines, you would have had to deliberately disable a bunch of security policies to disable secure RPC for netlogon.
The patch *doesn't* stop unknown devices from using non-secure RPC channel ('HTTP'). For example, non-windows devices you may have joined to your domain, or a trust with a non-windows forest. It *will* however cause the DC to log an event when this type of connection occurs.
So domain-joined Windows machines are prevented from 'downgrading', but unknown devices are not. Ultimately, non-secure RPC ('HTTP') is still available, so the DC is still vulnerable.
It is important to note here, that if your device doesn't have an AD machine account, it's not in scope for being impacted by this fix. An AD machine account is required to use netlogon.
So, if we know that Windows machines are (generally) not impacted, and non-windows machines will continue to work after that patch, you can be comfortable proceeding with the patch.
This is the part where you need to do some work. Deploy the patch, and monitor your DC system event logs for event ID 5829. If you find events, you have devices that are using non-secure RPC to connect to your domain controllers. You need to remediate them.
Once you have fixed them all, or maybe you don't have any, you need to turn on the flag that prevents the DC from allowing non-secure RPC ('HTTP') connections to anyone at all. You do this by enabling the FullSecureChannelProtection registry key support.microsoft.com/en-us/help/455…
Only then are you fully protected from this vulnerability.
What happens in 'phase 2' or the 'enforcement phase' on Feb 9, 2021? Microsoft turn this reg key on for you, and anything that is still logging those event IDs will break.
So to summarise, patch, then check to see if you have event ID 5829 in your event logs. If you do, remediate the non-compliant hosts. If you don't, proceed straight to turning on FullSecureChannelProtection yourself. Don't wait until Feb 2021.
