Hackers Attack FreePBX Servers With Malware to Steal SIP Credentials for Phone Fraud

Hackers targeting FreePBX phone servers have upgraded their malware to steal credentials that can keep phone fraud running even after an infected system is rebuilt.

The INJ3CTOR3 operation now collects configuration files containing SIP trunk passwords, database credentials, management secrets, and mail relay logins, extending the damage beyond the compromised server.

The change builds on an earlier campaign that placed unauthorized calls through victims’ own phone systems.

Previously documented six-layer FreePBX persistence mechanisms helped the malware survive removal attempts, but stolen carrier credentials now give attackers another way to charge calls to a victim’s account.

Researchers from Cyble Research & Intelligence Labs identified the updated malware while examining artifacts collected from the operation’s staging servers in September 2026.

Their October 28 analysis describes an installer configured to upload 17 files repeatedly. Researchers recovered the upload commands but did not capture live exfiltration or establish a victim count.

Hackers Attack FreePBX Servers With Malware

The updated installer contains two encoded command groups, each directing configuration uploads to a separate staging server. Scheduled tasks run the installer every minute, repeatedly exposing secrets while the infection remains active.

Changing passwords before removing the malware can therefore hand replacement credentials straight back to the attacker. The targeted files span FreePBX, Issabel, Elastix, Asterisk, and Postfix configurations.

They include SIP and PJSIP authentication settings, Asterisk Manager Interface credentials, database passwords, and outbound mail authentication details. These files expose both calling services and supporting infrastructure.

SIP trunk credentials are particularly valuable because they authenticate a business’s connection to its telephone provider.

Unless the carrier restricts access to approved IP addresses, stolen credentials can let attackers register from another machine and place calls without using the original PBX. Those calls may leave no records on the cleaned server.

The operation retains its JOMANGY and ZenharR webshells, which provide remote commands and access to phone-system functions.

Related FreePBX webshell exploitation activity previously demonstrated how attackers combine administrative access, backdoor accounts, and outbound calling capabilities to monetize compromised VoIP infrastructure.

Cyble also found changes designed to weaken older detection rules. Webshell watermarks now vary between builds, and the password-gate hash has changed.

The underlying persistence remains largely unchanged, including scheduled downloads, login triggers, protected backup files, and multiple webshell copies that can restore deleted components.

Detection and Recovery Must Include Credential Rotation

Investigators should not treat a normal-looking FreePBX dashboard as proof that a server is clean. In laboratory testing, Cyble created an Asterisk trunk directly in configuration files that carried calls without appearing in the FreePBX console. Researchers did not observe this campaign planting such a trunk.

The malware also modifies web-server rewrite rules so requests containing encoded whitespace can reach a webshell without naming its file in access logs.

Meanwhile, the takeover script clears logs and command histories, reducing the evidence available for incident reconstruction. Recovery requires isolation, evidence preservation, and removal of persistence before rotation of exposed credentials.

Earlier guidance covering FreePBX zero-day server compromises similarly recommends clean restoration and replacement of system, trunk, extension, and other account secrets rather than relying on patching alone.

Administrators should coordinate with carriers to replace trunk secrets, preserve registration and billing records, restrict allowed source addresses, and set spending limits where available.

Monitoring should cover unexpected registrations, premium-rate destinations, unusual call concurrency, and outbound configuration uploads. Cyble recommends rebuilding from a trusted image as the most reliable recovery option.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.