FOOD FOR THOUGHT a new spam attack defined, using CallerID

[hillclimber]

The article* below**, explaining how to block most incoming VoIP spam has been very useful to me, however lately I have noticed a disturbing trend which manages to bypass my block.

* https://nerdvittles.com/spam-phone-call-blocker-and-cnam-caching-for-freepbx
** this website rich text editor is broken today.

Before we get started, let's just assume my telephone number is distributed globally across ugly hacker networks.

Until recently, nearly all callerID spam was blocked using the technique + code documented in the first link above. Now, it seems the bot programming has evolved, and now the bots are dialing back multiple times, and initially they don't even ring for enough seconds to reasonably answer the telephone, (and now they bypass the CallerID filter simply by dialing back multiple times, otherwise I would not have even noticed them, when they subsequently made a very brief 'call'.

Sure, I manually blocked the CallerID, that came up as cityname, statename geographically close to my own area code. However this has happened more than once, and I am noticing a trend. The bots have started to re-use CallerID numbers as a means to break-through the spam filter cache.

 

[wardmundy]

Why would they bypass the CallerID filter by calling back multiple times?? Perhaps YOUR phone number is in the whitelist, and they are spoofing that number.

 

[kenn10]

On the spam filter you reference, the required digit must be pressed to get through. I had the issue with the bots learning to press '5' so I added code to randomize the required digit each time a call came in.

As Ward has stated above, never whitelist your own phone number.

 

[dicko]

If you think that only 'we' are recently learning to use TTS and STT, you would be wrong, the bad-guys have been doing it longer than most of us and are probably still better than many of us.

Most all of those 'techniques' assume that you accept calls from 0.0.0.0 to UDP:5060 or a few variations, if you move your extensions to TLS and only listen on UDP:5060 where essential (many VSP's haven't yet got it ;-) ) then you just won't see anything passing your 'blocks'.

Some fun TTS/STT recipes I have used, of course it get's better exercised when the allowed transport is UDP:5060 than when it is TLS:25674 ;-) :-

don't say a word but send the call to a live STT, if the caller speaks for more than 2 seconds assume it's spam and send to 'secondary inspection' which is mostly recording the rest of the call and STT'ing it to responsible adults.

'Primary inspection', where the response was a short 'hello?' 'Anyone there?' or even 'WTF' probably identifies wet-wear so the response might initially be, " hi, We see this is the first time you have called this number, you will only be asked this once to verify you are not a knuckle dragging droog from Belarus, thanks for your patience'

then , depending on the type of business

ask what day of the week it is,
ask what color the sky is
ask what number they are calling from
ask the caller to name the person or company they are trying to reach

( here I use STT over DTMF because as otherwise noted, these guys are starting to use their own STT to 'parse out' such a DTMF response that would allow progression of the call, here the first three are simple 'gatekeepers' of the first derivative but with a little more work the last one can eliminate the need for DTMF based IVR's completely

I only ask a new CallerID(Number) once, I keep the 'voice-print' in asteriskdb (via Vosk , the longer the sample , the more useful the voice-print will be, but you can append further calls and recompute the voiceprint for future re-cognitive) purposes, plus 'last called date' and 'destination to send call to' to mostly make IVR's an un-necessary pain to expose to repeat callers. I add the destination in the hangup context allowing 'AI' or just 'I' entities to 'pre-seed' the next call.

(Damn, that got longer than I meant it to be ;-) )

 

[kenn10]

If I'm not mistaken, a stock IncrediblePBX without allowing guest or anonymous sip calls will not accept a call from 0.0.0.0:5060.

On my spam blocker, it answers and delivers a SIT out-of-service tone (which causes many robodialers to drop) and then apologizes to the caller for the interruption but then asks the caller to press a random digit to proceed. No answer within 4 seconds and they get a warning about unsolicited calls to numbers on the do-not-call list. Their number is then blacklisted. If it is someone with a rotary phone, too bad.

 

[dicko]

If I'm not mistaken, a stock IncrediblePBX without allowing guest or anonymous sip calls will not accept a call from 0.0.0.0:5060.

On my spam blocker, it answers and delivers a SIT out-of-service tone (which causes many robodialers to drop) and then apologizes to the caller for the interruption but then asks the caller to press a random digit to proceed. No answer within 4 seconds and they get a warning about unsolicited calls to numbers on the do-not-call list. Their number is then blacklisted. If it is someone with a rotary phone, too bad.

I think that 'stock' behavior requires a pretty high maintenance 'whitelist' to work. Bot this is about Spoofed CallerID(Number) so possibly moot here but I have seen the escalating of penetrated servers to being zombified for such malfeasance.

What the thread is about is efficiently identifying spoofed calls and, at least in NANPA land, regulations are dismally failing what should work like 'do-not-call' . So Not 'pissing off' real callers yet still 'pissing on' robocallers is what we are seeking.

Pretty sure most businesses would not be pleased that new customers got an SIT on first contact, but probably wouldn't like to be called a knuckle dragging drood either, (I'll probably work on that phraseology.)

If you actual mean your recipe replaces the 'random' token with a voiced digit, then that is now trivial to STT and so DTMF it, I would suggest a simple answer of your voiced 'three times two' or 'one plus six' would be more exclusive.

Speech still works on rotary phones and robocallers need to speak more than just DTMF in a simple STT recipe.

I concede deaf folks will have problems with my method, But I have always wondered why there are braille instructions on my banks drive through teller machines .