Wazuh Whodata en Windows: corrección del error 6955

Cómo solucionar Wazuh Whodata en Windows: solución alternativa de localización mediante GUIDs de auditoría

La función set_policies() en src/syscheckd/src/whodata/win_whodata.c sigue esta secuencia:

• auditpol /backup → crea un archivo CSV con encabezados como "Nombre de subcategoría", "Éxito", "Fracaso"
• Analiza este CSV para determinar el estado actual
• auditpol /restore → intenta aplicar la configuración guardada

El problema es que, a partir de Windows 10/11 versión 1809, auditpol /restore requiere una coincidencia exacta de los nombres de subcategorías. Si el CSV especifica "Sistema de archivos" pero auditpol espera "File System", el comando falla con el código de error 0x134c (5004), que Wazuh interpreta como 6955. Este comportamiento está documentado en la documentación de Microsoft: “El comando /restore es sensible a la configuración regional y puede fallar si el archivo de copia de seguridad se creó en un sistema con configuraciones de idioma diferentes.”

La clave está en que todas las subcategorías de auditoría tienen GUIDs codificados de forma rígida, independientes del idioma del sistema operativo. Por ejemplo:

• Sistema de archivos: {0CCE921D-69AE-11D9-BED3-505054503030}
• Manipulación de manejos: {0CCE9223-69AE-11D9-BED3-505054503030}
• Cambios en el registro: {0CCE9227-69AE-11D9-BED3-505054503030}

Estos identificadores son accesibles mediante auditpol /list /subcategory:* y permanecen estables desde Windows Vista hasta Windows 11.

Cómo reescribir set_policies() sin dependencia de la configuración regional

Reescribir la función set_policies() en win_whodata.c es el paso técnico central. La nueva implementación elimina por completo la pila de CSV y se basa únicamente en llamar directamente a auditpol /set con GUIDs. Aquí están los requisitos clave para el parche:

• Llamadas mínimas al sistema: cada llamada a system() debe verificarse para asegurarse de que el código de salida no sea cero
• Atomicidad: si una subcategoría falla, las demás deben seguir configurándose
• Información de depuración: cada error debe registrarse junto con la subcategoría específica involucrada
• Compatibilidad con Windows Server 2016+: todos los GUIDs especificados son compatibles tanto en Server Core como en Desktop Edition

La implementación evita usar popen() o CreateProcessA para prevenir problemas de codificación de la consola. Llamar directamente a system() garantiza la ejecución en la página de códigos del sistema, donde auditpol interpreta correctamente los GUIDs.

Parches adicionales para compilar WinAgent con WIN_WHODATA

Compilar el agente de Wazuh para Windows requiere tres cambios críticos en el proceso de construcción:

• Habilitar la definición del preprocesador — agregar -DWIN_WHODATA a la sección DEFINES del Makefile para activar los bloques de código correspondientes en syscheckd
• Pasar la bandera a CMake — modificar la cadena de compilación syscheckd/build para pasar -DWIN_WHODATA a la línea de compilación CFLAGS
• Vincular contra wevtapi.lib — una dependencia obligatoria para las llamadas a EvtSubscribe, EvtNext y otras funciones de la API de registro de eventos utilizadas en el modo whodata

Sin el tercer punto, la compilación fallará debido a un error de enlace: referencia no definida a 'EvtSubscribe'. La biblioteca wevtapi.lib viene incluida con MinGW-w64 (el paquete mingw-w64-dev) y no requiere SDK externos.

Además, buffer.c necesita corrección: sustituir return NULL; por return 0; en la función dispatch_buffer(), ya que su firma devuelve int en lugar de void*. Este error provoca un comportamiento indefinido al procesar buffers de eventos en el modo whodata.

Pruebas y despliegue en producción

Después de una compilación exitosa (make TARGET=winagent), el resultado wazuh-agent.exe contiene una implementación completamente autónoma de whodata. Para validar:

• Iniciar el agente con whodata habilitado en ossec.conf:

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

• Asegurarse de que no haya errores 6955, 6915 ni 6916 en los registros
• Verificar la presencia de eventos FIM con el atributo type="whodata" en Kibana o mediante wazuh-logtest
• Confirmar el funcionamiento en Windows con locales ru-RU, zh-CN, es-ES — todas las pruebas deben pasar idénticamente

El despliegue en entornos empresariales requiere firmar el ejecutable con un certificado EV Code Signing, ya que auditpol /set requiere privilegios de administrador y puede ser bloqueado por Windows Defender Application Control (WDAC) sin una firma confiable.

Qué importa

• El error 6955 no se debe a un fallo de Wazuh, sino a la limitación de auditpol /restore en locales de Windows no anglosajones
• Usar GUIDs en lugar de nombres de subcategorías es la única manera de garantizar la compatibilidad entre regiones sin modificar la configuración del sistema
• wevtapi.lib es una dependencia obligatoria para whodata: sin ella, la suscripción en tiempo real a eventos de auditoría es imposible
• El parche de buffer.c es crucial para la estabilidad: una discrepancia en el tipo de retorno causa una falla de segmentación cuando el buffer de eventos se desborda
• El agente compilado no requiere instalar componentes adicionales — todo lo necesario está integrado en wazuh-agent.exe

Todos los cambios son retrocompatibles con las versiones oficiales de Wazuh 4.14.x y pueden integrarse en pipelines CI/CD mediante archivos de parche y scripts post-compilación. Para la automatización, se recomienda usar git apply con archivos diff previamente verificados y validación del hash del código fuente.

— Editorial Team