UPD2. According to the Central Bank in 2017, 339.5 mln. Rubles were stolen. It is not difficult to guess that we are talking about Globex. The
review of FinCERT says: “The Bank of Russia sent information on one successful attack on the workplace of the SWIFT system operator. The volume of unauthorized operations as a result of this attack amounted to 339.5 million rubles. ”
UPD. Bank victim - Globex. The size of the stolen is calculated in tens of millions of rubles.
One of the Russian banks was the victim of a cyber attack aimed at stealing money through the international interbank payment system SWIFT. About the attack it is known that it was made on December 15. However, the name of the bank and the amount of damage have not yet been announced. The development of the attack, allegedly organized by the Cobalt group, began with the distribution of malware several weeks before the incident. Moreover, according to the deputy head of the Central Security and Data Protection Directorate of the Central Bank Artem Sychev, hackers gained wide access to the infrastructure and could use other withdrawal channels. However, they were interested in withdrawing funds to a foreign bank, so the goal of hackers was access to SWIFT.
According to SWIFT, there is no evidence that unauthorized access occurred. This means that most likely, control over the account of the SWIFT operator was obtained. The story already knows several similar cases with banks from different countries, including the sensational
case with the Central Bank of Bangladesh, where hackers managed to steal the information necessary for authorization during transactions. Then they managed to steal $ 81 million, and only tried to withdraw money with a total amount of $ 951 million. A similar attack was made at the end of 2015 on the Vietnamese bank Tien Phon Bank, but then the bank blocked operations for $ 1 million in time. And in early 2015, $ 9 was stolen million from Ecuadorian Banco del Austro. In the summer of 2016, $ 10 million was stolen from a Ukrainian bank. Each time, attackers manage to gain access to the SWIFT system by overcoming the protective barriers implemented in banks.
')
I am a little aware of the activities of SWIFT and some banks, since for several banks I have already configured two-factor authentication for access to the SWIFT interfaces. Therefore, I will tell you what I see myself. After the largest embezzlement, which occurred just at the Central Bank of Bangladesh, SWIFT’s rather stable course was outlined to improve the security of access to SWIFT networks and its messaging services. Almost immediately, one of the requirements for further certification, allowing the use of SWIFT, was the requirement of two-factor authentication. This measure should stop intruders who managed to intercept the operator's password. And at the beginning it was enough for banks to report that they undertook to implement two-factor authentication. Some participants, whose active certification expired not soon, decided to postpone any actions.
Meanwhile, in 2017, SWIFT developed a Customer Security Program (Customer Security Program) and documented organizational and technical recommendations on information security. Security measures include protection of physical access, separation of powers, regular updates, restriction of access and, of course, protection of user accounts. Now financial institutions must first carry out a self-assessment, and later, I hope, an external audit for compliance with new requirements.
For about a year, SWIFT has its own implementation of two-factor authentication using one-time codes. The open standard OATH TOTP was taken as the basis, that is, one-time codes exist in their own time window. The secret seed is displayed on the monitor of the operator during registration as a QR code by analogy with Google Authenticator. By the way, you can use any mobile application that supports the TOTP standard, including the same Google Authenticator, as a generator. My opinion is that SWIFT offers such a basic solution. But in their implementation there are pitfalls. To begin with, the QR code itself, which contains the main secret, is transmitted to the operator’s PC and displayed on the screen, which means it can be intercepted or overseen. But the bigger problem is that SWIFT servers are usually (and this is also a recommendation) isolated from the local network and simply do not have access to NTP servers - time sources that are so necessary for TOTP to work correctly. As a result, tokens can be out of sync at the most unpredictable moment. Some information security services, for example, prefer to use one-time password hardware generators, rather than smart phones. Such a requirement is incompatible with what SWIFT offers. There is a solution proposed by SWIFT and other shortcomings, due to which some financial organizations choose a third-party solution, but, again, this is still better than nothing. In any case, everything described speaks of SWIFT attempts to counter existing threats, rather than bury its head in the sand.
I note that now two-factor authentication is required not only for the operator’s account, but also for other services in a secure SWIFT network, for example, RDP or SSH access to servers.
It is not known whether the infrastructure of the bank that was the victim of the latest attack corresponded to the SWIFT recommendations, but I guess not. Judging by the information available in the media, the Central Bank also made recommendations to this bank to improve security, but the details are unlikely to be known to the general public.