I NFORMATION S YSTEMS C ONTROL J OURNAL, VOLUME 5, 2007 1Copyright © 2007 ISACA. All rights reserved. www.isaca.org.A Hacker Breaks In—Lessons LearnedFrom a True StoryBy Zhu Wenming, CISA, Hu Hanhui and Wang HaoThis is a true story about an investigation in which theauthors are involved. Due to the complexity, volume andvulnerability of the nature of business, it could happen againin the future. Therefore, it is important to arouse people’sawareness and start to reconsider, review and redesign the riskmanagement system. (For privacy reasons, the names of theparties in the article have been altered.)The StoryOn 13 January, the Sunday before the Chinese SpringFestival, people in Shanghai were enjoying the last weekend ofthe lunar year. A week later, they would have a one-weekvacation to celebrate their most important holiday of the year.However, the call center of SOME Bank, a mid-sized bankin the city, was busier than ever. People were preparing theNew Year foods, clothes and gifts, and they needed help whenusing bank services. Miss Rosie, a young representative, hadjust finished the 20thcall of the morning, during which shesuccessfully taught a grandmother how to extract money froman automated teller machine (ATM). The busy lamp turned tored again, and Rosie pushed the connect button.“Hello! May I help you?” “I lost all my money!” Rosie tried to comfort the customer:“Don’t worry. We will look into it right now and see whathappened. Please believe me that your money will be safe.Now tell me what happened.”The customer, Mr. Rich, said that in checking his accountthrough Internet banking, he was astonished to find that theaccount balance had shrunk to several dollars, when, a weekago, the balance had been more than US $100,000. Rosie wrotedown all this information, as well as Mr. Rich’s contactinformation. She comforted the anxious man again, telling himthat everything would be fine. The InvestigationWithin 15 minutes, Mr. Rich’s case was escalated to Mr.Simpson, operations vice president of the bank. After a shortcall to the CEO, in which he briefly explained what hadhappened, he launched the contingency management process.Though it was still the weekend, he had to call together thehead of related functions, including IT, internal audit, Internetbanking, customer service, security and law. He explainedwhat had happened and set up a committee. Members of thegroup came from each of the functions. The responsibility of the group was to find out what happened and how, evaluate possible loss, take quick action, and minimize thenegative impact.All the members were included in a mail group to enableinstant communication during the investigation. Tasks wereassigned to each member as follows:• Internal audit—Investigate when, where and how the moneydisappeared, report possible loss, and work with police (ifinvolved) to find the perpetrator.• Information security—Conduct a health review of the Internetbanking system, find possible loopholes, and make a quick fix.• Customer service—Soothe the customer and minimize theinvolvement of the media. All service channels, including thecall center, were told to be extra vigilant and to send anysimilar cases directly to the group.• Public relations—Evaluate the necessity to report theincident to the police and regulatory body, and make properresponse to all parties involved.Two days later, the findings of the investigation team were finalized:• The computer records showed that the money was transferredto another account in the same bank two days earlier. Theodd thing was that the transaction code of the transfer was“Internet transfer between same holder’s accounts,” whichmeant that the transfer occurred between accounts registeredunder the same holder, while the actual account holders weredifferent people: Mr. Rich and Mr. Thief. Obviously, Mr.Thief’s information was falsified. It seemed that theperpetrator had bypassed the “same person’s accounts”verification control. • All transfers took place at midnight for US $10,000 per day(the daily maximum for Internet transfers). The first transferbegan with many failed attempts and ended with a successfulone. The following transfer succeeded easily with fewerattempts. A full search showed that the same thing happened tofour other customers, with a total loss of about US $1 million. • The day after the money transfer, the money was extractedfrom Mr. Thief’s account (as well as other destinate accounts)through ATMs throughout the city and at branch counters. Itappeared that was done because ATM extractions are limitedto US $5,000 per day, while counter service sets no limit.• Every branch was equipped with continuously running videocameras. The archived video recorded a young man takingthe money. However, because of the man’s intentionaldisguise (cap, glasses, wig) and quality of the video, it washard to tell his exact appearance.• By analyzing the web server’s access log, the auditor foundthat the attack came from several IP addresses. According tothe router table, these IPs belonged to a network café. Thefrequency of visits to a certain page was as high as thousandsof times per hour.I NFORMATION S YSTEMS C ONTROL J OURNAL, VOLUME 5, 2007The security officer who conducted a health review of theInternet banking system reported the following serious securityweakness: • Though the system locks the account after five successivewrong password attempts, it sets no limit for wrong accountnumber input. For example, one could enter a possiblepassword, such as 123456, to guess different accountnumbers, until a corresponding account was found. Thesystem could not identify and report this exception. • On the login page, no artificial verification code was used,which meant one could employ a robot (a specially designedprogram to perform functions automatically) to conductbrutal cracking. • Poor session management resulted in the same session IDbeing shared among all web pages during one’s connection.One could copy and reuse a previous ID before it expired tobypass the account verification and log in to the system. • The validation of “same holder’s accounts” did not take placeon the server end, but on the front end through an HTMLpage, making it easy to be compromised.• No process was in place to analyze and monitor transactions.The investigators could now determine how the break-inlikely happened: • Step 1—Someone connected to