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.
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?
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.
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.
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.
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.