FreePBX Infections: Shadowserver's Warning on 900+ Active Web Shells

We saw a spike in these infections right after the New Year. The command injection flaw allows the attacker to write directly to the disk, so they often drop a secondary payload for persistence. In our case, fwconsole ma list wouldn't even show the compromised modules.

We ended up restoring from snapshots for critical clients because finding the web shell was only half the battle—the crontab had been modified to reinfect the server on reboot. Always check your cron jobs if you find a shell!

I've been scanning for this specific IOCs using a YARA rule across our internal fleet. It catches the obfuscated PHP headers nicely. Here is a simplified rule we used for detection:

yara rule FreePBX_WebShell { meta: description = "Detects obfuscated PHP web shells" strings: $a = "eval($POST[" nocase $b = "base64_decode" nocase $c = "system($" nocase condition: 2 of them }

We found 3 instances that standard AV missed. Definitely recommend YARA for this type of sweep.

Solid advice. Once you've identified an infection, remember that web shells often hide backdoors in scheduled tasks. I recommend checking for recently modified cron jobs which might reinfect the host even after patching:

find /etc/cron* -type f -mtime -30 -ls

Also, verify that the patch applied correctly by checking the specific module versions against the Sangoma security advisory.

Good point on the persistence, Beth. Beyond cron jobs, we’ve found these web shells often maintain reverse shells. If you suspect an infection, run the following to spot unexpected outbound connections:

lsof -i -n -P | grep ESTABLISHED


It’s crucial to isolate the host immediately before cleaning, as simply removing the script might stop the process but leave the system vulnerable via other backdoors dropped during the initial foothold.

Excellent points on persistence. Don't overlook the web server logs to identify the initial entry vector. Since this exploits command injection, checking for URL-encoded payloads or suspicious PHP functions can reveal compromised instances even if the web shell evades filesystem signatures.

Here’s a quick grep to spot common payload staging attempts:

grep -Ei "(passthru\(|eval\(|base64_decode)" /var/log/httpd/access_log | tail -n 50

I've dealt with similar web shell infections, and one approach that worked well for us was using a combination of static file analysis and behavior-based detection. For FreePBX specifically, you might find this script helpful to locate potential web shells:

#!/bin/bash
# Find recently modified PHP files that could be web shells
find /var/www/html -name "*.php" -mtime -30 -type f -exec grep -l "eval\|base64_decode\|system\|exec\|shell_exec" {} \;

After identification, quarantine these files immediately and analyze them offline. Have any of you tried automated containment strategies, such as limiting execution permissions for newly created files in the web directories?

Great insights everyone! While detection is crucial, we should also consider limiting the impact if a web shell is present. One effective mitigation is to disable dangerous PHP functions in php.ini. We've used this configuration to limit execution capabilities:

ini disable_functions = exec,shell_exec,system,passthru,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

This won't prevent the initial exploit, but it significantly reduces what attackers can do with a web shell. Just remember to test thoroughly as it might break legitimate FreePBX functionality. Has anyone implemented similar restrictions successfully?

While cleaning the OS is vital, don't overlook the VoIP application itself. Attackers frequently create rogue SIP extensions for toll fraud after planting web shells. I recommend auditing SIP peers against your naming conventions to spot unauthorized accounts. You can quickly list active extensions with:

asterisk -rx "sip show peers"


If you see unknown IPs or names, assume the configuration is compromised.