Wazuh Whodata on Windows: fix error 6955

How to Fix Wazuh Whodata on Windows: Localization Workaround Using Audit GUIDs

The set_policies() function in src/syscheckd/src/whodata/win_whodata.c follows this sequence:

• auditpol /backup → creates a CSV file with headers like "Subcategory Name", "Success", "Failure"
• Parses this CSV to determine the current state
• auditpol /restore → attempts to apply the saved settings

The problem is that, starting with Windows 10/11 version 1809, auditpol /restore requires an exact match of subcategory names. If the CSV specifies "File System" but auditpol expects "File System," the command fails with error code 0x134c (5004), which Wazuh interprets as 6955. This behavior is documented in Microsoft Docs: “The /restore command is locale-sensitive and may fail if the backup file was created on a system with different language settings.”

The key insight: all audit subcategories have hard-coded GUIDs that are independent of the OS language. For example:

• File System: {0CCE921D-69AE-11D9-BED3-505054503030}
• Handle Manipulation: {0CCE9223-69AE-11D9-BED3-505054503030}
• Registry Changes: {0CCE9227-69AE-11D9-BED3-505054503030}

These identifiers are accessible via auditpol /list /subcategory:* and remain stable from Windows Vista through Windows 11.

How to Rewrite set_policies() Without Locale Dependency

Rewriting the set_policies() function in win_whodata.c is the central technical step. The new implementation eliminates the entire CSV stack and relies solely on directly calling auditpol /set with GUIDs. Here are the key requirements for the patch:

• Minimal system calls: each system() call must be checked for a non-zero exit code
• Atomicity: if one subcategory fails, others should continue to configure
• Debugging information: every error must be logged with the specific subcategory involved
• Compatibility with Windows Server 2016+: all specified GUIDs are supported in both Server Core and Desktop Edition

The implementation avoids using popen() or CreateProcessA to prevent console encoding issues. Directly calling system() ensures execution in the system’s code page, where auditpol correctly interprets the GUIDs.

Additional Patches for Building WinAgent with WIN_WHODATA

Building the Wazuh agent for Windows requires three critical changes in the build process:

• Enable the preprocessor definition — add -DWIN_WHODATA to the DEFINES section of the Makefile to activate the corresponding code blocks in syscheckd
• Pass the flag to CMake — modify the syscheckd/build build string to pass -DWIN_WHODATA into the CFLAGS compilation line
• Link against wevtapi.lib — a mandatory dependency for calls to EvtSubscribe, EvtNext, and other Event Log API functions used in whodata mode

Without the third point, the build will fail due to a linking error: undefined reference to 'EvtSubscribe'. The wevtapi.lib library is included with MinGW-w64 (the mingw-w64-dev package) and does not require external SDKs.

Additionally, buffer.c needs correction: replace return NULL; with return 0; in the dispatch_buffer() function, since its signature returns int rather than void*. This bug leads to undefined behavior when processing event buffers in whodata mode.

Testing and Deployment in Production

After successful compilation (make TARGET=winagent), the resulting wazuh-agent.exe contains a fully standalone whodata implementation. To validate:

• Start the agent with whodata enabled in ossec.conf:

<syscheck>
  <whodata>yes</whodata>
</syscheck>

• Ensure there are no errors 6955, 6915, or 6916 in the logs
• Verify the presence of FIM events with the type="whodata" attribute in Kibana or via wazuh-logtest
• Confirm operation on Windows with locales ru-RU, zh-CN, es-ES — all tests should pass identically

Deployment in enterprise environments requires signing the executable with an EV Code Signing certificate, as auditpol /set requires administrator privileges and may be blocked by Windows Defender Application Control (WDAC) without a trusted signature.

What Matters

• Error 6955 is caused not by a Wazuh bug, but by the limitation of auditpol /restore in non-English Windows locales
• Using GUIDs instead of subcategory names is the only way to ensure cross-locale compatibility without modifying system settings
• wevtapi.lib is a mandatory dependency for whodata: without it, real-time subscription to audit events is impossible
• The buffer.c patch is critical for stability: a mismatch in return type causes a segmentation fault when the event buffer overflows
• The compiled agent does not require installing additional components — everything needed is built into wazuh-agent.exe

All changes are backward compatible with official Wazuh releases 4.14.x and can be integrated into CI/CD pipelines via patch files and post-build scripts. For automation, it’s recommended to use git apply with pre-verified diff files and source hash validation.

— Editorial Team