← All articles

VirLabs Blog

Tracing SIXZUT and JITTERLY in the wild

VirLabs links additional JITTERLY samples to a populated SIXZUT configuration and artifacts reported in HestiaCP compromises. The findings complement Acronis and GreyNoise research into related activity around 981666.xyz.

On September 13, Acronis published an investigation into Red Heron, an actor exploiting vulnerable Gitea servers. Alongside the campaign, they documented a Linux implant named JITTERLY and its companion rootkit, SIXZUT. Digging around, I found additional public samples and used our platform to analyze them. VirLabs adds a populated rootkit configuration, additional endpoints, and a particularly interesting connection to compromises reported by HestiaCP administrators several months earlier.

The SIXZUT sample I found is configured to conceal and relaunch two agents, __hesti and __root. Both installation paths appear in the HestiaCP forum reports discussed below. This leaves us with JITTERLY samples corresponding to both entries and matching C2 endpoints. The __hesti sample contains another SIXZUT binary already in my collection.

The rootkit sample analyzed here has SHA-256 f9491b781edc2710f419a5bf70c5439fdb0d2a9d6f509edf9ff4819edf0366b3 (VirLabs report). Its family identification rests on a distinctive combination: the ADLGTBL1 configuration magic, an 18,704-byte encrypted table, 584-byte records, CRC32 validation, the /tmp/.X11-unix.lk lock, and the agent relaunch convention using -nodel (matching the SIXZUT design documented by Acronis).

Acronis's extracted rootkit had an unpopulated hiding table. This sample has two enabled records:

Agent nameConfigured endpointExpected executable
__hestip1.981666[.]xyz:6443/usr/lib/__hesti/__hesti
__rootp2.981666[.]xyz:8080/usr/lib/__root/__root

VirLabs recovered these records from the AES-128-CTR-encrypted configuration and reported a matching CRC32. They are consumed by the rootkit's initialization routine: the names drive process detection and concealment, while the endpoints populate its network-hiding rules. When loaded into a root process, the library checks whether the configured agents are running. For a missing agent, it checks the corresponding executable, daemonizes, and launches it with -nodel. Its hooks also suppress matching directory entries, conceal process listings and network connections, and refuse signals sent through the intercepted kill() function.

This gives us a concrete configuration in which one rootkit supports two agents. The name __hesti becomes more interesting when compared with a HestiaCP support thread from May 2026. On May 24, an administrator describing unauthorized web-terminal access on May 21 reported three artifacts:

/usr/lib/__hesti/__hesti
/lib/x86_64-linux-gnu/libnss_cache.so.2
/etc/ld.so.preload

On June 12, another participant reported /usr/lib/__root/__root. Both agent paths are present in our SIXZUT configuration. The library basename also matches its concealment logic: the rootkit explicitly hides libnss_cache.so.2, its .nss_cache.init state file, and the preload configuration. The May report describes repeated failing DNS lookups for a hostname resembling p1.<six digits>.xyz, consistent with the shape of p1.981666[.]xyz, although the administrator did not provide that exact domain.

Following the domain led to a sample with SHA-256 82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb (VirLabs report). Analysis of the binary recovered an authenticated configuration specifying p1.981666[.]xyz:6443. This matches the endpoint associated with __hesti in the separately analyzed rootkit. The sample is another JITTERLY build; its configuration schema, MessagePack protocol, AES-GCM session exchange, and rootkit management interface closely match the __root sample. VirLabs also decrypted its embedded rootkit and recovered a shared object with SHA-256 295133156b6a7d95b9c92f832f49e35235f1fbd3906e75c9202ef4cd65d1018c (another SIXZUT sample).

I would describe the HestiaCP incidents as strongly linked tooling activity. I suspect the incidents belong to the same broader activity, but the evidence is stronger for the toolset than for attribution to Red Heron.

There is a second connection worth revisiting. In July, dmpdump analyzed an unattributed Linux implant associated with iot.981666[.]xyz:8080, later noting similarities with Adaptix's Gopher agent protocol. Acronis explicitly cites that research.

GreyNoise's September 21 report provides further context. It links an actor to Red Heron through overlapping infrastructure, malware, and exploitation activity, while allowing that the actors could be related rather than identical. During June 12 attempts against UniFi devices, GreyNoise observed a backdoor using p3.981666[.]xyz:6379. Activity beyond Gitea was therefore already documented; the HestiaCP artifacts and recovered configurations add another connection.

