Bangladesh heist could have been prevented

ON May 15, 2015, three bank accounts were opened at the Rizal Commercial Banking Corporation (RCBC) in the Philippines. Each of these accounts was to lie dormant until Feb 4 the following year. The authorities were to find out only later that the accounts were fake, and linked to an attempt by the cyber criminals to steal nearly US$1 billion from the Bangladesh Central Bank.

The heist had been in the planning for nearly a year, but thanks in large part to a spelling error that raised alarm bells, the attackers made off with only US$81 million.

To understand how this attack occurred, it is first necessary to understand the role of Swift in monetary transactions between financial institutions, including central banks.

Swift is a member-owned financial services co-operative that provides a secure network through which banks can send and receive monetary transactions. The network is centrally controlled and managed by Swift, and each member bank has its own systems that can be used to securely connect to the Swift network to send and receive money.

Before any bank user is able to send or receive money, that user must first be granted a unique digital certificate directly by Swift.

And before a new certificate is issued, member banks must complete multiple steps of verification on behalf of their authorised users, validating these users' identities, their relationship to the bank and the permissions. Once the certificate is created and provisioned, it is up to each member bank to properly secure these highly sensitive credentials.

When an authorised user attempts to send a new message which initiates the transfer of funds from one bank to another, he or she must present his or her digital certificate. The Swift network verifies the certificate to authenticate the user.

Upon authentication, SwiftNet establishes an encrypted tunnel through which the message is sent, first from the initiating member bank to SwiftNet, then from SwiftNet to the recipient. This assures the integrity of the messages and prevents potential man-in-middle attacks.

While this process itself is secure, it is not immune to vulnerabilities at the level of the member banks. If a member bank does not properly secure its systems and accounts that can connect to SwiftNet, attackers can masquerade as authorised users and conduct transactions on SwiftNet - all without actually compromising the network itself.

In the Bangladesh incident, the attackers first penetrated the IT perimeter using some type of malware-based attack. This was likely a spear-phishing attack or a targeted drive-by-download attack.

HARVESTING DATA

Once the attackers were in, they were able to harvest credentials from infected systems and use those credentials to laterally move throughout the IT network until they were able to cross into the Swift-connected systems.

The Swift-connected systems owned and managed by Bangladesh Bank were configured with SwiftNet Link (SNL) software, which enabled these machines to securely connect to the Swift network. Once the attackers were inside the Swift-connected systems, they appeared to operate exclusively with local administrator accounts.

Notably here, central banks typically separate their Swift-connected systems from the rest of their IT network; up until October of 2015, Bangladesh Bank had done so too.

That month, however, it launched a new service called Real Time Gross Settlement (RTGS). When this service was configured, its systems were directly connected to both the IT network and the Swift-connected systems. This connection eliminated the "air gap" and gave the attackers an easy path from compromised IT systems to highly sensitive SwiftNet Link systems.

Once inside the Swift-connected systems, the attackers installed "SysMon in SwiftLive" to monitor all activity. One service the attackers discovered was related to the printers. Every time an order was sent or received, it was automatically sent to a printer. To keep their actions under the radar, the attackers used their privileged access to run an advanced piece of malware that disabled the connected printer and thus covered their tracks. When bank employees noticed the printer was not working, they assumed it was a simple printer error rather than an indication of an attack in progress.

Once inside the systems, the attackers were able to capture the digital certificates needed to send financial messages, as well as the passwords that Bangladesh Bank used to protect access to the certificates.

Bangladesh's central bank relied on single-factor authentication, which is far easier to crack. With the necessary credentials in hand and knowledge of the processes, the attackers were next able to start sending financial messages through the secure, access-controlled SwiftNet systems as legitimate, authorised users.

The attackers ordered a total of 35 transfers worth US$951 million. Because they were using stolen privileged credentials from Bangladesh Bank, SwiftNet authenticated the transactions and sent them on their intended recipient - the US Federal Reserve.

Interestingly, the timing of the orders raised some suspicion with the Fed - enough so that they called the Bangladesh bankers to confirm. However, by the time the calls were placed, it was the weekend in Bangladesh and no one took the call. But because the Fed bankers inherently trusted Swift messages, instead of holding the orders until Monday, the Fed began processing them.

The first four orders worth US$81 million were sent to four separate, fake bank accounts at RCBC in the Philippines. From there, the money was consolidated into a single bank account that had been opened on the same day, sent to a money-transfer company, and then distributed to a casino company, a hotel and a leisure company. The bulk of that money is still missing, as the money trail ended there.

The fifth order, worth US$20 million, was also executed by the New York Fed with minimal questioning, but it was flagged by Deutche Bank (a routing bank for this transaction) as being suspicious. The intended recipient had been listed as "Shalika Fandation". The spelling of "Fandation" prompted the initial question, and upon further investigation, no record of a Shalika Foundation in Sri Lanka was found.

At that point, the money had already been routed to Pan Asia Banking Company, but Deutche Bank was able to stop payment on the transaction, enabling Pan Asia to prevent the distribution of funds. As result, after the attacker was discovered, Pan Asia was able to return the US$20 million to its rightful owner.

This question over spelling from Deutche Bank next prompted the New York Fed to contact Bangladesh Bank regarding the 30 other transactions. Only then did Bangladesh Bank discover that it had a problem; the printer that had been taken down was restored, and all 35 transactions printed out.

To date, Bangladesh Bank has been unable to recover US$81 million - minimal when compared to the attempted theft of the US$951 million. Had it not been for that spelling error, Bangladesh Bank would likely be down close to a billion US dollars.

ADMIN PRIVILEGES

The role of privilege was essential in this bank robbery.

Compromised administrative credentials enabled the attackers to laterally move throughout the environment until they ultimately reached the Swift-connected systems. There, they were able to harvest both system credentials and Swift credentials, granting them persistent, privileged access to the Swift-connected systems and the Swift software platform itself. Admin privileges enabled the remote disabling of the printer to prevent employees from discovering the fraudulent transactions. Lastly, the attackers used the stolen Swift credentials to send financial messages, thus initiating the 35 transactions.

While this attack had a serious outcome and required advanced planning, the attack methods used were not very sophisticated. With the proper tools and policies in place, this likely could have been prevented. Proactive privileged account controls could have helped make it far more difficult for the attackers to get into the Swift environment to begin with, and advanced detection capabilities likely would have detected the anomalous log-in activity and alerted the security team that something was wrong.