Executive Summary

void_hackers has published a Python script presented as an exploit designed to bypass Zabbix Agent DenyKey rules and achieve remote command execution. For the first time, the artifact provides concrete code behind a narrative the actor had been promoting for several days, including its claim that a Zabbix vulnerability was exploited to obtain alleged access to the WSBI-ESBG corporate network.

The static analysis conducted by iQBlack changes that assessment, but does not resolve it.

The underlying technique has a technically plausible basis under specific Zabbix configurations. However, the published script requires remote command execution to have already been enabled, does not overcome the default system.run denial policy, and contains an implementation inconsistency that affects several examples included in its own README.

Based on the evidence currently available, the most defensible classification is a PoC for a potential conditional DenyKey policy bypass, rather than a general-purpose RCE exploit against default Zabbix installations or a confirmed zero-day.

From Claimed Access to Published Code

The publication represents a significant change in the evidence available so far.

Days earlier, void_hackers had linked an alleged Zabbix Agent exploit to supposed access to WSBI-ESBG. At the time, the actor claimed to have used an exposed system as the initial entry point and to have bypassed restrictions associated with remote command execution.

The internal assessment incorporated into 3C-INT preserved an important distinction: the announcement increased the intelligence relevance of the alleged vulnerability, but did not increase technical confidence in its existence to the same degree. There was no code, no independent reproduction, insufficient evidence regarding the affected configuration, and no vendor confirmation.

The appearance of zbx.py now makes it possible to confront that narrative with a concrete implementation. The result introduces a paradox: previously, there was an exploitation claim without an artifact; now there is an artifact, but the artifact does not demonstrate the scope of the original claim.

What zbx.py Actually Demonstrates

The script implements a minimal client for communicating with a Zabbix Agent through its passive protocol over TCP/10050. It checks whether the agent is reachable and then constructs a system.run[...] request in an attempt to execute a command supplied by the operator.

The proposed bypass mechanism relies on altering the command’s textual representation through escape characters. The hypothesis is that a modified string may fail to match a specific DenyKey rule while later retaining equivalent meaning when processed by the shell. That idea is not without technical basis.

Official Zabbix documentation confirms that AllowKey and DenyKey determine which item keys the agent is permitted to process and that those rules are evaluated according to their order. It also establishes a critical limitation for interpreting this artifact: all system.run items are disabled by default, effectively equivalent to a final DenyKey=system.run[*] rule. Zabbix recommends enabling only the commands that are strictly required. The published script contains no mechanism for overcoming that general denial.

For the technique to be applicable, a configuration must already broadly permit system.run while a more specific rule attempts to block individual commands. The deprecated EnableRemoteCommands=1 parameter is effectively equivalent to allowing system.run[*]; its disabled state represents the opposite policy.

This makes the case a potential bypass of a specific policy within an already permissive configuration, rather than a method for enabling remote command execution where Zabbix keeps it disabled.

The Code Also Contradicts Part of Its README

The static review identified another significant inconsistency between the technique as described and the way it is implemented.

zbx.py inserts escape characters both before forward slashes in a path and before spaces. In a POSIX shell, escaping a space changes its function: it no longer behaves normally as a separator between a command and its arguments.

As a result, several ordinary examples included in the README are inconsistent with the transformation actually performed by the script. The bypass example shown in the documentation also does not reproduce exactly the payload generated by the code.

This does not automatically invalidate the normalization hypothesis behind the technique. More constrained cases remain technically plausible. It does, however, prevent the published client from being treated as a reliable arbitrary-command execution implementation.

Another possibility also cannot be excluded: the publicly released artifact may not be identical to a private or commercially distributed implementation used by the actor. It could represent an incomplete version, a deliberately degraded release, or simply defective code.

New Evidence That Forces a Reassessment of the Old

This case illustrates why intelligence maintained over time should not freeze an assessment at the moment of its initial publication.

Within the private 3C-INT workflow, the alleged WSBI-ESBG access had already been recorded through a strategic addendum that maintained low confidence in the claimed zero-day and kept the operational assertion separate from its technical validation.

The new artifact makes it possible to revisit that assessment. But rather than confirming the mechanism allegedly used against WSBI-ESBG, zbx.py introduces prerequisites that are incompatible with the broader claim of having bypassed controls where remote command execution remained fully disabled.

The two pieces of information must therefore remain analytically separate: the alleged WSBI-ESBG access remains actor-declared activity, while the newly published script represents a distinct and conditional technique until further evidence establishes a technical relationship between them.

That incremental approach is precisely one of the models around which 3C-INT is structured: each new artifact, publication, or contradiction can change the confidence assigned to earlier intelligence, rather than simply adding another event to the record.

Indicator and Activity Signals

The artifact can be identified by:

Filename: zbx.py
SHA-256: a0a813a8c1dbfdcfddbf4a06b10252cc37fca2e2fadaa0b9d60a86d566fb9fe0

From a behavioral perspective, the presence of system.run does not by itself constitute evidence of malicious activity. It is legitimate Zabbix functionality when explicitly enabled.

The context becomes more significant when unexpected remote-command requests appear alongside unusual path representations using escape characters, connections to passive agents from unauthorized sources, or unexpected shell activity initiated by zabbix_agentd or zabbix_agent2 processes.

Particular attention should be given to installations that combine broad authorization of system.run[*] with specific rules intended to block only selected commands. Zabbix itself recommends an allowlisting model limited to the commands that are strictly required.

Analytical Closing

The publication of zbx.py adds something that had previously been missing from the void_hackers narrative: code that can be subjected to technical analysis. But the existence of an artifact does not validate the description used to promote it.

The script provides support for a possible discrepancy between the way a specific rule interprets a string and the way that same string may later be interpreted by a shell. At the same time, it requires an already permissive configuration, contains implementation defects, and does not demonstrate a bypass of Zabbix’s default policy that keeps remote command execution disabled.

The publication therefore does not confirm the alleged zero-day previously invoked to explain the supposed WSBI-ESBG access. It narrows its scope.

That distinction matters because, in technical intelligence, new evidence does not always increase confidence in an earlier claim. Sometimes, it allows analysts to define more precisely which part of that claim has still not been demonstrated.

Public References

[1] Zabbix — Restricting agent checks. The documentation describes the behavior of AllowKey/DenyKey, the default denial of system.run, and the recommendation to allow only the required keys. Official Zabbix documentation

[2] Zabbix — Zabbix agent configuration. Documents EnableRemoteCommands as a deprecated parameter and its equivalence to AllowKey/DenyKey rules. Zabbix Agent configuration reference

[3] iQBlack — Previous analysis of void_hackers’ alleged access to WSBI-ESBG and the associated Zabbix claim. void_hackers Offers Alleged Access to WSBI-ESBG