Don’t let Trojans infiltrate customer cash management

Late on a Friday afternoon, the day after Christmas, a large commercial bank received a file of ACH credits from one of its commercial customers, submitted through the bank’s electronic banking system. The file totaled over $400,000.

Then, the following Monday afternoon, a second file of ACH credits for almost $300,000 was received by the bank from the same commercial customer.

The originator of the transactions had used the proper identification and password information, and both transactions were validated according to procedures established by the bank, and, apparently, agreed upon with the customer.

In this case, the bank, in addition to authenticating the user ID and password, used a sophisticated scoring model to validate the transactions. Both scored as valid, even though they were originated on days of the week that were different than such transactions were typically received from this customer; came from a different originating computer address; and were for amounts in total and individually.

It wasn’t until late Tuesday afternoon that someone became aware that something was amiss. A gentleman from California called the bank’s customer to ask why he had been sent $22,000. By the time the customer notified the bank on Wednesday morning of the odd call, and the bank investigated the issue, only a small portion of the stolen funds could be recovered.

Of course, the customer felt the bank should reimburse it for the loss. The bank, with justification, noted that it had received the transactions from someone who logged on with the proper user ID and password, and that the transaction was further validated using a procedure agreed upon by the customer.

The bank refused to pay, and the customer sued. Extensive investigations by both parties determined that both bank and customer were somewhat to blame for the loss, and ultimately, the parties settled. By then, the bank had spent more than the settlement amount on attorneys and investigators. And its reputation was damaged from the negative press resulting from the lawsuit.

How did it happen?

Such frauds start at the customer level, with computer systems being attacked and compromised.

“Cybercriminals are moving away somewhat from direct attacks on bank networks unless they discover blatant security ‘holes’ or attack vectors [that] are not secured,” says Todd Stringer, Abound Resources director of IT security. “Instead, they are exploiting weaknesses in security of the bank’s customers.”

In the case of these frauds, a customer’s computers may be compromised in several ways. The employee may have visited a legitimate website that is secretly hosting the malware; a site designed to host the malware; or a legitimate site hosting the malware in an advertisement.

In many cases, the computer user opens what appears to be a legitimate email and clicks on a link that connects him to the site hosting the malware, typically a Trojan (short for “Trojan Horse”). The Trojan is downloaded to the customer’s computer and begins logging keystrokes, and recording passwords and IDs. It also may generate challenge-response questions (“What city were you born in,” etc.) when the customer visits various websites. (Zeus Trojans are known for targeting banking information.)

The Trojan will transfer the user’s log-in ID, password, date of birth, and other security information to the cyber thieves, who use it to fraudulently access the bank’s systems. The Trojan may also alert the cyber thieves when the custoer is logged onto the bank’s cash management system. The criminals then hijack the session and submit fraudulent payment information to the bank.

The Trojan may check the account balance, and if it is over a certain amount, it will determine how much to steal within a limit so as not to trigger automatic fraud-detection alarms. The money is transferred to bank accounts of so-called “money mules,” which are typically people who have been recruited by criminals or innocent parties who have had their own bank accounts compromised by the criminals. From there, the money is then transferred to accounts in other countries that are controlled by the cyberthieves.

The fraud described at the beginning of the article was by no means an isolated event.

Since it first appeared in 2007, the Zeus Trojan and variants have caused millions in losses to banks and their business customers. Recently, a variation of the attack has been used to exploit business customers’ email. A community bank suffered a loss of almost $500,000, because it executed wire transfers based on email instructions received from a customer (supposedly) that turned out to be fraudulent. The emails appeared genuine to the bank, since the criminals had compromised the customer’s email account. They were addressed to the bank employee who typically managed transactions with the customer, addressed the employee by name, and included other personal information.

Protecting bank and customer

Many banks employ sophisticated third-party services to protect against these types of attacks. These include cloud-based secure sites; encrypted transmissions passwords; biometric devices (like thumbprint and retina scanners attached to customer computers); and USB “keys” that must be inserted into the computer at the time the transaction is originated, and which incorporate tests and one-time passwords.

Use these security procedures where appropriate. As regulators and security experts agree, the strongest security systems include something the user “has” (a key), something “they are” (biometrics), and something “they know” (passwords and IDs, recognition of preselected pictures and icons).

However, no level of technology can totally eliminate the human element from the security process. As described earlier, the bank used a sophisticated scoring model to authenticate electronic transactions. Unfortunately, it set the score too high for considering a transaction suspect, and did not include vital criteria in the scoring model.

