What is Telecommunications Fraud?
Telecommunications fraud is the process of exploiting a misconfiguration in telecommunications systems to gain access to your telecommunication platform to make calls on your behalf.

Few things that are really bad about this type of exploit:

• The exploiter don’t even need an internet to perform such hack.
• It can be very costly.
• it can go unnoticed for a long time, or till you get a surprise bill.
• The exploiter caller ID will be your company number, might pretend to be your company representative.
• it can even be so bad that they can sell calling cards to use your system for long distance calls.
• other scenarios are left for imagination…

While Lync/SfB and Exchange UM doesn’t have a DISA feature (direct inward system access ) the below mix of configuration can cause a serious leak in the system to allow telecom fraud.

Lets first have a look on how that could be possible:

When you configure Lync/SfB integration with Exchange UM via the OCSUtil ; two contacts are going to be created in Lync/SfB and assigned automatic Dial Plan and Voice Policy.

1. The Auto Attendant contact
2. The Subscriber access contact

Also you in exchange UM an important component will be populated by running the exchUCUtil script which is the “virtual” 1:1 IP gateway.

Now lets go to the configuration:

I’ve seen a lot of companies now avoid the short extension assignment in Lync/SfB and just use E164 format with 10 digit North America DID for the users’ line URI.

so when they start the integration with Exchange UM they will need to assign Exchange UM extensions for the users in Exchange, and to simplify things, they will use that 10 digit DID as an “Extension”.

So far that is not going to cause an issue until they enable “Allow calls to Extension” in the UM dial plan, UM mailbox Policy or the Auto attendant.

Configuration of my lab was the following:

• 7 and 10 digits North American plan is configured in SfB/Lync at the Default,Pool or Site Dial plan to allow E.164 normalization.; Also if you dont have Default,Pool or Site dial plan normalization defined and created Translation rules on Global trunk normalization to capture 10 digits coming from the Trunk and normalize to E.164 that will also work.
• SfB Users have 10 digits DID normalized in E.164;  e.g: (lineURI is tel:+1(NPA)XXX-XXXX)
• Exchange UM dial plan is 10 digits extension and “allow calls to extensions” is enabled on Dial Plan , Auto Attendant and UM mailbox Policy

• ---

With this configuration the following scenarios was dialled:

1. Scenario 1: Caller dials the AA number and as it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and the call was made outside of my SfB server. so for that to happen:
   • A- The Extensions expected are 10 digits based on the UM dialplan
   • B- ExUM send that through the 1:1 IP gateway.
   • C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the UMAA object OR on the Trunk Global number translation.
   • D- The UMAA contact object that was created by the OCSUtil has the default Global or Site voice policy that has a route to terminate E164 digits on the PSTN.
2. Scenario 2: Caller dials the SA number and navigate till it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and the call was made outside of my SfB server.

• A- The Extensions expected are 10 digits based on the UM dialplan
• B- ExUM send that through the 1:1 IP gateway.
• C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the UMSA object OR on the Trunk Global number translation.
• D- The UMSA contact object that was created by the OCSUtil has the default Global or Site voice policy that has a route to terminate E164 digits on the PSTN.

• 3.   Scenario 3: Caller dials any SfB DID number and timeout to voicemail the caller press **## then it prompts to dial an extension, I dialled any 10 Digits number (eg.my mobile) and again the call was made outside of my SfB server.
  • A- The Extensions expected are 10 digits based on the UM dialplan
  • B- ExUM send that through the 1:1 IP gateway.
  • C- The 7 or 10 digit Extension will get Normalized to E.164 on the SfB Global, Site or Pool Dialplan which is the default/automatic dialplan for the Referred User (In that case the SfB Dialed/Voicemail User ).
  • D- The Referred User has the Global, Site or User voice policy that has a route to terminate E164 digits on the PSTN.

Below is a flowchart of my lab findings that I logged and how the call could be routed outside of your system from an anonymous caller.

That was the problem now for the solution:

For the First and Second Scenario where the Caller Dials the AA and SA you need the Allow Extensions dialling to be enabled in both the UMdial Plan and Auto Attendant, the reason is that you may have a PBX that is behind the SfB server that the legitimate caller might need to call.

So the solution is to assign both the AA and SA objects a Voice Policy and a Route that ONLY routes to PBXes without PSTN access (if your PBX are 7 or 10 digits) ; if your PBX extensions is less than the UMDial plan, it will not route anyway. Also you can remove the Associated Trunk altogether from that Route so if the number isnt found in SfB Server it doesn’t leave to any where.

But for the Third Scenario where the caller dials the voicemail and then press **## you wouldn’t be able to change the voice policy as the Referrer is the SfB user , so in that Case you will have to turn off the “dial by extension” from the UM Mailbox Policy. But at the same time you can enable the caller to dial (0) at the voicemail prompt to transfer only to the operator.