Article

Defending SWIFT payment systems from attack

Making sense of the recent attacks on payment systems and what can be done to defend against them.

It’s sometime between 4-5 February 2016, when offices are closed at the Bangladesh Central Bank (BCB). Attackers who had previously infiltrated the bank’s network issue a series of fraudulent SWIFT payment instructions for a total amount of $951 million. Although BCB was able to block most of the transfers, $81 million were lost to the Philippines, allegedly laundered through casinos.

In the wake of this, one of the largest bank heists in history, much uncertainly and panic spread throughout the industry and the media, with many headlines pointing the finger at the SWIFT systems themselves as being flawed. One year later, new concerns emerged as details of similar attacks against other banks were released into the public domain and linked to organized hacking groups, such as Lazarus. To exacerbate the situation, documents recently leaked by the Shadow Broker hacking group indicate that similar operations might’ve been carried out on SWIFT-related payment systems by nation state actors, albeit with a wholly different motive to stealing money. The alleged intent would have been gaining the ability to monitor SWIFT transactions issued by Middle Eastern and Latin American banks.

In this article we’ll try to answer two questions:

  • How do attacks on payment systems occur?
  • How can financial institutions prepare to defend against such attacks?

Our answers will be informed by evidence released in public reports and by our own experience in dealing with payment systems from an offensive, defensive and investigative perspective.

How do attacks on payment systems occur?

In spite of the initial hype following the BCB heist, this and other related attacks do not appear to be the result of a direct compromise of SWIFT itself. Rather, evidence indicates that the attackers managed to infiltrate the affected banks’ networks using different Advanced Persistent Threat (APT) techniques. Even in the documents leaked by Shadow Brokers, the alleged target of the infiltration was not directly SWIFT but EastNets, a company that provides payment services to other banks (detailed observations on the EastNets operation can be found in MWR's examination here).

The most common APT techniques used to infiltrate organizations rely on spear-phishing or watering hole attacks to deploy malware on user workstations. For example, in July 2016 attackers were able to breach the Union Bank of India’s perimeter using a phishing email containing a malicious attachment. This led to the attackers initiating $170 million worth of SWIFT transactions, which luckily the bank was later able to block.

In a more recent case investigated by Kaspersky Labs and allegedly related to the BCB heist of February 2016, the attackers were able to infiltrate an unnamed European bank’s network by delivering exploits through a compromised government website in a typical watering hole scenario. Incidentally, the exploit affected the Adobe Flash Player and was not a zero-day: the bank had measures in place to update the software, but the updated process failed on repeated occasions and no action was taken.

Less often, we still see attackers use more traditional techniques that involve breaching the perimeter through vulnerable servers and web applications. In another recent case still linked to the same group that targeted BCB in February 2016, attackers allegedly established their initial foothold into a Southern Asian bank’s network via vulnerabilities in a web application publicly exposed on the Internet.

Regardless of how they obtain an initial foothold, attackers then employ techniques to enumerate networks and users to spread further into the network. This is often made easier by the fact that internal networks often present a flat structure, with minimal segregation between user LANs, DMZs and critical payment systems. This means attackers can often reach payment systems from any compromised host.

Attackers are likely to focus their lateral movement activities on the identification and compromise of users with legitimate access to payment systems, either SWIFT or other upstream systems that feed payment instructions into the SWIFT network. Depending on their position, observation of user behavior on compromised workstations and servers will allow attackers to implement one of two scenarios. In the first scenario, attackers might be able to compromise a user with privileges to key in manually and approve payment instructions. In the second scenario attackers may be able to compromise a user with administrative access to the payment systems: this would allow them, for example, to tamper with databases and message exchange systems to insert fraudulent payment instructions. Administrative access to payment systems would also allow attackers to deploy specifically crafted malware, such as in the case of the BCB heist, where SWIFT-specific malware was found on a server belonging to BCB. The aim of this malware was to alter the behavior of SWIFT payment processing software – SWIFT Alliance Access - and cover the attacker’s tracks by disabling the reporting functionality.

How can financial institutions prepare to defend against such attacks?

We have seen how these hacking groups can be sophisticated and resourceful, sometimes even nation-state backed. They employ a plethora of different techniques to infiltrate an organizations’ network and then move laterally until they compromise the right employees and accounts with access to payment systems. On their own, classic vulnerability-centric and compliance-based approaches that look at every system individually have not proven effective against these advanced threats.

In contrast, financial organizations need to be focusing their defensive efforts on understanding and mapping the paths, or routes attackers could take to reach their payment systems. Mapping out these attack paths will help with prioritizing investment in prevention, detection and response capabilities. 

In some cases, analysis of the attack paths will make it possible to identify and remove some of the most significant routes an attacker could use. For instance, we discussed how attackers commonly start from a compromised user workstation or DMZ server, and perform lateral movement to reach the payment systems. Segregating payment systems away from DMZs and user LANs is an effective control that could be applied to reduce the risk associated to this path. Another common path is for attackers to leverage legitimate credentials which they have obtained from compromised users, especially those with administrative rights. To make traversing this path more challenging, administration of payment systems should require break-glass procedures with multi-factor authentication.

Nonetheless, for complex enough environments, such as those of banks, it will not be possible to completely remove all identified attack routes. The inevitable remaining attack paths that cannot be fully closed are the ones on which to focus the detection and alerting capabilities. The preventive measures implemented will frustrate attackers and force them down those known, well-monitored paths. Malicious efforts will be slowed down as attackers trip over the many controls along the way. This in turn will make them “noisy”, and alerts will be generated. This will also give threat hunting and incident response teams an earlier chance to identify, contain and remove the attackers before they can get to the crown jewels.

Another effective technique at the disposal of intrusion detection and threat hunting teams is end-point anomaly detection. Many of the attack paths used by modern attackers rely on lateral movement techniques that are difficult to spot early just by looking at traditional network traffic logs. However, the attackers’ malicious techniques become evident when looking at suspicious activity on end points, such as user workstations, especially if data can be analyzed and correlated across an entire estate, rather than an individual host. Effective, at-scale end-point anomaly detection will thus support early identification of attackers as they try to traverse those critical attack paths to the payment systems.

Conclusions

As with defending any asset, successfully defending a payment infrastructure like SWIFT means understanding the attackers who may try to attack it and the techniques they can call on to do so. This understanding needs to be consolidated into a coherent map, capturing the different attack paths that adversaries may traverse to achieve their goals. A defense strategy built around those attack paths gives organizations the best chance to be as effective as possible at preventing and detecting threat actors before they reach their final goal.

 

 

Accreditations

MWR is an accredited member of The Cyber Security Incident Response Scheme (CSIR) approved by CREST (Council of Registered Ethical Security Testers).
MWR is certified under the Cyber Incident Response (CIR) scheme to deal with sophisticated targeted attacks against networks of national significance.
We are certified to comply with ISO 14001 in the UK, an internationally accepted standard that outlines how to put an effective environmental management system in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR is approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.
As members of CHECK we are measured against high standards set by CESG for the services we provide to Her Majesty's Government.
MWR’s consultants hold Certified Simulated Attack Manager (CCSAM) and Certified Simulated Attack Specialist (CCSAS) qualifications and are authorized by CREST to perform STAR penetration testing services.