Compromised dial plan

I recently had an event on my PBX where some kind of robo-dialer was dialing what appears to be random feature codes trying to access my system. Luckily the long distance bill wasn’t terribly excessive but I am unsure of how to block this.

Specifically what I noticed was that they dialed the ## in call transfer feature. Somehow, even though it disconnected them, it kept the calls open for an excessively long time because the number they called was a conference call located somewhere in Minnesota.

They also turned on the call recording feature on a couple of calls.

I have turned off the ## feature but the issue is I have users that were using that feature.

I wonder if anyone else has experienced this and what other feature codes are potentially vulnerable.

Check your Admin --> Administrators and see if there are any unusual users that have been created

Also I could check Admin --> Config Ed and look at the extensions_custom.conf file

Thanks for that advice. Those are both good. No new administrator accounts or custom extensions.

Recent versions of FreePBX have an option in Advanced Settings “Disallow transfer features for inbound callers” that is on by default.

If you lack that setting, consider upgrading (if impractical, please explain).

If you have turned the setting off, explain your workflow.

If the setting is on (and obviously not working), post a log of a call where the inbound caller was able to transfer.

Also, how do you use the ## feature internally (how doesn’t the phone’s transfer button work right)?

That setting is on but it still works on IVRs. My inbound trunk is set as from-trunk in the incoming context.

This PBX is on version 13 for both FreePBX and Asterisk. It has recently been fully updated.

So the log is a little complicated. The actual FreePBX where the transfer occurred is only used to pass through and route calls between several other FreePBX systems and our local carrier. I was able to disable the feature codes on that one which solved that problem.

However, I do still have the issue on my target FreePBX systems when you dial one of their IVRs so I will duplicate this and post the log of one of those.

While in the IVR, or after passing through the IVR e.g. to an extension that then goes to voicemail? In either case, you may want to file a bug report; this seems like a serious oversight.

How do you use ##? Can you use the Transfer button (or softkey) instead?

For the most part I can have them use the softkey. At least until this is fixed that is going to have to be the way it works.

Or change the “Feature code” perhaps?

If the ## works only after the IVR dials an extension, removing T (but keeping t) in the Asterisk Dial Options should fix the problem.

If the ## works while in the IVR, I don’t understand what is happening, because AFAIK a Dial() command has not yet been executed.

Another thought on where the bug may lie:

If the IVR routes to a Ring Group, an extension with Follow Me, etc., where the members have the # suffix, that essentially makes a “fresh” outbound call which may lack the transfer prohibition.

If In-Call Transfer Feature codes are disabled but there are Ring Group/Follow Me with “#”, will that still carry a risk?

I’m reasonably certain that disabling them is global, but to be sure, call in from your mobile, have the call follow the path with the #, wait for answer then press ## and *2 and confirm that nothing happens.

1 Like

So just to be clear what I’m observing, the call is routed to the IVR and while the announcement is playing I can dial ## or *2 and transfer to an outbound caller. I can stay on the line with a *2 and talk to the outbound called person or hang up and they are still connected to the announcement on the IVR.

There is a 'T 'and a ‘t’ option, and these are allowed or denied by feature-code “mapping” in FreePBX the caller and the callee are self described, so in a transferred call the role is not what you thought, as I previously suggested, change your feature code from ‘##’ which as you have discovered is “well known” to perhaps “32” (f(3)orward c(2)all) , the use of digits in an “in-call” feature will not interact in any way with your internal dial-plan

Wow. I will set this up on a test system to confirm. I had been under the impression that this was controlled by the T and t options in the Dial command. However, when an Inbound Route goes to an IVR, AFAIK there is no Dial command executed, so I don’t know what controls these options. If they are on by default, that is really bad news and needs to be quickly fixed.

From a purely Asterisk perspective the options only exist and work during a Dial(), but you can Dial() using a Local channel which then executes dialplan. I can’t speak for what FreePBX does.

And yet again, if you redefine the feature codes for “in call attended/blind transfer” your problem will just go away. No?

Thanks. My production system doesn’t show that for calls to an IVR, but there may be circumstances when that happens.

Someone please post a log for a call to an IVR where ## or *2 is active.

Ok so I’m the victim of my own overly complicated systems! The transfer I was trying to do was from another PBX calling into this one. The actual transfer I was seeing was MY internal extension on THAT system transferring the call.

I’m embarrassed to have to admit this but it looks like, from what I can tell, inbound callers (I tried from my cell phone) are NOT able to transfer out after all.

I do appreciate all the comments on this. Sorry to have wasted your time.