Call Transfer Fraud

I noticed today a couple of hundred (failed) calls on an inbound route that all tried to transfer the call to a long distance number. Can anyone advise on how to stop this? What are we doing wrong? It’s the first time I see this. From the log it looks like they are in the internal dialplan with access to transfers, feature codes, etc…

[2017-09-06 06:14:49] VERBOSE[30923][C-00009df0] app_dial.c: Called SIP/AcmeCorp/+611229843315
[2017-09-06 06:14:50] VERBOSE[30923][C-00009df0] app_dial.c: SIP/AcmeCorp-000128e4 is ringing
[2017-09-06 06:14:50] VERBOSE[30923][C-00009df0] app_dial.c: SIP/AcmeCorp-000128e4 is ringing
[2017-09-06 06:14:50] VERBOSE[30923][C-00009df0] app_dial.c: SIP/AcmeCorp-000128e4 answered SIP/InboundRoute-000128e3
[2017-09-06 06:14:50] VERBOSE[30928][C-00009df0] bridge_channel.c: Channel SIP/AcmeCorp-000128e4 joined 'simple_bridge' basic-bridge <45b43d6e-0a3e-49fd-bbeb-b60a6fa57808>
[2017-09-06 06:14:50] VERBOSE[30923][C-00009df0] bridge_channel.c: Channel SIP/InboundRoute-000128e3 joined 'simple_bridge' basic-bridge <45b43d6e-0a3e-49fd-bbeb-b60a6fa57808>
[2017-09-06 06:14:56] VERBOSE[30928][C-00009df0] res_musiconhold.c: Started music on hold, class 'default', on channel 'SIP/AcmeCorp-000128e4'
***[2017-09-06 06:14:56] VERBOSE[30923][C-00009df0] file.c: <SIP/InboundRoute-000128e3> Playing 'pbx-transfer.alaw' (language 'en')
[2017-09-06 06:15:03] VERBOSE[31032][C-00009df0] bridge_channel.c: Channel Local/043277901@from-internal-xfer-00001da3;1 joined 'simple_bridge' basic-bridge <b5dc8259-f2f8-4c6b-8e6d-03da7cee17e0>
***[2017-09-06 06:15:03] VERBOSE[31031][C-00009df0] pbx.c: Executing [043277901@from-internal-xfer:1] Macro("Local/043277901@from-internal-xfer-00001da3;2", "user-callerid,LIMIT") in new stack
...
[2017-09-06 06:15:03] VERBOSE[31031][C-00009df0] pbx_builtins.c: Goto (from-internal-xfer,043277901,7)
[2017-09-06 06:15:03] VERBOSE[31031][C-00009df0] pbx.c: Executing [043277901@from-internal-xfer:7] GotoIf("Local/043277901@from-internal-xfer-00001da3;2", "0?,043277901,2:outbound-allroutes,043277901,2") in new stack
[2017-09-06 06:15:03] VERBOSE[31031][C-00009df0] pbx_builtins.c: Goto (outbound-allroutes,043277901,2)
[2017-09-06 06:15:03] WARNING[31031][C-00009df0] pbx.c: Channel 'Local/043277901@from-internal-xfer-00001da3;2' sent to invalid extension but no invalid handler: context,exten,priority=outbound-allroutes,043277901,2

You probably have T enabled on you inbound trunks, (not a good thing :slight_smile: )

Here is a big thread on the topic.
That might apply to you:

Hello,

In FreePBX 12 (probably in newer versions also) you have the option to disable this for the inbound callers:

Settings > Advanced Settings > Disallow transfer features for inbound callers should be set to YES

Info:

Asterisk Dial Options: Ttr
KEYWORD:DIAL_OPTIONS
Options to be passed to the Asterisk Dial Command when making internal calls or for calls ringing internal phones. The options are documented in Asterisk documentation, a subset of which are described here. The default options T and t allow the calling and called users to transfer a call with ##. If ‘Disallow transfer features for inbound callers’ is set to ‘Yes’ the T option is removed for inbound callers. The r option allows Asterisk to generate ringing back to the calling phones which is needed by some phones and sometimes needed in complex dialplan features that may otherwise result in silence to the caller.

Hope this helps!

Disallow transfer features for inbound callers is set to YES so that feature by itself does not fix the issue. Checking my inbound trunks now.

1 Like

I think that even after removing the “T” the system is still at risk if follow-me is configured.

We have seen that the follow me functionality views the external caller as an internal caller for the follow me leg of the call. I think this means that if an internal extension is set to follow me to a mobile that the external caller can transfer out (*2 or ##) of the call to the mobile and then dial out appearing to be an internal caller (which is allowed via the “t” in the dial plan.

regards Jason

1 Like

You are absolutely correct here. In-call transfers are rarely needed, SIP phones/Asterisk can generally handle transfers without such exposure.

Sorry Dicko, I’m going to show my ignorance here.

We use Grandstream GXP 1625 phones and with regards to transfer, they appear to need to be told what the transfer/three way call etc feature codes are. Does this suggest that they dont support the native transfer?

Is there a protocol and or standard that I should look for to confirm that it is handled without needing the tT settings ?

Sorry, i ave not touched a grandstream in many years

Am i secure with these configs?

Can anyone please let me know if this is the correct setting. Thanks

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