E1 Hacking

[pmvillarama]

Hi ,

Two of our customers reported similar issues, they're having unauthorized IDD calls reflected in their Telco billing. I can't see any records in the CUCM cdr, the only traces of the calls was found on the PSTN gateway (seems like a loop);

0x2B704    34A7 0x71465B08  0/2/1:15.3       0/2:6   7675034211  g711ulaw   1000/2
0x2B70B    34A7 0x71465B08  0/2/1:15.14      0/7:3  *7675034211  g711ulaw   2/1000
0x2B69F    348B 0x67EF46CC  0/2/0:15.14      0/1:2   7675034212  g711ulaw   1000/1
0x2B6A9    348B 0x67EF46CC   0/2/0:15.25      0/4:2  *7675034212  g711ulaw   1/1000
0x2B68F    3482 0x67EF46CC  0/2/0:15.9       0/1:3   7675034211  g711ulaw   1000/2
0x2B69B    3482 0x71465B08  0/2/1:15.25      0/1:5  *7675034211  g711ulaw   2/1000
0x2B64F    346B 0x71465B08  0/2/1:15.8       0/8:3   7675034236  g711ulaw   1000/2
0x2B658    346B 0x71465B08  0/2/1:15.17      0/7:5  *7675034236  g711ulaw   2/1000
0x2B616    345E 0x67EF46CC  0/2/0:15.8       0/3:3   7675034236  g711ulaw   1000/1
0x2B61D    345E 0x67EF46CC  0/2/0:15.20      0/6:5  *7675034236  g711ulaw   1/1000
0x2B5F6    3458 0x67EF46CC  0/2/0:15.2       0/2:1   7675034212  g711ulaw   1000/1
0x2B5F9    3458 0x67EF46CC  0/2/0:15.18      0/2:2  *7675034212  g711ulaw   1/1000
0x2B5E0    3452 0x67EF46CC  0/2/0:15.7       0/7:4   7675034212  g711ulaw   1000/1
0x2B5E6    3452 0x67EF46CC  0/2/0:15.10      0/1:1  *7675034212  g711ulaw   1/1000
0x2B5B9    3443 0x67EF46CC  0/2/0:15.1       0/4:6   7675034212  g711ulaw   1000/1
0x2B5BB    3443 0x67EF46CC  0/2/0:15.31      0/6:4  *7675034212  g711ulaw   1/1000

dial-peer voice 1000 pots
tone ringback alert-no-PI
service transfer
incoming called-number 1800
fax rate voice
port 0/3/1:0
!
dial-peer voice 1 pots
description *** PSTN OUTGOING CALLS TO ISDN ***
call-block translation-profile incoming call_block
preference 2
max-conn 15
destination-pattern .T
incoming called-number .
direct-inward-dial
port 0/2/0:15
!
dial-peer voice 2 pots
description *** PSTN OUTGOING CALLS TO ISDN ***
call-block translation-profile incoming call_block
preference 3
max-conn 15
destination-pattern .T
incoming called-number .
direct-inward-dial
port 0/2/1:15

In my understanding, these calls uses the same port for incoming and outgoing call leg. since I can't see any traces in the cdr, i'm thinking that there's a spot on the config or other reason that permits this. however, Upon testing I can't see any chance that this is possible.

Any ideas how can we stop this or prevent this from happening?

any help is very much appreciated.

[Daniele Giordano]

What is your phone number? Do you have the arc 76750342xx?
If you have a voip dial-peer, you can use "huntstop" command to stop the hunting of incoming calls to the pots dial-peer and so prevent loop.

Can you post the configuration of your gateway?
Can you execute a "debug voice ccapi inout" during the issue?

Regards.

[pmvillarama]

Hi giordano p,

Thanks for the reponse. No the called number in the logs is different from the customer's DID block

customer e1 DID block is (8118181)

Called number received from TELCO is 0017675034212 (as seen in incoming call from "show voice call stat")

I'm not really sure that it matches any voip dial-peer since all voip has specific patterns configured except in incoming called number of pots.

Even if theses calls seems using the gateway to hide its ANI..it should not be routed in a DID block that has a different number right?

any more ideas?

[William Burton · Accepted solution]

I have run into this same issue here in the USA, and overseas in Asia-Pac.  very simllar issues.

Are you integrated wi Call Center Express or Unity Express at either or both of the two locations?

I have been trying to lock this down for months!!

Thanks,

Bill B.

[phooghen · Accepted solution]

Paul,

Got a similar issue with one of my customer.

PSTN --- GW----H.323----CUCM

Call is coming from PSTN to the GW. The GW forwards the call to the CUCM across the first voip dial peer.

Since CUCM has no entry for the specific DN, the GW tries the second voip dial peer.

Since there is still no CUCM entry, the voice GW will try the default dial peer and redirect the call to the pots dial peer.

The pots dial peer will send the call back to the PSTN telco.

Since the called number is part of the specific company DID, the Telco will send back to the specic company GW.

Then, we have a loop exhausting all the B channels.

Maybe you can try to create a Translation pattern which redirect all the non assigned DID calls to the receptionist DN.

Suppose your DID is 12345XXXX, try to create a TP = 12345XXXX with a mask redirecting the calls to the reception DN or to an IVR.

Pierre.

[pmvillarama]

Hi Pierre,

thanks for the response.  The DNIS 0017675034212 in the gateway call logs does not belong to the DID group so I'm thinking how this call got end up in that e1 circuit in the first place.

customer e1 DID block is (8118181)

Called number received from TELCO is 0017675034212 (as seen in incoming call from "show voice call stat")

Perhaps debug logs can give us something but as of now, there's no issues after we shut/no shut the dial-peer 1000. another question is, since the DNIS received from telco is different from the DID block, the gateway should have no idea how it will route the call to cucm (all voip dial-peer has specific patterns) so most likely if you're right in the behavior of dial-peer 0, gateway will just route it back to telco.

If my analysis is correct, can I just  block all incoming call that has called number different from the DID block?

Thanks again, please let me know your thoughts on this.

[phooghen]

I recommend to block all incoming calls that has called number different from the DID.

But I am also wondering why the TELCO forward those calls to your GW.

Pierre.

[Craig Dyer]

Paul,

     What does the telco present for a normal incoming call? How many digits and an example would be interesting.

     What country is this happening in?

Craig