SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Early February 2016 : authorities of Bangladesh Bank were informed that 81 mUSD 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.
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 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.
They actually attempted to steal almost a billion USD!!! 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.
(latin words for ours and yours).
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.
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)
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.
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.
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.
2. The SWIFT network - Key Concepts
1. Correspondant Banking
2. Transfering Money
3. Application Architecture (Bengladesh case)
4. Introducing key SWIFT messages
3. The attack
1. Behaviour of the malware
2. Complete overview of the attack
3. Timeline of the attack
4. Laundering of the money
In February 2016, a group of CyberThieves have stolen 81 Million USDs from
the Bengladesh Central Bank
One of the three biggest bank Heists in global Financial History
Biggest Cyberheist ever
The Hackers broke into the Information System of the Bangladesh Central Bank
Attempted to transfer 951 Million USD from the Bank
Successfully transferred 81 Million USD
The money laundering scheme was brilliantly designed
The thieves are unknown, untroubled and safe
The successfully stole the money by hacking the SWIFT bridge within the bank
SWIFT is the heart of the worldwide finance system, it connects the financial
The attackers forged fraudulent SWIFT funds transfer messages to the network
They attempted to hide their traces by hiding confirmation to the fraudulent transfers
coming from the network
1. Introduction - Bangladesh Bank Heist – What we know
The team of thieves
Likely under 20 persons
Composed by (at least):
Hackers: social engineering and physical penetration in the bank to get administrator
Software Engineers: developed a custom version of the Dridex worm to perform the attack
and gain control over the SWIFT bridge
SWIFT experts: helped the team have an in depth understanding of the SWIFT messages
formats and the SWIFT network behaviour
This is the most puzzling aspects. SWIFT experts are not numerous worldwide
Finance experts: helped the team shape the attach, find the right timeframe and build the
money laundering scheme
The team leader(s) had the idea likely a few years before
He (they) assembled the team likely 2 years before the heist
The team started working likely 18 months before the heist
1. Introduction - Bangladesh Bank Heist – What we believe
Presenting key concepts about correspondent banking and the SWIFT network
SWIFT - Society for Worldwide Inter-bank Financial Telecommunication
A belgian company, located in Belgium,
a trusted and closed network used for communication between banks
around the world.
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'000 institutions in more than 200 countries
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.
For two financial institutions to exchange banking transactions, they must have a banking relationship
A cool introduction to SWIFT is available on the Fin website :
2. The SWIFT network – key concepts
2.1 Correspondent Banking (1/3)
A correspondent bank is a financial institution that provides services on behalf of
another financial institution.
facilitate wire transfers,
conduct business transactions,
accept deposits and
gather documents on behalf of another financial institution.
Correspondent banks are most often to be used by domestic banks to service
transactions in foreign countries, acting as a domestic bank's agent abroad.
Reasons for this 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.
The accounts held between correspondent banks and the banks to which they
are providing services are referred to as NOSTRO and VOSTRO accounts
An account held by one bank for another is referred to by the holding bank as a
The same account is referred as a NOSTRO account by the owning bank (the
Both banks in a correspondent relationship hold accounts for one another for the
purpose of tracking debits and credits between the parties.
2.1 Correspondent Banking (2/3)
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.
When the sending bank has no banking relationships with any bank having itself a
relationship with the target bank, then the order needs to be transferred through
several, sometimes many, distinct banks through the SWIFT network.
These are called routing banks.
2.1 Correspondent Banking (3/3)
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
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, big commercial banks worldwide open a correspondent banking relationships
with the US federal Reserve in New York and use their VOSTRO accounts there 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.
2.2 Transferring Money (1/6)
SWIFT provides a centralized store-and-forward mechanism, with some transaction
guarantees secure and reliable delivery of multiple targets and actions messages.
SWIFT guarantees are based primarily on high redundancy of hardware, software, and people.
Today the SWIFT network can be seen as a highly secured private network over Internet.
A financial institution needs to obtain a SWIFT gateway running the SWIFT NetLink software.
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 with higher level or simpler
SWIFT Network Security
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.
2.3 Application Architecture - Bengladesh case – (1/x)
The Bangladesh central bank 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
read/write SWIFT messages from/to files on the filesystem (huge security concern
!!!) and record transaction information in an Oracle database.
a manual process
after being sent
to a printer.
2.3 Application Architecture - Bengladesh case – (2/x)
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
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.
2.4 Introducing key SWIFT messages (1/x)
A lot of stuff goes through SWIFT, on the small message types subset related to
transferring money are interesting.
First the MT103 is an information message, basically announcing that a target
counterparty account will receive money from an internal (or correspondent) account to
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.
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 Bank IS 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.
Confirmation messages back from the SWIFT network were stored and printed.
Reconciliation is a manual process from these printed messages.
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
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.
Summary of the attack (1/2)
The attack is impressive and stands out on various levels, in terms of technical
means, maturity and complexity for several reasons:
Technical Mastery: the usage of a custom Dridex worm to hack the SWIFT Bridge by
the bank and likely other malwares to capture the administration credentials
In-depth understanding of the worldwide financial market: both the attack shape
and the money laundering scheme prove in-depth understanding of financial markets
SWIFT knowledge: in-depth Knowledge of the SWIFT messaging details is not that
much spread among software engineers
Attacking the VOSTRO account of the Bengladesh Central Bank managed
at the Fed was brilliant!
Such VOSTRO account usually have no limits whatsoever
They do not even need to be credited beforehand
In addition, since a correspondent bank knows nothing of the customer on behalf the
sending bank is acting, its fairly easy to make it believe the transaction is genuine
Summary of the attack (2/2)
The hackers used a custom version of the Dridex malware to hack software
called SWIFT Alliance Access to both make the transactions and hide the
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.
3.1 Behaviour of the malware (1/3)
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:
3.1 Behaviour of the malware (2/3)
If an organization can't keep its endpoint secure, it leaves itself very vulnerable
to being electronically robbed.
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 also 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 also
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.
3.1 Behaviour of the malware (3/3)
3.1.1 Forging fraudulent SWIFT messages (1/3)
Simplifying a bit the reality, we can picture the malware as forging fraudulent
SWIFT messages as follows:
3.1.1 Forging fraudulent SWIFT messages (2/3)
3.1.1 Forging fraudulent SWIFT messages (3/3)
3.1.2 Forging fraudulent SWIFT messages (1/3)
Here as well, by simplifying a little the reality, we can picture the malware as
intercepting SWIFT confirmations as follows:
3.1.2 Forging fraudulent SWIFT messages (2/3)
3.1.2 Forging fraudulent SWIFT messages (3/3)
What we know of the malware:
designed to hide the hacker's tracks by changing information on a SWIFT database
within Alliance Access
contained the IP address of a server in Egypt the attackers used to monitor the use of
the SWIFT system by Bangladesh Bank staff.
was compiled close to the date of the heist,
contained detailed information about the bank's operations
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
It was likely part of a broader attack toolkit that was installed after the attackers
obtained administrator credentials.
3.1.3 The Malware (1/2)
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
It could delete records of outgoing transfer requests from the database
and also intercept incoming messages confirming transfers ordered by the hackers.
It also able to manipulate account balances on logs to prevent the heist from being
discovered until after the funds had been laundered.
The malware also 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.
3.1.3 The Malware (2/2)
3.2 Complete overview of the attack (1/8)
On February 4, likely after months of preparation, organizationally and
gaining access to the systems,
developing the custom Dridex worm,
infecting the systems, etc.
The hackers launched the attack.
3.2 Complete overview of the attack (2/8)
On February 4, 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.
3.2 Complete overview of the attack (3/8)
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.
3.2 Complete overview of the attack (4/8)
Fortunately 850 million USD in other transactions managed to be saved initially
(thx to the Fed).
the losses could have been much higher had the name ”Jupiter” not formed part
of the address of a Philippines bank account where the hackers sought to send
hundreds of millions of dollars more.
“Jupiter” was the name of an oil tanker and a shipping company under United States'
sanctions against Iran. That sanctions listing triggered concerns at the Fed.
3.2 Complete overview of the attack (5/8)
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.
3.2 Complete overview of the attack (6/8)
Another 20 million USD intended to be sent to Pan Asia Banking have been
blocked later in the correspondent bank funds transfer routing process
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.
3.2 Complete overview of the attack (7/8)
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
They were transferred by a money transfer (remittance) company Philrem
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.
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.
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.
3.2 Complete overview of the attack (8/8)
3.3 Timeline of the attack (1/9)
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.
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,
because of banking holidays in Bengladesh, 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.3 Timeline of the attack (9/9)
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 was sent to the Philippines to accounts at the Rizal Commercial
Banking Corp (RCBC) held by two Chinese nationals (false identities).
The money was moved to several Philippine casinos and then subsequently to
international bank accounts.
Laundering money in a Casino is fairly straightforward...
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.
The volumes and the kind of operations during Chinese New-Year makes everything
Bamm ! Done. Money Laundered.
3.4 Laundering of the money
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 system.
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
4. Aftermath (1/6)
Who's to Blame?
Only the attackers of course !
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 ...
4. Aftermath (2/6)
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.
4. Aftermath (3/6)
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
The Bengladesh heist forced the Fed to invest massively in Fraud prevention
solutions and better transaction monitoring systems.
4. Aftermath (4/6)
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.
4. Aftermath (5/6)
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.
4. Aftermath (6/6)
The heist scares the whole financial system worldwide
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.
Imagine the following
if the worm had functioned 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,
Then 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 after the facts.
5. Conclusions (1/2)
Imagine that the same attack succeeds against european bank for instance
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
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.
Even further, imagine that one of these banks at stakes suspects
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.
5. Conclusions (2/2)