Technological Thoughts by Jerome Kehrli

The Bangladesh bank heist - or SWIFT attack - is one of the biggest bank robberies ever, and the most impressive cyber-crime in history.

This is the story of a group of less than 20 cyber-criminals, composed by high profile hackers, engineers, financial experts and banking experts who gathered together to hack the worldwide financial system, by attacking an account of the central bank of Bangladesh, a lower middle income nation and one of the world's most densely populated countries, and steal around 81 million US dollars, successfully, after attempting to steal almost a billion US dollars.

In early February 2016, authorities of Bangladesh Bank were informed that about 81 million USD was illegally taken out of its account with the Federal Reserve Bank of New York using an inter-bank messaging system known as SWIFT. The money was moved via SWIFT transfer requests, ending up in bank accounts in the Philippines and laundered in the Philippines' casinos during the chinese New-Year holidays.

Fortunately, the major part of the billion US dollars they intended to steal could be saved, but 81 million US dollars were successfully stolen and are gone for good.

The thieves have stolen this money without any gun, without breaking physically in the bank, without any form of physical violence. (There are victims though, there are always victims in such case, but they haven't suffered any form of physical violence)
These 81 million US dollars disappeared and haven't been recovered yet. The thieves are unknown, untroubled and safe.

The Bangladesh bank heist consisted in hacking the Bangladesh central bank information system to issue fraudulent SWIFT orders to withdraw money from the banking institution. SWIFT is a trusted and closed network that bank use to communicate between themselves around the world. SWIFT is owned by the major banking institutions.

In terms of technological and technical mastery, business understanding, financial systems knowledge and timing, this heist was a perfect crime. The execution was brilliant, way beyond any Hollywood scenario. And the bank was actually pretty lucky that that the hackers didn't successfully loot the billion US dollars as they planned, but instead only 81 million.
As such, from a purely engineering perspective, studying this case is very exiting. First, I cannot help but admire the skills of the team of thieves team as well as the shape of the attack, and second, it's my job in my current company to design controls and systems preventing such attack from happening against our customers in the future.

In this article, I intend to present, explain and decipher as many of the aspects of the Bangladesh bank heist and I know.

(This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/deciphering-the-bengladesh-bank-heist)

Summary

• 1. Introduction
• 2. The SWIFT network - Key Concepts
  • 2.1 Correspondant Banking
  • 2.2 Transfering Money
  • 2.3 Application Architecture (Bengladesh case)
  • 2.4 Introducing key SWIFT messages
• 3. The attack
  • 3.1 Behaviour of the malware
  • 3.2 Complete overview of the attack
  • 3.3 Timeline of the attack
  • 3.4 Laundering of the money
• 4. Aftermath
• 5. Conclusion

1. Introduction

The Bangladesh Bank hack is one of the biggest bank heists in global financial history. There have been larger scams and scandals, but cyber heists from a single bank, this takes the cake.

The heist of over 80 million US dollars sent shock-waves through the global financial system and security experts scrambled to find out how it had happened. Political and administrative authorities played the blame game, as was expected of them. Resignations were offered and statements were issued. It was a complete chaos.

The hackers managed to break into the bank's security system and transferred more than 80 million USD from the New York Federal Reserve account to multiple bank accounts located in Sri Lanka and Philippines.
A significant number of transfer requests, 30 out of 35, were blocked by the Federal Reserve, saving the bank a loss of an additional 850 million US dollars
But the five requests that managed to pass through, amounting to more than a 80 million US dollars, were devastating enough in their consequences.

Perhaps the most troubling aspect of the whole episode was that the hackers managed to hack into the SWIFT software. SWIFT, lies at the heart of the global financial system and is a network which connects majority of the world's financial institutions and enables them to send and receive financial information about financial transactions.

However, It was the bank's own systems and controls that were compromised, not the SWIFT network connection software. The SWIFT software behaved as it was intended to, but was not operated by the intended person or process. This was really a bank problem, not a SWIFT problem.

In the next chapter, I will present the key concepts required to understand the attack before presenting the shape and timeline of the attack.

2. The SWIFT network - Key Concepts

Some key concepts about correspondent banking and the principles of the SWIFT network are required to grasp a basic understanding of the Bangladesh SWIFT attack. These are presented in this chapter.

SWIFT - Society for Worldwide Inter-bank Financial Telecommunication - is a belgian company, located in Belgium, and is a trusted and closed network used for communication between banks around the world. It is overseen by a committee composed of the US Federal Reserve, the Bank of England, the European Central Bank, the Bank of Japan and other major banks.
SWIFT is used by around 11 thousands institutions in more than 200 countries and supports around 25 million communications a day, most of them being money transfer transactions, the rest are various other types of messages.

The majority of international inter-bank messages use the SWIFT network.
SWIFT does not facilitate funds transfer: rather, it sends payment orders, which must be settled by correspondent accounts that the institutions have with each other. For two financial institutions to exchange banking transactions, they must have a banking relationship beforehand.

A cool introduction to SWIFT is available on the Fin website : https://fin.plaid.com/articles/what-is-swift.

2.1 Correspondent Banking

Correspondent Bank

A correspondent bank is a financial institution that provides services on behalf of another financial institution.
It can facilitate wire transfers, conduct business transactions, accept deposits and gather documents on behalf of another financial institution.
Correspondent banks are most likely to be used by domestic banks to service transactions that either originate or are completed in foreign countries, acting as a domestic bank's agent abroad.

Generally speaking, the reasons domestic banks employ correspondent banks include:

• limited access to foreign financial markets and the inability to service client accounts without opening branches abroad,
• act as intermediaries between banks in different countries or as an agent to process local transactions for customers abroad,
• accept deposits, process documentation and serve as transfer agents for funds.

The ability to execute these services relieves domestic banks of the need to establish a physical presence in foreign countries.

NOSTRO / VOSTRO Account

The accounts held between correspondent banks and the banks to which they are providing services are referred to as NOSTRO and VOSTRO accounts (latin words for ours and yours).
An account held by one bank for another is referred to by the holding bank as a VOSTRON account.
The same account is referred as a NOSTRO account by the owning bank (the customer). Generally speaking, both banks in a correspondent relationship hold accounts for one another for the purpose of tracking debits and credits between the parties.

NOSTRO and VOSTRO accounts are really to the same thing but from different perspectives. For example, Bank X has an account with Bank Y in Bank Y's home currency. To Bank X, that is a NOSTRO, meaning "our account on your books," while to Bank Y, it is a VOSTRO, meaning "your account on our books." These accounts are used to facilitate international transactions

Transferring Money Using a Correspondent Bank

International wire transfers often occur between banks that do not have an established financial relationship. When agreements are not in place between the bank sending a wire and the one receiving it, a correspondent bank must act as an intermediary. For example, a bank in Geneva that has received instructions to wire funds to a bank in Japan cannot wire funds directly without a working relationship with the receiving bank.

Most if not all international wire transfers are executed through SWIFT. Knowing there is not a working relationship with the destination bank, the originating bank can search the SWIFT network for a correspondent bank that has arrangements with both banks.

Interestingly, when a bank wants to send some funds to another bank on the other side of the world, it happens often that the sending bank has no banking relationships with any bank having itself a relationship with the target bank. In this case, the order needs to be transferred through several, sometimes many, distinct banking institutions through the SWIFT network.
These intermediate banks are called routing banks.

2.2 Transferring Money

In the scope of funds transfers, correspondent banking relationships often happen between commercial banks and central banks. This is especially useful when a bank has to process massive funds transfers in different currencies.

Imagine that a non-US commercial banking institution has to transfer a massive amount of US Dollars for one of its big customers to some other account in another financial institution abroad. It would be very inconvenient in this case to have to build up enough reserves of US dollars for this kind of transfers.
Instead of building such reserves, big commercial banks worldwide have the tendency to open a correspondent banking relationships with the US federal Reserve in New York - called the Fed - and use their VOSTRO accounts at the Fed to process such big transfers.
Such VOSTRO accounts have typically no limits and do not necessarily need to be credited beforehand. The settlement can happen afterwards, on a regular basis.

Let's illustrate this situation with 2 imaginary customers and the Bangladesh central bank:

In case the money transfer requested by a customer in a foreign currency (here USD for the Bangladesh bank) exceeds some limits or even the reserves of the Bangladesh bank in USDs, the bank decides to go through the VOSTRO account by the correspondent central bank related to the foreign currency (Here the US Fed for USD) and instruct it to proceed with the transfer.
Again, that VOSTRO account doesn't even necessarily need to be credited beforehand, the settlement can happen way later or even never.

2.3 Application Architecture (Bangladesh case)

SWIFT provides a centralized store-and-forward mechanism, with some transaction management. For bank A to send a message to bank B with a copy or authorization with institution C, it formats the message according to standard and securely sends it to SWIFT. SWIFT guarantees its secure and reliable delivery to B after the appropriate action by C. SWIFT guarantees are based primarily on high redundancy of hardware, software, and people.

Principles

SWIFT moved to its current IP network infrastructure, known as SWIFTNet, from 2001 to 2005, providing a total replacement of the previous X.25 infrastructure. During 2007 and 2008, the entire SWIFT Network migrated its infrastructure to a new protocol called SWIFTNet Phase 2.
Today the SWIFT network can be seen as a highly secured private network over Internet.

In order to have access to this network, a financial institution needs to obtain a SWIFT gateway running the SWIFT NetLink software. This is most of the time proprietary hardware running with Linux and requiring a physical security dongle storing cryptographic keys to access the network.

SWIFT also provides a whole lot of other software such as SWIFT Alliance Access that can be used by a financial institution to access the SWIFT network (always through the gateway) in a more convenient way and with higher level or simpler APIs.

SWIFT Network Security

SWIFT's security stems from two major sources. First, it's a private network, and most banks set up their accounts such that only certain transactions between particular parties are permitted. The network privacy means that it should be hard for someone outside a bank to attack the network, but if a hacker breaks into a bank-as was the case here-then that protection evaporates.
The Bangladesh central bank has all the necessary SWIFT software and authorized access to the SWIFT network. Any hacker running code within the Bangladesh bank also has access to the software and network.

The Bangladesh bank architecture

The Bangladesh central bank, at the time of the heist, was handling SWIFT connectivity from the Banking Information System to the SWIFT network using the specific SWIFT Alliance Access software running on a bridge server.
Alliance Access, integrated the way it was at the Bangladesh banks, was setup to read/write SWIFT messages from/to files on the filesystem and record transaction information in an Oracle database. In addition, confirmation and reconciliation messages were handled through a manual process after being sent to a printer.

Again, the order reconciliation process in the Bangladesh central bank was a largely manual process.
In addition, passing through the filesystem to integrate the Banking Information System and the SWIFT network is a huge security weakness. We'll discuss this later.

2.4 Introducing key SWIFT messages

As we will see in the next chapter, the hackers created a malware that generated and manipulated key SWIFT messages to withdraw the money from the Bangladesh Central Bank's VOSTRO account at the Fed.

SWIFT messages consist of five blocks of the data including three headers, message content, and a trailer. Message types are crucial to identifying content.
All SWIFT messages include the literal "MT" (Message Type). This is followed by a three-digit number that denotes the message category, group and type

The key SWIFT messages in question here were of the following types:

• MT103 is used for cash transfer specifically for cross border/international wire transfer.
• MT202 is the general Financial Institution transfer order, used to order the movement of funds to the beneficiary institution.
• MT950 is the Final Statement report on all settlement operations with specified account within a current business day. Can be seen as the confirmation for an MT 202.

The workflow between these messages can be seen as follows:

A lot of stuff goes through SWIFT, here we focus on a really small subset of the supported message tapes, those related to transferring money.
First, the MT103 is an information message, basically announcing that a target counterparty account will receive money from an internal (or correspondent) account to be debited.
Then the MT202 is the inter-bank transfer order, it applies globally to transfer money from a banking institution to another banking institution, covering all individual account level transfer announces relating to the same target institution. There is a relationship between MT103 and MT202, they cross-reference each others (field 21 in MT103 reference MT202 and field 20 in MT202 references all related MT103)
Finally the MT950 is the extract that confirms all executed order. It is the bible and references all positions confirmed and executed by the correspondent bank. It is often an end of day extract used by banking institutions for reconciliations.

Again, when it comes to SWIFT messages processing from and to the Banking information System in the Bangladesh case, the important aspects here are:

• SWIFT messages originating from the Banking Information System simply needed to be put on the filesystem somewhere to be "slurped" by the SWIFT Alliance Access software integrated the way is was integrated at Bangladesh Central Bank. In terms of security of the process, this is more that questionable.
• Confirmation messages back from the SWIFT network were stored and printed. Reconciliation is a manual process from these printed messages. This is quite unusual (we'll get back to that)

3. The Attack

Summary of the attack

Capitalizing on weaknesses in the security of the Bangladesh Central Bank, hackers attempted to steal around a billion US dollars from the Bangladesh central bank's VOSTRO account with the US Federal Reserve Bank between February 4 and 5 when Bangladesh Bank's offices were closed.

The perpetrators managed to compromise Bangladesh Bank's computer network, observed how transfers were done, and gained access to the bank's credentials for payment transfers.
They used these credentials to authorize about three dozen requests to the Federal Reserve Bank of New York to transfer funds from the Bangladesh Bank VOSTRO to accounts in Sri Lanka and the Philippines.

Thirty transactions worth 851 million USD were flagged by the banking system for staff review, but five requests were granted; 20 million USD to Sri Lanka (later recovered), and 81 million USD lost to the Philippines, entering the Southeast Asian country's banking system on February 5, 2016.
This money was laundered through casinos and a little later transferred to Hong Kong.

The attack is impressive and stands out on various levels, in terms of technical means, maturity and complexity for several reasons:

1. Technical Mastery: the usage of a custom worm (filename evtdiag.exe) to hack the SWIFT Bridge by the bank and likely other malwares to capture the administration credentials
2. In-depth understanding of the worldwide financial market: both the attack shape and the money laundering scheme prove in-depth understanding of financial markets
3. SWIFT knowledge: in-depth Knowledge of the SWIFT messaging details is not that much spread among software engineers

Let's see how this is proven by analyzing the details of the attack.

3.1 Behaviour of the malware

The hackers used a custom version of malware to hack software called SWIFT Alliance Access to both make the transactions and hide the evidence. The hackers used a version of the malware that removed integrity checks within the Alliance software and then monitored the transaction files sent through the system, searching the payment orders and confirmations for specific terms. These terms and the responses to them were specified by a Command and Control server in Egypt.

When a message with one of the search terms was found, the malware would do different things depending on the kind of message. Payment orders were modified to increase the amounts being moved, updating the Alliance database with new values. Confirmation messages from the SWIFT network were also modified. Confirmations are printed and stored in the database. Before being printed, the malware would alter the confirmations to show the original, correct transaction value; it also deleted confirmations from the Alliance database entirely.

It's still not clear how the initial transactions were entered into the system to trigger the malware in the first place.

Again, the SWIFT network key components haven't been compromised, the malware was targeting the Bangladesh Central Bank's own bride to the SWIFT infrastructure running the SWIFT Alliance Access Software:

If an organization can't keep its endpoint secure, it leaves itself very vulnerable to being electronically robbed. That was the case here.
The bank lacked any firewalls and was using second-hand $10 switches on its network. These switches did not allow for the regular LAN to be segmented or otherwise isolated from the SWIFT systems. The lack of network security infrastructure has hindered the investigation.
It's still not known how the hackers penetrated the network, but it looks like the bank didn't make it difficult for them to do so.

How the attackers obtained administration credentials is still unclear. They might have obtained these credentials by using another malware or by exploiting a remotely available vulnerability (not impossible considering the weak security practices in place in the Bangladesh Central Bank) or it might also have been an insider job.
So far there are only speculations in this regards.

Forging fraudulent SWIFT messages

Simplifying a bit the reality, we can picture the malware as forging fraudulent SWIFT messages as follows:

The view above is a simplification of the reality. Actually, the worm was brilliantly implemented since forging from scratch consistent SWIFT announces (MT103) and Money Transfer Orders (MT202) messages would have been more difficult.
Instead, the worm was tampering with genuine messages issued by the Banking Information System and changing the amounts and recipient. This is a lot easier than blank forging.
It is still unclear for now if the initial untampered messages were simply authentic and relevant messages, perhaps duplicated by the worm, or forged through other malwares on different systems. I couldn't find clear information in this regards in all that has been published (if a reader has additional information in this regards, I would be happy to learn about it).

Just as a sidenote, whenever an institution such as the Bengladesh central bank sends a SWIFT funds transfer order, it's always in behalf of one of its customer. The SWIFT message(s) indicates the customer for which the bank requests a funds transfer.
Now of course the target correspondent bank cannot know if such customer exist, it doesn't have access to the list of customers of the sending bank. The SWIFT messages tampered by the worm could have been related to any random customer of the Bengladesh bank, this doesn't matter.
The only important aspect was that the beneficiary account and banking institution were the ones intended by the attackers.

Intercepting SWIFT confirmations

Here as well, by simplifying a little the reality, we can picture the malware as intercepting SWIFT confirmations as follows:

The malware was also developed in such a way that it was intercepting confirmation messages (MT950) back from the Fed (from the SWIFT network in fact). Confirmation of genuine orders were supposed to be allowed to pass through untampered while confirmation of fraudulent messages were supposed to be intercepted and hidden.
But the worm was buggy and while tampering with confirmations sent to the printer, it corrupted them somehow which caused the printer to crash. We'll get back to that later.

Interestingly, going as far as trying to tamper with confirmations was pure genius (even though it didn't work as expected). Had it worked, the bank might well have noticed the attack weeks after the facts since on both sides of the world (the Fed view and the Bengladesh Central bank view), positions would have been very different but yet consistent, the Fed knowing about the orders, taking them as genuine and the Bangladesh bank would have known nothing about them.
Also, one should note that transfer orders (MT202) are executed immediately. So trying to tamper with confirmations was not intended to give more chance to the transfer to succeed, it was really intended as a way to hide the theft until hopefully after the money is laundered.

The Malware

The malware, codenamed Dridex (Addendum 2020-Sep-03 - see note at the end of the article), filenamed evtdiag.exe, was designed to hide the hacker's tracks by changing information on a SWIFT database within Alliance Access and contained the IP address of a server in Egypt the attackers used to monitor the use of the SWIFT system by Bangladesh Bank staff.
It was likely part of a broader attack toolkit that was installed after the attackers obtained administrator credentials.

The malware was compiled close to the date of the heist, contained detailed information about the bank's operations and was uploaded from Bangladesh.
While that malware was specifically written to attack the Bangladesh Bank, the general tools, techniques and procedures used in the attack may allow the gang to strike again and as a matter of fact there have been attempts discussed by Reuters.

The malware was designed to make a slight change to the code of the Access Alliance software installed at the Bangladesh Central Bank, giving attackers the ability to modify a database that logged the bank's activity over the SWIFT network.
Once it had established a foothold, the malware could delete records of outgoing transfer requests altogether from the database and also intercept incoming messages confirming transfers ordered by the hackers.
It was also able to manipulate account balances on logs to prevent the heist from being discovered until after the funds had been laundered. Additionnaly, it manipulated the stream of confirmations sent to a printer that produced hard copies of transfer requests so that the bank would not identify the attack through those printouts.
This part went wrong and led the printer to crash.

More information on the malware is available in this article and this one.

3.2 Complete overview of the attack

On February 4, likely after months of preparation, organizationally and technically, gaining access to the systems, developing the custom worm, obtaining credentials, infecting the systems, etc. unknown hackers sent more than three dozens of fraudulent money transfer requests to the Federal Reserve Bank of New York asking the bank to transfer millions of the Bangladesh Bank's VOSTRO account to bank accounts in the Philippines, Sri-Lanka and other parts of Asia.

The hackers managed to get 81 million USD sent to Rizal Commercial Banking Corporation (RCBC) in the Philippines via four different transfer requests and an additional 20 million USD sent to Pan Asia Banking in a single request.

Fortunately 850 million USD in other transactions managed to be saved initially (thx to the Fed).

The 81 million USD was deposited into three accounts at a Rizal branch in Manila on Feb. 4. These accounts had all been opened a year earlier in May 2015, but had been inactive with just 500 USD sitting in them until the stolen funds arrived in February this year.

Another 20 million USD intended to be sent to Pan Asia Banking have been blocked later in the correspondent bank funds transfer routing process (thx to Deutsche Bank).

But the 81 million USD that went to Rizal Bank in the Philippines was gone. It had already been credited to multiple accounts, reportedly belonging to casinos in the Philippines, and all but 68 thousands USD of it was withdrawn on February 5 and 9 before further withdrawals were halted.
The stolen funds from Bangladesh Bank were transferred to money transfer company Philrem Services Corporation. Philrem converted into pesos some of the 81 million USD and delivered the money in cash tranches to a registered casino junket operator named Weikang Xu, Eastern Hawaii Leisure Company, and Bloomberry Hotels Incorporated (Solaire Resort & Casino).

The hackers might have stolen much more but most transfers have fortunately been stopped by the Fed and one transfer has been stopped by Deutsche Bank.

Deutsche Bank saved 20 million USD

Four requests to transfer a total of about 81 million USD to the Philippines went through, but the fifth one to transfer 20 million USD to a Sri Lankan non-profit organization was held up because the hackers misspelled the name of a non-existent NGO, Shalika Foundation, by writing "fandation" instead of "foundation".

This prompted the Deutsche Bank, a routing bank, to seek clarification from the Bangladesh central bank, thereby stopping the transaction.

The Fed saved 850 million USD

The Federal Reserve Bank did not execute 30 of the 35 transfers, worth around 851 million USD, officially due to "lack of details." These thirty transactions were flagged by the banking system for staff review.

The Fed was still tricked into paying out 101 million USD. But the losses could have been much higher had the name Jupiter not formed part of the address of a Philippines bank where the hackers sought to send hundreds of millions of dollars more.
By chance, Jupiter was also the name of an oil tanker and a shipping company under United States' sanctions against Iran. That sanctions listing triggered concerns at the New York Fed and spurred it to scrutinize the fake payment orders more closely.

It was a "total fluke" that the New York Fed did not pay out the 951 million USD requested by the hackers. There is no suggestion the oil tanker or shipping company was involved in the heist.
The Reuters examination has also found that the payment orders sent by the hackers were exceptional in several ways. They were incorrectly formatted at first; they were mainly to individuals; and they were very different from the usual run of payment requests from Bangladesh Bank.
Yet it was the word Jupiter that set the loudest alarm bells ringing at the New York Fed.

The printer error

A printer "error" helped Bangladesh Bank discover the heist. The bank's SWIFT bridge (running Alliance Access) was configured to automatically print out confirmations back from correspondent banks.
The printer works 24 hours so that when workers arrive each morning, they check the tray for transfers that got confirmed overnight.
But on the morning of Friday February 5, the director of the bank found the printer tray empty. When bank workers tried to print the reports manually, they couldn't. The software on the terminal that connects to the SWIFT network indicated that a critical system file was missing or had been altered.
The problem is deemed to be an unwanted bug with the worm, a failure in the attack if one likes, since the worm was programmed to remove confirmation of fraudulent payments from the confirmation stream being sent to the printer.
Fortunately, in this case, the Fed clarification requests and the Deutsche Bank request would have anyway alerted the bank, so even if the worm had functioned correctly, the bank would have been made aware of the attack.

When they finally got the software working the next day and were able to restart the printer, dozens of suspicious transactions spit out. The Fed bank in New York had apparently sent queries to Bangladesh Bank questioning dozens of the transfer orders, but no one in Bangladesh had responded.
Panic ensued as workers in Bangladesh scrambled to determine if any of the money transfers had gone through - their own records system showed that nothing had been debited to their account yet - and halt any orders that were still pending.
They contacted SWIFT and New York Fed, but the attackers had timed their heist well; because it was the weekend in New York, no one there responded. It wasn't until Monday that bank workers in Bangladesh finally learned that four of the transactions had gone through amounting to 101 million USD.

This article on the Fin website is magnificent and gives a lot of additional and cool information on the attack: https://fin.plaid.com/articles/anatomy-of-a-bank-heist.

3.3 Timeline of the attack

In every movie about bank robberies, timing is presented as critical. Here as well timing has been an essential concern and brilliantly mastered by the attackers.

In details:

• May 15, 2015: three dollar bank accounts in the Jupiter, Makati branch of the Rizal Commercial Banking Corporation (RCBC) were opened under the names of Enrico Teodoro Vasquez, Alfred Santos Vergara, Michael Francisco Cruz and Jessie Christopher Lagrosas, with an initial deposit of 500 USD each. These accounts, which were later found to be fake, remained idle until February 4, 2016.
• January 2016: The hackers installed the malware on the bank's system some time in January, not long before they initiated the bogus money transfers on February 4. This was brilliant as well since installing it too soon might have made it detected before the heist and installing it too late might not have enabled them to assess its behaviour.
• February 4, 2016: Under control of the hackers, the malware broke into Bangladesh Bank's VOSTRO account with the Federal Reserve Bank of New York, ordering 35 transfers worth 951 million USD, bulk of which to be transferred to RCBC Jupiter branch.
  The Fed managed to detect and block 30 fraudulent transactions but 5 transfers worth 101 million USD haven't been blocked.
• February 5, 2016: The fed tried to contact the Bangladesh Bank to get an explanation about these transfers, including the 5 non blocked.
  But Feb 5 was a banking holiday in the Bengladesh and nobody could answer.
• February 5 to February 8, 2016: The 5 transfer are executed by the correspondent banks and the routing banks.
  One transaction of 20 million USD has been salvaged. This was after an instruction to a fake Sri Lankan foundation was put on hold by Deutsche Bank, one of the routing bank, because of a typographical mistake.
  But the remaining 81 million USD stolen funds found their way to 4 fake bank accounts in RCBC.
• February 8, 2016: Bangladesh Bank sent a "stop payment" order to RCBC. The request means the central bank was asking to refund the stolen funds or freeze the funds if these were not transferred yet.
  February 8 is a Chinese New Year non-working holiday for the Philippines.
• February 9: RCBC received a SWIFT code from Bangladesh Bank requesting for a refund or putting it on hold if the funds had been transferred or freeze them for proper investigation.
  Despite the "stop payment" order, RCBC Jupiter branch still allowed withdrawals from the accounts.
  Money was then consolidated and deposited in a dollar account of William So Go of DBA Centurytex Trading, which was opened on the same day.
  In the following days the money was laundered in the Casinos.

The timing was perfect. A unique Week-End preceded by a business holiday in Bengladesh and followed by a the Chinese New Year holiday in the Philippines, an ideal situation. The Fed couldn't get the required clarification from Bangladesh Bank on the next day and as such didn't attempt to recover the 5 orders that passed immediately.
On Monday, the stop orders sent by the Bangladesh bank couldn't be processed by the RCBC to freeze the funds since it was a banking holiday in Philippines.
In addition, the chinese new-year and the volume of exchanges in casinos at such occasion made the laundering of the money straightforward, not to mention the Philippines weak AML laws and practices.

3.4 Laundering of the money

Getting the money out is also difficult. Here the laundering scheme was both easy and magnificent. Money has been laundered through the Philippines.

The 81 million USD that was successfully stolen was sent to the Philippines to accounts at the Rizal Commercial Banking Corp (RCBC) held by two Chinese nationals who organize gambling junkets in Macau and the Philippines. The money was moved to several Philippine casinos and then subsequently to international bank accounts.
Laundering money in a Casino is fairly straightforward. One just need to touch the money as chips at any counter, loose one at any random game and then pretend one's lost enough and put it back in another account. Boom, laundered. The banking institution behind the account one withdrawn money from assumes it's been lost gambling while the other banking institution behind the account the money is put back one assumes it's been won in the Casino.

Philippine casinos are exempted of anti-money laundering law that requires them to report suspicious transactions, making them an attractive target for this kind of crime.
Plus can you imagine the amount of money transferred, spent, won and lost in Philippine's Casinos during Chinese New-Year ?
The volumes and the kind of operations makes everything absolutely untraceable.

Bamm ! Done. Money Laundered.

4. Aftermath

What Does the Heist Mean?

Even if the hackers didn't compromise the SWIFT network itself, such that all of SWIFT banks were vulnerable, it's still bad news for the global banking process. By targeting the methods that financial institutions use to conduct transactions over the SWIFT network, the hackers undermine a system that until now had been viewed as stalwart.

Who's to Blame?

Honestly only the attackers are really to blame.
But still, without such amazing security weaknesses in the Bengladesh Central Bank and with better control and stricter procedures in place at the Fed, the attack would not have been possible.
Of course, the Bangladesh Bank blames the Fed for allowing the money transfers to go through instead of waiting for confirmation from Bangladesh. The Fed counters that it contacted the bank to question and verify dozens of suspicious transfers and never got a response. Authorities at the Fed said that workers followed the correct procedures in approving the five money transfers that went through and blocking 30 others. Bangladesh Bank says the Fed bank should have blocked all money transfers until it got a response on the ones it deemed suspicious. And so on ...

The Bengladesh Bank

Aside from the loss of money, the Central Bank's governor, Atiur Rahman has resigned due to the incident. The bank promised to improve their cyber-security and ensure this kind of bank heist is prevented in the future.

The Fed

The immediate result of the breach for the New York Fed is a claim from the Bangladesh Bank for payment of lost funds and a potential lawsuit.

The Fed focused security resources on other priorities, such as preventing money-laundering and enforcing U.S. economic sanctions, officials with knowledge of the bank's security operations told Reuters. Fed officials took some comfort in the fact that SWIFT's security software had never been cracked.

The Bengladesh heist forced the Fed to invest massively in Fraud prevention solutions and better transaction monitoring systems.

Philrem services

The Philippine central bank has revoked the license of a remittance company that anti-money laundering investigators said was used to transfer some of the 81 million USD hackers looted from the Bangladesh central bank.
The Anti-Money Laundering Council (AMLC) issued a complaint against Philrem Service Corporation on April 28, accusing it of creating a fog around transactions and washing the stolen funds via a web of transfers and currency conversions through Philippine bank accounts, before moving the cash through casinos in Manila and junket operators.

The Philippines

The Philippines' involvement in the 100 million USD Bangladesh Bank heist, which has risked its return to the FATF gray list, showed the urgency of putting more teeth into the Anti-Money Laundering Act (AMLA).

The law, which was first introduced in 2001, left casinos out of the list of entities required to report suspicious transactions to the AMLC. There were efforts in the Senate to include this provision in the amended AMLA in 2013, but this was blocked by some lawmakers and casinos lobbies.

5. Conclusion

If the hackers had indeed managed to get away with the terrifyingly large amount of 1 billion USD, this would have easily been the biggest bank heist in history, not to mention cyber heist.

Interestingly, these kinds of attacks will be increasingly common and if banks aren't updating their security processes and maintaining their network infrastructures, and the success rates of these attacks will only go up. Worse still, if hackers have access to banks and can manipulate funds, any businesses that partner with those banks is also at risk.

Imagine the following, if the worm had functionned correctly and not blocked the printer, if the Deutsche bank didn't find the typo, if the Fed didn't become suspicious because of the Jupiter keyword, the attack might have been a complete success. Not only the attackers would have successfully withdrawn almost one billion US dollars from the Bangladesh bank VOSTRO account at the Fed, but the attack might have been noted only weeks or months after the facts.

Finally, imagine that the same attack succeeds against a american or an european bank. In the US and in Europe, the SWIFT interfaces are integrated in an STP (Straight Through Processing) way. There is no such thing as manual reconciliation from some papers printed on a printer. The handling of confirmations and position reconciliation is mostly completely automated.
As such, the same attack succeeding in Europe for instance might take months to be discovered and uncovered, only a the moment the big position reconciliations between NOSTRO and VOSTRO accounts in correspondent banks are triggered.

And this is where it gets really funny. Everybody always had the illusion that SWIFT was so secure, so sure. It gave banking institutions worldwide the illusion that everything related to SWIFT is just as secure. But if the network itself is pretty secure indeed, the specific bridges and interfaces linking the Banking Information Systems to SWIFT can be very weak, as shown by the Bangladesh Heist.
Today european and US banking institutions and central banks are very worried and investigating transaction monitoring and security solutions to prevent such misadventure to happen to them.
Again the same attack in Europe would be a much bigger disaster.

Now another funny story to conclude this article: imagine a similar hack between two banks in Europe and imagine that one of them suspects something ... They would use SWIFT again to reconcile their views of the truth (MT109 and MT999).
These messages can be hacked just as well, in which case the theft may remain uncovered for months.
This is really hilarious.

(This article is available as a slideshare presentation here https://www.slideshare.net/JrmeKehrli/deciphering-the-bengladesh-bank-heist)