The hack of the month for April 2016 could be given to the Bangladeshi breach where $81 million was mysteriously siphoned off from the bank and sent to the money-laundering underworld of the casino system in the Philippines.
The theories about this breach have come fast and furious. The bank itself blamed the New York Federal Reserve for “a lack of security that made it easy for the unidentified hackers to make off with the loot.” Initially, the thieves requested the transfer of $951 million to bank accounts in Sri Lanka and the Philippines—a number that prompted the New York Fed to ask the Bangladesh bank to reconfirm that it actually wanted to make the transfer.
Immediately following the breach, an investigator into the cyber heist said that the bank didn’t even use a firewall and were using second-hand $10 switches that were easily breached. Separately, Sergei Shevchenko of Bae Systems wrote a fascinating post detailing the company’s discovery of tools they believe relate to the heist. This includes custom-built malware to cover the tracks of hackers as they “sent forged payment instructions to make the transfers.”
Observations from the Bae Systems Analysis
The Bae Systems post, mentioned above is a recommended read, and from it a number of observations can be made. For example, the post states: “The malware registers itself as a service and operates within an environment running SWIFT’s Alliance software suite, powered by an Oracle Database.”
Apparently the targeted SWIFT software had no host-based intrusion detection system (HIDS) that could monitor what was taking place on the host. Considering it hosted SWIFT software, the global standard for transferring money around the financial system, having an HID in place would have been a good idea.
Furthermore, we can see that:
- The hackers managed to register a new service on the server
- The SWIFT configuration file was altered to add the attackers Command & Control server to the running configuration
- The bank lacked separation of duties
While the malware itself:
- Could access the Oracle database, allowing it to “execute database transactions within the victim’s network”
- Enabled the hackers to intercept confirmation messages as they were sent to print, helping the hackers hide their footprints
- Could delete entries from the server’s log, enabling it to erase traces of activity and hide its presence
What was missing?
From our observations, we can see that there were security failures at multiple levels. The bank missed numerous opportunities to detect and prevent the attacks.
For example:
- Enforcement of host-based access controls could possibly have prevented the malware from being registered as a service
- A file integrity monitoring (FIM) solution could have detected changes to the SWIFT configuration files
- Database Profiling would have alerted the bank on the new service that was installed and accessing the Oracle database as it would have violated the existing profile for “known applications,” as well as anomalous behavior like a change in table access patterns
- Enforcing separation of duties by limiting the running of tasks to system administration credentials would have limited access and compromising them should have required compromising the core of the enterprise, the Identity and Access Management systems. Instead, hackers were given free reign
- A database firewall could have prevented the malware from accessing the Oracle database
At Imperva we’ve seen a significant increase over the past year or so of DAM and DBM users who purchased their products for compliance turning on database firewall blocking. While the trend is positive, we recommend all organizations with this capability enable it. Just auditing activity doesn’t prevent theft, it helps discover it after the fact, when it’s too late.
Sadly, in the case of the Bangladeshi bank, they apparently didn’t even have a basic firewall. In the end, the Federal Reserve Bank processed only five of the 35 fraudulent payment requests, after it could not reconfirm with officials in Bangladesh. But regardless, someone is paying for a $81 million security mistake.
So how do you protect yourself?
Planning and implementing a layered approach that monitors your system for changes and activity to your databases can block malicious access (turn database firewall blocking on!), and detect problematic or malicious activity, even among your own employees (insiders). Implementing the right solutions to monitor your operations and protect your assets will go a long way to detecting when someone is doing something in your network they’re not supposed to be doing, and in the end help prevent a damaging breach.
Try Imperva for Free
Protect your business for 30 days on Imperva.
