Over night I had abnormally high call volume and it appears incoming callers (PSTN) were able to gain access to dial out from my system.
It looks like they are dialing into an extension/voicemail and able to then dial out to various numbers.
I disabled directory/extension dialing from my IVR which appears to have curtailed the issue but wondering how they are able to do this and what I need to configure to remove this ability.
I tried various search criteria but can’t seem to get search terms specific enough to this issue to be useful.
The most common exploits involve transfers via DTMF (*2). Confirm that in Advanced Settings, ‘Disallow transfer features for inbound callers’ is turned on. If you don’t use these codes, disable them altogether; see
It is also possible to set up callback and/or making an outgoing call from voicemail. These are disabled by default but check VM Options for the extension involved. An attacker can abuse callback by spoofing caller ID with the number he wants to call, leaving a message, then calling in and choosing the callback option.
Thanks for the reply.
I checked my Disallow transfer features for inbound callers and it is turned on.
I did more checking and it appears the incoming call dialing through to an extension (directory dial from IVR) and somehow was able to change the forwarding rules on the extension. Once this was done, they simply dialed into the extension to have the system dial out to the number that was previously setup.
I have been reviewing the full asterisk log but can’t seem to figure out what they did to make this change. I did some additional searches but came up empty as to what technique was used. Any additional thoughts on what can be checked?
As you saw calls to ‘various’ numbers, he apparently made changes within the date range of your logs.
Possibilities:
Not the default, but some systems are set up to change forwarding remotely e.g. so an ‘on call’ person can forward urgent calls to himself. If you have such, the log will show these calls. If calls were made to different numbers only a few minutes apart, you won’t have much to search.
If your provisioning is open to the world and not password protected, the attacker could have scanned through known MAC address ranges and found the device.
The device itself might be open to the internet and its web interface accessible with a default password.
If you have UCP or another control panel set up and open to the internet, an attacker may have guessed a weak password.
If your admin GUI is open to the internet, even with a strong password, it could have been compromised by various vulnerabilities, if you are not current with security updates.
I worked through your possibilities but don’t see any indication of this being a breach outside of the phone call. I walked through the asterisk/full log again, and did notice the caller was able to dial *93 and set call forwarding inside the call. It appears that some how a bridge was setup between two extensions (I think) and then dialing to *93 was possible. I attached the call where this happened and the CF looks like it takes place at line 661.
The log for the call is below. I did search/replace phone numbers and employee names but shouldn’t impact reading of the log.
For now, I do have pin codes on the North American area codes that call outside the country, disabled call forwarding feature code and disabled extension dialing after hours until I understand how this occurred. I do appreciate your time looking at this and helping me through trying to figure out what happened.
I took only a brief look at the log so this is approximate:
Attacker called in and dialed 104 through IVR. Follow Me was enabled and the list included an external number “6026667777”. That was called and it answered after 26 seconds (probably went to voicemail). Attacker then was able to dial *2 (attended transfer) then *93 102 13172164903.
I believe that this is a FreePBX bug. With ‘Disallow transfer features for inbound callers’ turned on, this should not only disable transfers on the inbound leg, but the disable should be ‘inherited’ by any outbound legs spawned by the incoming call. I believe that this used to work and some recent changes in ‘local’ channel and Follow Me / Ring Group logic broke it. I don’t know whether updating all modules to current will fix the issue. If not, you should probably open a ticket.
But in any case, if you don’t use the ‘In-Call’ features listed in Admin -> Feature Code -> Core, disable them. Note that this does not affect SIP transfer (what the Transfer key on most IP phones and softphones does). Also, take a look in Advanced Settings at Asterisk Dial Options and Asterisk Outbound Trunk Dial Options; remove any that you don’t need. On my system, the former is ‘r’ and the latter is blank.
If you actually use DTMF transfer, e.g. you want someone working from home to be able to transfer calls that were forwarded to his mobile, include only the dial options needed (on the outbound trunk, t but not T). See https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_Dial .
Note that until you adjust the Dial Options and/or the In-Call features (or the bug gets fixed), an attacker could still use *2 to call out if his incoming call gets forwarded externally by whatever means. I see that his attempted call to India was rejected, though there is not enough info in the log to see why (I’m guessing that your International route is restricted to specific extensions or specific countries).
Thank you for taking the time to look at the log and giving me an analysis. I believe I am current on modules so I’ll confirm and then submit a bug request.
I’ll review the other items you mentioned and now that I understand what happened, I should be able to reproduce for testing purposes. For the India rejected call, you are correct - I do have international blocked with a pin – this is the reason for my other post regarding the “US International” dial pattern not being comprehensive (follow up calls were to the Caribbean).