Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!ames!ucbcad!ucbvax!kitty.UUCP!larry From: larry@kitty.UUCP Newsgroups: comp.dcom.telecom Subject: Submission for mod.telecom (Comments on telephone toll fraud) Message-ID: <8705020316.AA18941@seismo.CSS.GOV> Date: Fri, 1-May-87 23:16:11 EDT Article-I.D.: seismo.8705020316.AA18941 Posted: Fri May 1 23:16:11 1987 Date-Received: Sun, 3-May-87 09:22:52 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 127 Approved: telecom@xx.lcs.mit.edu > In a recent article AWalker@RED.RUTGERS.EDU (*Hobbit*) writes: [discussion about SF-tone detectors in central offices] > Isn't this a bit redundant in these CCIS-ridden days? I would think so! Most toll fraud today occurs through the fraudulent use of calling card numbers. However, during the 1970's when "blue box" fraud reached its peak, the Bell System in particular did use 2600 Hz SF tone detectors. One such device was called [somewhat euphemistically] a Multichannel Tone Test Unit (MTTU). One MTTU had the capacity to monitor up to 100 trunks. The MTTU could be used in a local office to monitor outgoing DDD access trunks, or in a tandem office to monitor 2-wire or 4-wire intertoll trunks. In the MTTU, each trunk connection had a dedicated SF tone receiver which would alarm if an SF signal longer than about 200 ms was detected. The sensitivity was pretty decent - something between -35 and -40 dBm - so it COULD conceivably be susceptible to the crosstalk situation mentioned in the earlier article. The MTTU had a trunk identification unit, which would send the identity of the "offending" trunk to the Call Identity Indexer of the central office CAMA or LAMA recording apparatus. This would allow the origin (i.e., calling number) of the fraudulent call to be ascertained. > Also, it seems rather improper for an office to assume that any occurrence of > 2600 on a subscriber loop indicates possible fraud. First of all, if someone > wanted to defraud he'd just hike down to the nearest pay phone. Second, there > are a lot of OCC switches that respond to 2600, so the phone co has another > think coming if they believe I'm committing toll fraud every time I clobber > one of them upon completion of a call. Fooey. If the [possibly apocryphal] crosstalk incident had occurred several years ago, I would believe it. If the incident is supposed to be contemporary, then I would be skeptical that an operating telephone company is still using such toll fraud detection apparatus (unless they have little or no CCIS and/or are still using CAMA trunks with local ANI - at least not likely today in an ESS office). Most message accounting today is LAMA; i.e., it is done in the local central office. Such message accounting has returned to the local central office primarily to permit message unit timing on local calls. So the point is: the LAMA knows every number that a subscriber has dialed (by dial-pulse and DTMF, that is). Assuming that there is no CCIS or 3700 Hz out-of-band signaling to cause a absolute denial of "blue box" usage, one can't implement a "blue box" fraud without gaining access to a toll switching office. And one generally can't gain access to a toll switching office without creating one of three situations: 1. Dialing an inward WATS number. Simple computer exception reporting from raw LAMA call data can ascertain if certain subscriber lines are making unusually large numbers of 800-number calls. Of course, such excessive usage can be perfectly legitimate, but detection of such high usage, along with other "anomalous calling patterns" can be used to pinpoint subscriber lines where toll fraud is suspected. A "roving" SF-tone detector could then be attached to _specific_ suspect subscriber lines. 2. Dialing directory assistance in other area codes. This is even easier to detect by exception reporting: one doesn't have many directory assistance calls lasting more than, say, three minutes! 3. Dialing an actual toll call, but applying SF before answer to reseize the toll switching office and dial a "more expensive" toll call. This is not very common because the subscriber line is still going to be billed for the original dialed toll call. In addition, most newer ESS offices closely monitor answer supervision on outgoing toll trunks; such monitoring makes it difficult to perpetrate "blue box" fraud. Failure to achieve answer supervision within say, three minutes results in a forced disconnect. Once answer supervision has been detected, its subsequent loss for more than say, 30 seconds will result in a forced disconnect. Furthermore, there is ESS software to monitor "anomalous" trunk answer supervision changes. > The user-end symptoms of 2600 detection seem to be as follows: Beeeep. Switch > disconnects your call, or whatever its fancy. Some switches drop the > connection to the office completely, forcing the call to throw back to the > office and return dial tone within a few seconds. At any rate, in the > background one can hear a small "grack" sort of click -- I would assume that > this indicates the bridging-in of the more sophisticated "fraud detection" > equipment that would listen for and report various other tones. This is > un-bridged again after about 20 seconds if nothing else happens. I could > determine this because in some offices the bridging equipment is flakey and > introduces extra line hum while it's connected. Good heavens! You actually tried it?! :-) :-) :-) You are most likely just hearing the originating register or its ESS equivalent being switched into the circuit to accept the anticipated MF signaling train, with the register "timing out" after 20 seconds of no signaling. Unless there is faulty apparatus, you will NEVER aurally detect the presence of any SF monitoring devices; all such devices use bridging amplifiers that result in an effective bridging loss of no more than 0.05 dB. > Would someone closer to the technical end of the above like to explain how > this works in greater depth? And what is generally done with the generated > reports when there's obviously no "fraud" happening on a given loop? Telephone company security personnel react very cautiously to any suspected "blue box" fraud. If an SF-tone detector or exception reporting software results in "hits" for a given line on several different days, chances are a dedicated SF-tone and MF signaling detector will be attached to the suspect subscriber line. Further information will then be obtained that can be used in a prosecution; mere detection of SF tones is insufficient. It is necessary not only to know exactly what destination number was dialed, but to have some idea as to the identity of the _person_ using a given subscriber line; merely knowing the subscriber line number where the fraud originates is insufficient - the identity of the actual _person_ making the call must be ascertained. In case anyone is wondering, it is the absolute right of any telephone company or communications common carrier to attach such monitoring apparatus to any subscriber's line. Furthermore, under most circumstances, it is also an absolute right of any such telephone company or communications common carrier to aurally monitor any subscriber line to detect fraud; this may be euphemistically referred to as "service observing" - and is more common than telephone companies would like their subscribers to believe. The point I am trying to make in the above is that "blue box" toll fraud is disappearing, and the use of toll fraud detection apparatus is consequently diminishing. While the incidence of "blue box" toll fraud has decreased, it has unfortunately been replaced by fraudulent use of calling card numbers, and most recently by cellular telephone "spoofing" fraud (which is probably the worst can of worms yet!). <> Larry Lippman @ Recognition Research Corp., Clarence, New York <> UUCP: {allegra|ames|boulder|decvax|rocksanne|watmath}!sunybcs!kitty!larry <> VOICE: 716/688-1231 {hplabs|ihnp4|mtune|seismo|utzoo}!/ <> FAX: 716/741-9635 {G1,G2,G3 modes} "Have you hugged your cat today?"