Microsoft fixes the ShadowCoerce Windows NTLM Relay bug quietly

Last Updated 1 month Ago

As part of the June 2022 updates, Microsoft has acknowledged that it patched a previously known “ShadowCoerce” vulnerability that allowed attackers to use Windows servers as a target for NTLM relay attacks.

Threat actors can take over the Windows domain by using this NTLM relay attack technique to force unfixed servers to authenticate against attacker-controlled servers.

A Microsoft representative told BleepingComputer that although this bug was not publicly disclosed, the “MS-FSRVP coercion misuse PoC aka ‘ShadowCoerce’ was mitigated with CVE-2022-30154, which targeted the same part.”

ACROS Security CEO Mitja Kolsek learned that ShadowCoerce was surreptitiously patched when investigating it with the 0Patch team to release a micropatch, and BleepingComputer notified Redmond about it.

Microsoft has addressed this problem, which is wonderful, but they haven’t yet made any information available to the public or given it a CVE ID.

Security companies and researchers have urged Redmond to be more transparent and to provide more information about the fixes in its security bulletins as a result of this [1, 2, 3, 4].

Abuse of the RPC-based protocol results in domain takeover.

Security researcher Lionel Gilles made the initial discovery and description of ShadowCoerce in late 2021 at the conclusion of a presentation presenting the PetitPotam attack.

Fortunately, the File Server VSS Agent Service must be active on the system in order for this attack approach to coerce authentication over the MS-FSRVP (File Server Remote VSS Protocol).

An RPC-based protocol called MS-FSRVP is used to make file share shadow copies on distant systems.

Sadly, as Gilles showed, this protocol is also susceptible to NTLM relay attacks, which let threat actors persuade domain controllers into authenticating against a malicious NTLM relay they control.

In order to obtain a Kerberos ticket-granting ticket (TGT), the malicious server relays (or forwards) the authentication request to a domain’s Active Directory Certificate Services (AD CS). This allows the attacker to pose as any network device, even a Windows domain controller.

They will obtain elevated rights after passing for a domain controller, which they can then utilize to seize control of the Windows domain.

However, in order to carry out these kinds of attacks, a network must already be infiltrated by a threat actor, and the accompanying services must be active and reachable on the targeted server.

Attacks On NTLM Relays And Their Defences

Threat actors may employ a number of techniques, such as the MS-RPRN and MS-EFSRPC (PetitPotam) protocols, to force a proxy server to verify against a malicious NTLM relay.

Additionally, Redmond patched an actively exploited Windows LSA spoofing zero-day vulnerability in May (recorded as CVE-2022-26925 and later determined to be a PetitPotam variation) that could be used to escalate privileges on any Windows version by using forced authentication.

The DFSCoerce Windows NTLM relay attack, which employs MS-DFSNM, a protocol that enables management of the Windows Distributed File System (DFS) using an RPC interface, still has to be addressed by Microsoft.

Security analyst Filip Dragovic published a proof-of-concept DFSCoerce script last month that may be used to relay authentication against arbitrary servers, enabling individuals with restricted Windows domain access to become domain administrators.

To thwart the DFSCoerce attack in their environments, Microsoft encouraged administrators to implement multi-factor authentication and immediately apply any available security patches.

Following Microsoft’s advice on minimizing the PetitPotam NTLM relay attack is the best approach to prevent similar attacks, according to security researchers and experts who spoke with BleepingComputer.

Disabling online services on Active Directory Certificate Services servers, turning off NTLM on DNS servers, and turning on Extended Protection for Authentication and signature features (such as SMB signing) to safeguard Windows credentials are all suggested mitigations.

Read More: