Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Toll Fraud issue 2

Status
Not open for further replies.

hawks

IS-IT--Management
Oct 9, 2002
5,869
0
0
US
Back to the pheakers, just got another call from a customer with a Call Pilot. They said they are being hacked, anyone got any steps they take to prevent this? Right now I have restriction filters built and assigned to the Vmail ports (still got out). We have outdial turned off for the mailboxes, I tried to have Outdial channels to 0 but it would not take it.
 
Get an SMDR on that system and find out what is happening.

PhM
 
SMDR sounds good. Are you sure they are using the call pilot to get out? Have you checked the call pilot reports; particularly the call handling section to see what is going on?
 
Hawks,

Make sure you deny '*'. It is a host signalling digit that will bypass all Norstar restrictions.

PhM

 
It is a Flash not a Call Pilot sorry. Is there any reporting in the Flash I can look at?
They have a SMDR on the system but all it shows is the number dialed. I know it's through the Vmail because we had them take it off the system for a couple of days and no problem. Once we put it back on we got hit that's when I tried restrictions. I'll add the '*' to my filter and see if that does anything. The calls seem to be mainly to the Phillippines.
 
DISA is off
I forgot to say thanks for the help from everyone so far. I just spoke with another Tech and he said that they had the same problem a month or so ago. He said that they could not figure out how to stop it so what they did was have the carrier put account codes on the lines. I'm trying not to do that so I hope we can figure somthing out.
 
That kind of proves the point of mailbox outdialing. I wonder if there is a back door Nortel doesn't publish? Hawkes, the SMDR should be able to state the didgits outdialed from the VMail DNs... what kind of dial string is there?

PhM

 
Just area code and number. We even have outdial turned off on the boxes, they still made calls. I agree it's from the voice mail because when we had it unhooked for the couple of days we had no issues.
 
Hawkes,

Deny or disable Pool 10 in particular; other high number pools if in use. I'm not quite sure myself how to do this but I believe after much research that here lies the key to the hacking problem. Perhaps try to tie up all available and unassigned access codes into functions that don't exist. Also try denying # as well as *.
Also if you have a FastRad on auto answer, make it attendant transfer only.

Let me know what you've found please. If not on this forum then at tisvcs@yahoo.com

Rgds
PhM
 
It is difficult to find a solution when it is not clear where the dial tone is coming from. We know that the voicemails seem to ignore dialing restrictions programmed in the switch but maybe they will not ignore destination codes.

I have an idea but have not had the time to explore or try it out. Get rid of all pool codes and the external code and build destination codes to do the same thing. A simple destination code could be 9 and give access to pool "A" and absorb the 9. To take this further you then build a destination code that reflects the calls dialed to the Philippines, 9-011-63-XX-XXX-XXXX and absorb enough digits to prevent the call from completing.

It may be possible to build a destination code that could cause all outbound calls to fail and put it on night service button. Assuming outbound dialing is not required at night.

I have not tried this and am a little rusty with destination codes. Maybe other members of the group could build on this idea to make it workable.

Rob
 
