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.
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 Chriss Miller 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
- Thread starter hawks
- Start date
- Thread starter
- #5
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.
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.
- Thread starter
- #7
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.
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.
- Thread starter
- #9
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
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
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
- Thread starter
- #12
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.
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.
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.
BerettaMan
Technical User
Change the password for Mailbox 100 and Mailbox 102.
BerettaMan
Technical User
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.
- Thread starter
- #19
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
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