FreePBX Servers Breached: Attackers Harvest SIP Credentials for Phone Fraud

FreePBX-based phone servers are facing a more dangerous evolution of malware that allows attackers to steal critical credentials—even surviving server rebuilds. This new tactic, part of the INJ3CTOR3 campaign, targets configuration files to harvest SIP trunk passwords, database logins, mail relay logins, and other secrets—enabling phone fraud that persists even after cleanup.

How the Latest Attack Unfolds

Researchers from Cyble Research & Intelligence Labs uncovered in September 2026 that malicious attackers have upgraded their tools to not just place unauthorized calls via compromised servers, but also to extract the underlying credentials powering those operations. The campaign now captures configuration files for SIP authentication, PJSIP settings, database access, and administrative interfaces.
Victims’ files across FreePBX, Issabel, Elastix, Asterisk, and Postfix systems are being siphoned to attacker-controlled staging servers where they can be used even if admins replace machines entirely. Scheduled tasks trigger this upload every minute, ensuring secrets are continually exposed while the malware remains active.

Persistence, Evasion, and the Hidden Risks

The attackers haven’t abandoned past tactics—they still rely on six-layer persistence mechanisms. These include scheduled downloads, backdoor webshells (notably JOMANGY and ZenharR), disguised login triggers, backup file protections, and multiple webshells that can restore deleted components. Indicators of compromise also include altered web rewrite rules that conceal webshell paths, and log-clearing scripts to destroy traces of malicious activity.

SIP trunk credentials are a particularly prized target: they’re what VoIP providers use to authenticate businesses’ phone systems. With those stolen, attackers can make calls from machines outside the original server—potentially leaving no trace once the server is restored. New changes also aim to evade detection tools; webshell watermarks now vary between builds and the authentication hash gate has been modified.

Cleaning Up and Mitigating Damage

Cleaning up requires more than just removing malware. Admins should assume that any visible system can still be compromised—normal dashboards might hide backdoors not logged or shown in interfaces. Best practices include isolating infected systems, preserving forensic evidence, removing all persistent components, and then rotating all credentials: trunk, extension, database, mail, and system secrets. Completely rebuilding from a trusted backup image is seen as the most reliable recovery option.

Operators are also advised to work closely with carriers—to replace trunk secrets, restrict allowable source addresses, set spending limits, monitor unusual call destinations, and watch for unexpected registrations or high outbound concurrency.

This campaign includes several indicators of compromise (IoCs), such as IPs for staging servers (e.g. 45[.]95[.]147[.]178, 160[.]119[.]69[.]4), specific URLs where credentials are collected via scripts, and SHA-256 hashes for installers, the takeover scripts, and webshells.