What is the "return" feature? It's being misused for toll fraud

I seemed to figure out how to resolve the issue with extensions being jacked, but now it seems somehow they’re calling in to an extension and then using the ‘return’ feature to call back out? I can’t find anything about Return anywhere in the docs, probably because it’s such a common word, but looking at the CDR I’m flummoxed.

This is a server I’m trying to retire set up by a guy before me but one of our trunk providers can’t figure out how to use PJSIP on non-standard ports (because standard ports are blocked by ATT and also it’s a way to slightly reduce the attack surface) so I still have it up, for now. I’d really like to figure out what door I’m leaving open for this, we are using fail2ban and the intrusion detection and you have to be whitelisted to even ping the server, so I don’t know what to do next to lock down this probably-compromised server to reduce the toll fraud issues.

Also, is there any way to do something about Comm1 hosting toll fraud? They own the NPA-NXX that’s receiving most of it.

It appears that the fraudulent caller was able to access the ‘attended transfer’ feature to make an outbound call. This is normally blocked by the Advanced setting (Dialplan and Operational) section) “Disallow transfer features for inbound callers”, which is Yes by default.

I can’t tell from the CEL how he got past that, but the Asterisk log for the call may give a clue. Logs are by default kept for a week, so the file /var/log/asterisk/full-20241109 should have the call. Paste the data for that call at pastebin.com and post the link here.

If you don’t use DTMF-based transfers, I suggest disabling them all by setting Asterisk Dial Options to r and Asterisk Outbound Trunk Dial Options to (blank). Check that you haven’t overridden these in your extension or trunk settings.

As an additional safeguard, the Telnyx portal allows you to configure a maximum rate, above which calls are rejected. Unfortunately, it appears to be unreliable; see Telnyx: Warning: US outbound: rate limit sometimes ignored - VOIP Tech Chat | DSLReports Forums

If the trunk is using registration, a non-standard port should be handled automatically. Using IP auth, indeed some providers won’t send to a non-standard port, but they may support SIP over TLS or other security options. Most providers will accept (for example) 1.2.3.4:5678 to send calls to 1.2.3.4 port 5678. In any case, your present problem is not IP-related; the attacker is dialing in to your system.

Finding that call at this hour is going to be a pain (I’m trying to sleep, but failing) but I can answer that Disallow transfer features for inbound callers is set to Yes. I will look through the logs in the “morning”.

I did set up the maximum cost per minute on Telnyx but I went too high originally, blocking only calls to Iowa, but not calls to Alaska. What is up with that? Why would Alaska be cheaper than Iowa? Wild.

The trunk provider doesn’t pass the DID when using the registration option. That does fix the non-standard port, but then I can’t tell where the call is supposed to go. They say they are “working on it” (but it’s not priority because they prefer ‘peer-to-peer’ registration).

If you have only one DID with them, try setting Contact User for the trunk to the DID number.
If multiple, try setting Context for the trunk to from-pstn-toheader
Temporarily set a catch-all Inbound Route (any / any) and make a test call in. Look at the CDR for the call and see what appears in the DID field. If it’s something useful, adjust your Inbound Routes to use that format.

There are some rural areas in Iowa where the mom-and-pop telco was able to convince the FCC to allow them to charge truly obscene termination rates. Telnyx or any other provider has to pass these on to their customers.

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