How Bank Hacking Works

A certain number of financial institutions that reside within the

packet-switched confines of the various X.25 networks use their connections to

transfer funds from one account to another, one mutual fund to another, one

stock to another, one bank to another, etc... It is conceivable that if one

could intercept these transactions and divert them into another account, they

would be transferred (and could be withdrawn) before the computer error was

noticed. Thus, with greed in our hearts, an associate and I set forth to test

this theory and conquer the international banking world.

We chose CitiCorp as our victim. This multinational had two address

prefixes of its own on Telenet (223 & 224). Starting with those two prefixes,

my associate and I began to sequentially try every possible address. We

continued through 1000 in increments of one, then A-Z, then 1000-10000 by 10's,

and finally 10000-99999 by 100's. Needless to say, many addresses were

probably skipped over in our haste to find valid ones, but many we passed over

were most likely duplicate terminals that we had already encountered.

For the next few days my associate and I went over the addresses we had

found, comparing and exchanging information, and going back to the addresses

that had shown 'NOT OPERATING,' 'REMOTE PROCEDURE ERROR,' and 'REJECTING.' We

had discovered many of the same types of systems, mostly VAX/VMS's and Primes.

We managed to get into eight of the VAXen and then went forth on the CitiCorp

DECNET, discovering many more. We entered several GS1 gateways and Decservers

and found that there were also links leading to systems belonging to other

financial institutions such as Dai-Ichi Kangyo Bank New York and Chase

Manhattan. We also found hundreds of addresses to TWX machines and many

in-house bank terminals (most of which were 'BUSY' during banking hours, and

'NOT OPERATING' during off hours). In fact, the only way we knew that these

were bank terminals was that an operator happened to be idle just as I

connected with her terminal (almost like the Whoopie Goldberg movie, "Jumpin'

Jack Flash," not quite as glamorous ...yet.)

Many of the computers we eventually did penetrate kept alluding to the

electronic fund transfer in scripts, files, and personal mail. One of the

TOPS-20 machines we found even had an account EFTMKTG.EFT, (password EFTEFT)!

All the traces pointed to a terminal (or series of terminals) that did nothing

but transfer funds. We decided that this was the case and decided to

concentrate our efforts on addresses that allowed us to CONNECT periodically

but did not respond. After another week of concentrated effort, we managed to

sort through these. Many were just terminals that had been down or

malfunctioning, but there were five left that we still had no idea of their

function. My associate said that we might be able to monitor data

transmissions on the addresses if we could get into the debug port. With this

idea in mind, we set out trying sub-addresses from .00 to .99 on the mystery

addresses. Four of the five had their debug ports at the default location

(.99). The fifth was located 23 away from the default. That intrigued us, so

we put the others aside and concentrated on the fifth. Although its location

was moved, a default password was still intact, and we entered surreptitiously.

The system was menu driven with several options available. One option,

Administrative Functions, put us into a UNIX shell with root privilege. After

an hour or so of nosing around, we found a directory that held the Telenet

Debug Tools package (which I had previously thought existed solely for Prime

computers). Using TDT, we were able to divert all data (incoming and outgoing)

into a file so we could later read and analyze it. We named the file ".trans"

and placed it in a directory named ".. ", (dot, dot, space, space) so it would

remain hidden. This was accomplished fairly late on a Sunday night. After

logging off, we opened a case of Coors Light and spent the rest of the night

(and part of the morning!) theorizing about what we might see tomorrow night

(and getting rather drunk).

At approximately 9:00 p.m. the following evening, we met again and logged

onto the system to view the capture file, hoping to find something useful. We

didn't have to look very far! The first transmission was just what we had been

dreaming about all along. The computer we were monitoring initiated by

connecting with a similar computer at another institution, waited for a

particular