FreePBX Malware

Overview

Attackers targeting FreePBX and related VoIP platforms have upgraded their malware to steal the credentials that control an organisation’s telephone services, potentially allowing phone fraud to continue even after a compromised server has been rebuilt. The campaign, tracked as INJ3CTOR3, demonstrates an important incident-response lesson: removing malware from a server does not necessarily remove the attacker’s access to the services behind that server.

The PBX Is No Longer the Only Target

Earlier versions of the campaign focused heavily on maintaining access to compromised FreePBX environments and using those systems to make unauthorised calls. The updated malware expands the objective. Researchers found an installer configured to repeatedly collect configuration files from FreePBX, Issabel, Elastix, Asterisk and Postfix environments. These files can contain SIP and PJSIP credentials, database passwords, Asterisk Manager Interface credentials, mail authentication details and other management secrets. Among these, SIP trunk credentials are particularly valuable. They can authenticate an attacker directly with a telecommunications provider, potentially allowing calls to be placed from another system rather than through the original compromised PBX.

The Fraud Can Follow You After the Rebuild

This creates a dangerous recovery scenario. An organisation might detect a compromised PBX, rebuild the server and restore its configuration. From an infrastructure perspective, the system may appear clean. But if the SIP trunk credentials were stolen before the rebuild, the attacker may still possess the credentials required to make calls through the organisation’s carrier account. The compromised server is gone. The attacker’s access is not. Unless the carrier credentials are rotated and the provider-side access is reviewed, the financial impact can continue independently of the original infection.

Persistence Makes Detection Harder

The campaign also maintains multiple mechanisms for surviving removal attempts, including scheduled downloads, login triggers, protected backup files and multiple webshells. Researchers found additional techniques designed to make the activity harder to detect, including changing webshell identifiers and modifying web-server rules. There is another important warning here: a normal-looking FreePBX management interface should not automatically be treated as evidence that the system is clean. In testing, researchers demonstrated that Asterisk configuration could contain a trunk that was not visible through the normal FreePBX interface. They did not establish that this particular campaign created such a trunk, but the example shows why administrators cannot rely exclusively on what the management dashboard displays.

Recovery Must Include the Entire Trust Chain

The appropriate response therefore extends beyond deleting suspicious files. A potentially compromised FreePBX server should be isolated and investigated while preserving evidence. Persistence mechanisms need to be removed, and organisations should consider rebuilding from a known-trusted image. More importantly, every credential that may have been exposed must be treated as compromised. That includes SIP and PJSIP credentials, trunk authentication, PBX accounts, database credentials, management accounts and relevant mail credentials. Telecommunications providers should also be involved. Organisations can review registrations and billing activity, restrict permitted source addresses where supported, establish spending limits and monitor for unusual call volumes or premium-rate destinations.

Expert in the Cloud Insight

Traditional incident response often focuses on restoring the compromised server. But modern attacks increasingly steal the credentials that connect that server to another service. That changes the definition of recovery. A clean server does not mean a clean environment if the credentials stolen from that server are still valid. For VoIP infrastructure, rebuilding the PBX is only one step. The real recovery is complete when the attacker has lost the ability to authenticate to the telephone network, the persistence is removed, and the organisation can prove that normal calling activity has resumed under its control.