Lessons Learned from the Bangladesh Bank Heist

Most have been following the story about the Bangladesh Bank Heist. If you haven’t, here is the scoop and timeline. On May 15, 2015, three bank accounts were opened at the Rizal Commercial Banking Corporation (RCBC). Each of these accounts would lay dormant until Feb 4, 2016. Only later did authorities discover these accounts were all fake. It turns out cyber criminals who attempted to steal nearly $1 billion from the Bangladesh Central Bank had been planning the heist for nearly a year. Thanks in large part to a spelling error, however, the attackers made off with “only” $81 million of the total attempted amount.

100% of advanced cyber attacks exploit privileged accounts, and that’s true for this bank heist. Let’s take a look at the role of privileged accounts in this breach. After breaking through the perimeter, the attackers were able to successfully capture local administrative credentials from infected machines. Using the stolen privileged credentials, the attackers continued to escalate privileges and move laterally throughout the environment until they ultimately reached the SWIFT-connected systems.

The attackers used local admin rights to install monitoring software on the SWIFT-connected systems. This enabled them to gain persistent access to the systems, learn how the secure message platform worked and gain access to the SWIFT-issued digital certificates required to authenticate to the SWIFT network. With this access, the attackers used the stolen SWIFT credentials to send financial messages, thus initiating 35 fraudulent transactions. To stay hidden, the attackers used their admin privileges to remotely execute a specific advanced malware that was developed to hide tracks when attacking SWIFT systems. One of the malware’s actions disabled the printer that was configured to automatically print all sent and received messages in order to prevent employees from discovering the fraudulent transactions.

There have been a number of industry reports highlighting the dangers of not locking down privileged accounts. Following are some best practices that could have mitigated the breach:

1. Standard business users should never have full local admin rights. Solutions, such as CyberArk Endpoint Privilege Manager, enable organizations to remove local admin rights while enabling users to elevate privileges when needed for approved tasks. Without local admin rights, it would have been difficult for the attackers to break in, move throughout the network and install malware.
2. Secure privileged account credentials. This includes the credentials for the remaining local admin accounts on endpoints, domain admin credentials, privileged SSH keys and any other credentials that provide access to a sensitive account or system. This also could have included the SWIFT user credentials needed to access the digital certificates. By centrally securing privileged credentials, controlling access to these credentials based on role, and enforcing multi-factor authentication before granting access, the attackers would likely not have been able to get the credentials needed to laterally move through the environment, reach the SWIFT-connected systems or execute the fraudulent transactions. Even if attackers were able to harvest the credentials using keylogging malware or by stealing the hash, proactive credential rotation would invalidate the compromised credentials, making them useless to the attacker.
3. Segment off highly sensitive systems from the rest of the IT network. This is often seen in retailers who have separate PCI environments, in utilities who separate and airgap their ICS systems, and it should be seen in central banks in their SWIFT-connected environments. For administration purposes, once these systems are separated from the standard IT network, remote access should only be permitted via a designated, secure and hardened jump server. Using this approach, organizations can tightly control access to these system, better protect against credential harvesting techniques and prevent malware from jumping from user endpoints to sensitive systems. This separation also adds a valuable monitoring component, in that all administrative access to SWIFT-connected systems can be recorded.
4. Monitor and analyze all privilege account activity. Privileged accounts protect the most sensitive data and assets, and as a last line of defense, security teams need to be able to quickly identify anomalous activity that could indicate an attack is in-process. In this case, had the Bangladesh Bank been monitoring SWIFT account activity, they could have been alerted to the abnormal login patterns, investigated what was going on, and stopped the attackers before they were able to execute 35 transactions.
5. Lastly, by controlling applications on endpoints and servers, organizations can apply application whitelisting policies that meet their risk tolerance. By doing this, organizations can proactively prevent unknown and malicious software from infiltrating the environment and detect when new applications enter and spread throughout the environment. In this case, Bangladesh Bank could have recognized the malware during the earlier stages of the attack. For example, SysMon (the monitoring software) and the Evtdiag.exe (the malware that hides malicious tracks) could be blocked from running on the SWIFT-connected machines.

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, this likely could have been prevented. For example, CyberArk’s 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 detected the anomalous login activity and alerted the security team that something was wrong.