SWIFT, the global financial messaging system, issued an alert message regarding new customer’s compromised environments by sophisticated adaptive attackers in an attempt to send fraudulent payment instructions. This resulted in February this year when a successful attack of over $1 billion transactions was made from Bangladesh’s central bank resulted in $81 million in unrecoverable losses. This added to several other SWIFT heists disclosed and suspected.
The level of sophistication and persistence used in these attacks suggestsit’s connected to previous high-yielding actors such as the Carabanak banking fraud team and the Sony hackers. In such a persistent and targeted attack where the victim is well-selected for security weaknesses and high potential gains, the attackers spent a lot of effort examining the victim to penetrating their premises and keeping a stealth hold inside the bank. For a hacker, much importance was given to choosing the right time to act, so the attack passed as legitimate by the SWIFT system as well as advanced targeted malware used to cover the tracks of the transfer from the victim to avoid cancellation.
Once the fraud attempt was detected, a forensic investigation took place with professional consultants to connect the puzzle pieces to discover the penetration vector. These consultants also determined the level of damage within the system. This was done in an attempt to avoid future cases and making sure the attack was not still persistent. The Bangladesh central bank was reported to have turned down a proposal to extend such investigation and sources were quoted to say the bank had paid about $280K for 700 hours of work.
SandBlast Agent swift forensic investigation:Our malware researchers Ofer Caspi and Michael Kajiloti helped in creating a similar environment as the one compromised. In this “duplicated environment,” we installed SandBlast Agent.
We ran the malware reported to be used to cover up the fraudulent SWIFT transfers.
This resulted in the following five easy to understand reports showing the cover operation and the potential damage done:
As a first step in looking at an automated forensics report (below), we want to understand what is the impact of this attack. For that, we can look either at the “Business Impact” pane or the “Business Impact” box in the report summary.In this case, there is a list of transaction tracks that were actually tampered by the intruder together with the exact time where they were made.
The amounts inside the document were actually, making the attacker’s transactions look regular in the eyes of the local branch.
This will automatically narrow down our damage assessment to those transactions.
Looking at the “remediation” pane, we can see the malware as it was discovered and deleted by SandBlast. SandBlast was the only piece of software that was actually “introduced” to the system by the attacker.
When looking at the execution tree below, we immediately see that for most of the attack, the attacker was actually exploiting tools that are already installed in the system (marked with a gray node). Some of the tools belong to the windows operating system (like cmd.exe), but others belong to the specific installation like “sqlplus.exe” and the SWIFT process, showing clearly how well informed the attacker is regarding the specific network and computer system he is attacking.
In a targeted attack such as this one, this knowledge can come either from a very long term recon effort or just from deep insider information that was provided to the attacker.
We also see how well the attacker knows the system by the persistent connections to the database installed in it, allowing them to run pre-defined queries to find the relevant transactions, using the regular sqlplus.exe tool, and successfully connecting as sysdba with no extra authentication.
In the same way, we can see him injecting the SWIFT process below (Here named swift_pe.exe) to change this course of operation, knowing the exact binary form to inject.
The attacker’s module also accesses the printer, pauses printer operations (presumably so the attackers’ transactions do not print out any operation). The printer has to be a specific one that the attacker is expecting to be there.
This way, the attacker can delete all the tracks of the specific transaction that he has done from the local branch where they actually take place. By the time the transactions are discovered, no tracks will be left.
ConclusionBefore our critical organization assets are attacked, we need to be prepared with a quick and automated damage assessment and a fast reaction to stop the attack spread. Then we should move to fight back by removing the attacker’s persistency in the system.
The cost of dealing with such an aftermath when caught by surprise is huge, and investigations don’t always lead to conclusions on the damage and infiltration vector.
This was a glimpse into an advanced targeted attack that wasn’t detected by anti-viruses.
We are seeing such sophisticated attacks rising in the banking industry, and we need to act now to be ready.