cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
649
Views
0
Helpful
1
Replies

non DDI extension receives a direct inbound call - CDR issue or Security threat?

Hi all,

I am hoping that this may well be something really obvious that I have missed but here goes.

One of our customers has an established centralised Multi-site CUCM v6.1(3) solution with 1 x Publisher &  1 x subscriber.

The Core site has a 2811 ISR configured for H.323.

The Telco is sending in 4 digits inbound and these are mapped to 4 digit internal extensions.

the DDI numbers are 60XX  & 92XX.

There are no called translation rules or profiles to amend digits being sent to the CUCM cluster.

There are ordered voip dial-peers pointing with destination patterns of 6...  & 9... with IPV4 session targets of the subscriber IP address & then second choice the Publisher (reflecting the Call-manager group configured on CUCM using the Subscriber as the call processing agent).

They have generated CDRs from yesterday after they had some weird calls coming inbound to a specific number, however the called number was not a DDI number.

The called number was 6216.

I have checked the CDRs and the number 6216 is found in the "originalCalledPartyNumber" column (which according to the documentation also can be the resulting number at the end of any translations).  I have checked the translation patterns and nothing matches this.  The source IP address is the local voice gateway and destination IP, the IP Phone. 


If there was a DDI extension with a CFA set to 6216 the "originalCalledPartyNumber" would reflect this DDI & then the "finalCalledPartyNumber" would reflect 6216. 



Definitions as per the guide

originalCalledPartyNumber  - This number designates the originally called party, after any digit translations have occurred.

FinalCalledPartyNumber - For forwarded calls, this number designates the last party to receive the call.  For non-forwarded calls, this field shows the original called
party.


I have tried to call the full external DDI number + this internal extension (whilst monitoring debug isdn q.931 on the voice gateway) externally and it definitely does not arrive at the gateway

They have had a malicious caller withholding his number for a while now (they believe using an autodialer).  The end user using 6216 stated that when these calls were happening, the call came in and then 6216 got connected to someone else on cluster.  Weird again but I don't actually see this on the CDRs.

Has anyone ever heard of anything like this where someone can get directly connected to a number that is non-DDI?  I tested an inbound call from the gateway using the csim start command and viewed it on CDRs, but as the call doesn't connect no destination IP address appears in the CDRs (think I was off track with this but I was wondering if the gateway had been compromised).

thanks in advance for any ideas,

Stuart

1 Reply 1

One option is to pull the CallManager Trace Files for the time period that the call came in, probably 2 minutes on either side to be sure.  Then load those trace files into the Voice Log Translator within RTMT.  VLT is a plug-in that you have to download from Cisco, but it is free and worth its weight in gold (which isn't saying much since it's software and it's weight is just that of a few trillion electrons, but I hope you get the idea).  The VLT will recontruct the Q.931 setup messages that the H.323 VG sent to the CUCM, so you can see what digits were received from the PSTN.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: