on July 13, 2016

Cyber Attacks Targeting SWIFT – Recap

SWIFT stands for Society for Worldwide Interbank Financial Telecommunication, and its purpose is to allow banks and financial institutions in general to communicate securely. It is used in the exchange of information between banks, such as transactions.

In this post you will get a short summary of the incidents and a brief description on how these attacks are usually carried-out. In addition, we’ll also provide some Yara rules and IoCs that will allow you and your company to detect a potential attack similar to those we’ve seen before.

Background 

SWIFT was recently a target of a series of thefts (some successful, some not) against banks in different countries. One of the most notorious, is the theft of $81 million from a Bangladeshi bank (Bangladesh Bank or BB for short). Following the attack on Bangladesh Bank, the authors have albeit unsuccessfully, attempted to steal from other financial institutions, specifically from banks in Vietnam, and the Philippines. The authors did however, manage to steal $12 million from Banco del Austro in Ecuador, and another $10 million from an unnamed bank in Ukraine. Other attempts may have been carried-out against other banks in the USA, but we do not know for certain.

Attack on Bangladesh Bank

Although it hasn’t been fully disclosed, it is known that the bank was using outdated hardware (network switches), and hadn’t properly set up a firewall. The attackers gained access to the internal network and deployed multiple tools to aid them in the theft.
Among the different used tools, one of them caught the eye of the forensics team performing the analysis.
This piece of software had two important characteristics that would allow the team to understand how the theft was performed, and to link this attack to the ones that occurred at other banks. For more information, you can search for TROJAN.BANKSWIFT (which is the name given to the malware sample).

To begin with, the malware was capable of interacting with the SWIFT systems and back-end. This allowed the authors to intercept and tamper with messages that were sent and received using the SWIFT infrastructure, extracting relevant information for the theft, such as identifiers of the transactions and other references. Even though each transaction has to be printed and manually reviewed, the malware had capabilities to alter the document and avoid detection of foul play.

The malware also had a very distinctive file deletion function. Usually, when you delete a file, the information from the file isn’t overwritten, it exists on the disk until the computer needs that space and overwrites it.
The malware, though, had a function that allowed the attackers to overwrite a file multiple times with random bytes. Using this unique function as a fingerprint, the analysts were able to link this attack to the ones that occurred in Vietnam, the Philippines and Ecuador.

How intrusions usually occur

Even though in this case we do not have all the information about the attack, every intrusion usually follows the steps below:

Gaining access to the internal network

This is the first challenge every external intrusion must overcome. Gaining access to the internal network will allow the attackers to move laterally (gain access to other systems with the same privileges as the one they have accessed) and, eventually, vertically (gaining more privileges in a network).
In order to gain access to the internal network, the attackers use mostly two methods:

Phishing campaign
A successful phishing campaign targeting the company and deploying a backdoor will allow the attackers to connect to at least one of the computers in the company, from which they can start to move laterally and vertically.

RCE vulnerability or misconfiguration in the external network
Due to a misconfiguration, or a vulnerability that allows Remote Command Execution (RCE), the attacker will be able to execute commands on the remote host.

This is probably the case for the Bangladesh Bank. The bank was using outdated switches without firewalls to connect to the SWIFT infrastructure.

Taking control of the internal network

Once the attackers have gained access to the internal network, there’s usually the need to escalate privileges, all the way up to the user with the most privileges (for example Domain Administrator in Windows networks). This way, they can move freely around the network, entering any system and eventually accessing all the data in the network. This is usually carried-out exploiting vulnerabilities from applications or from the operating system. It’s also possible to use social engineering to achieve this goal. In some cases, this second step is not necessary, because the authors may have already accessed the necessary systems to perform the attack.

Next steps

In the case that we’re talking about, the next steps that the authors probably took were to locate the host in which the SWIFT infrastructure was operating, and deploy their tools/malware to proceed with the theft.

Detecting the thread

Thanks to the work of the security experts at BAE systems and Symantec, it’s quite easy to write a Yara rule or an IOC to detect a possible intrusion similar to the one in Bangladesh, Vietnam, the Philippines or Ecuador.