How to beat the Trojans

“Sometimes, the old ways are the best,” says a character in the recent movie Skyfall to James Bond. With that in mind, here are a few steps to take.

1. Contracts. A contract is essential between the bank and its customers who use cash-management services—including those who only send wire transfers and may not use the cash-management system to transmit the wire instructions to the bank. All too often, banks have no customer agreements documenting the procedures for transmitting, receiving, and authenticating wire-transfer instructions. Or, at best, they have poorly worded ACH agreements.

In 1994, Section 4a was added to the Uniform Commercial Code, specifically revised to address the transmittal and authentication of electronic-payment orders, such as wire transfers and ACH files. The significance of this: If a bank provides customers a “commercially reasonable security procedure” for authenticating these orders, the customer agrees in writing with the procedure, and the bank follows the procedure, then the bank is insulated against loss—even if a fraudulent payment order is transmitted to and acted on by the bank.

“Commercial reasonableness” of a security procedure is generally determined by considering the circumstances of the customer known to the bank, such as the size, type, and frequency of payment orders normally issued by the customer; alternative security procedures offered to the customer; and security procedures in general use by customers and receiving banks processing similar transactions.

A security procedure also can be considered commercially reasonable if: It was chosen by the customer after the bank offered, and the customer refused, a security procedure considered commercially reasonable for that customer; and the customer expressly agrees, in writing, to be bound by any payment order issued in its name and accepted by the bank following that security procedure, whether or not it was properly authorized.

Shortcut security and authentication procedures—like recognizing a customer’s voice on the phone or comparing a faxed signature to one on file—are not commercially reasonable. Worse yet, many banks don’t document the procedures in a contract signed by the customer.

2. Customer awareness and controls. Make the customer aware of these threats and the types of security procedures they should consider. These include simple, common practices like not sharing passwords; requiring passwords to be changed frequently; restricting use of the computer used to access the bank’s cash-management system to only that purpose; and restricting the ability to access email and other websites on that computer.

Provide customers the capability for dual entry of these transactions so that two people are required to execute each transaction. One customer employee would enter the transaction using her user ID and password, and then a second employee should verify it and release the transaction.

Other practical controls include:

• Setting limits on how much money can be transferred out of the account in a given day.

• Restricting employees who can add new payees to the system, change payment amounts, and transfer checking account balances.

• Scheduling payments at the end of every workday, instead of the following morning.

Since Microsoft’s Internet Explorer has been the target of many of these attacks, encourage customers to consider using a different internet browser or access the bank’s system from software operating at one of the cloud-based secure sites.

3. “Out of band” authentication. Even if automated security procedures are used, they can still break down or be compromised. At least for larger transactions, banks should use an “out of band” authentication procedure. That is, if a payment instruction is received, and even authenticated through the cash-management system, an alternative method or channel should be used to authenticate the instruction.

For example, require customers to transmit information regarding the payments to the bank in advance by phone, fax, or text message, or confirm them after they are transmitted by the same methods. It would be better if the bank originated these authentication procedures—for example, calling the customer back using a predetermined phone number to confirm instructions before they are executed.

4. Positive pay. Provide customers with positive-pay systems, so that they can see information regarding pending payments, such as incoming debits, outgoing payments, and checks to be paid—and can specifically authorize payment by the bank.

5. Test security and controls. Encourage bank customers to have someone periodically scan their systems. They should test their security controls, make sure their virus and malware-protection software is up-to-date, and make sure their internet browser’s security patches are up-to-date. The bank could offer to provide these services, but the concern is that doing so would increase the bank’s liability if the customer does ultimately have a problem.

6. Insurance. In the almost inevitable event that something does go wrong, make sure that the bank has sufficient as well as appropriate cybercrime insurance.

“Most bankers today are somewhat in the dark about how their mixture of cyberfraud and privacy-related risks are covered or not covered in their insurance and fidelity-bond programs,” says Roger Haynes, executive vice-president and practice leader at William Gallagher Associates Financial Risks. He recommends that each bank review its coverage in detail, paying particular attention to the gaps where no coverage applies or especially where the limits of coverage are inadequate.

Haynes continues: “Today’s legal- and regulatory-notification requirements after a breach are very rigorous and expensive to fulfill. Generally, the standard sub-limited coverage available today to respond to the expenses of these notifications is woefully inadequate.” Costs go beyond what you might expect, and include paying a forensic accountant to identify the scope of the breach.