First Bank, one of the largest banks in Taiwan, was paralyzed. The bank faced a large-scale attack: masked men simultaneously emptied three dozen ATMs worth $2 million. The police were at a loss: there were no signs of hacking or overhead skimmers on the ATM bodies. The attackers didn't even use bank cards.
How everything happened was recorded by video cameras: people in masks approached ATMs, called on their mobile phones - the ATM dispensed money, the criminals put it in backpacks and ran away. After such a large-scale raid, eight of the country's largest banks suspended cash withdrawals from 900 ATMs.
What First Bank encountered is called a logic attack. Its essence is that cybercriminals gain access to the bank’s local network and from there establish full control over ATMs. Remotely they receive a command to issue money. The hackers' accomplices—the “mules”—take the money and hand it over to the attack organizers. Thus, Cobalt, the most active and dangerous criminal group, attacked banks in two dozen countries around the world in less than a year.
Contactless attacks on ATMs are just one type of targeted attack on banks. In addition to ATM control systems, cybercriminals are trying to gain access to interbank transfer systems (SWIFT), payment gateways and card processing.
Let's take a closer look at the tactics of logical attacks on ATMs and methods of counteraction. This article is based on the Group-IB report on the activities of the Cobalt group, released in the fall of 2016. Some of this information is being published in the public domain for the first time.
Penetration
Cobalt penetrates the banking network through sending phishing emails with an exploit or an executable file in an archive with a password. For CIS banks, criminals sent attachments “Storage_agreement2016.zip” and “list of documents.doc.” For foreigners - “The rules for European banks.doc” and “Bitcoin ATM's.doc”.
Phishing emails were most often sent on behalf of the European Central Bank, ATM manufacturer Wincor Nixdorf or regional banks. It was not easy to recognize the substitution: the sender's address included their official domains. To send fake letters in June, the anonymous mailing system “YaPosylalka v.2.0.” was used. (another name for the service: “alexusMailer v2.0”), and later attackers began to use the capabilities of Cobalt Strike. In general, Cobalt Strike is a rich framework for conducting penetration tests, allowing you to deliver and manage a payload to the attacked computer.
This is what the letter on behalf of the European Central Bank looked like:
[IMG"]https://habrastorage.org/r/w1560/files/2e5/15b/1d3/2e515b1d3f0a4280b3cae3cf0786b702.png[/IMG]
The letters were sent from two servers with IP addresses 88.212.208.115 and 5.101.124.34. Both are located in Russia. We obtained some of the emails sent from these servers, examined the malicious attachments, found instances of malware associated with them, and checked where suspicious files were being downloaded at the time of the attack on Virus Total, an online scanner that checks for viruses and malware.
Here is an example of the results of its upload to Virus Total:
So we were able to establish a more complete list of attack targets, which included banks from Russia, Great Britain, the Netherlands, Spain, Romania, Poland, Estonia, Bulgaria, Belarus, Moldova, Georgia, Armenia, Kyrgyzstan and Malaysia. In the case of First Bank, hackers penetrated the bank's branch network in the UK and through it gained access to the central office network.
In addition to banks, letters were received by leasing and insurance companies that are part of the bank's group of companies. In some cases, such companies have common networks, which is what the attackers took advantage of.
Sticking to the system
After the malicious attachment was launched, the process of sticking to the system began:
1. The attachment contained malicious RTF documents that exploited the CVE-2015-1641 vulnerability. It used standard shellcode generated by penetration testing tools such as Metasploit and Cobalt Strike.
2. A payload called Beacon, included with Cobalt Strike, was loaded into RAM.
Interaction with the Cobalt Strike backend occurs through the creation of covert channels using DNS, HTTP, HTTPS protocols to prevent detection of network communication using standard IDS/IPS systems.
List of commands for Beacon:
3. If the exploit method did not work, the attackers resent a letter with a password-protected archive containing the same Beacon.
In any case, after launching the malicious attachment, Beacon was loaded only into RAM. This means that after the operating system was rebooted, the attackers lost control of that computer.
To ensure constant operation on the system, a special Beacon module was automatically triggered, which checked which applications were included in startup and replaced some of them with its own executable file with the same name.
In real attacks, we observed the replacement of files named iusb3mon. exe (Intel® USB 3.0 eXtensible Host Controller) and jusched.exe (Sun Java Update Scheduler). As a result of this change, services that were supposed to automatically launch legitimate programs launched malicious applications.
4. A library named crss was also copied into the same directory where the replaced legal executable files were located. dll. Each time the operating system started, the replaced applications loaded this library into memory. Its main task was to download the Beacon module from the Internet into RAM.
This ensured the viability of the main program. After each reboot of the operating system, the main module was removed. All the steps described above were performed automatically after the malicious attachment was launched. In case the infected computer was turned off or the operating system was reinstalled, it was necessary to establish constant access to the local network. To do this, it was necessary to increase privileges.
Obtaining privileges
To explore the bank's local network and gain access to isolated network segments and information systems, the attacker needs domain administrator rights.
Starting with Windows Server 2008, additional functionality was added to group policies - Group Policy Preferences (GPP). GPPs allow administrators to apply many policies: automatically assigning a network drive when a user logs into their computer, updating the name of the built-in administrator account, creating new users, making changes to the registry, etc.
Actions such as adding a local user, connecting a network drive or printer may require a password. When such policies are downloaded for use on an individual computer, they will do so along with the specified password. The password, encrypted using the AES-256 algorithm and additionally Base64 encoded, is stored in the GPP Groups.xml configuration file.
This XML file is not always created, but when, for example, the built-in administrator account is created or changed. The file is stored on the domain controller in a subdirectory of the SYSVOL directory and, like the directory itself, is accessible to any user in the domain.
Attackers use Groups.xml to extract the domain administrator password as follows:
1. After gaining access to the local network, they find the domain controllers that are specified in the computer settings.
2. On the domain controllers, they check for the presence of the SYSVOL directory and the Groups.xml file, which is available at the following path: “\\[server_name]\sysvol\[domain_name]\Policies\[group_policy_name]\Machine\Preferences\Groups\Groups. xml"
3. From the Groups.xml file, they extract the domain administrator login and password from the cpassword and userName fields.
Fragment of the Groups.xml file:
4. To obtain the password in clear text, attackers decode the password using Base64, receiving a string like 2412D5A8073B0B9EEF429FB6AF94B737C95E66B685409A1FD9C36509DF7D6166
- this is a password encrypted using AES-256.
5. The resulting encrypted password is decrypted using the key 4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b, published on the official Microsoft MSDN website.
6. Once the password is successfully decrypted, they gain access to the domain controller and using the method below, they can access the password of any account.
Another way to extract logins and passwords from the RAM of an infected computer was using the free tool Mimikatz. The source code for this utility is published on Githud, publicly available, and built into several penetration testing tools, including Cobalt Strike.
Consolidation on an infected computer/server
So, the attackers have at least one host with Beacon. They need to have access to many computers, including those that do not have Internet access. To do this, they built their own mini-network of infected computers on the bank’s local network, which could be controlled through a single Cobalt Strike console installed on a remote server and providing the ability to work together.
The whole process can be described as follows:
This scheme allowed criminals to build a fairly reliable mechanism for constant access to the local network of the attacked bank, while remaining as invisible as possible.
To expel attackers from the network, it is necessary to at least identify all hosts performing the master-node role and remove them from the network at the same time, otherwise criminals have a chance to restore operation within a few minutes.
Providing a backup access channel
After successfully compromising the local network and domain, attackers could use legitimate remote access channels, for example, connecting through terminal servers, or via VPN with administrator or regular user rights.
Even though Cobalt Strike has a built-in VNC remote access module, the attackers played it safe and downloaded a modified TeamViewer installer, a legitimate remote access tool. It was not possible to completely restore the installer, so we assume that the main difference from the official application is the hiding of the notification that a remote connection was made to the computer, as was the case in attacks by other criminal groups in Russia. The preparations are complete - the last stage remains - withdrawing money.
Gaining access to ATMs
After gaining control of the bank's internal network and securing backup access channels, criminals moved on to searching for network segments from which ATMs could be accessed and the workplaces of employees who were supposed to monitor ATMs.
Having gained access to a computer or server that allowed access to ATMs, the attackers used standard remote access tools used in a bank. Typically, this is the Microsoft Remote Desktop Protocol.
Once they had access to ATMs, they loaded them with special software that allowed them to manage cash dispensing.
ATM attack software
Once remote access to an ATM is gained, three files are downloaded to it:
Contents of the script del.bat
sdelete.exe -accepteula -p 32 d2.exe
sdelete.exe -accepteula -p 32 xtl.exe
sdelete.exe -accepteula -p 32 *.txt
sdelete.exe -accepteula -p 32 d2s.exe
del sdelete.exe
del del.bat
The source code of the program was not protected, which greatly simplifies its analysis and makes it possible to make adjustments to the logic of its operation. This means that the author of the malware did not plan to distribute it, but is most likely part of a group of attackers.
The malware allows you to interact with the ATM dispenser using the XFS API and issue commands to empty cash cassettes. It operates according to the arguments that must be passed at startup. There are 5 such arguments in total, and the value of each of them must be specified.
The command line arguments must be in the following order:
ServiceLogicalName - The name of the service used as an argument to the WFSOpen function (for example, "Cash Dispenser Module").
Cassettes Count - the total number of cassettes present on the device. The value must be in the range from 1 to 15.
Cassette Number —the number of the cassette from which cash should be dispensed. The value must be in the range from 1 to 15.
Banknotes Count - the number of banknotes that must be dispensed from the cassette. The value must be in the range from 1 to 60.
Dispenses Count - how many times cash dispensing must be repeated. The value must be in the range from 1 to 60.
All these values are indicated in the console by the operator who is connected to the ATM remotely.
If all arguments were passed correctly, a message is displayed showing the parameters according to which further actions will be performed.
Next, an array is filled in, each element of which corresponds to the cassette number in the device. The number of array elements must match the total number of cassettes. The value that each element of the array stores is the number of banknotes that need to be dispensed from the corresponding cassette. The numbering of array elements starts from 1.
During operation, the program receives data about the system time, and if it does not correspond to that specified in the program code, it terminates its work.
Next, the program performs a number of standard actions that must be done before the cash dispensing operation, and if all of them are completed successfully, the ATM issues bills to the mule. This operation will be repeated as many times as specified in the "Dispenses Count" argument.
Upon successful completion of each such operation, a file named “disp. txt", located in the same directory as the malware, the text string "Cassettes Count: Banknotes Count" is written, where "Cassettes Count" and "Banknotes Count" are the values of the corresponding arguments.
Two versions of such a program were discovered. One was named d2.exe, and the second was d2sleep. exe. The only difference between them was that the second one gave out cash with a short pause - 1 second.
After the ATM ran out of bills, the operator launched the SDelete program, which deleted used files using a special algorithm that did not allow information to be recovered. After this, the ATM rebooted.
In addition, operators disabled the internal servers of the bank from which attacks on ATMs were carried out using the MBRkiller malware, which deleted MBR (master boot record) records. All this greatly complicates the forensic investigation of the attack.
Attack on ATMs
On a conditional day, special people - mules - were sent to the ATMs. They had to keep in touch with their accomplices by telephone, who gave the command to withdraw money from the ATM. Messages with six-digit codes were found on the phones of the detained mules. Typically, such codes are sent by the organizer to activate the malware on a specific ATM.
After the money in the ATM ran out, the person re-contacted the partners and left. The empty ATM was rebooting.
Often mules enter a country on tourist visas specifically to carry out an attack and leave once the operation is over. A few days after the attacks on First Bank ATMs in Taipei, citizens of Latvia and Romania were detained. The remaining 13 suspects, including Russian citizens, managed to leave the island.
Increased attention was paid to the security of the criminal scheme itself. To prevent operators from using the program to attack other ATMs without involving the organizer, a launch time check is built into its code. If the system time of the attacked ATM does not match the month specified in the code, the commands will not be executed. In this case, the program will not generate errors, and, most likely, operators are not aware of such a built-in check.
After each successful cash dispensing operation, the program writes a special log (file named “disp.txt”) with information about the number of banknotes dispensed from each cassette. The operator transmits this log file to the organizer, who uses the received information to control the cash-out chain.
Connection with Buhtrap
While investigating Cobalt's logical attacks on Russian and European banks, we noticed that the mechanisms for delivering phishing emails and gaining access to the domain controller are identical to the methods previously used by the Buhtrap group. From August 2015 to January 2016, she stole more than 1.8 billion rubles from Russian bank accounts.
After people involved in cashing out stolen money for the Buhtrap group were detained in May 2016, thefts from bank accounts using the Trojan of the same name stopped, but the botnet continued to exist.
It can be assumed that at least some of the members of the Buhtrap group entered Cobalt or, what is no less likely, the backbone of Buhtrap simply switched to attacks on ATMs.
How to repel logical attacks
Logical attacks are gaining more and more popularity. The number of incidents will only increase. Carrying out an attack does not require expensive development of complex software - most tools are publicly available.
These recommendations will help prevent theft, but risks can only be minimized by being proactive using Threat intelligence data and using specialized solutions to detect targeted attacks.
Subscribers to our Threat Intelligence service learned about the tactics and mechanics of Cobalt attacks back in the summer of 2016. Our consultations helped several banks stop the attack in time, completely clean up the network and block attackers’ access to ATMs.
Group-IB knows everything about cybercrime, but they tell you the most interesting things.
How everything happened was recorded by video cameras: people in masks approached ATMs, called on their mobile phones - the ATM dispensed money, the criminals put it in backpacks and ran away. After such a large-scale raid, eight of the country's largest banks suspended cash withdrawals from 900 ATMs.
What First Bank encountered is called a logic attack. Its essence is that cybercriminals gain access to the bank’s local network and from there establish full control over ATMs. Remotely they receive a command to issue money. The hackers' accomplices—the “mules”—take the money and hand it over to the attack organizers. Thus, Cobalt, the most active and dangerous criminal group, attacked banks in two dozen countries around the world in less than a year.
Contactless attacks on ATMs are just one type of targeted attack on banks. In addition to ATM control systems, cybercriminals are trying to gain access to interbank transfer systems (SWIFT), payment gateways and card processing.
Let's take a closer look at the tactics of logical attacks on ATMs and methods of counteraction. This article is based on the Group-IB report on the activities of the Cobalt group, released in the fall of 2016. Some of this information is being published in the public domain for the first time.
Penetration
Cobalt penetrates the banking network through sending phishing emails with an exploit or an executable file in an archive with a password. For CIS banks, criminals sent attachments “Storage_agreement2016.zip” and “list of documents.doc.” For foreigners - “The rules for European banks.doc” and “Bitcoin ATM's.doc”.
Phishing emails were most often sent on behalf of the European Central Bank, ATM manufacturer Wincor Nixdorf or regional banks. It was not easy to recognize the substitution: the sender's address included their official domains. To send fake letters in June, the anonymous mailing system “YaPosylalka v.2.0.” was used. (another name for the service: “alexusMailer v2.0”), and later attackers began to use the capabilities of Cobalt Strike. In general, Cobalt Strike is a rich framework for conducting penetration tests, allowing you to deliver and manage a payload to the attacked computer.
This is what the letter on behalf of the European Central Bank looked like:
[IMG"]https://habrastorage.org/r/w1560/files/2e5/15b/1d3/2e515b1d3f0a4280b3cae3cf0786b702.png[/IMG]
The letters were sent from two servers with IP addresses 88.212.208.115 and 5.101.124.34. Both are located in Russia. We obtained some of the emails sent from these servers, examined the malicious attachments, found instances of malware associated with them, and checked where suspicious files were being downloaded at the time of the attack on Virus Total, an online scanner that checks for viruses and malware.
Here is an example of the results of its upload to Virus Total:
So we were able to establish a more complete list of attack targets, which included banks from Russia, Great Britain, the Netherlands, Spain, Romania, Poland, Estonia, Bulgaria, Belarus, Moldova, Georgia, Armenia, Kyrgyzstan and Malaysia. In the case of First Bank, hackers penetrated the bank's branch network in the UK and through it gained access to the central office network.
In addition to banks, letters were received by leasing and insurance companies that are part of the bank's group of companies. In some cases, such companies have common networks, which is what the attackers took advantage of.
Sticking to the system
After the malicious attachment was launched, the process of sticking to the system began:
1. The attachment contained malicious RTF documents that exploited the CVE-2015-1641 vulnerability. It used standard shellcode generated by penetration testing tools such as Metasploit and Cobalt Strike.
2. A payload called Beacon, included with Cobalt Strike, was loaded into RAM.
Interaction with the Cobalt Strike backend occurs through the creation of covert channels using DNS, HTTP, HTTPS protocols to prevent detection of network communication using standard IDS/IPS systems.
List of commands for Beacon:
3. If the exploit method did not work, the attackers resent a letter with a password-protected archive containing the same Beacon.
In any case, after launching the malicious attachment, Beacon was loaded only into RAM. This means that after the operating system was rebooted, the attackers lost control of that computer.
To ensure constant operation on the system, a special Beacon module was automatically triggered, which checked which applications were included in startup and replaced some of them with its own executable file with the same name.
In real attacks, we observed the replacement of files named iusb3mon. exe (Intel® USB 3.0 eXtensible Host Controller) and jusched.exe (Sun Java Update Scheduler). As a result of this change, services that were supposed to automatically launch legitimate programs launched malicious applications.
4. A library named crss was also copied into the same directory where the replaced legal executable files were located. dll. Each time the operating system started, the replaced applications loaded this library into memory. Its main task was to download the Beacon module from the Internet into RAM.
This ensured the viability of the main program. After each reboot of the operating system, the main module was removed. All the steps described above were performed automatically after the malicious attachment was launched. In case the infected computer was turned off or the operating system was reinstalled, it was necessary to establish constant access to the local network. To do this, it was necessary to increase privileges.
Obtaining privileges
To explore the bank's local network and gain access to isolated network segments and information systems, the attacker needs domain administrator rights.
Starting with Windows Server 2008, additional functionality was added to group policies - Group Policy Preferences (GPP). GPPs allow administrators to apply many policies: automatically assigning a network drive when a user logs into their computer, updating the name of the built-in administrator account, creating new users, making changes to the registry, etc.
Actions such as adding a local user, connecting a network drive or printer may require a password. When such policies are downloaded for use on an individual computer, they will do so along with the specified password. The password, encrypted using the AES-256 algorithm and additionally Base64 encoded, is stored in the GPP Groups.xml configuration file.
This XML file is not always created, but when, for example, the built-in administrator account is created or changed. The file is stored on the domain controller in a subdirectory of the SYSVOL directory and, like the directory itself, is accessible to any user in the domain.
Attackers use Groups.xml to extract the domain administrator password as follows:
1. After gaining access to the local network, they find the domain controllers that are specified in the computer settings.
2. On the domain controllers, they check for the presence of the SYSVOL directory and the Groups.xml file, which is available at the following path: “\\[server_name]\sysvol\[domain_name]\Policies\[group_policy_name]\Machine\Preferences\Groups\Groups. xml"
3. From the Groups.xml file, they extract the domain administrator login and password from the cpassword and userName fields.
Fragment of the Groups.xml file:
4. To obtain the password in clear text, attackers decode the password using Base64, receiving a string like 2412D5A8073B0B9EEF429FB6AF94B737C95E66B685409A1FD9C36509DF7D6166
- this is a password encrypted using AES-256.
5. The resulting encrypted password is decrypted using the key 4e9906e8fcb66cc9faf49310620ffee8f496e806cc057990209b09a433b66c1b, published on the official Microsoft MSDN website.
6. Once the password is successfully decrypted, they gain access to the domain controller and using the method below, they can access the password of any account.
Another way to extract logins and passwords from the RAM of an infected computer was using the free tool Mimikatz. The source code for this utility is published on Githud, publicly available, and built into several penetration testing tools, including Cobalt Strike.
Consolidation on an infected computer/server
So, the attackers have at least one host with Beacon. They need to have access to many computers, including those that do not have Internet access. To do this, they built their own mini-network of infected computers on the bank’s local network, which could be controlled through a single Cobalt Strike console installed on a remote server and providing the ability to work together.
The whole process can be described as follows:
- On hosts with Internet access, a version of Beacon was launched, which established a connection to a remote control server via a covert channel. To prevent detection of such network communication using standard IDS/IPS systems, DNS, HTTP, HTTPS protocols were used. There were few such hosts, and they provided the ability to interact with other hosts on the local network. Let's call them master-node .
- The bank's greatest interest is in isolated hosts that do not have access to the Internet. But even if access is allowed, creating a connection to a remote server on critical systems raises suspicions among vigilant security personnel. To manage such hosts and not arouse suspicion from anomaly detection systems, the attackers used a special version of Beacon, which can only be controlled from the local network via the SMB protocol using pipe. Let's call them slave-nodes .
- Cobalt Strike allows you to connect a master-node and a slave-node through a special channel using the SMB protocol. Thus, slave-nodes become available in the remote central management console of Cobalt Strike. Those. isolated hosts access the Internet through the master-nod, which becomes a gateway for the slave-node.
This scheme allowed criminals to build a fairly reliable mechanism for constant access to the local network of the attacked bank, while remaining as invisible as possible.
To expel attackers from the network, it is necessary to at least identify all hosts performing the master-node role and remove them from the network at the same time, otherwise criminals have a chance to restore operation within a few minutes.
Providing a backup access channel
After successfully compromising the local network and domain, attackers could use legitimate remote access channels, for example, connecting through terminal servers, or via VPN with administrator or regular user rights.
Even though Cobalt Strike has a built-in VNC remote access module, the attackers played it safe and downloaded a modified TeamViewer installer, a legitimate remote access tool. It was not possible to completely restore the installer, so we assume that the main difference from the official application is the hiding of the notification that a remote connection was made to the computer, as was the case in attacks by other criminal groups in Russia. The preparations are complete - the last stage remains - withdrawing money.
Gaining access to ATMs
After gaining control of the bank's internal network and securing backup access channels, criminals moved on to searching for network segments from which ATMs could be accessed and the workplaces of employees who were supposed to monitor ATMs.
Having gained access to a computer or server that allowed access to ATMs, the attackers used standard remote access tools used in a bank. Typically, this is the Microsoft Remote Desktop Protocol.
Once they had access to ATMs, they loaded them with special software that allowed them to manage cash dispensing.
ATM attack software
Once remote access to an ATM is gained, three files are downloaded to it:
- del.bat script, which launched the SDelete program with the necessary parameters.
Contents of the script del.bat
sdelete.exe -accepteula -p 32 d2.exe
sdelete.exe -accepteula -p 32 xtl.exe
sdelete.exe -accepteula -p 32 *.txt
sdelete.exe -accepteula -p 32 d2s.exe
del sdelete.exe
del del.bat
- legitimate SDelete program (published on the Microsoft website). Its purpose is to delete files in a special way so that they cannot be recovered during forensic research.
- a malicious program that uses standard functions over the XFS interface through XFS Manager (eXtensions for Financial Services). It is this program that, upon command from the bank’s internal network, begins issuing money.
The source code of the program was not protected, which greatly simplifies its analysis and makes it possible to make adjustments to the logic of its operation. This means that the author of the malware did not plan to distribute it, but is most likely part of a group of attackers.
The malware allows you to interact with the ATM dispenser using the XFS API and issue commands to empty cash cassettes. It operates according to the arguments that must be passed at startup. There are 5 such arguments in total, and the value of each of them must be specified.
The command line arguments must be in the following order:
ServiceLogicalName - The name of the service used as an argument to the WFSOpen function (for example, "Cash Dispenser Module").
Cassettes Count - the total number of cassettes present on the device. The value must be in the range from 1 to 15.
Cassette Number —the number of the cassette from which cash should be dispensed. The value must be in the range from 1 to 15.
Banknotes Count - the number of banknotes that must be dispensed from the cassette. The value must be in the range from 1 to 60.
Dispenses Count - how many times cash dispensing must be repeated. The value must be in the range from 1 to 60.
All these values are indicated in the console by the operator who is connected to the ATM remotely.
If all arguments were passed correctly, a message is displayed showing the parameters according to which further actions will be performed.
Next, an array is filled in, each element of which corresponds to the cassette number in the device. The number of array elements must match the total number of cassettes. The value that each element of the array stores is the number of banknotes that need to be dispensed from the corresponding cassette. The numbering of array elements starts from 1.
During operation, the program receives data about the system time, and if it does not correspond to that specified in the program code, it terminates its work.
Next, the program performs a number of standard actions that must be done before the cash dispensing operation, and if all of them are completed successfully, the ATM issues bills to the mule. This operation will be repeated as many times as specified in the "Dispenses Count" argument.
Upon successful completion of each such operation, a file named “disp. txt", located in the same directory as the malware, the text string "Cassettes Count: Banknotes Count" is written, where "Cassettes Count" and "Banknotes Count" are the values of the corresponding arguments.
Two versions of such a program were discovered. One was named d2.exe, and the second was d2sleep. exe. The only difference between them was that the second one gave out cash with a short pause - 1 second.
After the ATM ran out of bills, the operator launched the SDelete program, which deleted used files using a special algorithm that did not allow information to be recovered. After this, the ATM rebooted.
In addition, operators disabled the internal servers of the bank from which attacks on ATMs were carried out using the MBRkiller malware, which deleted MBR (master boot record) records. All this greatly complicates the forensic investigation of the attack.
Attack on ATMs
On a conditional day, special people - mules - were sent to the ATMs. They had to keep in touch with their accomplices by telephone, who gave the command to withdraw money from the ATM. Messages with six-digit codes were found on the phones of the detained mules. Typically, such codes are sent by the organizer to activate the malware on a specific ATM.
After the money in the ATM ran out, the person re-contacted the partners and left. The empty ATM was rebooting.
Often mules enter a country on tourist visas specifically to carry out an attack and leave once the operation is over. A few days after the attacks on First Bank ATMs in Taipei, citizens of Latvia and Romania were detained. The remaining 13 suspects, including Russian citizens, managed to leave the island.
Increased attention was paid to the security of the criminal scheme itself. To prevent operators from using the program to attack other ATMs without involving the organizer, a launch time check is built into its code. If the system time of the attacked ATM does not match the month specified in the code, the commands will not be executed. In this case, the program will not generate errors, and, most likely, operators are not aware of such a built-in check.
After each successful cash dispensing operation, the program writes a special log (file named “disp.txt”) with information about the number of banknotes dispensed from each cassette. The operator transmits this log file to the organizer, who uses the received information to control the cash-out chain.
Connection with Buhtrap
While investigating Cobalt's logical attacks on Russian and European banks, we noticed that the mechanisms for delivering phishing emails and gaining access to the domain controller are identical to the methods previously used by the Buhtrap group. From August 2015 to January 2016, she stole more than 1.8 billion rubles from Russian bank accounts.
After people involved in cashing out stolen money for the Buhtrap group were detained in May 2016, thefts from bank accounts using the Trojan of the same name stopped, but the botnet continued to exist.
It can be assumed that at least some of the members of the Buhtrap group entered Cobalt or, what is no less likely, the backbone of Buhtrap simply switched to attacks on ATMs.
How to repel logical attacks
Logical attacks are gaining more and more popularity. The number of incidents will only increase. Carrying out an attack does not require expensive development of complex software - most tools are publicly available.
- To prevent infection through a phishing email with an attached exploit, it is recommended not to open suspicious emails and keep your Microsoft software up to date. Cobalt has not yet exploited zero-day vulnerabilities. Their exploits are old. Therefore, even a routine software update prevented attackers from entering the corporate network. Unfortunately, this requirement was not observed in some of the attacked banks.
- In cases where attackers encountered updated software, they sent attachments with executable files in an archive with a password. Such attacks can be repelled by sending such messages to quarantine for dynamic analysis in an isolated environment (“sandbox”).
- Deploying an attack after gaining access to a bank's network can take days, sometimes months. Use this time to identify attacker activity. Check the domain controller settings and the presence of a Groups.xml file in the SYSVOL directory with an encrypted password on a standard AES-256 key, as described in the section on obtaining privileges.
- Install integrity monitoring software on ATMs.
These recommendations will help prevent theft, but risks can only be minimized by being proactive using Threat intelligence data and using specialized solutions to detect targeted attacks.
Subscribers to our Threat Intelligence service learned about the tactics and mechanics of Cobalt attacks back in the summer of 2016. Our consultations helped several banks stop the attack in time, completely clean up the network and block attackers’ access to ATMs.
Group-IB knows everything about cybercrime, but they tell you the most interesting things.
