INJ3CTOR3 Campaign Adds Credential Theft to FreePBX Toll-Fraud Implant

Oct 28, 2026 · Original article ↗

Summary

Cyble reports that September 2026 INJ3CTOR3 builds of the JOMANGY FreePBX implant upload 17 configuration files to two staging hosts, exposing SIP, AMI, database and mail credentials; it details detection and cleanup steps.

Key points

Cyble’s comparison of April and September artifacts found code that uploads 17 FreePBX, Issabel, Elastix and Postfix configuration files to both staging hosts. The researchers saw the upload behavior in code, but did not capture credentials in transit.
The stolen configuration files may expose SIP trunk, extension, AMI, database and mail-relay credentials. Cyble says stolen trunk credentials could let an operator place calls from outside the infected PBX.
The September builds rotate webshell watermarks, a gate hash and staging details, making detections based only on earlier identifiers unreliable.
The implant uses self-rebuilding cron jobs and multiple persistence channels; its takeover script also wipes logs and histories, complicating investigation.
In a lab, an encoded-space request returned a working webshell even though the access log recorded only the requested path. A directly added Asterisk trunk also carried calls while absent from the FreePBX console.
Cyble recommends behavior-based monitoring, auditing Asterisk configuration and registrations, preserving evidence, cleaning or rebuilding the host, and rotating credentials only after the host is clean.

Article Details

Attack Vectors: The reported campaign scans exposed Asterisk-based PBXs and has used exploitation or brute force to gain access; Check Point Research reported that an earlier INJ3CTOR3 operation exploited CVE-2019-19006 in FreePBX.
After access, the operator deploys password-gated PHP webshells and uses cron jobs, shell-profile stagers, and a boot-time stager to maintain access and restore removed components.
The k.php implant reads 17 PBX, database, AMI, and mail-relay configuration files and repeatedly uploads them by HTTP POST to two staging hosts.
The report says stolen SIP trunk credentials can let the operator register with a carrier and place calls as the victim from another machine, even after the infected host is cleaned.
A crafted .htaccess rule lets requests containing encoded whitespace reach config.php and return the webshell without naming the webshell in the request.
Defensive Notes: Isolate suspected hosts or restrict outbound traffic; block both reported staging IPs in both directions, while recognizing that the operator may move infrastructure.
Rebuild from a clean image where feasible. If cleaning in place, remove cron persistence and its backups first, then address login and boot triggers, accounts and SSH, and webshells.
Rotate the secrets in the 17 identified configuration files only after the host is clean; include SIP trunk and extension secrets, AMI and database credentials, platform-admin credentials, and SMTP relay credentials.
Ask carriers to alert on trunk registrations from outside the organization's IP ranges and on premium or international calls, off-hours activity, and unusual concurrency; consider spend caps and destination blocks.
Check web-root .htaccess files, cron jobs, hidden files, UID-0 accounts, and Asterisk configuration files directly; compare Asterisk trunks and registrations with the FreePBX console.
Monitor for PBX configuration-file reads followed by outbound POSTs, recurring contacts to staging infrastructure, encoded-whitespace requests returning 200, and log or history deletion.
Applying the CVE-2025-57819 fix may prevent new exploitation, but the cited Sangoma advisory does not describe it as cleaning an already compromised system.

Indicators of compromise

Type	Indicator	Context
IPV4	`160[.]119[.]69[.]4`	Reported second staging host and credential collector used for plain-text commands and credential uploads.
IPV4	`45[.]95[.]147[.]178`	Reported staging host used for base64-encoded commands and credential uploads.
MD5	`8b3a1d970fda0c17a0b785a990fb7b6a`	Reported current MD5 gate hash shared by the JOMANGY and ZenharR webshells.
SHA256	`1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9`	SHA-256 of the reported k.php implant associated with 160[.]119[.]69[.]4.
SHA256	`38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838`	SHA-256 of the reported k.php implant associated with 45[.]95[.]147[.]178.
SHA256	`aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1`	SHA-256 of the reported wr.php implant associated with 160[.]119[.]69[.]4.
SHA256	`adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c`	SHA-256 of the reported JOMANGY webshell from the 45[.]95[.]147[.]178 build.
SHA256	`b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b`	SHA-256 of the reported wr.php implant associated with 45[.]95[.]147[.]178.
SHA256	`c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d`	SHA-256 of the reported /x takeover script, identical on both staging hosts.
SHA256	`d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672`	SHA-256 of the reported JOMANGY webshell from the 160[.]119[.]69[.]4 build.
URL	`hxxp[:]//160[.]119[.]69[.]4/hima_data/index.php`	Reported credential-upload endpoint on the second staging host.
URL	`hxxp[:]//45[.]95[.]147[.]178/hima_data/index.php`	Reported credential-upload endpoint on the staging host.