I presume you refer to mine:
https://twitter.com/LorneGaetz/status/1169051835044417536?s=20
Last week I got several commercial support tickets where the customer was reporting excessive calls to high tariff destinations for toll fraud. The calls were mostly to the 605 area code, somewhere in the Dakotas, a destination we’ve been seeing of late since most admins are savvy enough to block international calls. I personally touched 3 separate systems behind 3 separate routers on 3 separate sites for 2 customers.
In all three cases, the PBX was behind a Fortigate device of some sort, I don’t know what product specifically. In all three cases, the firewall was hacked to forward untrusted traffic to the PBX from the 'net. What’s more, the firewall NAT exploit was such that incoming traffic was masqueraded with the LAN IP of the gateway so the router was proxying the incoming traffic. As is customary, the local LAN subnet(s) were white listed so both the pbx firewall and fail2ban ignored the intrusion.
Once the above was in place, it was just a matter of brute forcing the provisioning services until they got a valid provisioning filename. The provisioning file leaked extension secrets allowing registrations of their own clients, which in turn allowed outbound calls from malicious users.
The log fingerprints were there for all to see. Excessive SIP registration attempts in /var/log/asterisk/full* all appearing to come from the LAN IP of the router/firewall. Also excessive http 404s in /var/log/httpd/access_log* as they attempted to guess a provisioning filename again from the router. tftp was enabled on all three systems as well, and since verbose logging is not enabled for tftp by default, I could only see the brute forcing attempts against tftp on one system in /var/log/messages.
Had tftp been disabled and had http provisioning been protected with apache creds, it would have taken far longer to brute force anything, allowing more time for the firewall/router compromise to be discovered prior to actual toll fraud.