As Symantec stated in their blog post [1], the one thing that connected the multiple attacks on the different banks was a wiping function.
Therefore, it’s possible to create a Yara rule to detect samples that share this subroutine, by looking for the most unique components of the subroutine. In our case we’ve chosen the following code snippets:

 

SWIFT_pic1

SWIFT_pic2

And we have created the following Yara rule:
rule banswift :banswift {
meta:
description = “Yara rule to detect samples that share wiping function with banswift”
threat_level = 10
strings:
$snippet1 = {88 44 24 0D B9 FF 03 00 00 33 C0 8D 7C 24 2D C6 44 24 2C 5F 33 DB F3 AB 66 AB 53 68 80 00 00 00 6A 03 53 AA 8B 84 24 40 10 00 00 53 68 00 00 00 40 50 C6 44 24 2A FF 88 5C 24 2B C6 44 24 2C 7E C6 44 24 2D E7}
/*
88 44 24 0D mov [esp+102Ch+var_101F], al
B9 FF 03 00 00 movecx, 3FFh
33 C0 xoreax, eax
8D 7C 24 2D lea edi, [esp+102Ch+var_FFF]
C6 44 24 2C 5F mov [esp+102Ch+var_1000], 5Fh
33 DB xorebx, ebx
F3 AB rep stosd
66 AB stosw
53 push ebx ; _DWORD
68 80 00 00 00 push 80h ; _DWORD
6A 03 push 3 ; _DWORD
53 push ebx ; _DWORD
AA stosb
8B 84 24 40 10 00 00 moveax, [esp+103Ch+arg_0]
53 push ebx ; _DWORD
68 00 00 00 40 push 40000000h ; _DWORD
50 push eax ; _DWORD
C6 44 24 2A FF mov [esp+1048h+var_101E], 0FFh
88 5C 24 2B mov [esp+1048h+var_101D], bl
C6 44 24 2C 7E mov [esp+1048h+var_101C], 7Eh
C6 44 24 2D E7 mov [esp+1048h+var_101B], 0E7h
*/
$snippet2 = {25 FF 00 00 00 B9 00 04 00 00 8A D0 8D 7C 24 30 8A F2 8B C2 C1 E0 10 66 8B C2 F3 AB}
/*
25 FF 00 00 00 and eax, 0FFh
B9 00 04 00 00 movecx, 400h
8A D0 mov dl, al
8D 7C 24 30 lea edi, [esp+30h]
8A F2 mov dh, dl
8B C2 moveax, edx
C1 E0 10 shleax, 10h
66 8B C2 mov ax, dx
F3 AB rep stosd
*/
condition:
all of ($snippet*)
}

Using the Yara, it’s possible to generate an IOC in stix format that can be used to detect this wiping function.

Thanks to the stix python lib, it’s easier to create an IOC from a Yara as shown in the python code below:

from stix.indicator import Indicator
from stix.extensions.test_mechanism.yara_test_mechanism import YaraTestMechanism
from stix.common import InformationSource
from stix.common import Identity

rule = “””
rule banswift :banswift {
meta:
description = “Yara rule to detect samples that share wiping function with banswift”
threat_level = 10

strings:
$snippet1 = {88 44 24 0D B9 FF 03 00 00 33 C0 8D 7C 24 2D C6 44 24 2C 5F 33 DB F3 AB 66 AB 53 68 80 00 00 00 6A 03 53 AA 8B 84 24 40 10 00 00 53 68 00 00 00 40 50 C6 44 24 2A FF 88 5C 24 2B C6 44 24 2C 7E C6 44 24 2D E7}
$snippet2 = {25 FF 00 00 00 B9 00 04 00 00 8A D0 8D 7C 24 30 8A F2 8B C2 C1 E0 10 66 8B C2 F3 AB}
condition:
all of ($snippet*)
}
“””
indicator = Indicator(title=”banswift”, description=”IOC to detect files that share wiping function with banswift”)

