Financial cyber fraud most often affects ordinary people, bank clients, but financial institutions themselves also experience problems as a result. Everyone suffers from the fact that user devices are easier to attack than banking infrastructure. But there are exceptions: the Carbanak campaign discovered by our experts last year , recent attacks by Metel, GCMan, and the Carbanak 2.0 campaign, which is more focused on (large) clients. Let's add to this the high-tech robbery of the central bank of the Republic of Bangladesh, which occurred in February of this year. Definitely, such attacks require significantly more skills and experience than fraud with user wallets, but you can hit a bigger jackpot, if possible (or go to jail for a longer time, depending on your luck).
This week, the story of the bank robbery continued: the technical details of the attack became known. It turned out that the robbers directly manipulated the software of the international payment system SWIFT. That is, the point is not only in the vulnerability of the infrastructure of a particular bank: all large financial organizations are susceptible to such an attack to one degree or another. We will return to technology later; this story is worth telling from the beginning.
So, with technology alone, even the coolest one, hackers wouldn’t get far: the theft of tens of millions of dollars would be noticed quickly in any case. The attack took place sometime between February 4 and 5, just before the weekend (Friday and Saturday in Bangladesh). In total, 32 transactions were carried out totaling nearly a billion dollars. Of these, 30 transactions were identified and blocked - despite the holiday. Two transfers, for amounts of $21 million and $80 million respectively, to Sri Lanka and the Philippines, were successful.
The transfer to Sri Lanka was later returned thanks to a banal typo. While directing funds to the account of a local non-profit organization, the organizers of the attack made a mistake in the word “fund” (fandation instead of foundation), and the German Deutsche Bank, which served as an intermediary, stopped the transaction “until clarification”. Everything worked out in the Philippines. Bangladesh Bank notified local bank RCBC about the fraud, but while the attack itself was made possible by Muslim holidays, the Philippine bank's employees were prevented from taking action on time by Chinese New Year. When everyone finally returned to work, someone had already withdrawn $58.15 million from the account using false documents. Wondering what the process of withdrawing $58 million from a bank account looks like?
Details of the attack have only recently become known. On April 22, local police shared the data, and according to officials, security at the bank was... not very good. With physical security, everything was not bad: all transactions with the SWIFT system were carried out from a separate and, apparently, carefully guarded room. Reports of all electronic transactions were required to be printed.
At the network level, SWIFT's operations were either poorly isolated or not at all, judging by the police's meager statements. They mentioned 10-dollar used switches and the lack of a firewall (apparently between the SWIFT infrastructure and everything else, including the Internet). The police are inclined to blame both the bank itself and representatives of the international payment system: the latter suddenly learned that SWIFT transactions were not protected when it was already too late. It is quite expected that the bank, in principle, could not understand how the leak occurred ( and what it even was ) until they invited experts to analyze it. By the way, this is the difference between the presence of protection systems and their absence (or incorrect implementation). Even a protected system can be hacked, but in an unprotected one you can also cover your tracks in such a way as to make further investigation as difficult as possible.
Well, now let's move on to technology. A detailed analysis of some of the attack tools was carried out by BAE Systems, and it was then that a direct attack on specialized software of the SWIFT system was revealed. The robbers could have acted differently: to seize control of a computer connected to the payment system and then make transactions manually, but they took a more complex and reliable route. The malicious code intercepted messages from the SWIFT system, looked for predetermined sequences of characters in them, and, in general, carried out reconnaissance.
To attack, hackers replaced standard modules of the payment system and disabled some checks. An indicative example is also given: to disable one of the checks, which, presumably, a fraudulent transfer could not pass, it turned out to be enough to change two bytes, removing the conditional jump from the code.
It also turned out to be easy to cheat the additional security measure of mandatory printing of transactions on a printer. For printing, the system generates files with the necessary information, and the malware simply filled these files with zeros, that is, it not only blocked printing, but also erased the information in digital form.
My colleagues from the Threatpost website asked SWIFT for comment and received a response very similar to the usual reaction of financial institutions to cases of fraud among ordinary customers.
I mean, the attack did not reveal vulnerabilities in the SWIFT infrastructure, we are talking about an unsafe environment on the client’s side, in short, the problem is not on our side . And they are right, but this is the kind of rightness that will not help anyone. I don’t think there will be many such incidents, and most likely conclusions have already been drawn from this whole story: there are not many places where you can steal a billion in one fell swoop. But “consumer” cyber fraud, attacks on various client banks for mere mortals, small and large businesses, will increase. It’s more difficult to fight him, but it’s necessary.
An unusual ransomware Trojan for Android with exploits included
News. Blue Coat Research.
Ransomware for regular computers makes full use of exploits, although they are not limited to them. But on mobile devices, until recently, the situation looked different: for the initial infection, attackers rely more on social engineering methods. But the threat landscape for Android is evolving in the same spiral as attacks on PCs, just much faster. This means that the emergence of malware for smartphones and tablets that are installed without the owner’s help is inevitable. And they did appear. A curious example of such a ransomware Trojan was analyzed by specialists from the Blue Coat company. The ransomware, known as Cyber.Police, attacks devices with Android versions 4.x, and is precisely a ransomware, but not an encryptor. The data is not taken hostage, the device is simply locked and a $200 ransom is demandedby greyhound puppies using iTunes payment cards.
Much more interesting is how the ransomware gets onto the device. Two exploits are used for this. The first exploit, lbxslt, allows you to seize control of a device after viewing a site with an infected script in a standard browser. This exploit, along with several others, was stolen from Hacking Team last year. The second, known as Towelroot, exploits a vulnerability in the Linux kernel before 3.4.15 ( CVE ) and is essentially a modification of a once popular utility for obtaining root rights. At this stage, a malicious application, the Trojan itself, is installed, suppressing standard messages about the appearance of a new app in the system.
According to Google itself, more than half of devices still run various versions of Android 4.x. Blue Coat researcher Andrew Brandt, in an interview with Threatpost, compared this version of Android to Windows XP - perceived as an outdated system, not supported by most vendors and extremely vulnerable. Meanwhile, Windows XP was released 15 years ago, and the latest version of Android 4.x (KitKat) was released 2.5 years ago. Progress is moving by leaps and bounds, but in this context it is somehow not at all inspiring.
FIN6 group attacks POS terminals, successfully steals 20 million credit card data
News. FireEye Research.
FireEye's research into the activities of the group known as FIN6 does not reveal America: yes, they hack cash registers and steal money. Such operations develop according to the scenario of a targeted attack: appropriate master keys are selected for the victim’s infrastructure, and then the malware finds specialized computers and begins intercepting data. The story is interesting in context. After similar attacks on the largest American retail chains (the Target chain stood out the most), the US began a long and painful transition to the chip card payment system generally accepted in Europe (and here too).
EMV cards are much more secure and are not necessarily susceptible to attacks like FIN6 (although they are possible). So, in this regard, US-oriented cybercrime started a party on a sinking ship. Companies that have implemented a chip-and-pin system report a noticeable decrease in the number of fraud-related incidents, but latecomers report an average increase of 11%. Since consumers are not in the habit of refusing to make purchases in places where they still scan the magnetic stripe on credit cards, it turns out that this temporary transition period for US residents and visitors will be more dangerous than before or after. However, the recommendation to use disposable cards for payments while traveling is unlikely to be canceled even when absolutely everyone switches to chipped credit cards.
What else happened:
Windows built-in program Regsvr32 can be used to download and run arbitrary code bypassing security systems, in particular AppLocker. Fortunately, this is still a Proof of Concept from a researcher, and technically it cannot even be called a vulnerability, rather the use of standard system tools in an unnatural way.
Antiquities:
“Astra-976”
A very dangerous resident virus, encrypted, written to the COM files of the current directory when the infected file is started and then to all COM files launched for execution. If the system clock shows 17 minutes when the file starts, the virus encrypts (XOR 55h) the disk partition table in the MBR of the hard drive. Traces int21h. Contains the lines: "© AsTrA, 1991", "(2)".
Quote from the book “Computer Viruses in MS-DOS” by Evgeniy Kaspersky. 1992 Page 26.
Disclaimer: This column reflects only the personal opinion of its author. It may or may not coincide with the position of Kaspersky Lab. It depends on your luck.
This week, the story of the bank robbery continued: the technical details of the attack became known. It turned out that the robbers directly manipulated the software of the international payment system SWIFT. That is, the point is not only in the vulnerability of the infrastructure of a particular bank: all large financial organizations are susceptible to such an attack to one degree or another. We will return to technology later; this story is worth telling from the beginning.
So, with technology alone, even the coolest one, hackers wouldn’t get far: the theft of tens of millions of dollars would be noticed quickly in any case. The attack took place sometime between February 4 and 5, just before the weekend (Friday and Saturday in Bangladesh). In total, 32 transactions were carried out totaling nearly a billion dollars. Of these, 30 transactions were identified and blocked - despite the holiday. Two transfers, for amounts of $21 million and $80 million respectively, to Sri Lanka and the Philippines, were successful.
The transfer to Sri Lanka was later returned thanks to a banal typo. While directing funds to the account of a local non-profit organization, the organizers of the attack made a mistake in the word “fund” (fandation instead of foundation), and the German Deutsche Bank, which served as an intermediary, stopped the transaction “until clarification”. Everything worked out in the Philippines. Bangladesh Bank notified local bank RCBC about the fraud, but while the attack itself was made possible by Muslim holidays, the Philippine bank's employees were prevented from taking action on time by Chinese New Year. When everyone finally returned to work, someone had already withdrawn $58.15 million from the account using false documents. Wondering what the process of withdrawing $58 million from a bank account looks like?
Details of the attack have only recently become known. On April 22, local police shared the data, and according to officials, security at the bank was... not very good. With physical security, everything was not bad: all transactions with the SWIFT system were carried out from a separate and, apparently, carefully guarded room. Reports of all electronic transactions were required to be printed.
At the network level, SWIFT's operations were either poorly isolated or not at all, judging by the police's meager statements. They mentioned 10-dollar used switches and the lack of a firewall (apparently between the SWIFT infrastructure and everything else, including the Internet). The police are inclined to blame both the bank itself and representatives of the international payment system: the latter suddenly learned that SWIFT transactions were not protected when it was already too late. It is quite expected that the bank, in principle, could not understand how the leak occurred ( and what it even was ) until they invited experts to analyze it. By the way, this is the difference between the presence of protection systems and their absence (or incorrect implementation). Even a protected system can be hacked, but in an unprotected one you can also cover your tracks in such a way as to make further investigation as difficult as possible.
Well, now let's move on to technology. A detailed analysis of some of the attack tools was carried out by BAE Systems, and it was then that a direct attack on specialized software of the SWIFT system was revealed. The robbers could have acted differently: to seize control of a computer connected to the payment system and then make transactions manually, but they took a more complex and reliable route. The malicious code intercepted messages from the SWIFT system, looked for predetermined sequences of characters in them, and, in general, carried out reconnaissance.
To attack, hackers replaced standard modules of the payment system and disabled some checks. An indicative example is also given: to disable one of the checks, which, presumably, a fraudulent transfer could not pass, it turned out to be enough to change two bytes, removing the conditional jump from the code.
It also turned out to be easy to cheat the additional security measure of mandatory printing of transactions on a printer. For printing, the system generates files with the necessary information, and the malware simply filled these files with zeros, that is, it not only blocked printing, but also erased the information in digital form.
My colleagues from the Threatpost website asked SWIFT for comment and received a response very similar to the usual reaction of financial institutions to cases of fraud among ordinary customers.
I mean, the attack did not reveal vulnerabilities in the SWIFT infrastructure, we are talking about an unsafe environment on the client’s side, in short, the problem is not on our side . And they are right, but this is the kind of rightness that will not help anyone. I don’t think there will be many such incidents, and most likely conclusions have already been drawn from this whole story: there are not many places where you can steal a billion in one fell swoop. But “consumer” cyber fraud, attacks on various client banks for mere mortals, small and large businesses, will increase. It’s more difficult to fight him, but it’s necessary.
An unusual ransomware Trojan for Android with exploits included
News. Blue Coat Research.
Ransomware for regular computers makes full use of exploits, although they are not limited to them. But on mobile devices, until recently, the situation looked different: for the initial infection, attackers rely more on social engineering methods. But the threat landscape for Android is evolving in the same spiral as attacks on PCs, just much faster. This means that the emergence of malware for smartphones and tablets that are installed without the owner’s help is inevitable. And they did appear. A curious example of such a ransomware Trojan was analyzed by specialists from the Blue Coat company. The ransomware, known as Cyber.Police, attacks devices with Android versions 4.x, and is precisely a ransomware, but not an encryptor. The data is not taken hostage, the device is simply locked and a $200 ransom is demanded
Much more interesting is how the ransomware gets onto the device. Two exploits are used for this. The first exploit, lbxslt, allows you to seize control of a device after viewing a site with an infected script in a standard browser. This exploit, along with several others, was stolen from Hacking Team last year. The second, known as Towelroot, exploits a vulnerability in the Linux kernel before 3.4.15 ( CVE ) and is essentially a modification of a once popular utility for obtaining root rights. At this stage, a malicious application, the Trojan itself, is installed, suppressing standard messages about the appearance of a new app in the system.
According to Google itself, more than half of devices still run various versions of Android 4.x. Blue Coat researcher Andrew Brandt, in an interview with Threatpost, compared this version of Android to Windows XP - perceived as an outdated system, not supported by most vendors and extremely vulnerable. Meanwhile, Windows XP was released 15 years ago, and the latest version of Android 4.x (KitKat) was released 2.5 years ago. Progress is moving by leaps and bounds, but in this context it is somehow not at all inspiring.
FIN6 group attacks POS terminals, successfully steals 20 million credit card data
News. FireEye Research.
FireEye's research into the activities of the group known as FIN6 does not reveal America: yes, they hack cash registers and steal money. Such operations develop according to the scenario of a targeted attack: appropriate master keys are selected for the victim’s infrastructure, and then the malware finds specialized computers and begins intercepting data. The story is interesting in context. After similar attacks on the largest American retail chains (the Target chain stood out the most), the US began a long and painful transition to the chip card payment system generally accepted in Europe (and here too).
EMV cards are much more secure and are not necessarily susceptible to attacks like FIN6 (although they are possible). So, in this regard, US-oriented cybercrime started a party on a sinking ship. Companies that have implemented a chip-and-pin system report a noticeable decrease in the number of fraud-related incidents, but latecomers report an average increase of 11%. Since consumers are not in the habit of refusing to make purchases in places where they still scan the magnetic stripe on credit cards, it turns out that this temporary transition period for US residents and visitors will be more dangerous than before or after. However, the recommendation to use disposable cards for payments while traveling is unlikely to be canceled even when absolutely everyone switches to chipped credit cards.
What else happened:
Windows built-in program Regsvr32 can be used to download and run arbitrary code bypassing security systems, in particular AppLocker. Fortunately, this is still a Proof of Concept from a researcher, and technically it cannot even be called a vulnerability, rather the use of standard system tools in an unnatural way.
“Astra-976”
A very dangerous resident virus, encrypted, written to the COM files of the current directory when the infected file is started and then to all COM files launched for execution. If the system clock shows 17 minutes when the file starts, the virus encrypts (XOR 55h) the disk partition table in the MBR of the hard drive. Traces int21h. Contains the lines: "© AsTrA, 1991", "(2)".
Quote from the book “Computer Viruses in MS-DOS” by Evgeniy Kaspersky. 1992 Page 26.
Disclaimer: This column reflects only the personal opinion of its author. It may or may not coincide with the position of Kaspersky Lab. It depends on your luck.
