Asterisk: a targeted VOIPspionage campaign - update PBX to patch the vulnerability

FYI, I would like to share these two articles hoping to encourage the community in keeping their system up to date.

In summary, attackers could use a vulnerability to access the FreePBX, steal data and install crypto mining scripts. It seems that the security hole has been patched, so it is recommended not to put off updates for long.


I love articles like these. The ones where they tell you have a huge vulnerability but then they don’t tell you what that vulnerability is, what version of Asterisk/FreePBX this impacts and what version has the patch to fix it.

Despite both articles coming from the same source, one claims Asterisk/FreePBX and the other just claims Asterisk. One claims there was a patch released for this vulnerability but the other has no mention of the patch.

Articles like these are click bait as far as I’m concerned because they do nothing but tell you that you could be exposed to being compromised but give you no actionable information on how to resolve or mitigate the issue. Very helpful.


The point is to encourage people to keep their systems up to date. When vulnerabilities are discovered the responsible parties are first to be informed before it is made public and they issue patches. So regardless of the affected Asterisk version, updating the software is important to mitigate any known or (publicly) unknown security risks.

Here is the thing about these articles. Asterisk, itself, doesn’t have a GUI. That means it doesn’t require or need Apache (or any web server) or PHP. So that would mean there are numerous Asterisk installs out in the world that would never be impacted by this, at all.

Conversely, FreePBX (which uses Asterisk) is GUI based and therefore uses Apache and PHP which would mean 100% of FreePBX boxes could be impacted by this. These articles fail to relate how this is being done. What attack vectors are being used? Is it a buffer overflow? Is it a SQL injection? What?!

Again, ZERO information provided. Right now FreePBX v13 and v14 are the “current” releases for FreePBX. The former uses PHP 5.3 while the latter uses PHP 5.6. What versions of FreePBX where these monitored systems running? Were they current boxes? Were they v13 or v14?

I mean come on, look at the first article. The report is based off of reporting from Feb - July of 2018! Over a year and a half ago. It even says a patch was released (but doesn’t tell you what update has the patch or what versions should be patched). So honestly, if you are a year and a half behind on your updates, you deserve a quick kick in the gonads to wake you up.

Articles like this are reckless because they promote a panic with no resolution.

1 Like

The ZDNet article (and this post) are meant to reach general audience with interest in FreePBX. I included the source article for people like you to contact the researches to get more details.

The article says:

@BlazeStudios I had to shutdown a PBX server because someone installed crypto miner in it. This could be related to this vulnerability or another one. How many of FreePBX users screen their server for crypto mining? I know the risk is real.

The users in this forum are mixed audience with different level of IT/PBX knowledge. My aim to bring awareness to general audience to take action by updating their systems. And for people interested in details, the second link provide the source article with the researcher names to get more information.

If we take the article content at face value (that they are exploiting a vulnerability as opposed to brute forcing a password on a poorly secured system) they probably refer to this vulnerability:

That is the most recent exploit but there was also one from 2014 in the long deprecated Asterisk Recordings Interface (ARI). I’m speculating of course, because the authors have chosen not to share even the SLIGHTEST useful detail, only that it dates from 2018 and there was a fix at that time. Note the date in the wiki page, it is more than 3 years old.

As an aside, the authors don’t seem to be overly knowledgeable about PBX exploits specifically, in that they seem more concerned about ‘espionage’, leaking CDR records, generating outbound calls with spoofed CID, or listening to call recordings. While I suppose some organizations might be targeted for those types of activities, what we see in practice is ALWAYS traffic pumping, generating outbound calls to high cost destinations

1 Like

The truth is, any server CAN be compromised, no sane person would claim that there are absolutely no problems with any http/php code, certainly there are possible dialplan intrusions.

A good suite of security tools should include all the standard things plus a root kit tool, I use

It would detect new files appearing in standard ( or custom) places which seems to cover the last few FPBX patches.

Watching for unusual calling patterns also, many attempted attacks happen early on Sunday morning :wink:


Or after hours/midnights.

@lgaetz I love FreePBX and wish the best for the project. I believe in teamwork and shared responsibility. This is why I have shared this hear to be vetted by skilled people. The second link is an abstract in a security conference. They are usually limited to the number of characters. I believe the researchers work for Check Point Research and this is their website In my experience, such organizations tends to responds to inquiries and questions from verifies professionals like personals with Sangoma emails. You can answer the right questions.

There are three basic vectors open to compromise Asterisk, FreePBX, which has multiple ports open via htttp and https and downline by the version of PHP you rely on.

The most obvious is ssh, simple answer just use keys and disallow passwords, move ssh to anything but 22 for quietness.

Allowing any incall DTMF WILL allow compromise, just don’t allow it, that leaves the more insidious one hich is TCP 5038, which is pure asterisk, and is often left open unknowingly. If compromised, there is little evidence in any “log files” but the calls still go out.

Watching the md5sums of /etc/asterisk/*.conf is a very good starting point for backstop-checking FreePBX intrusions, you would be informed everytime you or anyone else managed to change the dialplan.

But watching /etc/asterisk/bin/asterisk/astdb.sqlite3 won’t easily work as it is too busy.

Quick check from outside, check tcp connections open

nmap -vv -p 1-65535 your.pbx.server

(don’t worry too much about UDP ports)

Each hit is a possible problem . . .

Below is a scan from the LAN to the PBX with all ports default:

Below is the scan from the Internet:

Starting Nmap 7.50 ( ) at 2019-10-10 07:36 Eastern Daylight Time
NSE: Loaded 144 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 07:36
Completed NSE at 07:36, 0.00s elapsed
Initiating NSE at 07:36
Completed NSE at 07:36, 0.00s elapsed
Initiating Ping Scan at 07:36
Scanning [4 ports]
Completed Ping Scan at 07:36, 2.05s elapsed (1 total hosts)
Nmap scan report for 12.216.341.565 [host down]
NSE: Script Post-scanning.
Initiating NSE at 07:36
Completed NSE at 07:36, 0.00s elapsed
Initiating NSE at 07:36
Completed NSE at 07:36, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 8.06 seconds
Raw packets sent: 8 (304B) | Rcvd: 20 (800B)

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.