tm = YaraTestMechanism()
tm.rule = rule
tm.efficacy = “High”
tm.producer = InformationSource(identity=Identity(name=”Yara”))
tm.producer.references = [“http://plusvic.github.io/yara/”]
indicator.test_mechanisms = [tm]

print indicator.to_xml()
Which gives the following output

<indicator:Indicator
xmlns:cybox=”http://cybox.mitre.org/cybox-2″
xmlns:cyboxCommon=”http://cybox.mitre.org/common-2″
xmlns:cyboxVocabs=”http://cybox.mitre.org/default_vocabularies-2″
xmlns:example=”http://example.com”
xmlns:indicator=”http://stix.mitre.org/Indicator-2″
xmlns:stix=”http://stix.mitre.org/stix-1″
xmlns:stixCommon=”http://stix.mitre.org/common-1″
xmlns:stixVocabs=”http://stix.mitre.org/default_vocabularies-1″
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:yaraTM=”http://stix.mitre.org/extensions/TestMechanism#YARA-1″ id=”example:indicator-31d9c315-6350-4822-9a6d-d78bd57c4fbe” timestamp=”2016-06-17T10:43:14.930335+00:00″ xsi:type=’indicator:IndicatorType’>
<indicator:Title>banswift</indicator:Title>
<indicator:Description>IOC to detect files that share wiping function with banswift</indicator:Description>
<indicator:Test_Mechanisms>
<indicator:Test_Mechanismxsi:type=’yaraTM:YaraTestMechanismType’>
<indicator:Efficacy timestamp=”2016-06-17T10:43:14.930473+00:00″>
<stixCommon:Value xsi:type=”stixVocabs:HighMediumLowVocab-1.0″>High</stixCommon:Value>
</indicator:Efficacy>
<indicator:Producer>
<stixCommon:Identity>
<stixCommon:Name>Yara</stixCommon:Name>
</stixCommon:Identity>
<stixCommon:References>
<stixCommon:Reference>http://plusvic.github.io/yara/</stixCommon:Reference>
</stixCommon:References>
</indicator:Producer>
<yaraTM:Rule><![CDATA[

rule banswift :banswift {
meta:
description = “Yara rule to detect samples that share wiping function with banswift”
threat_level = 10

strings:
$snippet1 = {88 44 24 0D B9 FF 03 00 00 33 C0 8D 7C 24 2D C6 44 24 2C 5F 33 DB F3 AB 66 AB 53 68 80 00 00 00 6A 03 53 AA 8B 84 24 40 10 00 00 53 68 00 00 00 40 50 C6 44 24 2A FF 88 5C 24 2B C6 44 24 2C 7E C6 44 24 2D E7}
$snippet2 = {25 FF 00 00 00 B9 00 04 00 00 8A D0 8D 7C 24 30 8A F2 8B C2 C1 E0 10 66 8B C2 F3 AB}
condition:
all of ($snippet*)
}

]]></yaraTM:Rule>
</indicator:Test_Mechanism>
</indicator:Test_Mechanisms>
</indicator:Indicator>

Do keep in mind, however, that even though this serves as mitigation, if you do find a match for the Yara rule or the IOC in your systems, it might mean that the attackers have already breached your systems.

Results

Using the Yara, we’ve been able to find up to 9 different samples that use this same wiping function, the most recent one being from 2016-06-13.
In some cases, the samples aren’t being properly detected and classified by some antivirus vendors.

Conclusions

After these series of attacks on multiple banks, it’s apparent that there’s an ongoing campaign targeting banks, and that the attacks won’t stop here.
We will probably see more attempts throughout the year, so as always we recommend that you keep your systems updated and take extra precautions.

 

To stay up to date with the latest IOCs and information about cyber threats, please visit Blueliv’s free online community the Threat Exchange Network.

 

Additional sources of information

[1] http://www.symantec.com/connect/blogs/swift-attackers-malware-linked-more-financial-attacks

http://www.reuters.com/article/us-usa-fed-bangladesh-idUSKCN0XI1UO
http://www.theregister.co.uk/2016/04/25/bangladeshi_malware_screwed_swift/
http://www.theregister.co.uk/2016/05/27/fourth_bank_hit_by_swift_hackers/
http://baesystemsai.blogspot.com.es/2016/05/cyber-heist-attribution.html
http://baesystemsai.blogspot.com.es/2016/04/two-bytes-to-951m.html


Demo Free Trial Community