Preface: this article is about theft of funds from user accounts in payment systems, online banking, etc.

It is no secret that payment and other financial services have very strict requirements when it comes to security. To that end, comprehensive protection measures are applied both to the system itself and user accounts. To prevent the possibility of hacking and destroying the system, various means are used. The following are a few of them:

Various firewalls; currently WAFs (Web Application Firewall) are very popular;

Duplicating the system’s key elements;

Data replication; tokenization of various system’s operation stages;

Hardware encryption with HSM (Hardware Security Modules).

In terms of protection of a user’s account and their transactions, regular password protection and other security methods are used:

IP address based access restriction;

Code cards, payment passwords, PINs;

Biometrics;

User environment verification.

And, of course, two-factor authentication tools, electronic digital signature (EDS) and contactless tokens — one-time password (OTP) generators.

I always thought that two-factor authentication is a panacea in the case of any possible vulnerabilities in the user authentication process. Following the latest trends in the sphere of security, as we thought at the moment, we recommended that our users should use hardware tokens (TOTP, which is called “time-based token”) from the world’s leading providers or Google’s software Authenticator. The abovementioned tokens were used for payment transaction verification, and in the case of users that did not have those tokens we required that a one-time password from an SMS message be entered. We believed that such protection was absolutely reliable, but if that was the case, this article would not have been written…

I will not be beating about the bush and get straight down to business. One day, the customer support service received a ticket from a very angry user complaining that his account had been completely “drained”, i.e. all the funds had been withdrawn from the account. After our preliminary investigation, we saw from the transaction history that the funds were withdrawn by making several regular transactions to different accounts by the user himself. Prior to that, there was no connection (no transactions performed) between the user and those accounts. After a more detailed and thorough data review and analysis, it turned out that the user became a victim of “automated transfer system” or “replacer” malware.

Below you will find a bit of theoretical knowledge gathered from various online sources:

Automated Transfer System is a web inject with an administrative panel that performs automated and coordinated actions in a victim’s account based on the account conditions/situation. This malware gathers information on the account details, sees what the account contains and sends the data to the administrative panel. The panel contains a table of “drops” and their statuses, notes, details of accounts to transfer funds to, and the amounts of funds to transfer so as to circumvent the limits and avoid raising suspicion. Based on automated rules or by means of manual coordination, the panel selects the “drop” and specifies it to the web inject. There are several alternative variants of how things may develop further:

Variant 1) the inject shows the user a pop-up window with a text that says something like this “Please wait while the data is being verified”, and in the meantime it secretly performs actions resulting in transferring funds to a drop account by “clicking” the required links in the account and filling out the forms required by the system. If a ТАН/OTP/PIN code and other details are required to complete the transfer, the automated transfer malware shows a fake page with a request to enter the code, but under a different (fraudulent) pretext. The account holder enters the required details on the fake page, and the malware uses the data to continue/complete the fraudulent transfer of funds.

Variant 2) the inject waits until the user wants to make a legitimate transaction for which the ТАН/OTP/PIN code will be required, but this code will be used to verify a fraudulent transaction to transfer money to a drop account.

After that, the account holder is allowed access to the account, where a replacer begins to work.

Replacer is software code used for the purpose of hiding the details of the money transfer made by the automated transfer system malware. In other words, balance replacement means hiding the transfer in the transfer history and other manipulations aimed at preventing the account holder from noticing the transfer made. In our case, the account holder sees a fake balance and a fake legitimate transaction.

In our system, there are various means of multi-level verification, for example, checking the balance against the total of the user’s transactions and comparing the balances in our system and external systems, as well as some other methods. All that did not help in this case because the transaction did not “materialize out of nowhere” — it looked like a totally normal legitimate transaction.

Of course, we had heard about different types of attacks, and we encounter various types of fraudulent activities, but we were truly amazed to discover what happened in this case. Even though the funds were “drained” from the user’s account, the company’s management made the decision to refund the victim part of the money lost to avoid negative consequences for the company’s reputation. The decision was also made partly due to the fact that the user was an honest customer with high turnovers, and — most importantly — as of the moment of the attack on his account, he had all the account security features we offered installed.

After some searching for information, we discovered that this method for circumventing two-factor authentication is well-known, and many leading providers offer solutions aimed at eliminating this vulnerability (data signing, CWYS (Confirm What You See)) — the solutions may be called by different names, but they are similar in their implementation. In essence, a one-time password is generated based not only on the secret key, time or counter, but also the key transaction details such as the transaction’s amount, currency and recipient. In this case, even if a fraudster captures the password, they will not be able to use it for their malicious purposes. Here you can find a detailed description. To implement this feature, we considered offers from several providers, and we made our choice.

So, for now we can breathe a sigh of relief… And, wait for new challenges to overcome.