In a windowless office on the eighth floor of a nondescript annex building, in a Bangladeshi city of 15 million people, sit four servers, four monitors, and a printer. According to reporting from Reuters, this room is called the SWIFT room, so named for its computers’ connections to the international payment messaging service. The four computers—along with 5,000 others in the building, which is home to the Bank of Bangladesh—are connected to the network via a couple of cheap, used routers, leftover from other work. These also connect to the bank’s real-time gross settlement system, which allows domestic and central banks to settle large transfers. The office is frequently unmonitored, and the network is unburdened by a firewall. All of it is connected to the open internet. Each day, messages sent using the computers are automatically printed. But when that printer suddenly stops producing an accounting of activities, on an otherwise ordinary weekend morning in February 2016, no one notices.
Timing is everything
It turns out that the four-day lapse before the fraud was uncovered was plenty of time for $81 million to be transferred from the Bangladesh Bank account at the New York Fed to Wells Fargo Mellon Bank, Citibank, and Bank of New York, to Rizal Commercial Banking Corporation’s Settlement Division, to bank accounts for a Chinese businessman at a local branch at RCBC, and then on to casinos in the Philippines, according to Bloomberg News.
The money moved on orders passed through the SWIFT network, the world’s largest electronic payment messaging system.
The bank heist has exploited vulnerabilities in international bank account monitoring, network and physical security, credentials, weekend protocols, and in some ways SWIFT itself. The incident, which is still being investigated, served as a reminder that trust still underpins the system and that many failsafes are not foolproof.
In fact, what happened in Bangladesh demonstrates the twin difficulties: how hard it is to prevent international money laundering, and how the global money movement system can be undone by its weakest link. One might say that the North Korean hackers were lucky, or exceptionally sophisticated. But with missteps by the authorities at every turn (and some, like that telltale typo, from the hackers), it was probably a bit of both.
Before North Korea’s involvement was suspected, it was easy to pin much of the blame on Bangladesh itself. The notion that insiders were involved circled the investigation, especially since the bank’s physical and technical safeguards have been found wanting. The country’s own finance minister has admitted Bangladesh has a problem with cybersecurity.
But even though the hackers’ identity has now come to light, it doesn’t diminish the role SWIFT played in the attack. Tracing how the money moved through the financial system suggests that SWIFT could be more vulnerable than anyone expected. After all, by the time Bangladesh Bank requested a hold on the $81 million on Monday, Feb. 8, when its systems were back in order, it was too late.
All this begs the question of what SWIFT is, and does, and demands. It’s easy to understate SWIFT’s role in international money transfer: After all, it’s basically just a messaging system. It doesn’t move money itself—but it tells banks where it needs to go. Hundreds of billions of dollars are moved internationally through the SWIFT system daily. Indeed, its power speaks to the how fragmented the world of money movement really is. SWIFT is a centralized, international messaging system that banks use to communicate important information securely—such as payment requests. It comprises a system of codes to standardize information across languages, an encrypted network across which those codes are passed, and software banks use to tap into the network. As an organization, SWIFT is a cooperative of financial institutions that runs the whole operation. While not all financial institutions participate in SWIFT, more than 11,000 do, including 193 central banks.
To protect the integrity of its communication system, the global SWIFT organization recommends certain security best practices, from the physical to the technical: a separate room dedicated to SWIFT equipment, which ought to be monitored at all times. Layered authentication protocols. Complex passwords. But it evidently doesn’t require them. And, as one security consultant pointed out in an interview with Reuters, it lacks regulatory firepower to do so.
So, as a spokesperson for the Bangladesh Bank told Reuters, a massive understatement if ever we’ve seen one, "There might have been a deficiency in the system in the SWIFT room.”
This made it ripe for exploitation. And finger-pointing.
“As a SWIFT user like any other, Bangladesh Bank is responsible for the security of its own systems interfacing with the SWIFT network and their related environment—starting with basic password protection practices—in much the same way as they are responsible for their other internal security considerations,” SWIFT wrote in a statement posted to its website May 9.
In its rebuttal, Bangladesh told reporters that the technicians who set up the environment were from SWIFT itself.
How it happened
If nothing else, the heist seems to have been an exercise in patience. And no wonder: The hackers were after nearly a billion dollars, $951 million. And all evidence points to the fact that North Korea was simply trying to steal money to make up for its hurting economy. $1 billion is about one-tenth of the country’s GDP.
In May 2015, the North Korean hackers opened four bank accounts at Rizal Bank in the Philippines. These lay dormant for more than six months. But when the accounts showed sudden depository activity in February, the bank didn’t seek to verify it. (Or, for that matter, notice that they’d been opened under fake names.) The lack of an investigation here is not necessarily unusual, but sudden bursts of activity are often triggers for compliance audits. And in hindsight, this oversight seems to be a major failure on the part of the depository institution.
The attack itself got underway almost half a year later, in January 2016. Partly due to the bank’s general lack of a firewall—and maybe with a hand from an insider—the hackers managed to breach the Central Bank of Bangladesh's servers. Conveniently for the hackers, because the Bank of Bangladesh secured its SWIFT servers no differently than it did the rest of the network, the hackers had access to those, too. It’s believed, according to an audit performed by security firm FireEye, that the hackers installed a keylogger, a tool so named because it logs keystrokes. In this case, the keystrokes were specific to the passwords needed to access the SWIFT network and authorize the transactions.
Then, they injected binary malware code into SWIFT’s client software, Alliance Access. Alliance is a messaging software, sold by SWIFT, that allows banks to connect to its messaging network and logs its activity. That particular software is used by 2,000 banks around the world; the other 11,000 connect to SWIFT through other means.
A unique, unusual string of numbers was used in the code at this and the other banks, as well as the Sony and South Korean attacks. Identifying this sequence helped investigators piece the puzzle together—but not before the large amounts of money were funneled out of the banks practically beneath everyone’s noses.
Representatives from SWIFT were quick to point out that the malware found in its software “can only be installed on users’ local systems by attackers that have successfully identified and exploited weaknesses in their local security.”
Sure. But that doesn’t address the fact that the malware exploited Alliance itself.
“The tool was custom made for this job, and shows a significant level of knowledge of SWIFT Alliance Access software,” researchers from independent security firm BAE, which has been studying the breach and found malware that resembles what was used in Bangladesh, wrote in a blog post. (In April, SWIFT released a software update to thwart the malware.)
The malware could trick the Alliance software into recording a failed check as successful—making it possible to confirm fraudulent transfers. The malware also manipulated account balances on logs.
And, to put a bow on the whole thing, it also manipulated the aforementioned printer that would ordinarily produce records of transfer requests in Bangladesh, effectively jamming it.
It’s not exactly clear how, but the hackers were able to use the central bank’s actual codes to initiate the transfers through SWIFT. On Feb. 4, the bank sent nearly three dozen requests for the Federal Reserve Bank of New York to move almost a billion dollars from the Bangladesh Bank’s account there to private accounts in the Philippines and Sri Lanka.
(To clarify a bit: The New York Fed holds the accounts of 250 foreign central banks and governments, including the Central Bank of Bangladesh’s. So the heist pilfered from the Bangladesh government’s own account, which has $28 billion in currency reserves.)
A few hours after the orders came through to the New York Fed, the Fed flagged them as suspicious but authorized them. Officials reached out to the Bank of Bangladesh in an effort to confirm the requests, but when their foreign counterparts didn’t answer, the Fed let five of them clear as usual. Then came the weekend.
Meanwhile, the Bank of Bangladesh had no idea anything was awry. The bank’s engineers didn’t rush to fix the printers, thinking it was a routine glitch. Annoying, but not all that important—and certainly not a signal of more sinister activities.
Zubair Bin Huda, a director at the Bangladesh Bank, noticed that the printed confirmations were missing when he checked the morning of Feb. 5, according to a report from Bloomberg News. He then tried to print the messages manually—but that didn’t work either.
“Since such glitches happened before, we thought it was a common problem just like any other day," Huda reportedly wrote in a police complaint.
And anyway, it was a Friday, which counts as a weekend in Bangladesh.
So the printers weren’t repaired until Feb. 6. That’s when they observed that the software on the terminal connecting to the SWIFT system wasn’t working normally, either. When they got their system up and running, they frantically tried to contact the New York Fed by email, fax, and phone to ask that the transactions be suspended. But those messages didn’t get through: It was the weekend in the United States, which meant that the bank was closed.
In April, as more details about the heist began to emerge, SWIFT gave a statement in an apparent effort to absolve it of culpability:
SWIFT is aware of a malware that aims to reduce financial institutions’ abilities to evidence fraudulent transactions on their local systems. This malware has no impact on SWIFT’s network or core messaging services.
But that wasn’t really the point. If fraud can’t be detected, it almost begs the question of what's even the point of having a so-called “secure” international money transfer system.
On its website, SWIFT doesn’t give much insight into recommended security practices. “Given the volume of messages, a manual review of every payment order may not be feasible or effective. However, intermediary banks should have, as part of their monitoring processes, a risk-based method to identify incomplete fields or fields with meaningless data. U.S. banks engaged in processing cover payments should have policies to address such circumstances, including those that involve systems other than SWIFT.”
The New York Fed did see signs of unusual activity after the four transfer requests went through. After all, the unusually high number of payment instructions and the transfer requests to private entities, rather than other banks, made the Fed suspicious. While most of the 35 transfer orders were stopped, the Fed’s fraud detection systems didn’t stop several of the transactions before they went through.
Four SWIFT requests, totaling $81 million, had been sent to Rizal Bank. Those all went through.
The fifth request was cleared by the Fed, too. But it had been sent via SWIFT to Pan Asia Banking to transfer $20 million to a Sri Lankan non-profit organization, Shalika Foundation.
Because the payment was so big, Pan Asia contacted its routing counterpart, Deutsche Bank.
“The transaction was too large for a country like us,” a Pan Asia representative told Reuters. “Then [Deutsche] came back and said it was a suspect transaction.”
That’s because the request spelled the recipient’s name as Shalika Fandation, which reportedly raised red flags at Deutsche. Though the payment had been cleared by the Fed, the typo was caught in time to freeze the funds, which were returned to Bangladesh Bank’s account in New York via Deutsche Bank on Feb. 17.
And sure, the misspelling was bad enough. But there also isn’t an NGO under the name of Shalika Foundation in the list of registered Sri Lankan non-profits—signaling that compliance checks may not be lengthy.
Deutsche Bank’s win came on the heels of some high-profile failures. In June 2015, it was hit by a scandal over suspected money laundering at its Moscow office. It also settled with U.S. authorities over alleged sanctions-related violations, allegedly for moving funds through the U.S. financial system for countries such as Iran and Sudan.
It responded with plans to invest more in technology to prevent money laundering.
“You are looking for a needle in a haystack,” Werner Steinmueller, head of Deutsche Bank's Global Transaction Banking business, acknowledged in an interview with Reuters.
When Bangladesh Bank discovered that its funds were being siphoned, it grew panicked.
On Feb. 9, it sent more than 100 messages to RCBC’s Settlements Department. But RCBC had nearly 800 other SWIFT messages in its queue.
“They did not send us any high priority requests. They did not send us any stop payment order. They just sent us an unauthenticated free format message,” Maria Celia Estavillo, RCBC head of legal and regulatory affairs, told a Senate blue ribbon committee, according to The Manila Times.
Questions have naturally been raised about the security standards in developing countries.
But SWIFT effectively connects more than 11,000 institutions, and the situation in Bangladesh sucked in institutions as supposedly secure as the New York Fed, which failed to detect irregular activity over the weekend. It suggests that SWIFT security is only as strong as its weakest link.
As institutions grapple with liability and responsibility, it’s not certain what steps will be taken to make the system more efficient or secure. But it is clear that changes must be made.
At first, it might have been easy to dismiss the the heist as an isolated—if spectacular—one-off. That’s a harder argument to make now, especially since it has been linked to so many of North Korea’s other high-profile breaches. The fate that has befallen SWIFT is looking more and more systemic.
Not long after the Bangladesh breach, as officials, investigators, and reporters worked to understand just what went wrong, two more breaches that occurred before Bangladesh have also made headlines—and those are just the ones to find their way into print.
It turns out that nearly a year earlier, a series of SWIFT messages from Ecuador’s Banco del Austro instructed Wells Fargo to transfer money to bank accounts in Hong Kong. In all, Wells Fargo transferred $12 million of BDA's money. This breach has not yet been linked to North Korea.
In Vietnam, Tien Phong Bank reported that it, too, had seen—but thwarted—a cyber attack that used that same strange sequence of numbers as the Bangladesh attack. . It appears that hackers installed malware on a software application used by a third-party vendor whose servers are based overseas. But the approach had a twist: Instead of targeting the printer, as they had in Bangladesh, the hackers manipulated a PDF reader typically used to confirm payments.
Unlike the Bank of Bangladesh, which was maligned for its rural infrastructure and outdated security system, TPBank was established in 2008 and is viewed as a tech-savvy institution.
SWIFT has been quick to point out that its system wasn’t actually directly compromised in any of the attacks—but that’s sort of beside the point. The network is no less vulnerable whether the attacks target its core system or the connections to it.
SWIFT is taking steps to stem the threats: Last week, according to The Wall Street Journal, the cooperative announced it would implement third-party audits for how customers should protect their systems and software.