Talk to an expert
PricingNewsTalk to an expert
Back to Newsroom
Threat Intel

FreePBX Malware Now Steals SIP Trunk Credentials So Phone Fraud Survives a Rebuild

The INJ3CTOR3 campaign against FreePBX and Asterisk servers has added a credential-theft stage: trunk passwords, database logins and mail secrets are uploaded every minute, so attackers can keep billing calls to a victim long after the server is wiped.

4T4Tify Team4Tify
Oct 29, 2026·6 min read
FreePBX Malware Now Steals SIP Trunk Credentials So Phone Fraud Survives a Rebuild

FreePBX Malware Now Steals SIP Trunk Credentials So Phone Fraud Survives a Rebuild

The INJ3CTOR3 operation, a long-running campaign against internet-facing FreePBX and Asterisk phone systems, has quietly changed what it is after. Earlier waves planted webshells and pushed unauthorized calls through the victim's own PBX. The current build goes one step further: it harvests the configuration files that hold SIP trunk passwords, database logins, management secrets and outbound mail credentials, and ships them to attacker-controlled staging servers. Once those secrets are out, wiping and rebuilding the server no longer ends the fraud.

What changed

The updated installer carries two encoded command blocks. Each one uploads the same set of 17 configuration files to a different collection server, and a scheduled task re-runs the installer every minute for as long as the infection is alive. The targeted files cover FreePBX, Issabel, Elastix, Asterisk and Postfix, including:

  • SIP and PJSIP authentication, endpoint, transport and registration settings;
  • Asterisk Manager Interface (AMI) credentials;
  • the database passwords stored in the FreePBX and portal configuration;
  • the Postfix SASL password file used for outbound mail relay.

The campaign keeps its known JOMANGY and ZenharR webshells, which give the operators remote command execution and direct access to phone-system functions. A built-in control panel can forge an administrative session on FreePBX or Elastix without knowing a password. New builds also rotate the webshell watermark strings and have changed the hash protecting the shell's password gate, a small tweak that is enough to defeat detection rules written for earlier samples.

The persistence layer is largely unchanged and still deep: scheduled downloads, login-triggered hooks, protected backup copies, and multiple webshell duplicates scattered across the web root that restore anything a responder deletes. Web-server rewrite rules are altered so that requests containing encoded whitespace reach a shell without its file name ever appearing in access logs, and a takeover script clears logs and command histories to frustrate reconstruction.

The installer and upload commands were recovered from artifacts collected on the staging servers in September 2026. No live exfiltration was captured and there is no reliable victim count, so the true scale of credential theft is unknown.

Why it matters

A SIP trunk credential is, in effect, the password to a company's phone bill. It authenticates the business to its carrier, and unless the carrier restricts registrations to approved source addresses, anyone holding the secret can register a softswitch elsewhere and place calls charged to the victim's account. Those calls never touch the original PBX, so a freshly cleaned server shows no sign of them.

The minute-by-minute upload also creates a trap for incident responders. If an administrator rotates passwords before the malware is fully removed, the new secrets are collected on the next run and handed straight to the attacker.

A normal-looking dashboard is not proof of a clean system either. In laboratory testing, an Asterisk trunk defined directly in the configuration files carried calls without appearing anywhere in the FreePBX console. That technique has not been observed in this campaign, but it shows how much can hide below the web interface.

What to do

  1. Isolate first, then preserve. Take the PBX off the network and save logs, registration records and call detail records before cleaning anything. The takeover script actively destroys this evidence.
  2. Eradicate completely before rotating. Given the layered persistence, rebuilding from a trusted image is the most dependable option. Only after the system is known clean should you replace every secret: trunk and extension passwords, AMI users, database accounts, mail relay logins and administrative accounts.
  3. Work with the carrier. Ask for new trunk credentials, a source-IP allow list on registrations, spending limits and blocks on premium-rate or unused international destinations.
  4. Watch the signals that survive a cleanup. Alert on registrations from unexpected addresses, calls to premium-rate numbers, unusual call concurrency, and outbound uploads leaving the PBX.
  5. Hunt for indicators. Check for connections to 45[.]95[.]147[.]178 and 160[.]119[.]69[.]4, PHP files in the web root containing strings beginning with trace_, and local accounts whose password hash starts with $1$nRz1Cbtk$.
  6. Stop exposing the admin interface. FreePBX management should sit behind a VPN or a strict allow list, never open to the whole internet.

Phone systems tend to live outside the asset inventory that web and cloud teams watch, which is exactly why campaigns like this keep finding them. Our Attack Surface Management service continuously maps what an organisation actually exposes to the internet, including forgotten VoIP management panels, so they can be locked down before someone else logs in.

SHARE