We have some 3cx instances hosted with a 3rd party. Three times in the past six weeks are so, we have had extensions compromised and fraudulent toll calls were able to be placed until the sip provider noticed this and shut it down. (happened after hours and they caught it in about 4 hours). High tolls were charged. I'm trying to determine how this is happening and harden the system. Originally we were using default 3 digit extension numbers as auth id with 5 character random alpha numeric characters for pw. Also the default 3cx security of lockout for 30 minutes after 25 failed attempts was in place. After the first compromise, this was changed to use 16 alpha numeric mixed case strings (for Auth ID and Password) and lockout was configured to lockout for a year after 5 failed attempts. The other passwords for Yealink web ui and others were changed also. Since that last change at least one of the same extensions that was compromised previously was compromised again. Very doubtful if not impossible to brute force random 16 character STRONG user id and separate 16 character STRONG pw in five attempts. The 3rd party host is pointing to security issues w/ 3cx. Specifically they are suggesting the provisioning url is public facing and this is being brute forced. I reviewed the provisioning url they provided and it contains two separate random strings in the url, so I think brute force is highly unlikely. However, if the url is truncated to include just the first random string and then the macaddressofphone.cfg is appended to it, the full config is visible. Grant it a bad guy would need to figure out the first random string and also know the mac address of a phone on that system which doesn't seem likely unless this information was leaked somewhere. Even with the random strings in the provisioning url, should this be public facing at all? I asked about locking it down to an ip address, but was told that would break connections for the mobile and desktop apps. If it was leaked and now that information is secure, how would one change the provisioning url so bad actors in possession of it can't use that compromised link anymore? Any help or thoughts are appreciated.