Search

Flickr

Labels

Two bytes to $951m

In February 2016 one of the largest cyber heists was committed and subsequently disclosed. An unknown attacker gained access to the Bangladesh Bank’s (BB) SWIFT payment system and reportedly instructed an American bank to transfer money from BB’s account to accounts in The Philippines. The attackers attempted to steal $951m, of which $81m is still unaccounted for.
The technical details of the attack have yet to be made public, however we’ve recently identified tools uploaded to online malware repositories that we believe are linked to the heist. The custom malware was submitted by a user in Bangladesh, and contains sophisticated functionality for interacting with local SWIFT Alliance Access software running in the victim infrastructure.

This malware appears to be just part of a wider attack toolkit, and would have been used to cover the attackers’ tracks as they sent forged payment instructions to make the transfers. This would have hampered the detection and response to the attack, giving more time for the subsequent money laundering to take place.

The tools are highly configurable and given the correct access could feasibly be used for similar attacks in the future.

Malware samples

SHA1

Compile time

Size (bytes)

Filename

525a8e3ae4e3df8c9c61f2a49e38541d196e9228

2016-02-05 11:46:20

65,536

evtdiag.exe

76bab478dcc70f979ce62cd306e9ba50ee84e37e

2016-02-04 13:45:39

16,384

evtsys.exe

70bf16597e375ad691f2c1efa194dbe7f60e4eeb

2016-02-05 08:55:19

24,576

nroff_b.exe

6207b92842b28a438330a2bf0ee8dcab7ef0a163

N/A

33,848

gpca.dat

We believe all files were created by the same actor(s), but the main focus of the report will be on 525a8e3ae4e3df8c9c61f2a49e38541d196e9228 as this is the component that contains logic for interacting with the SWIFT software.

The malware registers itself as a service and operates within an environment running SWIFT’s Alliance software suite, powered by an Oracle Database.

The main purpose is to inspect SWIFT messages for strings defined in the configuration file. From these messages, the malware can extract fields such as transfer references and SWIFT addresses to interact with the system database. These details are then used to delete specific transactions, or update transaction amounts appearing in balance reporting messages based on the amount of Convertible Currency available in specific accounts.

This functionality runs in a loop until 6am on 6th February 2016. This is significant given the transfers are believed to have occurred in the two days prior to this date. The tool was custom made for this job, and shows a significant level of knowledge of SWIFT Alliance Access software as well as good malware coding skills.

Malware config and logging

When run, the malware decrypts the contents of its configuration file, using the RC4 key:

4e 38 1f a7 7f 08 cc aa 0d 56 ed ef f9 ed 08 ef

This configuration is located in the following directory on the victim device:

[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\gpca.dat

The configuration file contains a list of transaction IDs, some additional environment information, and the following IP address to be used for command-and-control (C&C):

196.202.103.174

The sample also uses the following file for logging:

[ROOT_DRIVE]:\Users\Administrator\AppData\Local\Allians\recas.dat

Module patching

The malware enumerates all processes, and if a process has the module liboradb.dll loaded in it, it will patch 2 bytes in its memory at a specific offset. The patch will replace 2 bytes 0x75 and 0x04 with the bytes 0x90 and 0x90.

These two bytes are the JNZ opcode, briefly explained as 'if the result of the previous comparison operation is not zero, then jump into the address that follows this instruction, plus 4 bytes'.

Essentially, this opcode is a conditional jump instruction that follows some important check, such as a key validity check or authorisation success check.

The patch will replace this 2-byte conditional jump with 2 'do-nothing' (NOP) instructions, effectively forcing the host application to believe that the failed check has in fact succeeded.

It parses the messages, looking for strings defined in gpca.dat. We expect these will be unique identifiers that identify malicious transactions initiated by the attackers. If present, it then attempts to extract a MESG_TRN_REF and MESG_SENDER_SWIFT_ADDRESS from that same message by looking for the following hard coded strings:

The malware will use this extracted data to form valid SQL statements. It attempts to retrieve the SWIFT unique message ID (MESG_S_UMID) that corresponds to the transfer reference and sender address retrieved earlier:

SELECT MESG_S_UMID FROM SAAOWNER.MESG_%s WHERE MESG_SENDER_SWIFT_ADDRESS LIKE '%%%s%%' AND MESG_TRN_REF LIKE '%%%s%%';

The MESG_S_UMID is then passed to DELETE statements, deleting the transaction from the local database.

Login monitoring

After start up the malware falls into a loop where it constantly checks for the journal record that contains the "Login" string in it:

SELECT * FROM (SELECT JRNL_DISPLAY_TEXT, JRNL_DATE_TIME FROM SAAOWNER.JRNL_%s WHERE JRNL_DISPLAY_TEXT LIKE '%%LT BBHOBDDHA: Log%%' ORDER BY JRNL_DATE_TIME DESC) A WHERE ROWNUM = 1;

NOTE: ‘BBHOBDDH’ is the SWIFT code for the Bangladesh Bank in Dhaka.

If it fails to find the "Login" record, it falls asleep for 5 seconds and then tries again. Once the "Login" record is found, the malware sends a GET request to the remote C&C.

The GET request has the format:

[C&C_server]/al?[data]

The malware notifies the remote C&C each hour of events, sending "---O" if the "Login" (open) event occurred, "---C" in case "Logout" (close) event occurred, or "---N" if neither of the events occurred, e.g.:

Printer manipulation

In order to hide the fraudulent transactions carried out by the attacker(s), the database/message manipulations are not sufficient. SWIFT network also generates confirmation messages, and these messages are sent by the software for printing. If the fraudulent transaction confirmations are printed out, the banking officials can spot an anomaly and then respond appropriately to stop such transactions from happening.

Hence, the malware also intercepts the confirmation SWIFT messages and then sends for printing the 'doctored' (manipulated) copies of such messages in order to cover up the fraudulent transactions.

To achieve that, the SWIFT messages the malware locates are read, parsed, and converted into PRT files that describe the text in Printer Command Language (PCL).

These temporary PRT files are then submitted for printing by using another executable file called nroff.exe, a legitimate tool from the SWIFT software suite.

The PCL language used specifies the printer model, which is "HP LaserJet 400 M401":

Once sent for printing, the PRT files are then overwritten with '0's (reliably deleted).

CONCLUSIONS

The analysed sample allows a glimpse into the toolkit of one of the team in well-planned bank heist. Many pieces of the puzzle are still missing though: how the attackers sent the fraudulent transfers; how the malware was implanted; and crucially, who was behind this.

This malware was written bespoke for attacking a specific victim infrastructure, but the general tools, techniques and procedures used in the attack may allow the gang to strike again. All financial institutions who run SWIFT Alliance Access and similar systems should be seriously reviewing their security now to make sure they too are not exposed.

This attacker put significant effort into deleting evidence of their activities, subverting normal business processes to remain undetected and hampering the response from the victim. The wider lesson learned here may be that criminals are conducting more and more sophisticated attacks against victim organisations, particularly in the area of network intrusions (which has traditionally been the domain of the ‘APT’ actor). As the threat evolves, businesses and other network owners need to ensure they are prepared to keep up with the evolving challenge of securing critical systems.