Hunt.io Says a Russian-Speaking Operator Used a Graylog Log4Shell Chain on Logging Servers Tied to Ukraine's State Data-Exchange System, Then Left the Evidence in an Open Directory

LONDON - A lone operator working from a rented server spent May through September hunting for one piece of government data-exchange software across Ukraine and got code running on at least two logging servers next to it, according to research the threat-hunting company Hunt.io published on Oct. 20. The company said it could reconstruct the campaign because the operator served his own working directory over the open internet for 17 hours, including the staging server's access log.

Hunt.io said that before publishing it shared its findings and the victim data it recovered with the national CERTs of the affected countries, which are handling notification. It does not attribute the activity to a tracked actor, but it noted Russian-language comments in the operator's scripts.

One port, one string

The operator began with a public list of Ukrainian IP ranges, 2,874 networks and 9,102,336 addresses, and swept it twice with masscan on Sept. 3 for a single port, 5000. That left 7,576 live hosts. The operator then requested each over HTTPS and kept only those whose response contained "UXP Verifier," the web interface for the message log of a security server in the Cybernetica UXP platform on which Ukraine's data-exchange system is built. Two addresses survived the filter.

A day earlier, the operator had probed a hand-built list for ports 5500, 5577 and 4000, the standard security-server ports of the X-Road platform that UXP is built on. Port 4000 carries the management interface, which Hunt.io noted the documentation says must not be reachable from the internet. Reverse DNS on that list returned three Ukrainian government names, though Hunt.io said it had no evidence the operator accessed any of them.

The chain against Graylog

The host Hunt.io documents in full was a Graylog logging server in the same /24 network as one of the UXP Verifier hosts. A 61-line bash script, fire3.sh, sent one POST request to Graylog's sessions endpoint, /api/system/sessions, with a JNDI lookup string in the username field. Two serialized CommonsBeanutils objects followed with a pause between them: the first made the target fetch a shell script, the second ran it to open a reverse shell.

The request carried an X-Requested-By: cli header, which Graylog enforces as a cross-site request forgery control. Without it the request is rejected rather than parsed, so Hunt.io said its presence is "a reliable indicator of an attempt against this platform." The researchers also warned that the command runs from a Java class's static initializer, firing when the class loads, so "EDR rules written against Runtime.exec call sites in application logic will miss it. A spawned child process is the only reliable signal."

The proof of execution came from the operator's own habit of printing the tail of the staging log after each trigger. In the recovered log, the target fetched the stager six seconds after the trigger and made only three requests in 17 hours. Hunt.io said the reverse shell itself is not directly recorded.

Measuring, not yet moving, the data

Once on the host, the operator queried the Elasticsearch cluster behind Graylog. Against a uxp index, the operator ran five aggregations at once over sender, receiver, service, user and success fields, which Hunt.io read as evidence that the schema "was already known." The indices held 6,833,058 documents, but the queries returned aggregate counts only, and Hunt.io found no export tools or uploads in a shell history of 1,682 lines. "That is absence of evidence, not proof nothing moved," the researchers wrote. Forty-six minutes after the stager, the same host fetched the operator's SSH tunnel keypair, which Hunt.io described as a pivot setup rather than persistence.

An earlier staging server ran predecessors of the same script against a second Ukrainian organization whose host serves the UXP Verifier page, and on Aug. 24 that target fetched the stager six seconds after the trigger as well. A script then opened an SSH tunnel forwarding port 4000, the UXP management interface. Hunt.io said nothing in the capture shows what crossed it.

Elsewhere the operator was less effective. Seven of eight exploit directories were unmodified public proofs of concept, a FortiGate SSL VPN touched 170 times with six different tools never yielded access, and the operator's one piece of original research, against a MikroTik RouterOS flaw, targeted a binary that does not contain the bug. The open directory itself served 15,254 requests to 224 addresses, and third parties took the operator's tunnel private key 27 seconds before the victim did.

What defenders should do

• Alert on POST requests to Graylog's /api/system/sessions that contain a ${jndi: substring in the username field together with an X-Requested-By: cli header, and patch or isolate any Graylog instance still exposed to Log4Shell.
• Alert on any child process spawned by the Graylog Java service; per Hunt.io, that is the only reliable host signal for this gadget chain.
• Add a content match for the template name ysoserial/payloads/util/Gadgets$StubTransletPayload in network and file inspection.
• Keep UXP and X-Road security-server management ports, especially 4000, off the internet, and review which logging clusters sit beside data-exchange servers.
• Retrohunt for 31[.]77[.]220[.]141 and 85[.]239[.]144[.]170 and for the port pattern 8888 with 1389 and 8890, which Hunt.io said has no common legitimate use.