Telephony Fraud – Further Analysis

Following yesterday’s post, I’ve decided to take another set of data – this time following the start of the year, with a specific data profile. What is the profile? I will describe:

  1. The honeypot server in this case was a publically accessible Kamailio server
  2. The honeypot changed its location and IP every 48 hours, over a period of 2 weeks
  3. The honeypot was always located in the same Amazon AWS region – in this case N.California
  4. All calls were replied to with a 200 OK, followed by a playback from an Asterisk server

In this specific case, I wasn’t really interested in the attempted numbers, I was more interested to figure out where attacks are coming from. The results were fairly surprising:

The above table shows a list of attacking IP numbers, the number of attempts from each IP number – and the origin country. For some weird reason, 97% of potential attacks originated in Western Europe. In past years, most of the attempts were located in Eastern European countries and the Far-East, but now this is Mainland Europe (Germany, France, Great Britain).

Can we extrapolate from it a viable security recommendation? absolutely not, it doesn’t mean anything specific – but it could mean one of the following:

  1. The number of hijacked PBX systems in mainland Europe is growing?
  2. The number of hijacked Generic services in mainland Europe is growing?
  3. European VoIP PBX integrators are doing a lousy job at securing their PBX systems?
  4. European VPS providers pay less attention to security matters?

If you pay attention to the attempts originating in France, you would notice a highly similar IP range – down right to the final Class-C network, that is no coincidence, that is negligence.

Now, let’s dig deeper into France and see where they are attempting to dial:

So, on the face of it, these guys are trying to call the US. I wonder what are these numbers for?

Ok, that’s verizon… let’s dig deeper…

Global Crossing? that is interesting… What else is in there???


So, all these attempts go to Landlines – which means, these attempts are being dialed most probably into another hijacked system – in order to validate success of finding a newly hijacked system.

Well, if you can give me a different explanation – I’m all open for it. Also, if any of the above carriers are reading this, I suggest you investigate these numbers.



Telephony Fraud – Still going strong

Who would believe, in the age of Skype, Whatsapp and Facebook – telephony fraud, one of the most lucrative and cleanest form of theft – is still going strong. Applications of the social nature are believed to be harming the world wide carrier market – and carrier are surely complaining to regulators – and for a legitimate reason. But having said that, looking at some alarming fraud attempt statistics, thing will show you a fairly different story.