Starting of day 2 with no complaint (hopefully they didn't just take a day off). What we did was go in and take away any Pool access for the mail, we rebuilt the restriction filters. I still have not added the "*" yet because I'm trying to do this one step at a time. The customer and carrier are willing to work on this so maybe we can find out how they are doing it. I understand about the desti codes but what about the systems that don't have that capability. I'll keep you posted if I find out anything else.
 
Systems that don't have destinatin codes also likely won't have mbox outdial either.

PhM
 
I had started a thread on this issue a few months ago. It has some good info in it, so I just added a post to it to bring it to the top. Check out "Toll Fraud. How do I keep from getting hacked".

Also, you might recommend that your customers check with their LD vendors to see how they treat toll fraud. I had one company that worked with the customer, but one of the big 3 stuck it to someone else I know for $7K.
 
P.S. I'll bet all of your mailboxes have a CLS of 1 and that you have some people with simple 4 digit passwords that got cracked. CLS 1 is UNRESTRICTED! You MUST change ALL mailbox passwords to AT LEAST 6 digits! You MUST build a new odd numbered CLS and reassign it to all your mailboxes.This is where you will restrict the hackers.Your restriction filters on your lines and sets has nothing to do with and WILL NOT RESTRICT calls made through your voice mail system! I really can't go into much more detail then this.We don't know who else might be listening.
 
Bman,
Are you trying to say that even if outdial has been denied in Mbox set up it will still go through if so programmed in the user side where COS1 is in force?

PhM

 
I had two customers get hacked lately.

I had customer change mbox password to 6 digit,(you can also make them change it through class of service every so many days)change allow redirect to N, in mbox programing dont allow out bound transfer.
 
It's Tuesday and still no complaint so either the changes worked or they moved on to someone else. Thanks agin for all the help.
 
Had a customer call this AM with Fraud- Mics 6.1 /analog lines/ cp150.
The fraud was caught within a day by Qwest, which was nice.

Anyways, I have locked down all the usual stuff, changed passwords, outdial, COS, etc.

In the cp logs there are some new entries starting yesterday that were never present before:

The change was Ctx Trans =89. Previously this was always 0. I am guessing this means the fraud went out over a centrex (flash) transfer.

The question- is this simply a hacker dialing in, guessing the password, and changing some settings? Or is there some hack/ backdoor I am not aware of? The calls were to 20 different countries.

I traced the log back to where it all started, but I am not familiar enough with them to know exactly what the guy did…anyone have experience with these logs…log is below.

If you know something about this, but don’t want to post for security reasons, please email me-
memtosh at yahoo.com

2005/02/08 15:24:11 FtLog buffer overrun attempted. See Module, Functi
et code below:
2005/02/08 15:24:11 Shell 1
2005/02/08 15:24:11 Warning: F986Start mbDisconnect() failed
2005/02/08 15:24:11 rc=39(0x27)
2005/02/08 15:24:11 Internal call from DN 348.
2005/02/08 15:24:11 Dump: Shell 1
2005/02/08 15:24:11 2005/02/08 15:15:57 AsResumePrompts 1st timeout
2005/02/08 15:24:12 2005/02/08 15:15:58 AsResumePrompts call disconnec
2005/02/08 15:24:12 2005/02/08 15:15:58 F981MainMenu call disconnec
2005/02/08 15:24:12 2005/02/08 15:15:58 F981Menu call disconnec
2005/02/08 15:24:12 2005/02/08 15:15:58 Idle State init event
2005/02/08 15:24:12 2005/02/08 15:24:10 Idle State call offered
2005/02/08 15:24:12 2005/02/08 15:24:10 WaitForAnswer init event
2005/02/08 15:24:12 2005/02/08 15:24:10 WaitForAnswer call answered
2005/02/08 15:24:12 2005/02/08 15:24:10 F986Start init event
2005/02/08 15:24:12 2005/02/08 15:24:10 AsInitAddrEntry init event
2005/02/08 15:24:12 2005/02/08 15:24:10 AsAddrEntry init event
2005/02/08 15:24:12 2005/02/08 15:24:10 AsAddrEntry data entry pro
2005/02/08 15:24:13 2005/02/08 15:24:10 AsPresentPrompt init event
2005/02/08 15:24:13 2005/02/08 15:24:10 AsResumePrompts init event
2005/02/08 15:24:13 2005/02/08 15:24:10 AsResumePrompts key three
2005/02/08 15:24:13 2005/02/08 15:24:10 AsAddrEntry key three
2005/02/08 15:24:13 2005/02/08 15:24:10 AsDataEntry key three
2005/02/08 15:24:13 2005/02/08 15:24:10 AsAddrEntry key three
2005/02/08 15:24:13 2005/02/08 15:24:10 AsDataEntry key three
2005/02/08 15:24:13 2005/02/08 15:24:10 AsAddrEntry key five
2005/02/08 15:24:13 2005/02/08 15:24:10 AsDataEntry key five
2005/02/08 15:24:13 2005/02/08 15:24:10 AsAddrEntry data entered
2005/02/08 15:24:13 2005/02/08 15:24:10 AsInitAddrEntry addr entered
2005/02/08 15:24:13 2005/02/08 15:24:10 F986Start addr entered
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top