Hi all,
As per my last post, I’ve developed a module for SentryPeer (which is now live). It’s a VoIP fraud early warning platform (fully open source too).
Using the FreePBX module, every call attempt via a trunk gets checked against the SentryPeer API, and if a match, it gets dropped.
I’m looking for testers of the module and service if anyone has time?
They’ll be an open source mobile app to receive alerts etc. too.
Many thanks,
Gavin.
Can I ask how you are determining a toll call for this? With the way things are these days, I have local calls that cost more than calling across the country. This is due to the interchanges with rural ILECs that cost a premium to terminate to.
This means that I can have a customer that makes a local call which is more per minute than calling a rural place in South Dakota. I mean the concept of toll charges or even Local vs Intrastate vs Interstate are not really a thing in VoIP. If you’re paying per minute then you will have some sort of rate deck or zone rate. The provider doesn’t care if that zone is actually local, intra/interstate they care it is in that zone.
I actually had a user compromised earlier this year. The majority of the charges where to some place in Iowa but because my agreements it was costing me $0.008/min, there were just a lot of them an all under 15 minutes. They also hit destinations that were $0.05/min, in those cases there weren’t as many and they were also much shorter. In the end, they had more charges to the low cost destinations than the high cost.
Hi Tom,
There’s no cost analyse to this. We’re logging events from SentryPeer nodes we run that capture actual attempts of trying to get an outside call completed. This is the activity that happens before fraudsters reveal and call the expensive numbers that cost of all money (customers and operators etc).
When we get a match on an API query, that’s an indication that there is a compromised device or system trying to make calls. I explain more on our about page.
Of course, if the PBX is compromised other things can happen, but it’s a great heads up that something is going on and you can reach out to your customer or consume a webhook alert to lock their account. If you use CGRateS for billing, they recently integrated SentryPeer there to do the same.
Thanks.
I saw that you check for a probing number. So I’m guessing your using some database of known probing destinations? Based on the code I’m just trying to understand the logic. If an unknown number is found the call is passed, but what if that unknown number was a probe and it succeeded so the next attempt is a high cost (or not) destination for pumping?
Outside of checking for a probing number, how does this catch actual fraud calls that do get made? Because, again, based on the code only known numbers are blocked. Looks like unknown failures/responses are still let through.
Hi Tom,
We’re checking against data we have collected via SentryPeer nodes, otherwise known as honeypots. These allow calls to be attempted. They log all activity the fraudsters make. Which, after SIP registering, try to call various versions of the same number or other patterns, e.g. 008 in front, 9 in front etc. What the module does, or an API call, is check the number against that.
If we’ve not seen the activity/number on one of our nodes, then yes, it’s possible that something gets through. I have an FAQ about this.
We can only check what we have seen in the wild. I’m working on machine learning alerts based on the patterns of your systems. For example, more API checks than usual could mean a compromised device or system etc.
You should run one yourself in debug mode and watch the numbers or select the Contributor Plan and watch the live data come in on sentrypeer.com dashboard.
I put one on Digital Ocean last week (we move them around for fresh IPs), and within 6 mins I got a probe (8pm at night). Then at 1.30~am all the real attempts to call places came through. It’s all out there and I’m trying to generate alerts as soon as there is a match so users and customers alike can lock an extension or whatever they deem fit.
Does this make sense? Should I do a video or re-work our about page do you think?
Gavin.
For example, here’s two events just in on a node I run on my home internet connection:
Source IP: 45.155.91.239
Called Number: 80046910291628
SIP Method: INVITE
Transport Type: UDP
User Agent: Linksys/SPA942
Same number too.
Source IP: 45.155.91.239
Called Number: +46910291628
SIP Method: INVITE
Transport Type: UDP
User Agent: Linksys/SPA942
Does this work with NANP? Is the 800 prefix like the 011 prefix (indicates International call)?
I am trying to understand why you allow all the fraudulent hosts to register to your PBX in the first place.
That’s just an attempt to break through a prefix code to get an outside like, like when you’d set anything with a 9 prefix going to a SIP trunk route.
Which PBX are you referring to? These are SIP honeypots gathering data so that if your own PBX tries to call any of these number patterns you’d get an alert which means something is wrong within your network. Like a canary in a mine.
I understand that, but why are you still accepting connections on UDP:5060 from 0.0.0.0 in 2023?
Instead of say, only TLS? The node listens on different transport protocols, and surprising in 2023 UDP still gets hit the most. Unless I’m misunderstanding your question?
So you’re tracking random prefix codes or just using the most common? I mean the example you showed isn’t a probing number before trying a real number, they were trying the same number with different prefixes. Someone sending 01146910291628 or +46910291628 is still calling the same International destination they are just checking which method will be accepted.
I guess I still don’t understand the logic being used here. I’m still not understanding how you determine a destination is fraud or not.
You miss my point, UDP:5060 will always get probed much as ssh is on TCP:22 because that’s where the low hanging fruit is, but if your PBX is not listening on that transport, then they can (and they do) slow drip you every few minutes on random variations of one base number often incrementing the international bit sometimes to national sometimes WTFK , commonly the baton is passed every few days or more to another host usually in the same ASN , the best ones do even better, look first for a ‘fingerprint’ of open connections on specifically non VOIP services, (Each ‘Distro’ has a different fingerprint).
Sans an upline firewall , sngrep will continue to tick off these half opened UDP:5060’s with little effect whether they are on your ‘list’ or not.
Do you have statistics as to what port and protocol you have been successful on?
(Advice of the day, “Don’t be a low hanging fruit provider ;-)” )
To explain again, SentryPeer (SentryPeer API) sits between your PBX and the outside world to help detect compromised devices. You could be the most secure provider in the world, most secure PBX, but somehow (which always happens), a customer/user device has been compromised. Using SentryPeer to check all outbound calls helps detect this so you can be alerted to do something about it.
To ask again, how is it detecting compromised devices? I’m still struggling to see how it does that accurately.
No worries. So, our nodes are pretending to be PBXs. They allow attackers to register, then the attacker tries to call numbers it owns. The attacker does this so it knows they can make external calls. That’s early reconnaissance. At this point, the attacker hasn’t revealed the expensive numbers that they call to make money from. We don’t want them to get to that point. At some point, we’ll start letting real calls go out and record the audio and build a new list of numbers.
We log all this as it happens at sentrypeer.com, as the nodes are sending all those events in realtime. That is building up a live database.
On FreePBX, for every call that goes to an external trunk, the SentryPeer module will query that number at https://sentrypeer.com/api/phone-numbers/{number}
If it gets a 200 OK, it drops the call. We know a device could then potentially be compromised as we are seeing matches that our external fake systems have seen. It doens’t matter what the number is, nor whether it is real as the attacker that has compromised a device doesn’t know your dialplan.
That’s the logic.
And you’re catching a lot of NANP stuff that would pass normal validation here, i.e. 1NXXNXXXXXX and it could cost a lot depending on the location within the country it is calling? Because it doesn’t seem like this accounts for traffic pumping, which is what I described in an earlier post. You can have a compromised customer in South Dakota calling a destination in South Dakota or even Iowa, something that looks like a normal LD call but the destination has a cost of $0.025 or higher. This is what actual toll fraud/traffic pumping looks like here in the US.
We, as the providers in the US, can freely block offshore numbers (Guam, Puerto Rico); Alaska; high cost Canada or all Canada; International. What we can’t block, no matter the cost to us, is domestic destinations. Only the customer can choose to block South Dakota destinations or any high cost domestic destinations.
So what is the fraud protection SentryPeer offers again actual domestic traffic pumping and toll fraud in the US? Something that is actually a bigger concern and seen more of recently than Offshore/International which is generally now blocked by default until action is taken.
Gavin joined us on an Open Source Lounge back in April and provided a pretty good intro to the project. As I understood things then, SentryPeer’s goal is to alert the pbx admin AFTER an extension compromise has happened but BEFORE serious traffic pumping attempts begin. It does this by hosting exploitable honeypots which identify and catalog the outbound calling patterns of known traffic pumping compromises. With the knowledge that pumping exploits often initially make outbound calls to non-suspicious destinations before later making the serious toll calls. SentryPeer attempts to identify and notify the admin during the initial trial balloon phase of the exploit, potentially giving the admin time to investigate before the traffic pumping begins in earnest.
So again, it can tell a domestic long distance call is traffic pumping without knowing the cost of the destination? Are there honeypots in the US?
Again, I had a customer that got compromised and was doing traffic pumping to both low cost and high cost US destinations. How would have SentryPeer stopped that? Oh and they didn’t do a crap ton of calls at once. They had calls under 20 minutes and never more than 3-5 at a time which was well within the allow channels for the account.