Cyble Says the INJ3CTOR3 FreePBX Implant Now Uploads SIP Trunk and Database Credentials From 17 Configuration Files Every Minute, So Rebuilding an Infected Phone System No Longer Stops the Toll Fraud

SINGAPORE - The operators behind a six-year-old toll-fraud campaign against internet-facing phone systems have changed what they take, according to research published Wednesday by Cyble. Their implant for FreePBX, Issabel and Elastix servers now copies the SIP trunk, Asterisk Manager Interface, database and mail-relay credentials off the box every minute it runs, which Cyble says means a cleaned or rebuilt server can still be defrauded through the carrier account those secrets unlock.

Cyble Research and Intelligence Labs, or CRIL, documented the actor's JOMANGY webshell generation in May. In the new report, it compares those April artifacts with files collected on Sept. 9 from the operator's staging servers. INJ3CTOR3 has abused Asterisk-based phone systems since at least 2020; Check Point Research named the operation that November, when it was exploiting CVE-2019-19006 in FreePBX.

Seventeen files, every minute

The September version of the installer script, k.php, ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to a /hima_data/index.php collector, one line for each staging host. Three of the cron beacons fetch and run k.php every minute, so the upload repeats for as long as the host stays infected. Cyble warns that rotating credentials on a host that is still infected hands the new secrets to the operator within minutes.

The files cover chan_sip and PJSIP trunk and extension secrets, AMI users in manager.conf, the FreePBX and platform configuration that holds the database password, and the Postfix SMTP relay account. Previously, Cyble says, the fraud ran through the victim's own PBX and landed in its call records, so removing the implant stopped it. With a stolen trunk secret, the operator can register to the carrier from any machine and place calls as the victim, unless the carrier restricts the trunk to the victim's IP addresses. "A successful disinfection stops the first route; only rotation stops the second," the researchers wrote.

The September build talks to two staging hosts, 45[.]95[.]147[.]178 and a new one, 160[.]119[.]69[.]4. Commands written in plain text point to the new address, while base64-encoded commands still use the old one, so Cyble advises decoding every base64 string in crontabs and shell profiles before deciding which hosts a server talks to. Both hosts stopped responding in late September, Cyble said, but infected PBXs keep trying to upload credentials every minute to addresses that could be reassigned. Cyble saw the uploads in code, did not capture one in transit and holds no victim list.

The indicators defenders were given have changed

The operator rotated the values from earlier reporting. Cyble's May report advised hunting for the watermark trace_e1ebf9066a951be519a24140711839ea; the September builds carry a different value per build, including trace_bd42a8a0d23ae16c85dede7d2abaec05. The MD5 gate hash shared by the JOMANGY and ZenharR webshells moved from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Behind the gate, a panel button builds a FreePBX administrator session from the product's own classes, so changing the admin password does not lock the operator out.

Two other findings bear on investigations. k.php writes a seven-line .htaccess file to /var/www/html/admin/views/ that routes requests whose path begins with an encoded space or tab to a webshell copy, and because the access log records only the requested path, a search for the webshell's filename can come back empty on a host that is serving it. In a lab test, Cyble also wrote a trunk directly into /etc/asterisk/pjsip_custom.conf and placed a call through it while the FreePBX Trunks page showed no records. Cyble says it did not see the campaign plant such a trunk, but recommends auditing trunks from the Asterisk command line and comparing them with the console.

Detecting it without indicators, and cleaning in order

Because hashes, watermarks, gate values and hosts change between builds, Cyble recommends asking who put a file on disk rather than whether it is known to be bad. It points PBX administrators to beagle.sh, a report-only triage script, and lists 11 behaviors for teams with telemetry, including crond spawning a shell that downloads and runs a file, the web server account spawning a shell, chattr or touch -r applied to files in the web root, 12 PHP files written in the same second, a PBX contacting a staging host roughly every 60 seconds, requests with leading encoded whitespace that return 200 for paths not on disk, AMI or CLI calls outside the dial plan and premium or off-hours call records. In its own detonation, backdoor accounts were created and deleted 27 seconds apart.

Cleanup is where victims have struggled. Cyble cites Shadowserver data showing more than 900 compromised FreePBX instances in February 2026, more than 700 of them still compromised in May, and notes that Sangoma's advisory for CVE-2025-57819 says the patch prevents new exploitation but does not clean a compromised system. Deleting the webshell fails because cron re-runs k.php within minutes, and a password change misses backdoor accounts that bypass the FreePBX login.

The report's order of operations starts with evidence. Cut the host off from the internet, or block everything outbound except the SIP carrier, then capture crontabs and their eight hidden backups, account files, shell profiles, the web root with file attributes, the FreePBX user table, call records and the Asterisk log, and ask the carrier to preserve its records, because the takeover script truncates and deletes logs and clears histories. Then clean from the system layer up: cron and its spares, login and boot triggers, extra accounts and the SSH configuration, then the 12 webshell copies, the .htaccess file and the rogue admin row. Only then, Cyble says, rotate the secrets in all 17 files and every account on the host. Rebuilding from a clean image remains the most reliable fix.