EndpointSource and role
iot.981666[.]xyz:8080C2 in dmpdump's July analysis
s2.981666[.]xyz:8082C2 reported by Acronis
p3.981666[.]xyz:6379Backdoor C2 reported by GreyNoise during UniFi exploitation attempts
p1.981666[.]xyz:6443__hesti JITTERLY C2 and matching SIXZUT hiding rule
p2.981666[.]xyz:8080__root JITTERLY C2 and matching SIXZUT hiding rule

For __root, the JITTERLY sample has SHA-256 663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c. It installs itself at /usr/lib/__root/__root when running as root, installs an LD_PRELOAD component named libnss_cache.so.2, manages .nss_cache.init, and uses p2.981666[.]xyz:8080 as its C2.

The two agents share the same configuration structure but use different connection timing:

Configuration field__hesti__root
type24210525632421052563
addressesp1.981666[.]xyz:6443p2.981666[.]xyz:8080
banner_size77
conn_timeout3030
conn_count10000000001000000000
sleep_delay60600
jitter3050

The recovered delay calculations yield approximately 42–60 seconds for __hesti and five to ten minutes for __root before connection attempts in beacon mode. Failed connections use a 30-second retry delay, with a retry count large enough to be effectively indefinite in practice. Different timing and endpoints distinguish the configurations, but do not really explain why both agents were included in the same rootkit table.

The transport is encrypted reverse TCP, with a configured seven-byte server banner before the encrypted exchange. The implants serialize messages with MessagePack and encrypt them with AES-128-GCM, preceded by a four-byte big-endian length. Initial registration carries a newly generated session key under an embedded bootstrap key; subsequent traffic uses the session key. The port numbers should not be mistaken for evidence of HTTP or TLS.

Another specific overlap with dmpdump's sample is the host identifier. In __root, VirLabs recovered a SHA-1-based construction from the following concatenated inputs:

"nginx" + machine-id (or boot-id) + username + non-loopback MAC + "reverse"

The implant takes the first digest word and applies an endian conversion. The __hesti analysis identifies the same fingerprint inputs. There is also a useful difference in the registration data: dmpdump observed rootkit_scheme fixed at zero in the sample they examined. Both samples analyzed here support ldpreload and implement rootkit installation and management. The __root command handlers include checking installation, uninstalling the component, enumerating hiding-rule groups, updating them, and removing groups by prefix. This connects the agent's tasking interface to the configurable concealment behavior visible in SIXZUT.

The breadth of this activity raises a question about the operator's role. My working hypothesis is that acquiring and maintaining infrastructure may be a substantial part of the job: vulnerable servers turned into staging points and proxies, potentially supporting an operational relay box (ORB) network. JITTERLY's TCP forwarding and persistent access would be useful for that purpose, although those capabilities also serve ordinary intrusions. Acronis reports theft of hundreds of repositories from an industrial automation company, including SCADA/HMI code, and attempted collection of complete VM images. GreyNoise documents theft of more than 18,000 sensitive government records. I would definitely expect an actor involved in mass 1-day weaponization to opportunistically collect intelligence when they stumble on a juicy target.

Indicators of Compromise

663a8088faca8e126a11648f5671fcf4eaf96435e10daf63a1d1b17d8385154c  JITTERLY (__root)
82d072ab03d90c0131b06a576eadf2c986a51f0de986d50db4e49be01bf125cb  JITTERLY (__hesti)
f9491b781edc2710f419a5bf70c5439fdb0d2a9d6f509edf9ff4819edf0366b3  SIXZUT (populated two-agent configuration)
295133156b6a7d95b9c92f832f49e35235f1fbd3906e75c9202ef4cd65d1018c  SIXZUT (extracted from __hesti)
3992cff217d615b321e0844bf4a44942891653418b79ef42ee0abe07c90264b4  SIXZUT
64677002011bc2e4bc642a4154a20fdb95620ebd0144b98fc60f917901ec8b92  SIXZUT
c285df843c35392214d129818b3634f1f134bd568a5f502d629cb07dee18a62e  SIXZUT
c19b185a1404317fbf711c7f596d39260d3d080c08ca0f93b4df322d432ecd83  SIXZUT

p1.981666[.]xyz:6443    JITTERLY __hesti
p2.981666[.]xyz:8080    JITTERLY __root
iot.981666[.]xyz:8080   Implant analyzed by dmpdump
s2.981666[.]xyz:8082    JITTERLY C2 reported by Acronis
p3.981666[.]xyz:6379    Backdoor C2 reported by GreyNoise
104.223.65[.]148        Current address of `p2` and `voas`
104.225.153[.]141       Current address of s2–s9, budi, bug, erp, and xyz; historical address of p1
203.88.123[.]148        Current address of iot, root, s0, and s1
104.225.156[.]244       Historical address of iot, root, and bug