The U.S. Department of Justice (DoJ) on Tuesday announced the seizure of a domain associated with a bulletproof hosting provider (BPH) named Virtualine.
The move was in response to the service being used to commit and facilitate prolific criminal activity, including “the advertisement of sexually explicit images of minors, the intentional disclosure of nonconsensual intimate visual depictions
Source: The Hacker News · 2026-10-28
Japan’s GMO Internet Group is offering up to $1 million in total for tips that help catch the attackers who breached its Onamae.com Desktop Cloud service, after refusing to pay an extortion demand.
The reward program opened on October 28 and pays only if a tip helps lead to an arrest or an international wanted notice. The service hosts Windows desktops used for FX trading,
Source: The Hacker News · 2026-10-28
Tailscale has released version 1.104.4 to fix flaws in its built-in SSH server that could let an attacker reach services and files on other servers that only the root user should be able to touch.
The flaws are in how Tailscale SSH forwards network connections, a job the Tailscale background process carries out with root privileges. To use them, an attacker must
Source: The Hacker News · 2026-10-28
The critical Oracle PeopleSoft bug that ShinyHunters has exploited since May is not one flaw but three chained together, the researchers who reported it said this week.
Oracle patched all three under a single identifier, CVE-2026-35273, in June. Its root is a server-side request forgery (SSRF) that reaches an internal management interface because PeopleSoft trusts its own loopback address
Source: The Hacker News · 2026-10-28
Interpol’s annual Operation Serengeti, now in its third iteration, led to 1,462 arrests across 20 African countries and the US, recovering $105 million in stolen funds.
Source: Dark Reading · 2026-10-28
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Tuesday added two vulnerabilities impacting Adobe Commerce and Magento, and Google’s Brotli decoder library to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.
The vulnerabilities are listed below –
CVE-2026-111497 (CVSS score: 9.2) – An unchecked return value vulnerability in
Source: The Hacker News · 2026-10-28
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
| Value | Type | Context |
| 45[.]95[.]147[.]178 | IPv4 | Staging host since April |
| 160[.]119[.]69[.]4 | IPv4 | Second staging host and credential collector, new |
| hxxp://45[.]95[.]147[.]178/hima_data/index.php | URL | Credential upload endpoint |
| hxxp://160[.]119[.]69[.]4/hima_data/index.php | URL | Credential upload endpoint |
| c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d | SHA256 | /x takeover script, identical on both hosts |
| 38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838 | SHA256 | k.php, 45[.]95[.]147[.]178 |
| 1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9 | SHA256 | k.php, 160[.]119[.]69[.]4 |
| b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b | SHA256 | wr.php, 45[.]95[.]147[.]178 |
| aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1 | SHA256 | wr.php, 160[.]119[.]69[.]4 |
| adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c | SHA256 | JOMANGY webshell on disk, 45[.]95[.]147[.]178 build |
| d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672 | SHA256 | JOMANGY webshell on disk, 160[.]119[.]69[.]4 build |
| trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e | String | JOMANGY watermarks, one per build |
| 8b3a1d970fda0c17a0b785a990fb7b6a | MD5 | Webshell gate hash, JOMANGY and ZenharR |
| $1$nRz1Cbtk$ | Hash prefix | Password hash set on backdoor and service accounts |
Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.
| Technique ID | Tactic | Name | Evidence |
| T1059.004 | Execution | Command and Scripting Interpreter: Unix Shell | /x and k.php run as bash scripts fetched by cron |
| T1105 | Command and Control | Ingress Tool Transfer | wget of /x, k.php and wr.php from the staging hosts |
| T1053.003 | Persistence | Scheduled Task/Job: Cron | Minute-level beacons, a restore line and a watchdog |
| T1505.003 | Persistence | Server Software Component: Web Shell | JOMANGY and ZenharR, 12 copies across the web root |
| T1546.004 | Persistence | Event Triggered Execution: Unix Shell Configuration Modification | Stager added to /root/.bash_profile and /root/.bashrc |
| T1037.004 | Persistence | Boot or Logon Initialization Scripts: RC Scripts | Stager added to /etc/rc.local |
| T1136.001 | Persistence | Create Account: Local Account | Backdoor accounts, several at UID 0 |
| T1098 | Persistence | Account Manipulation | Shared password hash set on existing accounts; FreePBX admin row inserted |
| T1027 | Stealth | Obfuscated Files or Information | base64, base64 and ROT13 layers around the webshell; base64 cron payloads |
| T1564.001 | Stealth | Hide Artifacts: Hidden Files and Directories | Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority |
| T1070.006 | Stealth | Indicator Removal: Timestomp | touch -r copies footer.php’s timestamp onto the webshell |
| T1070.003 | Stealth | Indicator Removal: Clear Command History | Shell and MySQL histories cleared |
| T1222.002 | Defense Impairment | File and Directory Permissions Modification: Linux and Mac Permissions | chattr +i and +a on webshells and crontab spares |
| T1685.006 | Defense Impairment | Disable or Modify Tools: Clear Linux or Mac System Logs | Web server, Asterisk, cron, secure and audit logs truncated, then deleted |
| T1686 | Defense Impairment | Disable or Modify System Firewall | iptables rules dropping rival actors’ addresses |
| T1496 | Impact | Resource Hijacking | Victim’s PBX and trunks used to place premium-rate calls |
| T1552.001 | Credential Access | Unsecured Credentials: Credentials In Files | k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets |
| T1119 | Collection | Automated Collection | The 17 files are collected by hardcoded commands on every k.php run |
| T1041 | Exfiltration | Exfiltration Over C2 Channel | Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts |
Source: Cyble Research · 2026-10-28
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
| Reference | Encoding | Points to |
| k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback | Plain text | 160[.]119[.]69[.]4 |
| Camouflaged cron payloads, login-triggered stager | Base64 | 45[.]95[.]147[.]178 |
| Credential upload | Base64 | Both |
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]| Request path | Status | What answered |
| /dir/zzz | 404 | Nothing |
| /dir/%20zzz, /dir/%09zzz (space, tab, etc) | 200 | config.php |
| /dir/+zzz | 404 | Nothing |
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell by its filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
| Check | What it flags |
| Packed shells | Several identical, same-size PHP files across unrelated directories |
| Locked files | chattr +i or +a under the web root or in hidden directories |
| Unowned .htaccess | An .htaccess no installed package accounts for |
| Self-rebuilding cron | A cron line that downloads a file and hands it to a shell |
| Accounts | An extra UID-0 account, or a full-permission FreePBX admin, nobody created |
| Blocklist | Addresses dropped in and out by iptables outside fail2ban’s chains |
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
| Layer | Behavior | What it catches |
| Host | crond spawns a shell that downloads a file and runs it | The takeover script on its single run, before persistence and before credentials leave |
| Host | The web server account spawns a shell | The webshell’s command box in use |
| Host | A cron child rewrites the crontab every minute without reading it first | Beacon reinstallation |
| Host | chattr +i or touch -r on a file in the web root | The lock and the borrowed timestamp |
| Host | Twelve PHP files were written to the web root in the same second | The webshell copies, as they are written; fan-out |
| Network | The PBX contacts staging host roughly every 60 seconds | The beacon’s rhythm, whatever the address |
| Network | Many configuration files read, then outbound POST requests | Credentials leaving |
| Web | A request with leading encoded whitespace returns 200 for a path not on disk | The .htaccess door |
| Decoy | Any read of a decoy config file that the implant reads, but nothing legitimate does | Credential collection, with no false positives by design |
| Phone | Channels originate over AMI or the CLI outside your dial plan | A call asking for nothing legitimate |
| Phone | CDRs with premium destinations, off-hours calling and unusual concurrency | The fraud itself |
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
| First move | Why it fails on its own |
| Delete the webshell | Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags. |
| Patch FreePBX | Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system. |
| Change the admin password | The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login. |
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Then clean, in this order
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
| Value | Type | Context |
| 45[.]95[.]147[.]178 | IPv4 | Staging host since April |
| 160[.]119[.]69[.]4 | IPv4 | Second staging host and credential collector, new |
| hxxp://45[.]95[.]147[.]178/hima_data/index.php | URL | Credential upload endpoint |
| hxxp://160[.]119[.]69[.]4/hima_data/index.php | URL | Credential upload endpoint |
| c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d | SHA256 | /x takeover script, identical on both hosts |
| 38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838 | SHA256 | k.php, 45[.]95[.]147[.]178 |
| 1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9 | SHA256 | k.php, 160[.]119[.]69[.]4 |
| b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b | SHA256 | wr.php, 45[.]95[.]147[.]178 |
| aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1 | SHA256 | wr.php, 160[.]119[.]69[.]4 |
| adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c | SHA256 | JOMANGY webshell on disk, 45[.]95[.]147[.]178 build |
| d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672 | SHA256 | JOMANGY webshell on disk, 160[.]119[.]69[.]4 build |
| trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e | String | JOMANGY watermarks, one per build |
| 8b3a1d970fda0c17a0b785a990fb7b6a | MD5 | Webshell gate hash, JOMANGY and ZenharR |
| $1$nRz1Cbtk$ | Hash prefix | Password hash set on backdoor and service accounts |
Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.
| Technique ID | Tactic | Name | Evidence |
| T1059.004 | Execution | Command and Scripting Interpreter: Unix Shell | /x and k.php run as bash scripts fetched by cron |
| T1105 | Command and Control | Ingress Tool Transfer | wget of /x, k.php and wr.php from the staging hosts |
| T1053.003 | Persistence | Scheduled Task/Job: Cron | Minute-level beacons, a restore line and a watchdog |
| T1505.003 | Persistence | Server Software Component: Web Shell | JOMANGY and ZenharR, 12 copies across the web root |
| T1546.004 | Persistence | Event Triggered Execution: Unix Shell Configuration Modification | Stager added to /root/.bash_profile and /root/.bashrc |
| T1037.004 | Persistence | Boot or Logon Initialization Scripts: RC Scripts | Stager added to /etc/rc.local |
| T1136.001 | Persistence | Create Account: Local Account | Backdoor accounts, several at UID 0 |
| T1098 | Persistence | Account Manipulation | Shared password hash set on existing accounts; FreePBX admin row inserted |
| T1027 | Stealth | Obfuscated Files or Information | base64, base64 and ROT13 layers around the webshell; base64 cron payloads |
| T1564.001 | Stealth | Hide Artifacts: Hidden Files and Directories | Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority |
| T1070.006 | Stealth | Indicator Removal: Timestomp | touch -r copies footer.php’s timestamp onto the webshell |
| T1070.003 | Stealth | Indicator Removal: Clear Command History | Shell and MySQL histories cleared |
| T1222.002 | Defense Impairment | File and Directory Permissions Modification: Linux and Mac Permissions | chattr +i and +a on webshells and crontab spares |
| T1685.006 | Defense Impairment | Disable or Modify Tools: Clear Linux or Mac System Logs | Web server, Asterisk, cron, secure and audit logs truncated, then deleted |
| T1686 | Defense Impairment | Disable or Modify System Firewall | iptables rules dropping rival actors’ addresses |
| T1496 | Impact | Resource Hijacking | Victim’s PBX and trunks used to place premium-rate calls |
| T1552.001 | Credential Access | Unsecured Credentials: Credentials In Files | k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets |
| T1119 | Collection | Automated Collection | The 17 files are collected by hardcoded commands on every k.php run |
| T1041 | Exfiltration | Exfiltration Over C2 Channel | Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts |
Source: Cyble Research · 2026-10-28
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
| Area | April | September |
| Credential Exfiltration | None | 17 files to /hima_data/index.php on both hosts |
| Staging hosts | 45[.]95[.]147[.]178 | 45[.]95[.]147[.]178 and 160[.]119[.]69[.]4 |
| webshell watermark | One value in every copy | A different value per build |
| Webshell gate hash (JOMANGY and ZenharR) | a2f6863413c4192a4abfa360577b9961 | 8b3a1d970fda0c17a0b785a990fb7b6a |
| /x takeover script | 367 lines | 620 lines, mostly added cleanup: removing rival actors’ implants and SSH keys |
| wor.php, people2.txt, _*.php status files | Present | Absent from the collection |
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
| What it unlocks | Files uploaded | Rotate |
| SIP trunks and extensions (chan_sip) | /etc/asterisk/sip.conf, sip_additional.conf, sip_registrations.conf, sip_general_additional.conf, sip_custom.conf | Every trunk secret (with your carrier) and extension secret, changed in the FreePBX GUI, since the *_additional.conf files are regenerated |
| SIP trunks and extensions (PJSIP) | /etc/asterisk/pjsip.auth.conf, pjsip.endpoint.conf, pjsip.aor.conf, pjsip.identify.conf, pjsip.transports.conf | The same secrets; review IP-based identity rules |
| Call origination without SIP | /etc/asterisk/manager.conf | Every AMI user. |
| PBX database, AMI, and platform admin | /etc/freepbx.conf, /etc/amportal.conf, /etc/asterisk/amportal.conf, /etc/issabel.conf, /etc/elastix.conf | The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there |
| Outbound mail | /etc/postfix/sasl_passwd | The SMTP relay account, with your mail provider |
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
| Reference | Encoding | Points to |
| k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback | Plain text | 160[.]119[.]69[.]4 |
| Camouflaged cron payloads, login-triggered stager | Base64 | 45[.]95[.]147[.]178 |
| Credential upload | Base64 | Both |
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]| Request path | Status | What answered |
| /dir/zzz | 404 | Nothing |
| /dir/%20zzz, /dir/%09zzz (space, tab, etc) | 200 | config.php |
| /dir/+zzz | 404 | Nothing |
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell by its filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
| Check | What it flags |
| Packed shells | Several identical, same-size PHP files across unrelated directories |
| Locked files | chattr +i or +a under the web root or in hidden directories |
| Unowned .htaccess | An .htaccess no installed package accounts for |
| Self-rebuilding cron | A cron line that downloads a file and hands it to a shell |
| Accounts | An extra UID-0 account, or a full-permission FreePBX admin, nobody created |
| Blocklist | Addresses dropped in and out by iptables outside fail2ban’s chains |
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
| Layer | Behavior | What it catches |
| Host | crond spawns a shell that downloads a file and runs it | The takeover script on its single run, before persistence and before credentials leave |
| Host | The web server account spawns a shell | The webshell’s command box in use |
| Host | A cron child rewrites the crontab every minute without reading it first | Beacon reinstallation |
| Host | chattr +i or touch -r on a file in the web root | The lock and the borrowed timestamp |
| Host | Twelve PHP files were written to the web root in the same second | The webshell copies, as they are written; fan-out |
| Network | The PBX contacts staging host roughly every 60 seconds | The beacon’s rhythm, whatever the address |
| Network | Many configuration files read, then outbound POST requests | Credentials leaving |
| Web | A request with leading encoded whitespace returns 200 for a path not on disk | The .htaccess door |
| Decoy | Any read of a decoy config file that the implant reads, but nothing legitimate does | Credential collection, with no false positives by design |
| Phone | Channels originate over AMI or the CLI outside your dial plan | A call asking for nothing legitimate |
| Phone | CDRs with premium destinations, off-hours calling and unusual concurrency | The fraud itself |
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
| First move | Why it fails on its own |
| Delete the webshell | Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags. |
| Patch FreePBX | Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system. |
| Change the admin password | The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login. |
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Then clean, in this order
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
| Value | Type | Context |
| 45[.]95[.]147[.]178 | IPv4 | Staging host since April |
| 160[.]119[.]69[.]4 | IPv4 | Second staging host and credential collector, new |
| hxxp://45[.]95[.]147[.]178/hima_data/index.php | URL | Credential upload endpoint |
| hxxp://160[.]119[.]69[.]4/hima_data/index.php | URL | Credential upload endpoint |
| c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d | SHA256 | /x takeover script, identical on both hosts |
| 38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838 | SHA256 | k.php, 45[.]95[.]147[.]178 |
| 1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9 | SHA256 | k.php, 160[.]119[.]69[.]4 |
| b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b | SHA256 | wr.php, 45[.]95[.]147[.]178 |
| aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1 | SHA256 | wr.php, 160[.]119[.]69[.]4 |
| adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c | SHA256 | JOMANGY webshell on disk, 45[.]95[.]147[.]178 build |
| d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672 | SHA256 | JOMANGY webshell on disk, 160[.]119[.]69[.]4 build |
| trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e | String | JOMANGY watermarks, one per build |
| 8b3a1d970fda0c17a0b785a990fb7b6a | MD5 | Webshell gate hash, JOMANGY and ZenharR |
| $1$nRz1Cbtk$ | Hash prefix | Password hash set on backdoor and service accounts |
Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.
| Technique ID | Tactic | Name | Evidence |
| T1059.004 | Execution | Command and Scripting Interpreter: Unix Shell | /x and k.php run as bash scripts fetched by cron |
| T1105 | Command and Control | Ingress Tool Transfer | wget of /x, k.php and wr.php from the staging hosts |
| T1053.003 | Persistence | Scheduled Task/Job: Cron | Minute-level beacons, a restore line and a watchdog |
| T1505.003 | Persistence | Server Software Component: Web Shell | JOMANGY and ZenharR, 12 copies across the web root |
| T1546.004 | Persistence | Event Triggered Execution: Unix Shell Configuration Modification | Stager added to /root/.bash_profile and /root/.bashrc |
| T1037.004 | Persistence | Boot or Logon Initialization Scripts: RC Scripts | Stager added to /etc/rc.local |
| T1136.001 | Persistence | Create Account: Local Account | Backdoor accounts, several at UID 0 |
| T1098 | Persistence | Account Manipulation | Shared password hash set on existing accounts; FreePBX admin row inserted |
| T1027 | Stealth | Obfuscated Files or Information | base64, base64 and ROT13 layers around the webshell; base64 cron payloads |
| T1564.001 | Stealth | Hide Artifacts: Hidden Files and Directories | Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority |
| T1070.006 | Stealth | Indicator Removal: Timestomp | touch -r copies footer.php’s timestamp onto the webshell |
| T1070.003 | Stealth | Indicator Removal: Clear Command History | Shell and MySQL histories cleared |
| T1222.002 | Defense Impairment | File and Directory Permissions Modification: Linux and Mac Permissions | chattr +i and +a on webshells and crontab spares |
| T1685.006 | Defense Impairment | Disable or Modify Tools: Clear Linux or Mac System Logs | Web server, Asterisk, cron, secure and audit logs truncated, then deleted |
| T1686 | Defense Impairment | Disable or Modify System Firewall | iptables rules dropping rival actors’ addresses |
| T1496 | Impact | Resource Hijacking | Victim’s PBX and trunks used to place premium-rate calls |
| T1552.001 | Credential Access | Unsecured Credentials: Credentials In Files | k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets |
| T1119 | Collection | Automated Collection | The 17 files are collected by hardcoded commands on every k.php run |
| T1041 | Exfiltration | Exfiltration Over C2 Channel | Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts |
Source: Cyble Research · 2026-10-28
In May, Cyble Research & Intelligence Labs (CRIL) documented JOMANGY, a PHP webshell generation deployed by INJ3CTOR3 with self-healing persistence channels and a built-in toll-fraud dialer.
Back then, the fraud ran through the victim’s own PBX, so removing the implant would have stopped it. Artifacts we collected from the operator’s C2 staging servers during mid-September 2026 show that this is no longer true: the installer now sends credentials off the box on every run, and a second staging host serves it.
INJ3CTOR3’s FreePBX implant now uploads the victim’s SIP trunk, AMI, database, and mail-relay credentials to the operator, so disinfecting or rebuilding an infected host no longer ends the exposure. Anyone running FreePBX, Issabel, or Elastix who suspects compromise must rotate the secrets in 17 configuration files, and only after the host is clean.
The infection and persistence code is nearly unchanged; what the operator rotated are the identifiers that were available to defenders since the last time. Each section below pairs a finding with what to do about it.
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
| Area | April | September |
| Credential Exfiltration | None | 17 files to /hima_data/index.php on both hosts |
| Staging hosts | 45[.]95[.]147[.]178 | 45[.]95[.]147[.]178 and 160[.]119[.]69[.]4 |
| webshell watermark | One value in every copy | A different value per build |
| Webshell gate hash (JOMANGY and ZenharR) | a2f6863413c4192a4abfa360577b9961 | 8b3a1d970fda0c17a0b785a990fb7b6a |
| /x takeover script | 367 lines | 620 lines, mostly added cleanup: removing rival actors’ implants and SSH keys |
| wor.php, people2.txt, _*.php status files | Present | Absent from the collection |
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
| What it unlocks | Files uploaded | Rotate |
| SIP trunks and extensions (chan_sip) | /etc/asterisk/sip.conf, sip_additional.conf, sip_registrations.conf, sip_general_additional.conf, sip_custom.conf | Every trunk secret (with your carrier) and extension secret, changed in the FreePBX GUI, since the *_additional.conf files are regenerated |
| SIP trunks and extensions (PJSIP) | /etc/asterisk/pjsip.auth.conf, pjsip.endpoint.conf, pjsip.aor.conf, pjsip.identify.conf, pjsip.transports.conf | The same secrets; review IP-based identity rules |
| Call origination without SIP | /etc/asterisk/manager.conf | Every AMI user. |
| PBX database, AMI, and platform admin | /etc/freepbx.conf, /etc/amportal.conf, /etc/asterisk/amportal.conf, /etc/issabel.conf, /etc/elastix.conf | The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there |
| Outbound mail | /etc/postfix/sasl_passwd | The SMTP relay account, with your mail provider |
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
| Reference | Encoding | Points to |
| k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback | Plain text | 160[.]119[.]69[.]4 |
| Camouflaged cron payloads, login-triggered stager | Base64 | 45[.]95[.]147[.]178 |
| Credential upload | Base64 | Both |
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]| Request path | Status | What answered |
| /dir/zzz | 404 | Nothing |
| /dir/%20zzz, /dir/%09zzz (space, tab, etc) | 200 | config.php |
| /dir/+zzz | 404 | Nothing |
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell by its filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
| Check | What it flags |
| Packed shells | Several identical, same-size PHP files across unrelated directories |
| Locked files | chattr +i or +a under the web root or in hidden directories |
| Unowned .htaccess | An .htaccess no installed package accounts for |
| Self-rebuilding cron | A cron line that downloads a file and hands it to a shell |
| Accounts | An extra UID-0 account, or a full-permission FreePBX admin, nobody created |
| Blocklist | Addresses dropped in and out by iptables outside fail2ban’s chains |
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
| Layer | Behavior | What it catches |
| Host | crond spawns a shell that downloads a file and runs it | The takeover script on its single run, before persistence and before credentials leave |
| Host | The web server account spawns a shell | The webshell’s command box in use |
| Host | A cron child rewrites the crontab every minute without reading it first | Beacon reinstallation |
| Host | chattr +i or touch -r on a file in the web root | The lock and the borrowed timestamp |
| Host | Twelve PHP files were written to the web root in the same second | The webshell copies, as they are written; fan-out |
| Network | The PBX contacts staging host roughly every 60 seconds | The beacon’s rhythm, whatever the address |
| Network | Many configuration files read, then outbound POST requests | Credentials leaving |
| Web | A request with leading encoded whitespace returns 200 for a path not on disk | The .htaccess door |
| Decoy | Any read of a decoy config file that the implant reads, but nothing legitimate does | Credential collection, with no false positives by design |
| Phone | Channels originate over AMI or the CLI outside your dial plan | A call asking for nothing legitimate |
| Phone | CDRs with premium destinations, off-hours calling and unusual concurrency | The fraud itself |
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
| First move | Why it fails on its own |
| Delete the webshell | Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags. |
| Patch FreePBX | Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system. |
| Change the admin password | The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login. |
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Then clean, in this order
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
| Value | Type | Context |
| 45[.]95[.]147[.]178 | IPv4 | Staging host since April |
| 160[.]119[.]69[.]4 | IPv4 | Second staging host and credential collector, new |
| hxxp://45[.]95[.]147[.]178/hima_data/index.php | URL | Credential upload endpoint |
| hxxp://160[.]119[.]69[.]4/hima_data/index.php | URL | Credential upload endpoint |
| c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d | SHA256 | /x takeover script, identical on both hosts |
| 38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838 | SHA256 | k.php, 45[.]95[.]147[.]178 |
| 1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9 | SHA256 | k.php, 160[.]119[.]69[.]4 |
| b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b | SHA256 | wr.php, 45[.]95[.]147[.]178 |
| aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1 | SHA256 | wr.php, 160[.]119[.]69[.]4 |
| adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c | SHA256 | JOMANGY webshell on disk, 45[.]95[.]147[.]178 build |
| d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672 | SHA256 | JOMANGY webshell on disk, 160[.]119[.]69[.]4 build |
| trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e | String | JOMANGY watermarks, one per build |
| 8b3a1d970fda0c17a0b785a990fb7b6a | MD5 | Webshell gate hash, JOMANGY and ZenharR |
| $1$nRz1Cbtk$ | Hash prefix | Password hash set on backdoor and service accounts |
Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.
| Technique ID | Tactic | Name | Evidence |
| T1059.004 | Execution | Command and Scripting Interpreter: Unix Shell | /x and k.php run as bash scripts fetched by cron |
| T1105 | Command and Control | Ingress Tool Transfer | wget of /x, k.php and wr.php from the staging hosts |
| T1053.003 | Persistence | Scheduled Task/Job: Cron | Minute-level beacons, a restore line and a watchdog |
| T1505.003 | Persistence | Server Software Component: Web Shell | JOMANGY and ZenharR, 12 copies across the web root |
| T1546.004 | Persistence | Event Triggered Execution: Unix Shell Configuration Modification | Stager added to /root/.bash_profile and /root/.bashrc |
| T1037.004 | Persistence | Boot or Logon Initialization Scripts: RC Scripts | Stager added to /etc/rc.local |
| T1136.001 | Persistence | Create Account: Local Account | Backdoor accounts, several at UID 0 |
| T1098 | Persistence | Account Manipulation | Shared password hash set on existing accounts; FreePBX admin row inserted |
| T1027 | Stealth | Obfuscated Files or Information | base64, base64 and ROT13 layers around the webshell; base64 cron payloads |
| T1564.001 | Stealth | Hide Artifacts: Hidden Files and Directories | Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority |
| T1070.006 | Stealth | Indicator Removal: Timestomp | touch -r copies footer.php’s timestamp onto the webshell |
| T1070.003 | Stealth | Indicator Removal: Clear Command History | Shell and MySQL histories cleared |
| T1222.002 | Defense Impairment | File and Directory Permissions Modification: Linux and Mac Permissions | chattr +i and +a on webshells and crontab spares |
| T1685.006 | Defense Impairment | Disable or Modify Tools: Clear Linux or Mac System Logs | Web server, Asterisk, cron, secure and audit logs truncated, then deleted |
| T1686 | Defense Impairment | Disable or Modify System Firewall | iptables rules dropping rival actors’ addresses |
| T1496 | Impact | Resource Hijacking | Victim’s PBX and trunks used to place premium-rate calls |
| T1552.001 | Credential Access | Unsecured Credentials: Credentials In Files | k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets |
| T1119 | Collection | Automated Collection | The 17 files are collected by hardcoded commands on every k.php run |
| T1041 | Exfiltration | Exfiltration Over C2 Channel | Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts |
Source: Cyble Research · 2026-10-28
In May, Cyble Research & Intelligence Labs (CRIL) documented JOMANGY, a PHP webshell generation deployed by INJ3CTOR3 with self-healing persistence channels and a built-in toll-fraud dialer.
Back then, the fraud ran through the victim’s own PBX, so removing the implant would have stopped it. Artifacts we collected from the operator’s C2 staging servers during mid-September 2026 show that this is no longer true: the installer now sends credentials off the box on every run, and a second staging host serves it.
INJ3CTOR3’s FreePBX implant now uploads the victim’s SIP trunk, AMI, database, and mail-relay credentials to the operator, so disinfecting or rebuilding an infected host no longer ends the exposure. Anyone running FreePBX, Issabel, or Elastix who suspects compromise must rotate the secrets in 17 configuration files, and only after the host is clean.
The infection and persistence code is nearly unchanged; what the operator rotated are the identifiers that were available to defenders since the last time. Each section below pairs a finding with what to do about it.
INJ3CTOR3 has been abusing Asterisk-based phone systems for toll fraud since at least 2020. Check Point Research named the operation that November, when it exploited CVE-2019-19006 in FreePBX and used a basic webshell to read amportal.conf and sip_additional.conf by hand. Unit 42 reported a related operation against Elastix in 2022, Fortinet documented the EncystPHP webshell in January 2026, and our May report covered JOMANGY.
The playbook has held for six years: scan for exposed PBXs, exploit or brute-force a way in, plant a password-gated webshell, and dial out at the victim’s expense. Figure 1 below shows the chain as it stands in the September build, now including the credential upload back to the staging hosts.
We compared the April artifacts behind our May report with the 9 September collection from both staging hosts, after decoding every layer.
| Area | April | September |
| Credential Exfiltration | None | 17 files to /hima_data/index.php on both hosts |
| Staging hosts | 45[.]95[.]147[.]178 | 45[.]95[.]147[.]178 and 160[.]119[.]69[.]4 |
| webshell watermark | One value in every copy | A different value per build |
| Webshell gate hash (JOMANGY and ZenharR) | a2f6863413c4192a4abfa360577b9961 | 8b3a1d970fda0c17a0b785a990fb7b6a |
| /x takeover script | 367 lines | 620 lines, mostly added cleanup: removing rival actors’ implants and SSH keys |
| wor.php, people2.txt, _*.php status files | Present | Absent from the collection |
Unchanged: the decoded webshell panel, the encoding chain (base64 in the shell script, base64 again in PHP, then ROT13), the persistence channels, the backdoor account password hash, and the borrowed timestamp. Behavioral detections built on our May report still apply.
The September k.php ends with two new base64-encoded lines, each holding 17 curl commands that upload one configuration file apiece to /hima_data/index.php, one line per staging host (See Figure 2 below). The paths are typed out by hand and cover FreePBX, Issabel, and Elastix layouts. The collector path echoes hima, a backdoor account the takeover script creates. The name goes back further: Check Point’s 2020 INJ3CTOR3 report shows a Telegram post by a user called Hima sharing a tool that scans and cracks SIP ranges, saving its output as HimaResults.
Three of the cron beacons fetch and run k.php every minute (the others every two or three minutes), so the upload repeats every minute during the infection. Rotating credentials on a still-infected host hands the new secrets to the operator within minutes.
| What it unlocks | Files uploaded | Rotate |
| SIP trunks and extensions (chan_sip) | /etc/asterisk/sip.conf, sip_additional.conf, sip_registrations.conf, sip_general_additional.conf, sip_custom.conf | Every trunk secret (with your carrier) and extension secret, changed in the FreePBX GUI, since the *_additional.conf files are regenerated |
| SIP trunks and extensions (PJSIP) | /etc/asterisk/pjsip.auth.conf, pjsip.endpoint.conf, pjsip.aor.conf, pjsip.identify.conf, pjsip.transports.conf | The same secrets; review IP-based identity rules |
| Call origination without SIP | /etc/asterisk/manager.conf | Every AMI user. |
| PBX database, AMI, and platform admin | /etc/freepbx.conf, /etc/amportal.conf, /etc/asterisk/amportal.conf, /etc/issabel.conf, /etc/elastix.conf | The database password (AMPDBPASS), the MySQL root password, and any AMI password stored there |
| Outbound mail | /etc/postfix/sasl_passwd | The SMTP relay account, with your mail provider |
This opens a second route to fraud. Our May report covered calls placed through the webshell, which require the shell to be alive and to land in the victim’s own call records. With a stolen trunk secret, the operator can register to the carrier from any machine and call as the victim, leaving nothing on the host, unless the carrier also restricts the trunk to the victim’s IP addresses. A successful disinfection stops the first route; only rotation stops the second.
By design, victims’ credentials were collected on the two staging hosts, which stopped responding in late September 2026. Going offline does not end exposure: hosting providers may still retain server data, and infected PBXs keep trying to upload their credentials every minute to addresses that could be reassigned to someone else.
Both are reasons for law enforcement and national CERTs, which have the legal standing that researchers lack, to work with the providers on preserving that data and sinkholing the addresses, which would also identify victims for notification. We saw the uploads in code; we did not capture one in transit and hold no victim list.
An infected host now talks to both staging hosts, and which one depends on whether the command was written in plain text or base64. The /x takeover script is byte-identical on both.
| Reference | Encoding | Points to |
| k.php line 2 (re-runs /x), eight cron schedules in /x, wr.php’s callback | Plain text | 160[.]119[.]69[.]4 |
| Camouflaged cron payloads, login-triggered stager | Base64 | 45[.]95[.]147[.]178 |
| Credential upload | Base64 | Both |
In April, all of these pointed to 45[.]95[.]147[.]178. We assess that the operator replaced the address in plain text and never re-encoded the base64 strings; the credential upload, which names both hosts, appears deliberate. This host is distinct from the scanner 160[.]119[.]76[.]250, which is named in our May report.
Defend: block both hosts in both directions, and decode every base64-encoded string in a crontab or shell profile before deciding which hosts a host talks to. A plain-text review would miss every channel that still reaches 45[.]95[.]147[.]178.
Decoded, the September JOMANGY panel is identical to April’s except for the values defenders were told to look for.
Per-build watermark. Our May report advised hunting for trace_e1ebf9066a951be519a24140711839ea, present in every April copy. The September builds carry trace_bd42a8a0d23ae16c85dede7d2abaec05 (45[.]95[.]147[.]178) and trace_7544725ebaaadac217dfaa7ca8e8fe7e (160[.]119[.]69[.]4), so that hunt now misses current infections.
One gate for two generations. JOMANGY and ZenharR share a single hardcoded MD5 gate hash, rotated together from a2f6863413c4192a4abfa360577b9961 to 8b3a1d970fda0c17a0b785a990fb7b6a. Our May report listed the April value under ZenharR only.
A forged administrator session. Behind the gate, the FreePBX button builds an admin session using FreePBX’s own ampuser class and setAdmin(); in our lab, it opened the full console without any password. Therefore, changing the FreePBX admin password affects neither the gate nor this session. (See Figure 3 below)
Because each of these identifiers changes between builds, the detection approach later in this report focuses on who put a file on disk rather than on what the file contains.
k.php writes a seven-line .htaccess to /var/www/html/admin/views/. It does not hide the webshell; it unblocks it, and it lets requests reach a copy without naming it.
RewriteEngine On
# enable symbolic links
Options +FollowSymLinks
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^\s+ config.php [L]| Request path | Status | What answered |
| /dir/zzz | 404 | Nothing |
| /dir/%20zzz, /dir/%09zzz (space, tab, etc) | 200 | config.php |
| /dir/+zzz | 404 | Nothing |
Simulating an operator and a victim in an isolated environment, we confirmed that a request to a URL containing an encoded space returned a working webshell for the attacker. The access log records only the requested path, never the file that answered, so searching logs for the webshell by its filename can return nothing on a host that is serving it.
Defend: check every .htaccess across the web root for who put it there; one that no package, FreePBX module, or member of your team accounts for is suspect, whatever it contains. Because the takeover script wipes logs, treat log hunting as secondary: requests with %20, %09, or %0A directly after a slash that return 200 are worth a look where logs survive.
FreePBX lists the trunks it created from its own database; Asterisk reads whatever is in its configuration files. In our lab, a trunk we wrote directly into /etc/asterisk/pjsip_custom.conf carried a call while the FreePBX Trunks page reported no records (See Figure 4 below). We did not see the campaign plant one, but its root-equivalent accounts and stolen trunk secrets give the operator everything needed to do so.
Defend: audit from the Asterisk CLI (pjsip show endpoints, pjsip show registrations, sip show peers, sip show registry) and compare with what the console lists. Review the *_custom.conf files for trunks or contexts that nobody on your team added.
Before detecting or cleaning, it helps to see the whole apparatus. Everything in Figure 5 is read from /x and k.php: ways the implant stays on the box, and doors allowing the operator to come back, through a system account or a single web request. Each piece can rebuild/repair all others under a minute, which is why removing any one of them on its own fails. (See Figure 5 below)
The operator rotates hashes, watermarks, gate values, and hosts between builds, so asking whether a file is known-bad quickly stops working. The better question is who put the file there: compare what is on disk with what the package manager or a clean install says it should be.
On the host: triage with beagle.sh
PBX admins can run beagle.sh, a report-only script that makes no changes to the host, to check a PBX server for signs of compromise. (See Figure 6 below)
| Check | What it flags |
| Packed shells | Several identical, same-size PHP files across unrelated directories |
| Locked files | chattr +i or +a under the web root or in hidden directories |
| Unowned .htaccess | An .htaccess no installed package accounts for |
| Self-rebuilding cron | A cron line that downloads a file and hands it to a shell |
| Accounts | An extra UID-0 account, or a full-permission FreePBX admin, nobody created |
| Blocklist | Addresses dropped in and out by iptables outside fail2ban’s chains |
The script separated one infected server from one clean server of the same FreePBX version, a sample of one, so expect some legitimate findings. However, it cannot tell you whether the credentials have already been left: that happens during the first cron run, within a minute of infection, and long before anyone scans. The upload leaves no file behind, and the takeover script wipes what might have recorded it: the web server, Asterisk, cron and audit logs, plus shell and MySQL histories, which makes forensic timelines hard to reconstruct.
With telemetry
The most distinctive actions leave little on disk; in our detonation, backdoor accounts were created and deleted 27 seconds apart. These eleven behaviors are detection strategies to build into your own tooling:
| Layer | Behavior | What it catches |
| Host | crond spawns a shell that downloads a file and runs it | The takeover script on its single run, before persistence and before credentials leave |
| Host | The web server account spawns a shell | The webshell’s command box in use |
| Host | A cron child rewrites the crontab every minute without reading it first | Beacon reinstallation |
| Host | chattr +i or touch -r on a file in the web root | The lock and the borrowed timestamp |
| Host | Twelve PHP files were written to the web root in the same second | The webshell copies, as they are written; fan-out |
| Network | The PBX contacts staging host roughly every 60 seconds | The beacon’s rhythm, whatever the address |
| Network | Many configuration files read, then outbound POST requests | Credentials leaving |
| Web | A request with leading encoded whitespace returns 200 for a path not on disk | The .htaccess door |
| Decoy | Any read of a decoy config file that the implant reads, but nothing legitimate does | Credential collection, with no false positives by design |
| Phone | Channels originate over AMI or the CLI outside your dial plan | A call asking for nothing legitimate |
| Phone | CDRs with premium destinations, off-hours calling and unusual concurrency | The fraud itself |
The last two catch the fraud rather than the machinery, whatever the files are called, and whether you ever find the shell. The host rows need process telemetry that PBX appliances rarely have, which is part of why so many stay infected.
| First move | Why it fails on its own |
| Delete the webshell | Cron re-runs k.php within minutes and rewrites all 12 copies, the .htaccess, and the immutable flags. |
| Patch FreePBX | Sangoma’s advisory for CVE-2025-57819 states the fix prevents new exploitation but does not clean a compromised system. |
| Change the admin password | The gate and the forged session never use it, and the backdoor accounts bypass the FreePBX login. |
Shadowserver data showed more than 900 compromised FreePBX instances in February 2026; over 700 of them were still compromised in May. Rebuilding from a clean image is the most reliable fix; if you clean in place, work from the system layer up, because it replants everything above it.
The takeover script truncates logs, then deletes them, and clears shell and database history, so evidence shrinks with every run:
Then clean, in this order
The hard part of the campaign used to be getting the implant off the box, and that has not changed. What has changed is that the box is no longer the whole problem: an organization that rebuilds but does not rotate has removed the operator’s calling platform and handed over its carrier account.
The code ties this generation to the actor in our May report through the takeover script, backdoor hash, and staging host, and a gate rotated in step across JOMANGY and ZenharR.
The operator is now rotating exactly the strings defenders were given, so detections built on provenance and behavior will outlast this build, and detections built on its hashes will not. CRIL continues to monitor INJ3CTOR3’s infrastructure.
Hashes and strings rotate between builds; use them to confirm a finding, not as your only detection.
| Value | Type | Context |
| 45[.]95[.]147[.]178 | IPv4 | Staging host since April |
| 160[.]119[.]69[.]4 | IPv4 | Second staging host and credential collector, new |
| hxxp://45[.]95[.]147[.]178/hima_data/index.php | URL | Credential upload endpoint |
| hxxp://160[.]119[.]69[.]4/hima_data/index.php | URL | Credential upload endpoint |
| c6e64453ea8bc0856333b6f57567c9efd8c440410787cae135d1c4a248c07c0d | SHA256 | /x takeover script, identical on both hosts |
| 38edbfc4ac89619d2bdb3f4bb2626deaaf422868d6d7af640f59d7959903f838 | SHA256 | k.php, 45[.]95[.]147[.]178 |
| 1c14a761620691a43b1a554a9eccd38d21c15d59463945250d4f57b10d20fce9 | SHA256 | k.php, 160[.]119[.]69[.]4 |
| b54a8d9e98ff36dfe63b2aea97a2003b670f7311595bb4dd072850fed5900a0b | SHA256 | wr.php, 45[.]95[.]147[.]178 |
| aa6dfd7ee90d9aea5af29ae39c14ff70cf8687118abadd7aa4fc98923f01ffd1 | SHA256 | wr.php, 160[.]119[.]69[.]4 |
| adeb015fdb37814edc3ed45230f48d2b0e87bb195a5a7e4487c01549b47c744c | SHA256 | JOMANGY webshell on disk, 45[.]95[.]147[.]178 build |
| d345671e688ee807e1bb9b6fc45e6bb0611bbb1331c33888c8030ec2db47e672 | SHA256 | JOMANGY webshell on disk, 160[.]119[.]69[.]4 build |
| trace_bd42a8a0d23ae16c85dede7d2abaec05, trace_7544725ebaaadac217dfaa7ca8e8fe7e | String | JOMANGY watermarks, one per build |
| 8b3a1d970fda0c17a0b785a990fb7b6a | MD5 | Webshell gate hash, JOMANGY and ZenharR |
| $1$nRz1Cbtk$ | Hash prefix | Password hash set on backdoor and service accounts |
Mapped from the September /x and k.php to MITRE ATT&CK v20; the last three rows are new in this generation.
| Technique ID | Tactic | Name | Evidence |
| T1059.004 | Execution | Command and Scripting Interpreter: Unix Shell | /x and k.php run as bash scripts fetched by cron |
| T1105 | Command and Control | Ingress Tool Transfer | wget of /x, k.php and wr.php from the staging hosts |
| T1053.003 | Persistence | Scheduled Task/Job: Cron | Minute-level beacons, a restore line and a watchdog |
| T1505.003 | Persistence | Server Software Component: Web Shell | JOMANGY and ZenharR, 12 copies across the web root |
| T1546.004 | Persistence | Event Triggered Execution: Unix Shell Configuration Modification | Stager added to /root/.bash_profile and /root/.bashrc |
| T1037.004 | Persistence | Boot or Logon Initialization Scripts: RC Scripts | Stager added to /etc/rc.local |
| T1136.001 | Persistence | Create Account: Local Account | Backdoor accounts, several at UID 0 |
| T1098 | Persistence | Account Manipulation | Shared password hash set on existing accounts; FreePBX admin row inserted |
| T1027 | Stealth | Obfuscated Files or Information | base64, base64 and ROT13 layers around the webshell; base64 cron payloads |
| T1564.001 | Stealth | Hide Artifacts: Hidden Files and Directories | Crontab spares in dot-paths such as /var/tmp/.X11/.Xauthority |
| T1070.006 | Stealth | Indicator Removal: Timestomp | touch -r copies footer.php’s timestamp onto the webshell |
| T1070.003 | Stealth | Indicator Removal: Clear Command History | Shell and MySQL histories cleared |
| T1222.002 | Defense Impairment | File and Directory Permissions Modification: Linux and Mac Permissions | chattr +i and +a on webshells and crontab spares |
| T1685.006 | Defense Impairment | Disable or Modify Tools: Clear Linux or Mac System Logs | Web server, Asterisk, cron, secure and audit logs truncated, then deleted |
| T1686 | Defense Impairment | Disable or Modify System Firewall | iptables rules dropping rival actors’ addresses |
| T1496 | Impact | Resource Hijacking | Victim’s PBX and trunks used to place premium-rate calls |
| T1552.001 | Credential Access | Unsecured Credentials: Credentials In Files | k.php reads 17 Asterisk, FreePBX, Issabel, Elastix and Postfix configuration files holding secrets |
| T1119 | Collection | Automated Collection | The 17 files are collected by hardcoded commands on every k.php run |
| T1041 | Exfiltration | Exfiltration Over C2 Channel | Multipart HTTP POST of each file to /hima_data/index.php on both staging hosts |
Source: Cyble Research · 2026-10-28
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-118613.
Source: Zero Day Initiative — Published Advisories · 2026-10-28
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-118614.
Source: Zero Day Initiative — Published Advisories · 2026-10-28
This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The ZDI has assigned a CVSS rating of 7.8. The following CVEs are assigned: CVE-2026-118615.
Source: Zero Day Initiative — Published Advisories · 2026-10-28