From Langflow to Monero: Inside CVE-2026-33017 Cryptominer
From Langflow to Monero: Inside CVE-2026-33017 Cryptominer
Stage 2: isp.sh – the dropper that prepares the ground
isp.sh is a bash script served from 83[.]142[.]209[.]214. Its job is to download the lambsys binary, execute it, and spread to every SSH-reachable host that the victim can authenticate to. It does not touch a single security control: no firewall disablement, no SELinux manipulation, and no AppArmor suppression.
The script begins by verifying if the miner is already running. If it is, it exits immediately. Otherwise, it creates a hidden persistence directory at /var/tmp/.xlamb (survives reboots, unlike /tmp) and checks whether the binary already exists there. If it does, the script re-executes it and skips straight to lateral movement. For a fresh infection, it downloads an elf file named lambsys via curl, falling back to wget if curl is unavailable. If neither tool exists, the script exits. After downloading the file, the script runs chmod +x on the binary and launches it in the background with nohup.
The script’s last action is to turn isp.sh into an SSH-key-reuse worm. The function finds targets in two ways:
- By checking for id_rsa, id_ed25519, or id_dsa in ~
/.ssh/ and parsing ~/.ssh/known_hostsfor every host the victim has previously connected to - By querying SSH_AUTH_SOCK to extract hosts from loaded key fingerprints via ssh-add -l
The agent technique catches passphrase-protected or hardware-token keys that never exist on disk. For each target, the function runs two delivery methods in parallel:
- Pull method: SSH in, curl lambsys from the C&C, then execute
- Push method: SCP the local copy, SSH in, then execute. The push works even if the target has no outbound internet access.
All SSH connections use BatchMode=yes, ConnectTimeout=5, and StrictHostKeyChecking=no, so the worm never blocks on a password prompt or host-key confirmation.
The impact scales directly with Langflow’s deployment posture. If Langflow runs as root on a continuous integration and continuous delivery (CI/CD) runner with known_hosts containing hundreds of production targets, isp.sh reaches all of them. If it runs as an unprivileged service account, the worm might reach nothing. For any incident response team that finds lambsys artifacts, this is the key scoping detail, and they should treat the discovery as an SSH-key-exposure incident and not a single-host mining incident.
Stage 3: lambsys.elf on contested ground
Before diving into runtime behavior, one static detail about the binary itself is worth noting. The lambsys sample in our analysis is not the first version of this tool to exist. A sample from a previous generation was compiled on May 25, 2024, roughly 22 months before the sample delivered in this campaign.
That earlier build had a substantially higher AV detection rate at the time of its original emergence, which tells us two things about the operator:
- They have been iterating on this family for at least two years.
- The gap in detection rate between generations is the result of deliberate rebuild effort, recompiling with new Go toolchain versions, repacking with UPX variants, and shuffling strings to evade signature-based AV.
Nothing in the lineage suggests a new threat actor. This is a maintained toolset whose current low detection rate is the product of ongoing maintenance, not novelty.
The 2024 sample is largely similar to the 2026 build in its overall functionality. The runtime behaviors described in the sections below are confirmed from our analysis of the 2026 build. The deltas span packaging and protocol. On the packaging side, it’s a 48% smaller binary repacked with a newer UPX (4.24 vs. 3.96), a detection rate drop from 31/66 to 4/66 on VirusTotal, sandbox-stalling sleeps (T1497), and a shift to a multistage delivery architecture via isp.sh.
On the protocol side, the C&C rotated from 94[.]156[.]64[.]241 to 83[.]142[.]209[.]214, the beacon endpoint renamed from /r.php to /status.php, and the status payload replaced the victim’s public IP with a Unix timestamp, a deliberate OPSEC improvement. The full protocol comparison is in the Lineage section below.
One more static detail points at attribution. The 95-character XMR wallet used by the procq miner is campaign-unique. Zero other binaries in the broader public corpus embed this address. Commodity-focused threat actors such as Kinsing and TeamTNT reuse wallets across dozens of samples. A wallet being tied to exactly one binary family suggests a standalone operator, not a group affiliate.
The kill list reveals how deeply the operator knows the Linux cryptomining landscape. Targets include kingsin and kinsin (typo variants of Kinsing, copy-pasted through generations of miner tooling), kthreaddi (a typosquat of the legitimate kthreadd kernel thread), and dozens more.
The attributions span at least five rival families:
- Kinsing (kdevtmpfsi, kingsin, kinsin)
- WatchDog (pdefenderd, updatecheckerd, meminitsrv, dbused, phpguard)
- Rocke/KORKERDS (
/tmp/.x/kworker) - Outlaw (hezb, bashirc)
- Generic pool-name catches (e.g., xmrig, monero, moneroocean, supportxmr, nanopool, c3pool, crypto-pool, miner)
This is an operator who has read the research and written a kill script to take them all out.
Monero mining on a compromised host is a zero-sum CPU game. An operator who wants to maximize revenue does not share. lambsys burns the first ten seconds of every infection, proving exclusive control of the hardware.
The name-based kill list is not the only elimination vector. First, lambsys terminates processes bound to 12 specific mining pool ports via netstat -anp | grep :<port> pipelines: 3333, 4444, 5555, 6666, 7777, 3347, 14444, 14433, 56415, 9999, 13531, and 3380. These are standard cryptocurrency mining protocol ports used by MoneroOcean, MinerGate, NiceHash, and other XMR-compatible pools. Any rival miner that is actively connected to a pool will be caught by this sweep even if its process name is not on the kill list.
Second, lambsys reads PIDs from hidden files and kills them:
/tmp/.X11-unix/01/tmp/.X11-unix/11/tmp/.X11-unix/22(using cat <file> | xargs -I % kill -9 %)/tmp/.systemd.1/tmp/.systemd.2/tmp/.systemd.3(using both the xargs pattern and a redundant kill -9 $(cat <file>) variant)
These are PID files that rival cryptominers use to track their own processes. On the other hand, lambsys weaponizes them. The /tmp/.X11-unix/ directory is a particularly notable hiding spot because it legitimately exists on any Linux system running X11, and files named 01, 11, 22 blend into the socket namespace.
A companion cleanup pass deletes rival wallet and key material: rm -rf /tmp/addre*, rm -rf /tmp/walle*, and rm -rf /tmp/keys. Taken together, the name-based kill list, the port-based and PID file-based termination, and the file cleanup constitute a four-vector rival elimination system. The operator is not just preventing competitors, but also erasing their persistence artifacts.
Even more revealing are the two userdel commands buried in the sequence:
- userdel akay
- userdel vfinder
Neither akay nor vfinder is a default Linux account. Both are backdoor usernames from prior commodity cryptocurrency-mining campaigns. The akay account traces to the Autom campaign back in 2019, which created it with root sudo on compromised Docker hosts. The only published research that documents both akay and vfinder being deleted together is TrendAI™ Research’s analysis of Trojan.SH.MALXMR.UWEKB, a 2019 shell-based cryptominer in the KORKERDS family. That sample’s dropper was called is.sh, while ours is named isp.sh. It used the same SSH-worm-via-known_hosts lateral movement. It ran the same pattern of evicting rival accounts and killing competitor processes before launching its own miner.
The resemblance is strong enough to warrant a lineage hypothesis. The KORKERDS playbook was publicly available on Pastebin, so any operator could have copied the techniques. The Go rewrite, unique wallet, and novel artifacts like init_rmount and /var/tmp/.xlamb/ all point to a distinct operator rather than a direct continuation. However, the is.sh-to-isp.sh naming, the preserved akay/vfinder eviction, and the shared SSH worm pattern make technique inheritance from the KORKERDS/MALXMR lineage the most plausible explanation for what we are looking at.
If your endpoint detection and response (EDR) solution sees a userdel akay command outside a legitimate incident response playbook, it could indicate competing cryptominer activities.
How lambsys actually runs
Before the kill list fires, lambsys raises the file-descriptor limit to 65,535 with ulimit -n. A Monero miner sustaining pool connections, watchdog subprocesses, and C&C beacons will exhaust the default 1024 FD limit within minutes. The preraise is a sign that this author has run XMRig at scale before.
lambsys also does its own antirerun check, independent of the one that isp.sh performs. The dropper calls pgrep -f “lambsys”, which loosely matches any process whose argv contains the substring. In contrast, lambsys fires pgrep -x lambsys.elf repeatedly throughout its own execution. The -x flag requires an exact match on the process basename, which tightens the gate significantly. That distinction matters to a responder triaging a pgrep hit in shell history. The binary’s strict check is the higher-fidelity signal. The dropper’s loose check can and does produce a false positive.
What follows is architecturally unusual. lambsys does not run its attack logic as Go functions. Instead, it forks a cascade of short-lived sh -c subprocesses, each executing one shell command (one pkill, one chattr, one sysctl). The design trades stealth for reliability. If one of 51 pkill commands fails, the failure is contained to that subprocess and the other 50 carry on. Shelling out every command (i.e., spawning a new shell/subprocess to run an external command) suggests an operational approach intended to maximize coverage across a heterogeneous Linux fleet.
Defense evasion in multiple security controls
Once the rival miners are dead, lambsys systematically disables the host’s security posture before it commits anything to disk that defenders could notice. The sequence targets security controls commonly used across several Linux distributions, indicating that the malware is designed to run in varied environments.
The first step is disabling the kernel’s NMI watchdog, a mechanism that detects and terminates CPU-pegging processes. It’s precisely the profile of a running Monero miner. lambsys disables it in three ways:
- sysctl kernel.nmi_watchdog=0 (runtime)
- echo ‘0’ >
/proc/sys/kernel/nmi_watchdog(fallback if sysctl is restricted) - Appending to
/etc/sysctl.conf(reboot persistence)
Firewalls come next. ufw disable takes out Ubuntu’s Uncomplicated Firewall, and iptables -F flushes all filter-table rules beneath it. Combined, these remove any egress restrictions that might prevent the miner from reaching its mining pool or the C&C from reaching 83[.]142[.]209[.]214.
AppArmor, Ubuntu’s default Mandatory Access Control framework, is stopped with service apparmor stop and taken out of the boot path with systemctl disable apparmor. If present, the /etc/rcS.d/K01apparmor kill-script symlink ensures the MAC stays dead across reboots.
SELinux, the RHEL/CentOS equivalent, gets the same treatment: setenforce 0 disables enforcement at runtime, and echo SELINUX=disabled >/etc/selinux/config makes it permanent. That the operator targets both MAC frameworks indicates that the deployment script is built for a heterogeneous Linux fleet: Debian-family and Red Hat-family hosts alike.
One more defensive subsystem is targeted, which reveals the threat actor’s expected infrastructure. The commands service aliyun.service stop and systemctl disable aliyun.service stop and disable Alibaba Cloud’s host-based security monitoring agent. The operator expects to land on Aliyun-hosted infrastructure and has a prebuilt evasion technique for its cloud-native security tooling.
The chattr sweep also targets SSH configuration: chattr -iae ~/.ssh/ and chattr -iae ~/.ssh/authorized_keys remove immutable and append-only attributes from the SSH directory and authorized_keys file, clearing the way for the lateral movement stage (isp.sh) to plant its key.
The broader chattr campaign suggests that the author has direct experience with rival-miner persistence. Many earlier cryptominers, particularly Kinsing, set chattr +i on their cron entries and authorized_keys to make them undeletable even by root. lambsys strips that protection preemptively in a systematic sweep, as shown below:
chattr -iua /tmp/
chattr -iua /var/tmp/
chattr -R -i /var/spool/cron
chattr -i /etc/crontab
chattr -i /etc/ld.so.preload
chattr -iae ~/.ssh/
chattr -iae ~/.ssh/authorized_keys
About Author
