Sold a Lemon in Internet Banking – Krebs on Security

An online bank robbery in which computer crooks stole $63,000 from a Kansas car dealership illustrates the deftness with which cyber thieves are flouting the meager security measures protecting commercial accounts at many banks.

At 7:45 a..m. Monday, Nov. 1, 2010, the controller for Abilene, Kansas based Green Ford Sales, Inc. logged into his account at First Bank Kansas to check the company’s accounts. Seven hours later, he logged back in and submitted a payroll batch for company employees totaling $51,970. The bank’s authentication system sent him an e-mail to confirm the batch details, and the controller approved it.

The controller didn’t know it at the time, but thieves had already compromised his Microsoft Windows PC with a copy of the ZeuS trojan, which allowed them to monitor his computer and log in to the company’s bank account using his machine. Less than an hour after the bookkeeper approved the payroll batch, bank records show, the thieves logged in to Green Ford’s account from the same Internet address normally used by the dealership, using the controller’s correct user name and password.

The attackers cased the joint a bit — checking the transaction history, account summary and balance — and then logged out. They waited until 1:04 p.m. the next day to begin creating their own $63,000 payroll batch, by adding nine new “employees” to the company’s books. The employees added were in fact money mules, willing or unwitting individuals recruited through work-at-home job scams to help crooks launder stolen funds.

Green Ford’s controller never received the confirmation email sent by the bank to verify the second payroll batch initiated by the fraudsters, because the crooks also had control over the controller’s e-mail account.

“They went through and deleted it,” said Green Ford owner Lease Duckwall. “If they had control over his machine, they’d have certainly had control over his email and the password for that, too.”

To me, this attack gets to the heart of why these e-banking thefts continue unabated at banks all over the country every week: An attacker who has compromised an account holder’s PC can control every aspect of what the victim sees or does not see, because that bad guy can then intercept, delete, modify or re-route all communications to and from the infected PC. If a bank’s system of authenticating a transaction depends solely on the customer’s PC being infection-free, then that system is trivially vulnerable to compromise in the face of today’s more stealthy banking trojans.

It is difficult to believe that there are still banks that are using nothing more than passwords for online authentication on commercial accounts. Then again, some of the techniques being folded into today’s banking trojans can defeat many of the most advanced client-side authentication mechanisms in use today.

Banks often complain that commercial account takeover victims might have spotted thefts had the customer merely reconciled its accounts at day’s end. But several new malware strains allow attackers to manipulate the balance displayed when the victim logs in to his or her account.

Perhaps the most elegant fraud techniques being built into trojans involve an approach known as “session riding,” where the fraudster in control of a victim PC simply waits until the user logs in, and then silently hijacks that session to move money out of the account.

Amit Klein, chief technology officer at Trusteer, blogged this week about a relatively new strain of malware dubbed OddJob, which hijacks customers’ online banking sessions in real time using their session ID tokens. According to Klein, OddJob keeps online banking sessions open after customers think they have “logged off,” enabling criminals to extract money and commit fraud unnoticed.

All of these developments illustrate the need for some kind of mechanism on the bank’s end for detecting fraudulent transactions, such as building profiles of what constitutes normal customer activity and looking for activity that appears to deviate from that profile. For example, in almost every case I’ve written about, the victim was robbed after thieves logged in and added multiple new names to the payroll. There are most certainly other such markers that are common to victims of commercial account fraud, and banks should be looking out for them. Unfortunately, far too many small to mid-sized banks outsource much of their visibility at the transaction level to third-party service providers, most of whom have been extremely slow to develop and implement solutions that would enable partner banks to flag many warning signs of account takeovers.

FOLLOWING THE MONEY

Duckwall praises his bank for moving quickly to contact the mules’ banks after being alerted by the company’s controller at 8 a.m. on Nov. 3. But he said the recovery effort was slowed considerably by the responses from many of the mules’ banks.

“The really frustrating thing was we got on phone with our bank and they immediately contacted all of the other banks, and most of them in turn fax or email you a form that you have to fill out, sign and send back,” Duckwall said. “It’s just really frustrating how long it takes to try to stop something that like that. It was kind of a large disruption in our operation.”

Duckwall reached out to one of the mules, a man named Shawn Young from New York, who received nearly $5,000 of Green Ford’s money. Young hadn’t yet wired the money overseas as instructed by his recruiters, a bogus entity calling itself “R.E. Company” (its Web site is still up at this link). Young said he communicated with the mule recruiters at R.E. Company by logging in to his account at this Web site, uploading his personal and bank account information, and awaiting instructions. Those instructions would later arrive on Nov. 3 (see screen shot below left).

Duckwall said First Bank Kansas managed to recover all but $22,000 of the stolen funds, and that the company and bank have made several security adjustments since the incident.

“Two confirming e-mails are sent…one to me, and one to [the controller]. Our ACH limit for our account is kept at $0 all the time except for pay days,” Duckwall explained in an email. “Then the bank president raises the limit. On paydays, the limit is raised, [the controller] logs in and creates the ACH batch file, and [he] contacts me.  I log in, review the file, and authorize it.  I use a machine from home for that. Then I notify the bank president, who lowers our limit back to $0. Every time the controller and I log in we request a email passcode (no cookies set on our machines).  I receive all of the confirming emails that are generated by the system, on four different machines.”

From where I sit, that’s a ridiculous number of hoops to have to jump through to make a payroll every other week. Also, those changes don’t address the root of the problem: They still succeed or fail based on an insecure mode of communication (email) that can be hijacked on the customer’s end. What’s more, these changes continue to push all of the security and authentication of the transaction out to the customer, which is always the weakest link.