Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!bionet!hayes.ims.alaska.edu!accuvax.nwu.edu!nucsrl!telecom-request From: IZZYAS1@oac.ucla.edu (Andy Jacobson) Newsgroups: comp.dcom.telecom Subject: Re: Mysterious LD Fraud Message-ID: <14371@accuvax.nwu.edu> Date: 4 Nov 90 14:22:00 GMT Sender: news@accuvax.nwu.edu Organization: TELECOM Digest Lines: 50 Approved: Telecom@eecs.nwu.edu X-Submissions-To: telecom@eecs.nwu.edu X-Administrivia-To: telecom-request@eecs.nwu.edu X-Telecom-Digest: Volume 10, Issue 792, Message 9 of 10 In TELECOMecom Digest V. 10 #785: Barton F. Bruce writes: Long story deleted >blocked from all but a few managment phones. All, and I mean ALL >including brief aborted misdialed sequences, outward dialing is >captured on the SMDR log. NO DISA is enabled on their switch, and the more story deleted >Their NET&T bill showed MCI calls on their LDN. Curiously, that new more story deleted >There is NO WAY anyone could have routed calls 10222, and even if they >had, they would have shown up on the SMDR log. Also the trunks are in >a rotary hunt group outgoing that always picks another trunk on >successive calls. The chance of anyone getting even a few, let alone >all these calls, onto THE ONE TRUNK that ANIs as xxx.8000 is >impossible from behind the PBX. more deleted >I suspect that something is screwed up in the CO, or that someone has >tapped the line outside this building and explicitly dialed 10222 >before these calls. Well, it sounds like either someone is getting onto that LDN trunk only, and that can either be an inside job, which was not mentioned as a possibility, or an outside job. (Someone in the manhole with a but set or tapping your crossconnect. _A definite_possibility_.) One thing to note, depending on the type of trunk you have and the type of switch that serves it, it is possible that someone "behind the PBX" is dialing one type of CAROT test port on your local switch, signalling it to disconnect, and getting trunk dial tone. Supervision may not be ended by the local CO on some types of test ports, and a second call can be piggy backed on to the test port call. This would not explain why only one trunk is getting these calls unless that trunk is the only one that can get to those test ports on the right type of switch. Check your log for calls that fall on coincident times, and if any test port numbers are being dialed. Good luck. P.S. I think it's spelled CAROT(?) Someone correct me if I'm wrong. A. Jacobson