So, analysing fraud is one of my things, I enjoy dropping honeypots around the world, let them live for a few days and then collect my data. My rig is fairly simplistic:

  1. A have a Homer ( server to capture all my traffic
  2. A have an amazon AWS cloudformation script that launches up instances of Asterisk, FreeSwitch and Kamailio
  3. All instances are pre-configured to report anything back to Homer
  4. Upon receiving a call – it will be rejected with a 403

Why is this a good honeypot scheme? simple – it gives the remote bot a response from the server, making it keep on hitting it with different combinations. In order to make the analysis juicy, I’ve decided to concentrate on the time period between 24.12.2016 till 25.12.2016 – in other words, Christmas.

I have to admit, the results were fairly surprising:

  1. A total of 2000 attacks were registered on the honeypot server
  2. The 2 dominant fraud destinations were: The palestinian authority and the UK
  3. All attacks originated from only 5 distinct IP numbers

Are you wondering what the actual numbers are? Here is the summary:

Row Labels Grand Total
441224928354 19         19
441873770007       204   204
76264259990     1     1
17786514103         2 2
972592315527   1774       1774
Grand Total 19 1774 1 204 2 2000

As you can see, the number 972592315527 was dailed 1774 from a single IP – I can only assume this is a botnet of some sort, but the mix of IP numbers intrigued me. So, a fast analysis revealed the following:

Amsterdam? I wonder if it’s a coffee shop or something. The thing that also intrigued me was the phone number, why would the bot continue hitting the same mobile phone number? I couldn’t find any documentation of this number anywhere. Also, the 97259 prefix automatically suggests a mobile number in the PA, so my only conclusion would be that this is a bot looking for a “IPRN” loop hole – which is again fraudulent.

So, if this what happens in 48 hours – you can imagine what happens over a month or a year.


The above post contains only partial information, from a specific server on a network of worldwide deployed honeypots. The information provided as-is and you may extrapolate or hypothesize what it means – as you see fit. I have only raised some points of discussion and interest.

Should you wish to join the lively discussion on HackerNews, please follow this link: for further discussion.




Goodbye Elastix – we will miss you

Last week marked a sad point in the history of Open Source, the highly acclaimed and established Asterisk distribution was taken down from the Internet, leaving all of its users, followers, eco-system, resellers, integrators and more with a gigantic void to be filled.

While the void will be filled at some point, I can’t but help but observe the joy and cheerfulness of the proprietary telecommunications industry, as 3CX had rapidly taken over the Elastix business in such brutal manner. According to the various discussions in the Open Source community, the entire thing was cause by, a so called “violation of copyright” or “violation of IP” of some sort, within the Open Source communities. In the past, as far as I know, when various distributions or projects violated each other’s copyright, they would notify one another – and would ask to rectify the situation. Apparently, this hadn’t happened here – or if it happened, it wasn’t published in an open manner – as you would expect.

One of the things that the community started shouting was: “Elastix had been trixboxed”. Honestly, I don’t see the similarity between the two cases. When fonality acquired trixbox, they had a clear indication of where they are going. This is not 3CX acquired Elastix, this is 3CX obliterated Elastix. This is something completely different – and with major personas in the open source community indicating that a certain, well known and renowned, Open Source persona was involved in this happening, I can only be highly offended by the everlasting stench of people’s own ambition and personal hatred towards things that are not their own.

I admit it, I never really used Elastix in my projects, I found it to be bloated, inflated with software that shouldn’t be there, too slow for my taste and with a lack of proper project leadership, patches went in and out like crazy. Yet, I can’t argue with their success and the acceptance of the product around the world. I remember being at VoIP2Today in Madrid only a few weeks ago, and there were Elastix boxes sitting on tables. Yes, Elastix wasn’t my first choice for an Office PBX, but yes, they were a choice – the idea of a commercial company coming in and removing that choice off the table – is just annoying and troubling at the same time.

My hope is that some Elastix developers will simply post the entire source code to Github or some other public repository, slapping a BSD/MIT license on their work – telling the world: “Here is our creation, the proprietary daemons decided it should die – but no one can kill an idea!” – and Elastix will keep on living in the Open Source like other projects. If the world will forget it, then so be its fate – but if the world needs it, let the world take it in two hands and raise it up to the sky and say: “You shall not die!”


Source code and individuality

Developers! We are the modern day artists, the masters of the keyboard and the sculptors of algorithms and ideas. We turn obscure thought and imagination into real life creations, capable of doing things previously not done (well, at least not in the same form). As such, we are individuals and unique – each one of us in our own way. Whether we develop a mobile app or a web application, our unique style, way of thought, organization and coding style will be reflected into our creation – we can’t help it, this is who we are.

About 2 years ago I’ve done a project for a start-up company in Israel, where I developed a full blown switching environment for them. I worked on that project for around 9 months and how shall I put it, my name was all over the place. Normally, when I take a piece of code from the OpenSource/PublicDomain, I will document where it came from within the code – then I will add a simple remark next to my modifications.

So, the other day I met one of the new developers working on the project – who didn’t know I was the original developer. And he told me about some issue that he was having with his project – so, in a very natural way, I pointed out to him that the original code wasn’t meant to work like that, specifically, he should into a specific function to resolve the issue and add some additional code to make it work as he wanted. The guy was shocked – “What the hell? are you psychic or something? how can you know that?” – I replied – “Well, I wrote the damn code, I should know”, which followed by me showing him the original source code on my computer. The guy said: “Yes, that is the source code, but all the remarks of the original source code are gone”. Seems that following my departure from the project, someone went into great length in order to remove the various comments I’ve put into the code, to make its origins as unclear as possible.

So, on one hand, I truly understood it – after all, the guy running the show doesn’t want the new people to call up the previous developers and exposing new stuff to them – even if by mistake. On the other hand – Dude, are you really that lame? are you really the afraid that your team will know who wrote the original code?. Source code is a living organism, it is an unique as the person who wrote it and will evolve and change as more people write more code. The Asterisk project still contains remarks that Mark Spencer put back in 2002 – and they are no longer relevant to the existing code, but only to an obscure part of the original code – but it’s still there.

So, to sum up, I never remove remarks that other people wrote from my code – it’s rude, it’s bad practice and worst of all – it’s ugly and disrespectful. Developer will join and leave a project, show your minimal level of respect by respecting their code and their remarks, leave them where they are – removing them is just like performing an act of murder.

Federating Asterisk – truth or myth?

During this years’ Asterisk Developers’ Conference, one of the subjects I’ve raised an issue for Asterisk is: “Federating Multiple Asterisk Instances”. Now, for the seasoned Asterisk user/developer, the answer would be simple – use Kamailio/OpenSIPS for that scalability, and use Asterisk as a Media Gateway or application server.

But I ask the following: “What if we could federate Asterisk without the need for an external component? What if we could federate Asterisk in such a way where our users aren’t event aware of the federation process, and it’s fully autonomous? What would actually be required in order to do that?”

I’m normally confronted with these questions on a day to day basis, looking at the problem from different angles – thinking to myself: “Ok, I know the normal box here – but where are the outer limits? what can I do to make it more robust on one hand, without truly making a mess out of it.”

A federated database is defined as: “A federated database system is a type of meta-database management system (DBMS), which transparently maps multiple autonomous database systems into a single federated database. The constituent databases are interconnected via a computer network and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or virtual database, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation.” –

So, we would like to virtually create a “map-reduce” functionality for Asterisk? can we truly create a map-reduce’ish functionality for Asterisk? should it be internal? should it be external?

In order to accomplish this, we are required to create a federator – a device capable of handling the information regarding each users, device, trunk, provider and other wise SIP/IAX2 entity connected to our system. The federator for all practical purposes is a data store, be it a key-value store, a database, a shared memory environment or some other form of data distribution layer.

Here are some key issues that true federation may be required to tackle:

  1. Geo-Position Agnostic – A truly federated system should render services identically across the board, regardless of where the user is located.
  2. Services Agnostic – A truly federated system doesn’t care if the user is connected to an Asterisk server version 12 or 13, it should behave identically.
  3. Version Agnostic – A truly federated infrastructure can leverage older version and even other software, without changing the underlying federation layer.
  4. Predictable Scalability – A truly federated infrastructure will allow for growth to be planned linearly, with discrete measure methods.

So, you want a tip on how to start federating your systems? here’s step number 1 – there is no central registry, there is no SIP proxy, there is only the cloud and the services it renders. Start thinking from this point and see where you go.