IVR And Feature Code Exploit

Hi Community,

PBX Firmware: 12.7.5-1807-1.sng7
PBX Service Pack:

I have a newly installed server with an IVR setup.

I have a problem today where a hacker has bee exploiting the *2 and ## feature codes.
They call in and dial *2destination# to make out free calls via our Pabx.

I have tried the following from a previous post which does not work. Those feature codes still remain active
although they are disabled in the FreePBX GUI:

I have also tried disabling *2 and ## feature codes on previous installations and when i dial in while the ivr plays and press *2destionation # the call is successfull.

This does not make sense as the feature codes have been disabled.

Please advise.

Option in Advanced Settings called "Disallow transfer features for inbound callers is set to Yes

Can you provide a call trace?

Will this suffice or do you want the raw asterisk log?

Full log start to finish.


Log here : https://pastebin.freepbx.org/view/27cbf8fe

I could not make sense of your log. It starts with an outbound call; a quick search did not find any reference to an inbound context.

However, if you have IP phones (or softphones with transfer functionality) and don’t need the DTMF-controlled transfer features, simply disable them. In Advanced Settings, set:
Asterisk Dial Options: r
Asterisk Outbound Trunk Dial Options: (blank)
Submit, Apply Changes, test.

IMO, transferring calls via DTMF is a specialty function, e.g. if you want to allow an incoming call sent to a mobile phone (follow-me, forwarding, misc destination, etc.) to be transferred by the mobile user. Otherwise, keep it disabled. In addition to security issues, it can interfere with DTMF control of remote systems or result in loud DTMF beeps being heard by the connected party, and adds needless load to the system.

Hi Stewart,

That was the first setting i changed, view below…but i am still able to dial in and while
the ivr is playing i dial *2destination and the call goes through.

So i thought maybe the GUI on this PABX wasnt writing to the core asterisk files, so i tested it on 2 other
installations and changed those 2 settings, and the result was the same, as successfull call via the IVR.

You sure it’s your PBX that is allowing the transfer and not some feature on your trunk.

Is the context for your incoming trunk correct? If it’s set to from-internal, that’s a serious security vulnerability, even without transfers enabled.

Please make a test call and provide a log showing the problem. Make the call from your mobile (or another phone not on your PBX). The log should start with when Asterisk first sees a call on the incoming trunk.

Right here:

[2018-11-03 03:38:15] VERBOSE[20835][C-0000ba86] pbx.c: Executing [[email protected]:1] Macro(“Local/[email protected];2”, “user-callerid,LIMIT,EXTERNAL,”) in new stack

The reason it looks like an outbound calls is because it is an outbound call. These calls are being generated from the PBX via Originate commands. This is being dialed via a Local channel which is what Asterisk uses for originating calls. This could be a FollowMe or some other function (like Ring Groups) that uses Local channels to initiate calls.

These are also being generated back to back to back. So now the big question, does TRUNK-SEEHOA actually exist and it is yours? Because they are not only going out that trunk, they are going through your Outbound Routes and matching.

[2018-11-03 03:41:33] VERBOSE[21095][C-0000ba8b] pbx.c: Executing [[email protected]:4] ExecIf(“Local/[email protected];2”, “1?Set(TRUNKCIDOVERRIDE=000000000000)”) in new stack

[2018-11-03 03:41:33] VERBOSE[21095][C-0000ba8b] pbx.c: Executing [[email protected]:15] ExecIf(“Local/[email protected];2”, “1?Set(CALLERID(all)=seehoa)”) in new stack

[2018-11-03 03:41:33] VERBOSE[21095][C-0000ba8b] pbx.c: Executing [[email protected]:16] ExecIf(“Local/[email protected];2”, “0?Set(CALLERID(all)=)”) in new stack

[2018-11-03 03:41:33] VERBOSE[21095][C-0000ba8b] pbx.c: Executing [[email protected]:17] ExecIf(“Local/[email protected];2”, “1?Set(CALLERID(all)=000000000000)”) in new stack

Please double check that trunk and your outbound routes and confirm they are correct and the ones that should be there.

I agree with @BlazeStudios analysis. It shows outbound calls to Somalia and raises several questions.

Is the initial ‘2’ an intentional trunk access code on your system? If not, it’s been compromised (presumably over the internet) by an attack unrelated to the transfer vulnerability.

As a secondary security measure, it’s good practice to restrict outbound calling, e.g. allowing calls only to countries you need to call.

But in any case, you were writing about an inbound call being inappropriately transferred to an external destination. Your log needs to show the inbound call and how it is handled – if you start with the outbound call made by the attacker, the important information is not present.

My bigger point was the box could be compromised and there isnt inbound calls per se but something triggering orignation based calls.

Sure, but the OP stated that he could call into the system (and two other installations) and transfer to an external number. A log of this attempt would almost certainly show the incoming leg and indicate whether the behavior was caused by malicious modification.

For centuries, Somalia has been famous for piracy. It appears that they are moving from ships to chips.

Is http://www.simbithinet.co.za/ relevant to the OP? If so, please describe your role. Are you representing Simbithi, the HOA, or a business with property in the Estates?


Yes, Trunk-Seehoa is the trunk to my voip server for outbound calls.

Here is my test call log from earlier : https://pastebin.freepbx.org/view/4abf4cc1
It is not a compromised box. Like i stated above, feature codes on trunk is disabled under advance settings, yet it works on this install and 2 new installs we have done.

One of the latest boxes we did didnt have any ivr, so i went as far as setting up a test ivr, changed the advance sip settings to disable dtmf on the trunks. I dialled in and dialed *2destination# and the call went through.

Third pabx i tested had an ivr, without changing anything, i tested the exploit and it worked. I then disabled dtmf on trunk and the *2 and ## and tested, call via *2destination# and it worked.

Note i am testing the exploit from a Freepbx server with a Yealink handset. I tried the exploit from a mobile phone and a standard analogue line and it did not work.

Config below.

I first thought this but as i have tested, i have tested this on Pabxs that have not been hacked and the exploit works.

Again, nothing useful showing in your call trace.

I agree, and it doesnt even log / show the destination i am dialling, just the source.

Has anyone else tried this or is it only @xtranetcc machines

Would be good if soemone else could simulate and test.