Just as we thought that automated transfer systems (ATS) used in SpyEye and Zeus malware families were becoming outdated and less innovative since the discovery of Operation High Roller earlier this year, we have discovered a newly emerging attack targeting the European SEPA payments network.
In the past we have seen very rudimentary code (similar to dynamic transaction modification) designed to manipulate an outgoing SEPA payment that the victim intended to make; but we had not yet seen a specialized attack combining elements from Operation High Roller to create a sophisticated automated attack. Fraudsters target the SEPA payments channel because it brings many benefits to cross-border transactions: It simplifies the process for the bank, making this a rich target. Typically in these organized fraud campaigns we see a lot of mule activity in countries other than the nation hosting the victim’s bank; thus it makes sense to initiate a SEPA payment instead of a typical wire transaction.
SEPA is also very similar to the Automated Clearing House (ACH) network based in the United States and operates in a similar manner. In the case of the attacks we discovered, fraudsters initiate SEPA credit transfers via the ATS, which essentially sends a withdrawal request to the victim’s account to credit to a mule’s account.
Typically these ATS systems have targeted the wire networks of banks around the world and have been the preferred choice. This was the case with the attacks we covered earlier this year with Guardian Analytics, dubbed Operation High Roller. This technique of using an ATS to remove the human element has been around for many years. Now, let’s highlight the differences in this campaign targeting the SEPA network that is in some cases still gaining ground among financial institutions in Europe.
The Basics
The latest attack targets the German banking industry with a targeted ATS designed with SEPA in mind. The malicious “webinjects” target two German banks with a specially crafted JavaScript payload deployed to about a dozen of their online banking customers that have SEPA as an option, keeping this attack very targeted in nature.
The targeted nature of such malware tends remain undetected for a time. Thus, these campaigns are hard to discover because they infect only dozens of customers, rather than hundreds or more.
The transaction server used in this attack is hosted in Moscow and hosts a separate control panel for each of the targeted banks. Although the control panel isn’t sophisticated, the machinery that acts behind the scenes is complex.
This control panel doesn’t have much functionality, other than showing recent transfers and a link to the log file. It can also add a drop account and save that to a database.
Furthermore, the fraudsters have locked access to the log files for one of the targeted banks. However, they left access to a hidden directory that contains log data and other interesting information that helped us to gain insight into this attack. The webinjects have variables that specify the transaction ranges that the ATS system would use when making a transaction.
The fraudsters included a variables section that defines the elements that the ATS code can use. They elements do not have a fixed value to begin. We suspect that this can be updated when required.
It’s interesting that the system is hard coded to allow up to a maximum of €100,000 for a single SEPA transaction and a minimum of €1,000. The system is designed to choose an account for withdrawing funds given its balance, very similar to the operation of older European ATS.
Several interesting functions indicate that this is not some old European ATS reused to target SEPA, rather new code created and deployed to target a specific payments network.
Much of the framework resembles hybrid attacks that combine both server-side elements and client-side elements; this attack would be considered a hybrid.
Key functions:
- Hiding security alerts
- Advanced transaction searching and replacement specific to the bank’s processing of SEPA transactions
- Information sent to the transaction server to enable it to send a SEPA transfer to a given mule account
We found that the log entries are recorded with the device used to initiate the transaction and not the IP of the victim. Thus we determined that the transactions were originating from the server in Moscow. For one of the banks the directory structure was open to view, so we were able to gather further intelligence and determine the estimated impact. For one of the financial institutions targeted, we estimated from the log files we retrieved that €61,000 in attempted SEPA transactions were made to mule accounts. Some of the accounts had more than €50,000 as the standing account balances.
Conclusion
Although many of the basic threat techniques haven’t changed much, new ways of targeting a financial institution’s online channel continue to grow. The fraudsters are looking for different angles to exploit: these can be anything from the processing times in ACH payments that allow them to get funds to mules quickly, to the lack of two-factor authentication associated with outgoing wires. In this case, the fraudsters have evolved from automated wire transactions to different types of payment channels.
We don’t expect Operation High Roller activity to disappear anytime soon, so it’s important that we stay vigilant for these attacks.