SWIFT Confirms Repeat Hack Attacks

Bangladesh Bank Not the Only Victim of Bank-Messaging System Attacks
SWIFT Confirms Repeat Hack Attacks

The February Bangladesh Bank hack wasn't the first time that the SWIFT messaging platform used by banks around the world was subverted by attackers in an attempt to steal money, SWIFT now acknowledges (see Bangladesh Bank Attackers Hacked SWIFT Software).

See Also: Webinar | Identity Crisis: Combating Microsoft 365 Account Takeovers at Scale

The Society for Worldwide Interbank Financial Telecommunication is a Belgium-based cooperative of 3,000 organizations that maintains the SWIFT messaging platform, which it says handles the majority of international interbank messages. Those messages are used to send and receive information about financial transactions, for example, to move money between banks both domestically and internationally, in many countries.

SWIFT says it's issued an alert to customers warning that it's seen repeat attempts by attackers to subvert its messaging system. It has released a "mandatory" software update to all customers to help identify related signs of attack or evidence of a breach.

"We have informed our customers that there are other instances in which customers' internal vulnerabilities have been exploited, in order to stress the importance and urgency of customers' securing their systems," a SWIFT spokesman tells Information Security Media Group. The mandatory software update is designed to help customers "identify situations in which attackers have attempted to hide their traces, whether these actions have been executed manually or through malware," he adds.

The alert and software update follow SWIFT confirming April 25 that the central bank of Bangladesh was attacked in February with malware. Investigators say that attackers attempted to transfer nearly $1 billion out of Bangladesh Bank's account at the U.S. Federal Reserve in New York and ultimately were able to move and steal $81 million. Investigators believe just $6.9 million might still be recoverable.

Bangladesh Bank has not responded to multiple requests for comment.

Multiple 'Recent Cyber Incidents'

But the attack against the bank is not an isolated incident, according to SWIFT's April 25 customer alert. "SWIFT is aware of a number of recent cyber incidents in which malicious insiders or external attackers have managed to submit SWIFT messages from financial institutions' back-offices, PCs or workstations connected to their local interface to the SWIFT network," the alert reads, according to Reuters.

SWIFT declined to share a copy of the alert with ISMG or offer more details about which organizations were hacked, and when. "We cannot comment on the details of any particular customer or incident, but confirm that the commonality in what we have seen is that - internal or external - attackers have successfully compromised banks' own environments and thereby obtained valid operator credentials with the authority to create, approve and submit messages from those entities' interfaces," the spokesman says.

The organization also declined to comment about whether the custom malware or other attack tools - most of which have yet to come to light - may have been used in the previous incidents. On April 25, cybersecurity consultancy BAE Systems Applied Intelligence published research into custom-built malware that it discovered, which it says was used to target Bangladesh Bank's SWIFT software.

SWIFT has reiterated that the malware attack against Bangladesh Bank succeeded because the bank apparently failed to properly lock down its IT environment, thus allowing attackers to install and execute their malware (see Bangladesh Bank Heist: Lessons Learned). As a result, it stresses that the best defense against SWIFT-targeting malware remains a locked-down IT infrastructure. It also reiterated that "the SWIFT network and core messaging services are not affected and continue to operate as normal."

SWIFT-Targeting Malware Hides Its Tracks

The malware used in the Bangladesh Bank hack was cunning, in that it allowed attackers to steal money by surreptitiously altering the Oracle database used by SWIFT's software, and then send the appropriate SWIFT messages to other institutions to facilitate money transfers, according to BAE Systems. The malware also ensured that related messages that would normally have been sent to a printer at the initiating bank to create a paper trail were suppressed to help hide attackers' tracks.

"The malware is designed to hide the traces of fraudulent payments from customers' local database applications and can only be installed on users' local systems by attackers that have successfully identified and exploited weaknesses in their local security," the SWIFT spokesman says.

Guidance: Isolate Internal SWIFT Systems

Many financial services firms could be doing more to lock down any systems that they use to handle SWIFT messages, including using dedicated PCs - not used for anything else - and isolating them on the network, says Sean Sullivan, an adviser at Helsinki-based security firm F-Secure.

Every such system could be further locked down so that no unapproved software installations or modifications would be permitted. "It's long been possible to set up critical computers with hardware to lock down the software," Sullivan says. "It's possible to set up and configure a computer to handle SWIFT payments which would not allow for software/malware to be installed - without, for example, [using] a physical dongle."

Of course, security experts have long advised banks to lock down their IT environments. "This is not new advice - SWIFT and others have been giving this advice for years," says independent information assurance consultant William Murray, who's also an associate professor at the U.S. Naval Postgraduate School.

Because of the potential power that SWIFT offers to attackers - if successful, they can easily move money from a victim account into one that they control, even across borders - it's a natural target. "Given the number of SWIFT customer banks in the world, a compromise should not come as a complete surprise," Murray says.

Ongoing Risk

In the Bangladesh Bank hack, Sullivan notes that the malware was only part of what looks to have been a very well-planned crime, which investigators say involved moving the money into accounts at Rizal Commercial Banking Corp. in the Philippines, changing millions of dollars into pesos, and then laundering it via the country's casinos by exchanging cash for casino tokens, and then converting them back into cash. Investigators in the Philippines have focused their probe, in part, on Maia Deguito, the manager of the RCBC branch into which the money was deposited, although two Chinese casino operators have also been questioned, Reuters reports.

"The entire heist involved some creative thinking," Sullivan says. "Transferring funds to a casino and cashing out in chips was a brilliant move. Once somebody figured out that component, it's not a surprise that they would invest in developing the malware required."

In other words, malware is only one of the risks facing SWIFT-using financial services firms, Murray says. "The fundamental vulnerability is that some banks do business with customers that they do not know and from whom they cannot recover," he says. "Or they are engaged in a criminal conspiracy with their customers."

About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.

Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.