Checking your Tandberg/Cisco VCS Expressway for hack-attacks from VOIP SIP scanners

SPIT, Toll Fraud, VCS

A SIP scanner is a tool that scans a VOIP/Video network from the Internet side with the intent of “breaking in” and using the network to place voice/video calls. Today, toll avoidance and toll fraud appear to be the primary motivation (rather than SPIT) – however, one thing is clear: the number of SIP scanner attacks is on the increase. Whilst the attacks that have reached my network  appear mostly to be targetted against badly configured Asterix IP telephony solutions (left with default settings), Cisco/Tandberg VCS Expressway video solutions could be every bit as vulnerable unless correctly configured. These attacks should be of special concern if you have any PSTN/ISDN gateways,  SIP ATAs or SIP trunks in use in your deployment. A typical attack appears to be to attempt to place a VOIP call through your gateway to get a free call (toll avoidance). A refinement of this attack used by organised crime is, instead, to attempt to place a calls to a premium rate international telephone number using your gateway – so you, the victim, get saddled with a huge telephone bill.  And, of course, because the calls  cross national boundaries this  makes it all the harder to try and recoup your losses through  legal means – few organisations have the wherewithal to mount an international lawsuit. Anatomy of a SIP scan attack: There seem to be a few different common attacks out there, as far as I have been able to tell.  Each attack differs somewhat from the other, but there appears to be a number of commonalities which suggest that the same attack tool (or set of attack tools) may be being used by the different attackers. What should be done? There is always going to be a balance  between the ability  to freely communicate over the Internet using open standards  – and  the risk that those fraudsters and spammers who would abuse this pose to others. The only safe system is a closed system – but, honestly, how useful would any telephony system be if you had to pre-arrange some sort of bilateral  trust relationship/federation  with any domain you wanted to call or be called by? Not very useful; not very scalable –  and an administrative nightmare.  And what happens if one of your trusted partners’ networks gets compromised and used as a jump-off point for attacking your network?  So, even this extreme approach isn’t very safe. The right thing to do (in my opinion)  is to learn to live with the risk – and to take reasonable steps to protect your network from the fraudsters and spammers. Vigilance General good practice is to remain vigilant to what is happening on your network.  In particular, check what calls  are being attempted so you can spot any suspicious activity and adjust configuration (if need be) to protect against it. One way of doing this is to regularly review call logs and search logs from your VCS. When I reviewed my VCS logs the other week I was shocked to see hundreds of rogue call attempts (thankfully deflected by the VCS’s default configuration):

excerpt from search history page of VCS expressway that had been attacked

(note: IP addresses of my Expressway has been changed to  for reasons of privacy) I believe that the attackers have found my system by a simple IP address scan – looking for a system with SIP port 5060 “open”.   Other possibilities include that they found the SRV records for my domain – but given that I have yet to receive an attack which includes my domain name, I’m reasonably confident that it’s the former. Attacks that my systems have received (so far) have tended to fall into one of the following categories:

  1. Exploration: a SIP “OPTIONS” request  usually claiming to be from 100@  dialing 100@my-ip-address.  Presumably, a positive response to this will alert the attacker that they’ve found a certain popular telephony platform with a default dialplan present (and so perhaps being administered by a novice). This suggests a ripe target for attack.
  2. Direct attack a):  a SIP “INVITE” request purporting to be from asterisk@<some ip address> to  <somenumber>@my-ip-address
  3. Direct attack b):  a SIP “INVITE” request purporting to be from unknown@<some ip address> to  <somenumber>@my-ip-address
  4. Direct attack c):  a SIP “INVITE” request purporting to be from 101@<some ip address> to  <somenumber>@my-ip-address
  5. Direct attack d):  a SIP “INVITE” request purporting to be from 100@<some ip address> to  <somenumber>@my-ip-address  – often a huge number of  different variants of “somenumber”  are used in an attempt to thwart any security-through-obscurity that local dial-plan conventions might be providing.

So, although there are some obvious patterns here, it’s going to be a never ending arms race to defend against these attackers.  As soon as awareness is raised of each common attack,  and defences against the common attacks are put in place, new attacks will be  developed by the attackers. My observation of these attacks   prompted me to decide to tighten up the default VCS configuration to provide extra layers of protection (even though, by luck, the attacks I received were harmlessly deflected by the default VCS configuration). I will discuss an iterative approach to tightening up  VCS Expressway security in a future post. If you’re now panicking,  and can’t wait until then, I suggest you investigate some of the VCS configuration advice to be found on the Cisco website and on messageboards.

Update: for up-to-date resources (2015) please take a look at  and sign up for the free newsletter!


8 thoughts on “Checking your Tandberg/Cisco VCS Expressway for hack-attacks from VOIP SIP scanners

  1. Hello,

    I have a tandberg VCS c20 system in my company for private corporative video conference. It was hacked in a way we are trying to understand yet, absorving all the local NW bandwidth and broadcasting different ranges of public ip’s. Could you imagine that?

    Is it the same issue you are thankfully presenting here?

    Best Regards

    1. That sounds like a different issue. One possible misconfiguration that could potentially lead to compromises of the type you describe is if you deploy your TANDBERG system and forget to change both the root and admin password from their defaults. Under the covers, many of these systems (and their competitors) run on Linux and so you have to take the same security precautions you would with any Linux server.

      I would always recommend:
      1) Changing all passwords on your TANDBERG systems to “strong” non-default values following normal industry best practice
      2) Disabling any unneeded services (e.g. disable SSH, Telnet etc. if you do not actually need them) – this reduces the “attack surface”
      3) Configuring your firewall to prevent unauthorised external access.
      4) Fixing alarms: On your VCS system, check that you are running without any raised alarms/warnings (if you see a red triangle in the corner of the administration web page, fix the underlying problem *properly* – don’t just acknowledge the alarm/warning!)
      5) Making sure that your system is running a recent version of firmware.

  2. Your post describes exactly what I have experienced recently, including the destination numbers being in Israel. We are still receiving attempts that are now deflected by a reconfiguration. But I would be very interested to see more about what you have done if it is sensible to discuss that sort of thing in an open forum!!

  3. Julian: Sorry for the delay in getting back with you.

    There are several steps I’d recommend:

    1) writing (&uploading to the VCS) a small CPL script to deflect inbound calls that shouldn’t be hitting your domain. For example, if you have a URI based dialplan where everyone has an alias such as then having CPL rules to reject “number@vcs-ip-address”/”sip:number@vcs-ip-address” will catch a lot of attacks. Of course, this defence probably only has a limited shelf life as attackers get more sophisticated and start trawling for sip SRV records instead of portscanning… But for now, it’s useful.

    2) Consider disabling SIP UDP transport (but leaving SIP TCP SIP/TLS enabled) if that’s tenable in your deployment (although this may require you to have NAPTR records set up for SIP TCP/SIP TLS as per the relevant docs).

    Again this defence probably only has a limited shelf-life as attackers may eventually work out this defence. SIP UDP based attacks certainly account for 99% of attacks that I’ve seen, but there are occasional incidences of SIP TCP and even the occasional H.323 based attack.

  4. In my setup I just used search rules to catch any requests for digits that would lead OUT to my gateway and replaced them with a nonsense entries that stop. Basically I don’t care who they are or how they come into the expressway, they just shouldn’t be able to ever search for 9+ a number to get out the ISDN gateway via the usual access code.

  5. what gets even worse on cisco VCS is that even the call might not go through in the end, they could continuously hog your licenses across the traversal zone, rendering your system useless for legit calls. I know, I ve seen it

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s