Resumen ejecutivo

void_hackers publicó un script Python presentado como un exploit para evadir reglas DenyKey de Zabbix Agent y obtener ejecución remota de comandos. El artefacto aporta por primera vez código concreto a una narrativa que el actor venía utilizando desde días atrás, incluida su afirmación de haber explotado una vulnerabilidad de Zabbix para obtener supuesto acceso a la red corporativa de WSBI-ESBG.

El análisis estático realizado por iQBlack modifica, pero no resuelve, aquella evaluación.

La técnica subyacente presenta una base técnicamente plausible bajo determinadas configuraciones de Zabbix. Sin embargo, el script publicado requiere que la ejecución remota de comandos ya haya sido habilitada previamente, no supera la política de denegación predeterminada de system.run y contiene una inconsistencia de implementación que afecta varios de los ejemplos incluidos en su propio README.

La clasificación más defendible, con la evidencia actualmente disponible, es la de un PoC para un posible bypass condicional de políticas DenyKey, no la de un exploit RCE general contra instalaciones Zabbix por defecto ni la de un zero-day confirmado.

Del acceso declarado al código publicado

La publicación introduce un cambio relevante respecto de la información disponible hasta ahora.

Días atrás, void_hackers había vinculado un supuesto exploit contra Zabbix Agent con un presunto acceso a WSBI-ESBG. El actor afirmó entonces haber utilizado un sistema expuesto como punto de entrada y haber superado restricciones relacionadas con la ejecución remota de comandos.

La evaluación interna incorporada a 3C-INT preservó una distinción importante: el anuncio aumentaba la relevancia de inteligencia de la supuesta vulnerabilidad, pero no incrementaba en la misma medida la confianza técnica sobre su existencia. No había código, reproducción independiente, evidencia suficiente de la configuración afectada ni confirmación del fabricante.

La aparición de zbx.py permite ahora confrontar aquella narrativa con una implementación concreta. Y el resultado introduce una paradoja: antes existía una afirmación de explotación sin artefacto; ahora existe un artefacto, pero el artefacto no demuestra el alcance de la afirmación original.

Qué demuestra realmente zbx.py

El script implementa un cliente mínimo para comunicarse con un Zabbix Agent mediante su protocolo pasivo sobre TCP/10050. Comprueba la disponibilidad del agente y posteriormente construye una solicitud system.run[...] para intentar ejecutar el comando proporcionado por el operador.

El mecanismo de bypass propuesto se basa en modificar la representación textual del comando mediante caracteres de escape. La hipótesis es que una cadena modificada podría no coincidir con una regla DenyKey específica y, sin embargo, adquirir posteriormente un significado equivalente al ser procesada por el shell. Esa idea no carece de sustento técnico.

La documentación oficial de Zabbix confirma que AllowKey y DenyKey controlan qué item keys puede procesar el agente y que las reglas son evaluadas según su orden. También establece un límite decisivo para interpretar este artefacto: todos los elementos system.run están deshabilitados por defecto, de forma equivalente a disponer de una regla final DenyKey=system.run[*]. Zabbix recomienda habilitar únicamente los comandos estrictamente necesarios. El script publicado no contiene un mecanismo para superar esa denegación general.

Para que la técnica resulte aplicable debe existir previamente una configuración que permita ampliamente system.run, mientras una regla más específica intenta bloquear determinados comandos. El antiguo parámetro EnableRemoteCommands=1, actualmente obsoleto, equivale precisamente a permitir system.run[*]; su valor deshabilitado equivale a la política contraria.

Eso convierte el caso en un posible bypass de una política específica dentro de una configuración permisiva, no en una forma de habilitar ejecución remota allí donde Zabbix la mantiene desactivada.

El código también contradice parte de su README

La revisión estática identificó además una inconsistencia importante entre la técnica descrita y su implementación.

zbx.py inserta caracteres de escape tanto delante de las barras de una ruta como delante de los espacios. En un shell POSIX, escapar el espacio modifica su función: deja de actuar normalmente como separador entre un comando y sus argumentos.

Como consecuencia, varios ejemplos ordinarios incluidos en el README no son consistentes con la transformación realizada por el propio script. El ejemplo de bypass mostrado en la documentación tampoco reproduce exactamente el payload generado por el código.

