Skrevet av:

Background

On August 11, 2020, Microsoft patched a privilege escalation vulnerability in Microsoft Netlogon Remote Protocol (MS-NRPC). The vulnerability allows an attacker to impersonate the machine account of any domain joined computer, and set a known or empty password for the machine account.

The vulnerability is particularly severe as it may be used to obtain full domain administrator privileges by spoofing the machine account of a Domain Controller. This enables the attacker to access the specific Domain Controller and extract all user password hashes, including hashes for domain administrators and kerberos service user (krbtgt), which can further be used to create golden tickets.  Effectively providing an attacker full domain administrator privileges.

Summary

Multiple examples of proof-of-concept code are publicly available. Our Technical Risk Services department have successfully verified the exploit. This vulnerability should be mitigated AS-SOON-AS-POSSIBLE.

In order to fully mitigate, you need to install the August 11 update and enable "enforcement mode" by modifying a registry key. Installing the patch alone does NOT fully mitigate the vulnerability.

Description

Microsoft is deploying mitigation in two phases. An initial deployment phase (2020-08-11) and an Enforcement Phase (2021-02-09). Microsoft is taking precautions in order to allow organisations time to rectify any non-compliant devices using MS-NRPC. First phase will provide new Event IDs to identify non-compliant devices and introduce a registry key to enable enforcement mode early. Second phase will enable enforcement mode regardless of registry setting.[1][2]

In the deployment phase (2020-08-11), Microsoft introduces a series of changes:

  • Enforcement of secure RPC for Machine accounts on Windows based devices, trust accounts, all Windows and non-Windows DCs.
  • A new GPO to allow non-compliant devices (using insecure RPC) to communicate with the DCs, even if they are configured in enforcement mode.
  • A new registry key to enable early enforcement mode on DC for all machine accounts (enforcement of secure RPC).
  • New event IDs which log when accounts are denied, or would be denied in enforcement mode (Event ID 5827, 5828 and 5829).

All modern Windows operating systems are using secure RPC by default and are therefore not affected by these changes. In order to force a modern Windows operating systems to use insecure RPC one would have to deliberately disable default security policies in Windows operating systems. But non-Windows devices that are domain joined or trusted Active Directory domains forests might be using insecure RPC.

In the Enforcement phase (2021-02-09), Microsoft will enforce secure RPC on all domain controllers, forcing all devices, Windows or non-Windows, to use secure RPC. The only exception are devices exempted using group policy settings as introduced by the August 11th 2020 update. In this phase, the Event ID 5829 will also be removed as all non-secure RPC connections become denied and logged as Event ID 5827.

In their conclusion, Secura observed that the August patch broke their implementation of the exploit, possibly due to the ClientCredential field starting with too many zeroes. At the time of writing, it is unknown if the vulnerability still can be used, after the patch, either with brute-forcing, for man-in-the-middle or as a vector for Denial of Service (through disconnecting AD machine accounts). It should also be noted that according to Microsoft MVP Ryan Newington, the August patch does not disable non-secure RPC, it will still be available to use for devices but they are now logged under the new Event ID 5829 to allow identification.

In an Active Directory environment with domain trust to other domains one would have to consider if the trusted party rely on using non-secure RPC. Identification of any devices in remote domains which use non-secure RPC is done in the same manner as domain local devices by analysing Event ID 5829. Allowing trusted domain to use non-secure RPC can be achieved by adding trust accounts to the exempted devices using group policy. Doing so is however strongly discouraged.[3]

Intelligence assessment

Proof-of-concept code for the exploit is widely available. The exploit is currently being implemented in commonly used attack frameworks and tools. It has already been included in the popular tool "mimikatz". The wide availability and fairly high stability of the proof-of-concept code we have seen makes it certain that this exploit will be used by a wide range of threat actors ranging from Nation-state actors, crime-syndicates, criminals and opportunists.

The only attacker drawback being that a password reset of a machine account in effect disconnects that machine from the domain (at least before an attacker can restore connection), making the exploit somewhat "noisy".

Consequences

If not mitigated, it will provide an attacker with an initial foothold means to perform privilege escalation from unauthenticated user to full domain administrator privileges.

If partially mitigated with the just the patch there is a risk that someone will circumvent the obstacle preventing the current PoC code from working.

Recommendations

Microsoft's recommendation is to install the patch and monitor for Event ID 5829, to see if you have non-Windows devices that uses insecure RPC, "mitigate these" and then enable enforcement mode.

mnemonic's recommendation: Install the patch and enable enforcement mode AS-SOON-AS-POSSIBLE. If it is not possible to immediately enforce secure RPC, you should only allow a small window of time to identify non-compliant devices. These devices must by patched, upgraded or removed. If you cannot remove them for the time being, you should use the GPO to add explicit exceptions, and then turn on enforcement mode (note that we do not recommend to leave machine accounts with exceptions, as this is a potential backdoor for future privilege escalations, but it is better to have a few known systems, with insecure RPC enabled, than all systems).

Detection coverage for Argus customers and Argus Continuous Vulnerability Monitoring coverage (CVM)

Network based signatures have already been deployed, and our threat researchers are working on improving these further. Initial signatures from some of our vendors had issues with large amounts of false positives. Network coverage is dependent on network sensors being deployed in a fashion that allows for inspection of traffic between computers/servers and the Domain Controllers.

Our threat researchers are also working on log based detection for both scenarios with patched and vulnerable Domain Controllers. Thanks to the Windows Event IDs 5827, 5828 and 5829 we are confident we will be able to build content for patched Domain Controllers. We are still investigating if robust detection can be deployed for vulnerable servers. Detection through log analysis requires collection and analysis of Security Event Logs from domain controller as a part of the Argus service.

For EDR based detection, it is unlikely that the EDR tools themselves will be able to inspect and analyse Microsoft Netlogon Remote Protocol. We are working with our vendors to get feedback on this issue. It is highly likely that EDR detection will be based on detecting the specific implementation of the exploit (detection of the tool being used) instead of detecting the actual RPC exploit.

We are expecting vendors to deploy signatures to more tailored solutions (such as Azure ATP and SmartVision), and we are following up the vendors in our portfolio to get positive confirmation of working signatures.

All Argus CVM customers with registered unpatched vulnerabilities have been notified explicitly. CVM requires authenticated scans to successfully register vulnerable servers. Our CVM team is currently investigating if a safe network based unauthenticated scan can be utilised.

For further inquiries regarding Argus service, and coverage, please contact your Technical Account Manager (TAM) or create a ticket in the Argus portal.

References

  1. https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc
  2. https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc#EnforcementMode
  3. https://support.microsoft.com/en-us/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc#theGroupPolicy

More information

 

Do you want to be updated on mnemonic’s Threat Advisories? Sign up to our threat intelligence newsletter.