Esto no invalida automáticamente la hipótesis de normalización que existe detrás de la técnica. Casos más restringidos continúan siendo técnicamente plausibles. Sí impide tratar el cliente publicado como una implementación confiable de ejecución arbitraria de comandos.

Existe además una posibilidad que no puede descartarse: el artefacto público podría no ser idéntico a una eventual implementación privada o comercializada por el actor. Podría tratarse de una versión incompleta, deliberadamente degradada o simplemente defectuosa.

Una nueva evidencia que obliga a revisar la anterior

Este caso ilustra por qué la inteligencia mantenida en el tiempo no debería congelar una evaluación en el momento de la primera publicación. En el flujo privado de 3C-INT, el supuesto acceso a WSBI-ESBG ya había sido registrado mediante un addendum estratégico que conservaba una confianza baja sobre el alegado zero-day y separaba la afirmación operacional de su validación técnica.

El nuevo artefacto permite volver sobre aquella evaluación. Pero en lugar de confirmar el supuesto mecanismo utilizado contra WSBI-ESBG, zbx.py presenta requisitos incompatibles con la afirmación más amplia de haber superado controles que mantuvieran completamente deshabilitada la ejecución remota.

Ambas piezas de información deben, por lo tanto, permanecer separadas: el acceso atribuido a WSBI-ESBG continúa siendo actividad declarada por el actor, mientras que el nuevo script representa una técnica distinta y condicionada hasta que nueva evidencia permita establecer una relación técnica entre ambas.

Ese seguimiento incremental es precisamente uno de los modelos sobre los que se estructura 3C-INT: cada nuevo artefacto, publicación o contradicción puede modificar el nivel de confianza asignado a información anterior, en lugar de limitarse a acumular nuevos eventos.

Indicador y señales de actividad

El artefacto puede identificarse mediante:

Filename: zbx.py
SHA-256: a0a813a8c1dbfdcfddbf4a06b10252cc37fca2e2fadaa0b9d60a86d566fb9fe0

Desde una perspectiva conductual, la presencia de system.run no constituye por sí sola evidencia de actividad maliciosa: es funcionalidad legítima de Zabbix cuando ha sido explícitamente habilitada.

El contexto adquiere mayor valor cuando aparecen solicitudes inesperadas de ejecución remota, representaciones anómalas de rutas mediante caracteres de escape, conexiones hacia agentes pasivos desde fuentes no autorizadas o actividad de shell iniciada de manera inesperada por procesos zabbix_agentd o zabbix_agent2.

Especial atención merecen las instalaciones que combinan una autorización amplia de system.run[*] con reglas específicas destinadas a bloquear únicamente determinados comandos. El propio fabricante recomienda un modelo de allowlisting limitado a los comandos estrictamente requeridos.

Cierre analítico

La publicación de zbx.py aporta algo que hasta ahora faltaba en la narrativa de void_hackers: código susceptible de evaluación técnica. Pero disponer de un artefacto no equivale a validar la descripción que acompaña su comercialización.

El script proporciona soporte a una posible discrepancia entre la forma en que una regla específica interpreta una cadena y la forma en que posteriormente puede interpretarla un shell. Al mismo tiempo, requiere una configuración previamente permisiva, contiene defectos de implementación y no demuestra un bypass de la política predeterminada que mantiene deshabilitada la ejecución remota en Zabbix.

Por eso, la publicación no confirma el supuesto zero-day utilizado anteriormente para explicar el presunto acceso a WSBI-ESBG. Lo acota. Y esa diferencia es relevante porque en inteligencia técnica, la aparición de nueva evidencia no siempre aumenta la confianza en una afirmación anterior. En ocasiones, permite definir con mayor precisión qué parte de aquella afirmación todavía no ha sido demostrada.

Referencias públicas

[1] Zabbix — Restricting agent checks. La documentación establece el comportamiento de AllowKey/DenyKey, la denegación predeterminada de system.run y la recomendación de permitir solamente las claves necesarias. Documentación oficial de Zabbix

[2] Zabbix — Zabbix agent configuration. Documenta EnableRemoteCommands como parámetro obsoleto y su equivalencia con las reglas AllowKey/DenyKey. Referencia de configuración de Zabbix Agent

[3] iQBlack — análisis previo del supuesto acceso de void_hackers a WSBI-ESBG y de la afirmación asociada sobre Zabbix. void_hackers ofrece presunto acceso a WSBI-ESBG