BadB
Professional
- Messages
- 1,860
- Reaction score
- 1,897
- Points
- 113
Contents of the article
Today, we'll examine ATMs and discuss the main types of attacks on them. Then, we'll examine in detail the theft scenarios we've uncovered and provide recommendations on how to prevent them.
This article was prepared by analysts from PT Cyber Analytics. This team supports Red Team projects: analyzing results, describing the activities of ethical hackers, assessing the severity of discovered threats and the level of company security, and providing recommendations for remediating vulnerabilities and monitoring infrastructure. The article is based on expertise gained during research into ATM security analysis. Other Positive Technologies employees, including banking system security specialists and reverse engineers from the Application Analysis Department, also contributed to this material.
We would like to express our gratitude to Lyudmila Osipova for her assistance in preparing this article.
This diagram describes the specific case discussed in the article and does not represent the default configuration, which may vary from device to device. Let's examine all the steps, from card presentation to cash withdrawal or deposit. Consider each step as a separate level of ATM operation, each with its own specific tasks.
User interaction with the device is limited to presenting a card and selecting a transaction. Previously, the only way to access an ATM was by inserting a card into the card reader. Back then, data interception attacks such as skimming and shimming were widespread. Criminals used the stolen information to create duplicate payment cards. In Russia, such methods have become largely obsolete. Additional security mechanisms have been implemented in ATMs, and the percentage of devices vulnerable to these attacks has decreased.
With the spread of contactless cards, ATMs now feature readers that use NFC (near-field communication) technology. Some devices even eliminate the need for a card. Instead, they use a one-time QR code, which is either generated on the ATM screen and scanned in the bank's mobile app, or created in the app and scanned by the machine.
To protect the user from unauthorized access to the card, the ATM additionally requests a PIN code. An encrypted panel (or PIN pad) is used to enter the password. It consists of a keyboard and a cryptographic module. Therefore, the PIN code is not transmitted or stored in clear text. The PIN block (the encrypted password value) is verified by the processing center. Moreover, modern ATMs that function as mini-offices (more on this below) can additionally verify the customer's identity before opening the machine — for example, using biometric modules and facial recognition technology.
After identity verification, the ATM prompts you to select a transaction: cash withdrawal, balance view, transfer, or other. The device itself is a regular computer, but the user cannot fully interact with it. Access to all necessary functions is limited to the full-screen banking app running in kiosk mode.
In addition to the system unit, the service area houses network equipment and peripheral connections, including a card reader, readers, a PIN pad, and a dispenser. Communication between this equipment and the system unit is via USB, Ethernet, PCI, or COM interfaces.
Most ATM computers run Windows. Previously, Windows Embedded was predominantly used, but now Windows IoT (based on Windows 10 and used in embedded systems) is more common. Furthermore, as part of import substitution efforts, many ATMs are being converted to Linux.
A Windows ATM, image from Reddit
In addition to the banking application running in kiosk mode, the OS also includes ATM management software and security features, such as:
A key component at the OS level is the control software (CSS). Previously, it was developed by ATM manufacturers. This created compatibility issues when using devices from different vendors in the same fleet. However, with the spread of the CEN/XFS hardware control standard (more on that later), universal solutions for controlling devices from different manufacturers have emerged. Most ATMs now use multi-vendor CEN/XFS-based CSS. This ensures optimal compatibility and allows for servicing a diverse fleet of devices using a single standard.
The primary functions of the ATM management system are managing peripheral equipment and interacting with the processing center. However, depending on the implementation, it may have additional capabilities. For example, it may include software for a monitoring server, which enables remote management of the self-service device network. To facilitate physical maintenance of the ATM, additional features (such as quick access to diagnostic utilities from a separate menu) can be implemented in supervisor mode. This mode is only available to technical staff.
The user has selected a transaction — it needs to be verified that it can be performed. The processing center, a server on the bank's internal network, is responsible for making this decision. It checks:
To prevent interception and modification of the processing center's responses, data exchange between the processing center and the ATM is protected by encryption, most often using a VPN connection. NDC or DDC are often used as the messaging protocol. These became the unofficial standard for communication with the processing center even before the advent of multivendor UPR. Furthermore, the ISO 8583 standard and its modifications are often used. UPR vendors can develop their own protocols for communication with the processing center, while maintaining support for standard rule sets to ensure backward compatibility.
The ATM can also communicate with a monitoring server, which is used for remote management, device status monitoring, and downloading updates. However, this communication is often not encrypted.
A dispenser (without cassettes) in an ATM safe, image from LiveJournal sravniru
Hardware management is based on the CEN/XFS standard, which describes a client-server architecture. It includes a hardware manager (XFS Manager), the API for which is provided by the UPO. The architecture also includes service providers (Service Providers) — drivers containing a set of standard functions for managing peripheral devices and retrieving information about them. Such devices can include dispensers, card readers, and cash acceptance modules.
To dispense cash, the dispenser selects the required number of bills from the ATM cassettes, moves them into a special tray, and opens the shutter. Data transmitted between the ATM and the dispenser can be encrypted. Before the exchange of information, the authenticity of the devices is verified to prevent counterfeiting. Encryption and authentication algorithms are activated by the dispenser's built-in firmware.
When cash is deposited, the validator verifies the authenticity of the bills. This is especially important for ATMs with a recirculation function — they are the most common type in the fleet. Unlike traditional machines that only dispense cash, these ATMs can accept bills deposited by other users.
Attacks in the first group involve direct physical impact on the ATM or its components. The goal is to extract money or interfere with the normal operation of the device without resorting to software. These are traditional attacks that ATMs have been subjected to long before the advent of specialized malware. They don't require specialized knowledge, and some of the skills required are related not to the ATM itself, but to its users.
Logical attacks, however, require specialized skills and advanced technical training. They exploit vulnerabilities in the ATM's software and network environment. Despite their complexity, these attacks attract less attention and allow the compromised ATM to be repeatedly re-used for further profit. This makes them particularly dangerous for banks.
The job of security analysts is to identify software vulnerabilities that allow for a logical attack. We'll focus on these below. They fall into two categories: system and network .
System attacks exploit functions or alter the logic of applications running at the ATM operating system level. The goal is to extract cash or bypass security mechanisms. Blackbox attacks are a special case . They involve connecting the attacker's device directly to the banknote dispensing mechanism, while most system attacks require the hacker to first gain access to the operating system. Blackbox techniques can also be used against other ATM peripherals (for example, the banknote validator). We will now examine interactions with the dispenser specifically.
Network attacks target ATM network components. Hackers may attempt to intercept or forge data transmitted over the network, use it in other ways, or gain remote control over the ATM. The most dangerous attacks are those aimed at interacting with the processing center. If security is weak, an attacker can forge responses sent to the ATM and withdraw funds even if transactions were rejected by the processing center.
Most system and network attacks require access to equipment in the service area. Security specialists are given this access by default during security assessments; a hacker can gain access by drilling a hole in the ATM body or by picking the lock on the service area door. It's also worth remembering that a key to this area can sometimes be purchased online or obtained from an insider — for example, a technical engineer servicing the ATM.
Only some of the attacks described result in the dispensing of banknotes; the remaining actions are intermediate steps leading to this goal. For example, an attacker can gain remote control of an ATM over the network and then operate at the operating system level using systemic attacks. This relationship can be traced using a matrix that reflects the possible transitions between different types of attacks aimed at stealing cash.
An example of such a matrix is shown below. The arrow in a row indicates the transition to an attack in the corresponding column, and the check mark indicates the possibility of receiving banknotes.
Here's how you can use the matrix to build a money disbursement scenario:
Some columns lack arrows, indicating that a hacker only needs access to the ATM's service area to perform an attack. For example, accessing the hard drive requires no additional procedures: this action could be the first step in a full-fledged theft vector.
The matrix provides a general overview of possible banknote issuance scenarios, but the real story lies in the details. Below, we'll take a detailed look at the most common attack scenarios identified by our banking security researchers.
The vulnerabilities discussed below are identified by identifiers like PT-ATM-XXX: they are used in an open collection of logical attacks on ATMs, prepared by our specialists. The collection contains descriptions of tests and detailed recommendations for remediating the vulnerabilities. It will be useful for both ATM security engineers and security analysts. The materials are available on GitHub in four languages.
This scenario requires access to the ATM's service area, which houses the dispenser's connection to the system unit (hereinafter referred to as the PC). By connecting the appropriate cable to their own device instead of the PC, the hacker gains the ability to send control commands directly to the dispenser. This is possible, provided the firmware has not been adequately protected.
Most vulnerabilities used in black-box attacks are related to flaws in the dispenser's built-in encryption, but other issues also exist (the overall ranking is presented below).
Other flaws in this category include the use of an imperfect random number generation mechanism, hard-coded encryption keys, and other issues that require an attacker to study the firmware source code. For example, during our research, we developed the following cash dispensing scenario:
The purpose of authentication is to verify the authenticity of the source of control traffic arriving at the dispenser. This is done using information that allows the ATM PC to be unambiguously identified as genuine. Authentication data can be static values generated based on the characteristics of the PC or devices connected to it. This allows an attacker with access to the service area to reproduce the necessary values by analyzing the PC configuration.
Furthermore, authentication data is often present during unencrypted communication, making it possible to extract it from USB traffic between the PC and the dispenser by eavesdropping. In this case, a black box attack would look like this:
Another way to bypass the firmware's built-in security mechanisms is through buffer overflow. By transmitting a specially crafted data packet to the dispenser firmware, the size of which exceeds the maximum allowed, an attacker can overwrite the data in the function stack with their own values.
In this way, the researchers were able to bypass the built-in check for the impersonation inserted into the most important commands. To do this, they sent a data packet whose size exceeded the specified limit in bytes. This allowed them to transmit the required request to the dispenser and withdraw funds without hindrance.
To perform an unsafe firmware update or buffer overflow, a hacker simply needs to connect their equipment to the dispenser and execute a specially crafted software script.
Modifying the BAT file after connecting the hard drive
Launching a command line interpreter as a result of running a script
However, these aren't all the possibilities open to an attacker after gaining direct access to the hard drive. For example, a hacker could plant malware on it or modify configuration files to bypass security measures. For example, to bypass restrictions on software launch controls, an attacker simply needs to modify the Windows registry. These files can be found in the C:\Windows\System32\config\ folder.
A scenario for stealing money from an ATM with this flaw might look like this:
Furthermore, access to a hard drive can be an intermediate step in more complex cash theft scenarios. For example, exploiting vulnerabilities in an ATM's UPR requires knowledge of its operating principles. An external attacker would have difficulty obtaining the UPR source code. A more accessible option is to examine the executable files using a specialized decompiler. The lack of hard drive encryption allows a hacker to copy the UPR executable files to their own computer for further analysis in a more secure environment.
Although the lack of hard drive encryption is a dangerous flaw, its statistics have not improved for several years. Using encryption can not only prevent the simplest cash withdrawal scenario but also complicate other attacks involving exploiting UPR vulnerabilities and bypassing security measures.
One drawback directly related to connecting a keyboard to an ATM is the ability to exit kiosk mode with a keyboard shortcut. Even the most common combinations often work, allowing access to an application that shouldn't be open to the user during normal ATM operation. For example, the default browser (Internet Explorer, Edge, and others) can be used to open Windows Explorer and then launch a command prompt.
But even if the most common hotkeys are blocked, this doesn't mean a hacker can't exit kiosk mode with a few keystrokes. A complex sequence for accessing the command line might look like this (note that each action is performed using hotkeys):
Selecting a support page (Intel HD Graphics Control Panel)
Selecting a directory to view downloads (Internet Explorer browser)
Managing hotkeys in the Explorer interface
Launching the Command Prompt from Explorer Using Hotkeys
This attack utilizes a DMA board installed in the slot (for example, one based on PCILeech software or a similar tool) to directly access the device's memory, bypassing the operating system's protection mechanisms. This allows for reading data from memory, including payment information transmitted to the ATM, and injecting arbitrary code directly into memory. A DMA attack effectively allows an attacker to execute OS commands with kernel privileges. This gives the hacker even more opportunities for unauthorized actions.
For example, the image below shows a RAM dump containing a bank account number (PAN) — a 16-digit sequence highlighted in yellow.
A dump of the attacked device's RAM, obtained using PCILeech.
The methods for gaining access to the ATM OS for an attacker located in close proximity to the device can be represented in the form of the following diagram.
Since the ATM's ATM controls peripherals using a well-known standard (CEN/XFS), the open nature of this standard can pose a threat if there are issues with the integrity of executable and configuration files.
In our research, insecure implementations of ATM file integrity monitoring were found in most of the configurations examined. This flaw can manifest itself in various ways — for example, if the ATM:
Reflection-based attacks are complex and require a certain level of skill from the attacker. After all, they would need to write an exploit for a specific UPR implementation, and before developing an exploit, they would also need to understand the UPR's operating principles. In the absence of the application's source code, specialized decompilers and debuggers, such as dnSpy (in the case of C#), are used. During analysis, the attacker obtains information about the program elements that must be interacted with to dispense banknotes. This information includes:
An example of a low-level function implementing the corresponding CEN/XFS interface
An example of a high-level call to control the corresponding interface.
The fragments above are taken from the ATM software developed for a demo setup.
After analyzing the software, a hacker can develop a script that loads the necessary assemblies into the application domain. The attacker then initializes certain objects and implements the cash dispensing logic. To extract banknotes, the attacker replicates the conditions of a standard user case: generates the necessary data, creates a standard environment for the function to operate, and prepares the objects. After this, the function itself is called.
A reflection attack allows one to alter the logic of the ATM software that directly interacts with the hardware and skip the communication step with the processing center. However, to be successful, the attacker must first gain the ability to execute OS commands and transfer a file with the payload to the ATM (e.g., via a USB drive).
This is the most optimistic scenario for an attacker. However, in real-world configurations, there are often limitations that hinder the attack at various stages.
For example, reading files from USB drives on most devices requires administrative privileges. And exiting kiosk mode using keyboard shortcuts may be prevented by local security policies. In this case, a more realistic scenario, including the vulnerabilities already described, might look like this:
Blocking the launch of specific software (for example, the command line interpreters cmd.exe and powershell.exe) is often accomplished using a blacklist, which includes standard paths to executable files. The first obvious drawback of this method is the ability to launch third-party software that is not on the blacklist but may still be malicious. Another drawback: bypassing the blocking is limited to launching the executable file from an alternative location. In the simplest case, this can be done using Windows Explorer.
As a demonstration, we examined a method using AppLocker to block PowerShell from launching from the C:\Windows\System32\Windows\PowerShell\v1.0 directory. To bypass the blocking, we copied the powershell.exe executable file to the service user's desktop and then ran the file from the new location.
Block PowerShell from running according to an AppLocker rule
Launching PowerShell from a Non-Standard Location
Sometimes, Windows Explorer can also be blocked from launching from its default location. In this case, we can return to the example of accessing Explorer using Internet Explorer. Furthermore, the browser allows you to perform the necessary actions without Explorer: researchers described a method for interacting with the file system using ActiveX technology. They first gained access to the browser and then executed JavaScript code in the developer console (using it to copy the powershell.exe file to a new directory and then launch it). The Scripting.FileSystemObject and WScript.Shell objects were used to access the Windows file system and launch the executable file, respectively.
This example demonstrates that blocking software launches using a blacklist with standard paths is inherently insecure, as a way to bypass each subsequent block can be found. If Explorer and the browser are simultaneously blocked from launching from their default paths on a device, access to the browser can be gained, for example, by accessing Help in any application that provides this feature. For example, Internet Explorer can be opened from the notepad.exe text editor.
Invoking Internet Explorer, notepad.exe
Let's return to the simplest cash withdrawal scenario discussed in this section and add a bypass of software launch control. Taking into account the described bypass options, it would look something like this:
Running arbitrary software on an ATM
Excessive file access rights of a service user can also pose a threat. For example, an attacker could modify the executable file of a service running with system privileges and gain the ability to execute arbitrary code with maximum privileges.
Sometimes, the VPN connection function is delegated to a separate network device. For example, in such a configuration, traffic encryption can be performed on a switch connected to the Ethernet port. This allows an attacker with access to the service area to reconnect the cable connecting the PC and the switch to their own device (e.g., a laptop). This allows access to unencrypted traffic.
When using a VPN client at the OS level, a hacker can try to disable it, but this often requires administrative privileges. For example, during our research, we renamed several drivers and disabled services related to the VPN client, causing it to stop working.
A rare scenario is possible in which the connection to the processing center is secured using UPO tools rather than a separate VPN solution. For example, the researchers encountered a UPO in which secure connection parameters were determined by Windows registry keys. One of these keys was "Protocol," which determined the data transfer protocol used for the connection. We changed the value of the "Protocol" key from "https" to "http," which disabled server authentication by the client and enabled a "processing center spoofing" attack.
Changing the protocol used from HTTPS to HTTP
Many analyzed configurations allowed root certificates to be installed on behalf of the service user. This flaw allows a hacker to add a self-signed certificate to the system store and masquerade it as trusted. When using such a certificate to establish an HTTPS connection, an attacker could interfere with mutual authentication (e.g., mTLS) and gain access to traffic between the ATM and the processing center.
Self-signed certificate on an ATM
As part of our research, our specialists analyzed the operation of one of these network services. They discovered that the application operates using the .NET Remoting protocol and allows remote code execution without authentication. This is accomplished using a method that accepts the path to the executable file on the ATM as a parameter for subsequent execution. We developed a script that accesses the network service and calls the required method, passing C:\Windows\System32\cmd.exe as an argument. As a result, an attacker with network access to the ATM can execute OS commands.
Launching a command line interpreter as a result of running a script
The result of the request for cash withdrawal in the emulator logs.
The full scenario for issuing funds by replacing the processing center may look like this:
One of the analyzed monitoring server implementations allowed downloading ZIP archives to the ATM and remotely executing plugins of a specific format. This could allow a hacker with access to the ATM network to transfer malware disguised as plugins with the required extension and initiate their remote execution.
Result of downloading and remotely executing the plugin.
Remote monitoring software may be capable of executing arbitrary OS commands, such as instantly rebooting an ATM using the shutdown command. While studying such software, we discovered that, to quickly reboot an ATM, the monitoring server is passed the path to the shutdown.exe executable file and its execution parameters. The file is then launched using the CommandExecute method (name changed).
Since the software does not verify the authenticity of the endpoint with which the ATM establishes a connection, our specialists developed a monitoring server emulator. Based on a previously discovered principle of using third-party utilities, we passed the path to the cmd.exe executable file to the required object, then launched the file using the CommandExecute method. This gave us access to execute OS commands.
In the first attack scenario involving spoofing a processing center, the hacker must first bypass kiosk mode. The vulnerability described above, in turn, allows for initial access to the OS through an alternative method if the attacker has network access. Here, for example, is one of the scenarios implemented by the researchers:
A similar example has been encountered internationally. In 2023, researchers from the Synack Red Team identified critical vulnerabilities in ScrutisWeb software, designed for remote monitoring and management of ATMs. Four vulnerabilities allowed any external attacker access to the web administration interface. The system allowed remote reboots of ATMs, file uploads, and device configuration changes.
Due to its narrow specialization, patching the UPO vulnerabilities can take a long time. It's worth implementing mitigating measures without waiting for patches: for example, using a VPN client makes network attacks more difficult, and a properly configured firewall will protect ports used by network services.
ATMs with facial recognition (left) and finger vein pattern (right). Sources: CaixaBank and The Guardian.
This is especially dangerous given that some devices use biometric authentication instead of PIN entry. For example, in 2020, the Spanish bank CaixaBank introduced ATMs that do not require PIN verification upon successful facial recognition.
ATMs with QR code-based cash withdrawals
Modified NFCGate software is also used in ATM attacks . Similar campaigns have been reported in Russia since October 2024. The final stage of these attacks involves intercepting and retransmitting NFC traffic between the user's card and their device to the attacker's smartphone. The hacker then taps their device on the contactless reader and withdraws money from the victim's account. According to data for the first quarter of 2025, damages from such attacks have already exceeded 432 million rubles.
Ready-made solutions offered on shadow marketplaces are accessible to low-skilled attackers. Despite this, the focus on ATM security remains on physical protection of the safe and network security. As a result, the devices remain vulnerable to simple but effective cash theft scenarios.
As technology advances, logical attack scenarios will become more and more common. Modern devices are no longer simply cash dispensers; they are full-fledged mini-offices through which one can pay for services, transfer money, and repay loans. Using a card is no longer necessary thanks to NFC modules, biometrics, and QR code payments: a smartphone or even a smile is all it takes to get started. It's likely that instead of cash theft, we'll increasingly see funds transferred to a hacker's account, and card data theft will give way to bypassing biometric authentication and NFC attacks.
In this article, we've covered the most common ATM theft scenarios and the vulnerabilities that lead to them. The likelihood of these scenarios in real-world situations shouldn't be underestimated simply because logic attacks are more complex than traditional methods of stealing cash. Some of the described schemes take no more than ten minutes to execute, yet they are significantly more difficult to detect quickly.
What are some tips for protection? First and foremost, our research has demonstrated the importance of monitoring system events that may signal unwanted access to the ATM operating system. Furthermore, it's essential to promptly update the software installed on the device and to work with hardware vendors to obtain patches if any flaws in the firmware are discovered.
A comprehensive approach to device security is essential. It should equally prioritize network and local security, as well as physically restricting access to the ATM's service area, which is used by attackers to connect third-party devices to the embedded computer.
(c) Source
- ATM device
- User level (input devices and kiosk application)
- OS level
- Network layer
- Firmware level
- Classification of ATM attacks
- Logical attack scenarios for ATMs
- Black box attacks
- Gaining access to the ATM OS (bypassing kiosk mode)
- Attacks on vulnerabilities in control software
- Exploiting network configuration flaws
- Replacement of infrastructure elements
- The Future of ATM Attacks
- Bypassing new authentication methods
- ATM as a link in fraudulent schemes
- Network attacks through banking infrastructure
- Attacks on cryptocurrency ATMs
- Conclusions
Today, we'll examine ATMs and discuss the main types of attacks on them. Then, we'll examine in detail the theft scenarios we've uncovered and provide recommendations on how to prevent them.
This article was prepared by analysts from PT Cyber Analytics. This team supports Red Team projects: analyzing results, describing the activities of ethical hackers, assessing the severity of discovered threats and the level of company security, and providing recommendations for remediating vulnerabilities and monitoring infrastructure. The article is based on expertise gained during research into ATM security analysis. Other Positive Technologies employees, including banking system security specialists and reverse engineers from the Application Analysis Department, also contributed to this material.
We would like to express our gratitude to Lyudmila Osipova for her assistance in preparing this article.
Warning
This article is for informational purposes only and is intended for security specialists conducting testing under contract. The author and editors assume no liability for any harm caused by the use of the information provided. Distribution of malware, disruption of systems, and violation of the privacy of correspondence are punishable by law.ATM device
To better understand attack vectors, it's important to understand how an ATM is structured and what operations occur during normal operation. In this article, we examine the user interaction process with an ATM using the example configuration shown in the diagram below.This diagram describes the specific case discussed in the article and does not represent the default configuration, which may vary from device to device. Let's examine all the steps, from card presentation to cash withdrawal or deposit. Consider each step as a separate level of ATM operation, each with its own specific tasks.
User level (input devices and kiosk application)
For convenience, individual components and internal processes of an ATM can be considered to operate at different levels.User interaction with the device is limited to presenting a card and selecting a transaction. Previously, the only way to access an ATM was by inserting a card into the card reader. Back then, data interception attacks such as skimming and shimming were widespread. Criminals used the stolen information to create duplicate payment cards. In Russia, such methods have become largely obsolete. Additional security mechanisms have been implemented in ATMs, and the percentage of devices vulnerable to these attacks has decreased.
With the spread of contactless cards, ATMs now feature readers that use NFC (near-field communication) technology. Some devices even eliminate the need for a card. Instead, they use a one-time QR code, which is either generated on the ATM screen and scanned in the bank's mobile app, or created in the app and scanned by the machine.
To protect the user from unauthorized access to the card, the ATM additionally requests a PIN code. An encrypted panel (or PIN pad) is used to enter the password. It consists of a keyboard and a cryptographic module. Therefore, the PIN code is not transmitted or stored in clear text. The PIN block (the encrypted password value) is verified by the processing center. Moreover, modern ATMs that function as mini-offices (more on this below) can additionally verify the customer's identity before opening the machine — for example, using biometric modules and facial recognition technology.
After identity verification, the ATM prompts you to select a transaction: cash withdrawal, balance view, transfer, or other. The device itself is a regular computer, but the user cannot fully interact with it. Access to all necessary functions is limited to the full-screen banking app running in kiosk mode.
OS level
Let's take a look at the processes taking place in the computer located inside the device. This part of the ATM is called the service area. It is separated from the outside world by a flimsy door secured with a simple lock. Furthermore, devices of the same series often use a single key, which can be purchased online.In addition to the system unit, the service area houses network equipment and peripheral connections, including a card reader, readers, a PIN pad, and a dispenser. Communication between this equipment and the system unit is via USB, Ethernet, PCI, or COM interfaces.
Most ATM computers run Windows. Previously, Windows Embedded was predominantly used, but now Windows IoT (based on Windows 10 and used in embedded systems) is more common. Furthermore, as part of import substitution efforts, many ATMs are being converted to Linux.
A Windows ATM, image from Reddit
In addition to the banking application running in kiosk mode, the OS also includes ATM management software and security features, such as:
- antiviruses;
- software launch control tools such as Windows AppLocker (restrict the execution of third-party programs);
- VPN client (organizes a secure connection to remote nodes in the bank’s internal network).
A key component at the OS level is the control software (CSS). Previously, it was developed by ATM manufacturers. This created compatibility issues when using devices from different vendors in the same fleet. However, with the spread of the CEN/XFS hardware control standard (more on that later), universal solutions for controlling devices from different manufacturers have emerged. Most ATMs now use multi-vendor CEN/XFS-based CSS. This ensures optimal compatibility and allows for servicing a diverse fleet of devices using a single standard.
The primary functions of the ATM management system are managing peripheral equipment and interacting with the processing center. However, depending on the implementation, it may have additional capabilities. For example, it may include software for a monitoring server, which enables remote management of the self-service device network. To facilitate physical maintenance of the ATM, additional features (such as quick access to diagnostic utilities from a separate menu) can be implemented in supervisor mode. This mode is only available to technical staff.
Network layer
At this level, data is exchanged with the processing center and the remote monitoring server.The user has selected a transaction — it needs to be verified that it can be performed. The processing center, a server on the bank's internal network, is responsible for making this decision. It checks:
- card details and the correctness of the entered PIN code, which is requested again before performing the operation;
- no restrictions on the selected card;
- user's balance of funds.
To prevent interception and modification of the processing center's responses, data exchange between the processing center and the ATM is protected by encryption, most often using a VPN connection. NDC or DDC are often used as the messaging protocol. These became the unofficial standard for communication with the processing center even before the advent of multivendor UPR. Furthermore, the ISO 8583 standard and its modifications are often used. UPR vendors can develop their own protocols for communication with the processing center, while maintaining support for standard rule sets to ensure backward compatibility.
The ATM can also communicate with a monitoring server, which is used for remote management, device status monitoring, and downloading updates. However, this communication is often not encrypted.
Firmware level
After receiving confirmation from the processing center, the ATM communicates with the dispenser (which dispenses cash) or the cash acceptance module, depending on the selected transaction. At this level, devices are used that are located in the safe area of most ATMs — this is the most secure part. In addition to the dispenser, the safe may also house a recycling module. In some models, this equipment is partially located in the service area along with other peripheral equipment. The safe area is made of more durable materials than the service area and has a separate key.
A dispenser (without cassettes) in an ATM safe, image from LiveJournal sravniru
Hardware management is based on the CEN/XFS standard, which describes a client-server architecture. It includes a hardware manager (XFS Manager), the API for which is provided by the UPO. The architecture also includes service providers (Service Providers) — drivers containing a set of standard functions for managing peripheral devices and retrieving information about them. Such devices can include dispensers, card readers, and cash acceptance modules.
To dispense cash, the dispenser selects the required number of bills from the ATM cassettes, moves them into a special tray, and opens the shutter. Data transmitted between the ATM and the dispenser can be encrypted. Before the exchange of information, the authenticity of the devices is verified to prevent counterfeiting. Encryption and authentication algorithms are activated by the dispenser's built-in firmware.
When cash is deposited, the validator verifies the authenticity of the bills. This is especially important for ATMs with a recirculation function — they are the most common type in the fleet. Unlike traditional machines that only dispense cash, these ATMs can accept bills deposited by other users.
Classification of ATM attacks
Now let's look at the threats that affect ATMs. There aren't many options. This list can be divided into two broad groups based on the target and the attacker's actions: physical and logical .Attacks in the first group involve direct physical impact on the ATM or its components. The goal is to extract money or interfere with the normal operation of the device without resorting to software. These are traditional attacks that ATMs have been subjected to long before the advent of specialized malware. They don't require specialized knowledge, and some of the skills required are related not to the ATM itself, but to its users.
Logical attacks, however, require specialized skills and advanced technical training. They exploit vulnerabilities in the ATM's software and network environment. Despite their complexity, these attacks attract less attention and allow the compromised ATM to be repeatedly re-used for further profit. This makes them particularly dangerous for banks.
The job of security analysts is to identify software vulnerabilities that allow for a logical attack. We'll focus on these below. They fall into two categories: system and network .
System attacks exploit functions or alter the logic of applications running at the ATM operating system level. The goal is to extract cash or bypass security mechanisms. Blackbox attacks are a special case . They involve connecting the attacker's device directly to the banknote dispensing mechanism, while most system attacks require the hacker to first gain access to the operating system. Blackbox techniques can also be used against other ATM peripherals (for example, the banknote validator). We will now examine interactions with the dispenser specifically.
Network attacks target ATM network components. Hackers may attempt to intercept or forge data transmitted over the network, use it in other ways, or gain remote control over the ATM. The most dangerous attacks are those aimed at interacting with the processing center. If security is weak, an attacker can forge responses sent to the ATM and withdraw funds even if transactions were rejected by the processing center.
Most system and network attacks require access to equipment in the service area. Security specialists are given this access by default during security assessments; a hacker can gain access by drilling a hole in the ATM body or by picking the lock on the service area door. It's also worth remembering that a key to this area can sometimes be purchased online or obtained from an insider — for example, a technical engineer servicing the ATM.
Only some of the attacks described result in the dispensing of banknotes; the remaining actions are intermediate steps leading to this goal. For example, an attacker can gain remote control of an ATM over the network and then operate at the operating system level using systemic attacks. This relationship can be traced using a matrix that reflects the possible transitions between different types of attacks aimed at stealing cash.
An example of such a matrix is shown below. The arrow in a row indicates the transition to an attack in the corresponding column, and the check mark indicates the possibility of receiving banknotes.
Here's how you can use the matrix to build a money disbursement scenario:
- Exiting kiosk mode itself doesn't result in the issuance of banknotes, but rather serves as an intermediate step. This may be followed by exploitation of OS and software vulnerabilities, bypassing local security policies, or exploiting flaws in network settings. For example, a hacker might attempt to download the VPN client configuration after gaining access to the OS.
- In turn, exploiting OS and software vulnerabilities can lead to money laundering — for example, if the UPR contains flaws. This attack can also serve as an intermediate step: for example, if a vulnerability exists in the VPN client being used, an attacker has the opportunity to access secure network traffic and intercept transmitted data.
Some columns lack arrows, indicating that a hacker only needs access to the ATM's service area to perform an attack. For example, accessing the hard drive requires no additional procedures: this action could be the first step in a full-fledged theft vector.
The matrix provides a general overview of possible banknote issuance scenarios, but the real story lies in the details. Below, we'll take a detailed look at the most common attack scenarios identified by our banking security researchers.
Logical attack scenarios for ATMs
During security analysis, information security specialists identify, if possible, all vulnerabilities of a specific ATM that could be exploited in attacks. Analysts then collaborate with security researchers to create complete cash dispensing scenarios: from gaining access to the ATM to extracting the required number of bills. Below are statistics from our research, highlighting the most common vulnerabilities leading to cash theft.The vulnerabilities discussed below are identified by identifiers like PT-ATM-XXX: they are used in an open collection of logical attacks on ATMs, prepared by our specialists. The collection contains descriptions of tests and detailed recommendations for remediating the vulnerabilities. It will be useful for both ATM security engineers and security analysts. The materials are available on GitHub in four languages.
Black box attacks
All ATM configurations analyzed contained vulnerabilities in the dispenser firmware that could allow for a black-box attack. These attacks are so named because the attacker uses an external device (a kind of black box) to directly control the dispenser.This scenario requires access to the ATM's service area, which houses the dispenser's connection to the system unit (hereinafter referred to as the PC). By connecting the appropriate cable to their own device instead of the PC, the hacker gains the ability to send control commands directly to the dispenser. This is possible, provided the firmware has not been adequately protected.
Most vulnerabilities used in black-box attacks are related to flaws in the dispenser's built-in encryption, but other issues also exist (the overall ranking is presented below).
Weak Encryption Algorithm and Other Deficiencies in Cryptographic Rules (PT-ATM-204)
A common flaw associated with encrypted traffic between a PC and a dispenser is the use of a weak algorithm. An attacker can exploit known vulnerabilities in the algorithms to reconstruct portions of the protected traffic and extract sensitive information.Other flaws in this category include the use of an imperfect random number generation mechanism, hard-coded encryption keys, and other issues that require an attacker to study the firmware source code. For example, during our research, we developed the following cash dispensing scenario:
- Having penetrated the ATM service area, the hacker obtains the data necessary for subsequent authentication.
- The intruder connects his equipment (for example, a laptop) to the dispenser using a USB cable.
- An attacker obtains secret values used to encrypt traffic between a PC and a dispenser by brute-forcing them or extracting them from the Windows registry and then decrypting them. The latter option requires prior access to the OS, for example, by exiting kiosk mode. This is possible due to the use of a weak pseudo-random number generation algorithm and the use of hard-coded values to store secrets in the registry.
- Using the information obtained in steps 1 and 3, the hacker establishes data exchange between the PC and the dispenser. This allows them to send cash dispenser requests.
Predictable Authentication Data (PT-ATM-203)
Another common flaw in dispenser firmware is the use of predictable authentication data, which is performed before communication between the PC and the dispenser.The purpose of authentication is to verify the authenticity of the source of control traffic arriving at the dispenser. This is done using information that allows the ATM PC to be unambiguously identified as genuine. Authentication data can be static values generated based on the characteristics of the PC or devices connected to it. This allows an attacker with access to the service area to reproduce the necessary values by analyzing the PC configuration.
Furthermore, authentication data is often present during unencrypted communication, making it possible to extract it from USB traffic between the PC and the dispenser by eavesdropping. In this case, a black box attack would look like this:
- Having gained access to the ATM's service area, the hacker identifies the cable that connects the dispenser and connects his equipment (for example, a laptop) to it.
- It intercepts USB traffic between the PC and the dispenser and extracts from it the information needed to pass off its hardware as a genuine PC.
- The attacker exchanges data between the PC and the dispenser to authenticate and initiates the encryption key generation algorithm. After this, the attacker is able to send cash dispenser requests.
Other vulnerabilities in the dispenser software (PT-ATM-206)
One of the common issues associated with dispenser firmware is an insecure update delivery and authentication mechanism. In most of the configurations studied, these mechanisms were found to be unreliable. An attacker could inject arbitrary control code into them. Loading such an update into the firmware can lead to both the dispensing of funds and the disabling of built-in security mechanisms. For example, in several of the configurations studied, this allowed the signature checks of commands transmitted to the dispenser to be disabled.Another way to bypass the firmware's built-in security mechanisms is through buffer overflow. By transmitting a specially crafted data packet to the dispenser firmware, the size of which exceeds the maximum allowed, an attacker can overwrite the data in the function stack with their own values.
In this way, the researchers were able to bypass the built-in check for the impersonation inserted into the most important commands. To do this, they sent a data packet whose size exceeded the specified limit in bytes. This allowed them to transmit the required request to the dispenser and withdraw funds without hindrance.
To perform an unsafe firmware update or buffer overflow, a hacker simply needs to connect their equipment to the dispenser and execute a specially crafted software script.
Recommendations for protecting against black box attacks
- Use strong encryption algorithms for data transfer, such as AES in an authenticated mode (such as GCM or CCM).
- Implement reliable mechanisms for authentication, storage, and transmission of passwords between the OS and the dispenser. For example, modern XFS platforms support physical authentication, which ensures that key transfer is only possible with confirmed access to the safe.
- Use robust encryption key generation mechanisms, avoid hard-coded secrets, and avoid predictable initialization values for the pseudo-random number generator.
- Implement a mechanism for verifying firmware update files. For example, asymmetric cryptographic algorithms could be used: a public key is stored on the device, and the update file contains a signature that is verified during the update process. Each firmware update must be signed by the developer.
- Strictly validate the length and format of incoming requests to the dispenser to reduce the likelihood of binary vulnerabilities. Additionally, buffer overflow protection mechanisms should be used.
- Implement hardware protection against connection to the dispenser's data bus, such as ATM Keeper, Cerber Lock, or ZUB-R. These devices should be located in the ATM's secure area, protected from intruders. Unexpected disconnection of the dispenser from the PC, as well as an unplanned reboot of the ATM, should be considered a potential intrusion and trigger an alarm.
Gaining access to the ATM operating system (bypassing kiosk mode)
Before we move on to the following cash theft scenarios, we need to discuss methods for gaining access to the ATM operating system. Unless we're talking about black-box attacks, which require a direct connection, this step is essential. A regular user can't fully interact with the ATM, limited to the interface offered by the kiosk app. Below, we describe vulnerabilities that allow a hacker to bypass kiosk mode and execute operating system commands on the ATM while only having access to the service area.No hard drive encryption (PT-ATM-231)
The lack of hard drive encryption stands out among the weaknesses open to an attacker with access only to the service area. Firstly, it is one of the most common flaws and can be exploited to gain initial access to the operating system. Secondly, the flaw enables the simplest possible theft scenario, which takes no more than ten minutes. A simple example of gaining access to the operating system: while examining the contents of an unencrypted hard drive, we discovered a BAT file that runs after the system fully boots up when the ATM is turned on. The line "start cmd.exe" was added to the file, causing the command line interpreter to launch after the ATM reboot. This allowed the attacker to execute operating system commands.
Modifying the BAT file after connecting the hard drive
Launching a command line interpreter as a result of running a script
However, these aren't all the possibilities open to an attacker after gaining direct access to the hard drive. For example, a hacker could plant malware on it or modify configuration files to bypass security measures. For example, to bypass restrictions on software launch controls, an attacker simply needs to modify the Windows registry. These files can be found in the C:\Windows\System32\config\ folder.
A scenario for stealing money from an ATM with this flaw might look like this:
- Having penetrated the ATM's service area, a hacker gains access to the hard drive's contents. To do this, they disconnect the hard drive from the PC and connect it to their own device (such as a laptop) using a suitable adapter.
- A hacker replaces one of the programs in the startup list with an executable file containing malicious code. This can be done by adding or modifying keys in the corresponding branch of the Windows registry.
- The attacker reboots the ATM. Once the operating system loads, the malicious file runs automatically.
Furthermore, access to a hard drive can be an intermediate step in more complex cash theft scenarios. For example, exploiting vulnerabilities in an ATM's UPR requires knowledge of its operating principles. An external attacker would have difficulty obtaining the UPR source code. A more accessible option is to examine the executable files using a specialized decompiler. The lack of hard drive encryption allows a hacker to copy the UPR executable files to their own computer for further analysis in a more secure environment.
Although the lack of hard drive encryption is a dangerous flaw, its statistics have not improved for several years. Using encryption can not only prevent the simplest cash withdrawal scenario but also complicate other attacks involving exploiting UPR vulnerabilities and bypassing security measures.
Insufficient USB device connection control (PT-ATM-004) and insecure key whitelist configuration (PT-ATM-001)
Restrictions on connecting USB drives to ATMs have become more common (for example, on some devices, this action is only available to administrators). However, connecting third-party USB keyboards is generally not prohibited. This means that other devices classified by the computer as USB HID, such as compact Rubber Ducky and Flipper Zero keyboards, can potentially be connected to the ATM. However, in scenario diagrams, all of these devices will be labeled as USB keyboards.One drawback directly related to connecting a keyboard to an ATM is the ability to exit kiosk mode with a keyboard shortcut. Even the most common combinations often work, allowing access to an application that shouldn't be open to the user during normal ATM operation. For example, the default browser (Internet Explorer, Edge, and others) can be used to open Windows Explorer and then launch a command prompt.
But even if the most common hotkeys are blocked, this doesn't mean a hacker can't exit kiosk mode with a few keystrokes. A complex sequence for accessing the command line might look like this (note that each action is performed using hotkeys):
- Open the Intel HD Graphics Control Panel.
- Opening the support page in Internet Explorer.
- Select a directory to view files downloaded from the browser.
- Calling the command line interpreter in the opened Windows Explorer tab.
Selecting a support page (Intel HD Graphics Control Panel)
Selecting a directory to view downloads (Internet Explorer browser)
Managing hotkeys in the Explorer interface
Launching the Command Prompt from Explorer Using Hotkeys
Direct Memory Access (PT-ATM-232)
So, it's possible to connect to the ATM's system unit via USB, Ethernet, PCI, and COM. If the ATM's motherboard has a free PCI slot, an attacker can attempt a direct memory access (DMA) attack.This attack utilizes a DMA board installed in the slot (for example, one based on PCILeech software or a similar tool) to directly access the device's memory, bypassing the operating system's protection mechanisms. This allows for reading data from memory, including payment information transmitted to the ATM, and injecting arbitrary code directly into memory. A DMA attack effectively allows an attacker to execute OS commands with kernel privileges. This gives the hacker even more opportunities for unauthorized actions.
For example, the image below shows a RAM dump containing a bank account number (PAN) — a 16-digit sequence highlighted in yellow.
A dump of the attacked device's RAM, obtained using PCILeech.
The methods for gaining access to the ATM OS for an attacker located in close proximity to the device can be represented in the form of the following diagram.
Recommendations for preventing access to the OS
- Use hardware or software hard drive encryption. It's important to ensure secure storage of the encryption key, such as using a hardware TPM (Trusted Platform Module). Storing the key on an unencrypted drive is strongly discouraged.
- Restrict USB devices connected during normal ATM operation. This can be done using Windows policies and/or Device Control security features.
- Limit the use of common key combinations that are not required for normal ATM operation (such as Win+F1, Alt+F4, Ctrl+Win+Enter, Alt+Tab, Ctrl+Alt+F12). Additionally, disable touchscreen gestures if relevant to the specific ATM configuration.
- Enable DMA attack protection. For example, the following methods are available for Windows:
- Open Windows security settings (Windows Settings → Privacy & security → Windows Security) and go to the core isolation settings (Device security → Core isolation details). Set the Memory integrity setting to On and ensure Memory Access Protection is listed among the available security features.
- Set the Kernel DMA Protection parameter to On using the System Information application (msinfo32.exe).
- Monitor and analyze events outside of scheduled maintenance hours (maintenance or collection) that may indicate unauthorized access to the ATM operating system:
- opening of the ATM case or unplanned transition to service mode;
- ATM power failure followed by power-on, despite the presence of a stable power source;
- OS reboot or user logout without any recorded reasons or errors in the ATM activity logs, as well as editing the activity logs on the hard drive.
Attacks on vulnerabilities in control software
Insecure Implementation of File Integrity Monitoring for Control Software (PT-ATM-417)
By bypassing kiosk mode, a hacker can perform actions on behalf of a service user. This is the account used by the ATM to perform various functions, such as running a banking application in kiosk mode. An attacker can attempt to withdraw cash using malicious tools that target the ATM's ATM.Since the ATM's ATM controls peripherals using a well-known standard (CEN/XFS), the open nature of this standard can pose a threat if there are issues with the integrity of executable and configuration files.
In our research, insecure implementations of ATM file integrity monitoring were found in most of the configurations examined. This flaw can manifest itself in various ways — for example, if the ATM:
- There is a built-in option to disable the application file checking;
- The function used to calculate the hash of files can be modified. If the calculation is incorrect, the integrity check may fail, allowing an attacker to modify the files;
- The integrity check is performed only once when the application is launched and applies to files with extensions from a specified list. If an attacker uses a payload with an extension not included in the list, the integrity check will pass.
Insufficient protection against reflection attacks (PT-ATM-417)
The UPR analyzed by the specialists was written in JIT-compiled languages. Some of these, including C#, have reflection capabilities: the program can analyze its structure at runtime, dynamically call methods, modify object state, and access type metadata. Attackers can exploit reflection: insufficient integrity checking of executable files allows for a successful attack. Most of the analyzed configurations were vulnerable.Reflection-based attacks are complex and require a certain level of skill from the attacker. After all, they would need to write an exploit for a specific UPR implementation, and before developing an exploit, they would also need to understand the UPR's operating principles. In the absence of the application's source code, specialized decompilers and debuggers, such as dnSpy (in the case of C#), are used. During analysis, the attacker obtains information about the program elements that must be interacted with to dispense banknotes. This information includes:
- classes whose objects must be initialized before interacting with the equipment;
- methods that represent an implementation of a particular CEN/XFS interface or call the corresponding low-level methods.
An example of a low-level function implementing the corresponding CEN/XFS interface
An example of a high-level call to control the corresponding interface.
The fragments above are taken from the ATM software developed for a demo setup.
After analyzing the software, a hacker can develop a script that loads the necessary assemblies into the application domain. The attacker then initializes certain objects and implements the cash dispensing logic. To extract banknotes, the attacker replicates the conditions of a standard user case: generates the necessary data, creates a standard environment for the function to operate, and prepares the objects. After this, the function itself is called.
A reflection attack allows one to alter the logic of the ATM software that directly interacts with the hardware and skip the communication step with the processing center. However, to be successful, the attacker must first gain the ability to execute OS commands and transfer a file with the payload to the ATM (e.g., via a USB drive).
This is the most optimistic scenario for an attacker. However, in real-world configurations, there are often limitations that hinder the attack at various stages.
For example, reading files from USB drives on most devices requires administrative privileges. And exiting kiosk mode using keyboard shortcuts may be prevented by local security policies. In this case, a more realistic scenario, including the vulnerabilities already described, might look like this:
- Having gained access to the ATM's service area, the hacker installs a DMA attack device into an accessible PCI slot. They then use publicly available software, such as PCILeech, to execute OS commands with NT AUTHORITY\SYSTEM user privileges.
- The attacker changes the administrator password and as a result gains access to an account whose rights allow connecting third-party USB drives.
- The attacker transfers the exploit via a USB drive and connects a keyboard to the ATM to further interact with the program.
- The attacker launches the exploit through the command line interpreter and gains the ability to issue money.
Bypassing third-party software launch control (PT-ATM-019)
Another potential obstacle may be restrictions on software launches. For example, banning the use of command line interpreters, which attackers use to interact with malware. On Windows-based ATMs, solutions such as AppLocker or software restriction policies (SRPs) are often used for blocking. Third-party Application Control solutions are also possible.Blocking the launch of specific software (for example, the command line interpreters cmd.exe and powershell.exe) is often accomplished using a blacklist, which includes standard paths to executable files. The first obvious drawback of this method is the ability to launch third-party software that is not on the blacklist but may still be malicious. Another drawback: bypassing the blocking is limited to launching the executable file from an alternative location. In the simplest case, this can be done using Windows Explorer.
As a demonstration, we examined a method using AppLocker to block PowerShell from launching from the C:\Windows\System32\Windows\PowerShell\v1.0 directory. To bypass the blocking, we copied the powershell.exe executable file to the service user's desktop and then ran the file from the new location.
Block PowerShell from running according to an AppLocker rule
Launching PowerShell from a Non-Standard Location
Sometimes, Windows Explorer can also be blocked from launching from its default location. In this case, we can return to the example of accessing Explorer using Internet Explorer. Furthermore, the browser allows you to perform the necessary actions without Explorer: researchers described a method for interacting with the file system using ActiveX technology. They first gained access to the browser and then executed JavaScript code in the developer console (using it to copy the powershell.exe file to a new directory and then launch it). The Scripting.FileSystemObject and WScript.Shell objects were used to access the Windows file system and launch the executable file, respectively.
This example demonstrates that blocking software launches using a blacklist with standard paths is inherently insecure, as a way to bypass each subsequent block can be found. If Explorer and the browser are simultaneously blocked from launching from their default paths on a device, access to the browser can be gained, for example, by accessing Help in any application that provides this feature. For example, Internet Explorer can be opened from the notepad.exe text editor.
Invoking Internet Explorer, notepad.exe
Let's return to the simplest cash withdrawal scenario discussed in this section and add a bypass of software launch control. Taking into account the described bypass options, it would look something like this:
- The hacker connects a USB drive with a previously saved exploit to the ATM PC.
- Connects a third-party keyboard and bypasses kiosk mode. Launches a third-party application that isn't restricted by local security policies and displays context-sensitive help. This allows it to access the browser.
- The attacker needs to copy the command line interpreter executable to a new path. To do this, they can access File Explorer from a browser or use the developer console to interact with the file system via ActiveX objects.
- The hacker gains access to OS commands and launches an exploit using the command line interpreter, taking advantage of the lack of restrictions on running third-party executable files.
User security policy settings are insufficiently effective (PT-ATM-003)
Often, a service user can have excessive privileges that allow them to perform unauthorized actions on an ATM without bypassing restrictions. For example, a complete lack of restrictions on running software that allows executing OS commands and making changes to the system configuration was found in half of the devices studied.
Running arbitrary software on an ATM
Excessive file access rights of a service user can also pose a threat. For example, an attacker could modify the executable file of a service running with system privileges and gain the ability to execute arbitrary code with maximum privileges.
Recommendations for protecting against attacks on control software
- Implement UPR protection measures against attacks that use reflection (implementation will depend on the development language). To make it more difficult for an attacker to analyze the application, source code obfuscation should be used.
- Limit the privileges of the service user, leaving a minimum set of rights for work.
- Use more flexible policies in application launch controls, such as blocking by hash or publisher.
- Configure application launch controls using a whitelist (allow only those utilities required for the ATM to function properly). This will help prevent third-party software from running on the ATM.
- Regularly update the software used on your ATM.
Exploiting network configuration flaws
Changing secure connection settings (PT-ATM-415)
On most ATMs, external access to network ports is restricted through the use of a VPN client. VPN solutions not only hinder external interaction with the ATM's network services but also prevent interference with data exchange between the device and the processing center. Changing these settings can be one of the goals of an attacker with access to the operating system.Sometimes, the VPN connection function is delegated to a separate network device. For example, in such a configuration, traffic encryption can be performed on a switch connected to the Ethernet port. This allows an attacker with access to the service area to reconnect the cable connecting the PC and the switch to their own device (e.g., a laptop). This allows access to unencrypted traffic.
When using a VPN client at the OS level, a hacker can try to disable it, but this often requires administrative privileges. For example, during our research, we renamed several drivers and disabled services related to the VPN client, causing it to stop working.
A rare scenario is possible in which the connection to the processing center is secured using UPO tools rather than a separate VPN solution. For example, the researchers encountered a UPO in which secure connection parameters were determined by Windows registry keys. One of these keys was "Protocol," which determined the data transfer protocol used for the connection. We changed the value of the "Protocol" key from "https" to "http," which disabled server authentication by the client and enabled a "processing center spoofing" attack.
Changing the protocol used from HTTPS to HTTP
Many analyzed configurations allowed root certificates to be installed on behalf of the service user. This flaw allows a hacker to add a self-signed certificate to the system store and masquerade it as trusted. When using such a certificate to establish an HTTPS connection, an attacker could interfere with mutual authentication (e.g., mTLS) and gain access to traffic between the ATM and the processing center.
Self-signed certificate on an ATM
Exploiting vulnerabilities in ATM network services (PT-ATM-401)
Network services run alongside the ATM software on the device — usually services that allow remote control of the ATM or downloading updates. This functionality is attractive to hackers, as it allows access to the ATM's operating system using only network access.As part of our research, our specialists analyzed the operation of one of these network services. They discovered that the application operates using the .NET Remoting protocol and allows remote code execution without authentication. This is accomplished using a method that accepts the path to the executable file on the ATM as a parameter for subsequent execution. We developed a script that accesses the network service and calls the required method, passing C:\Windows\System32\cmd.exe as an argument. As a result, an attacker with network access to the ATM can execute OS commands.
Launching a command line interpreter as a result of running a script
Recommendations for troubleshooting network configuration issues
- Restrict access to network ports by allowing connections only for trusted processes that require them in normal operation.
- To protect interactions with the processing center, use separate (not included in the UPO) VPN solutions that are resistant to emergency situations, such as:
- loading the ATM in safe mode;
- unplanned device shutdown;
- disconnecting or reconnecting network equipment (if encryption is performed by a separate device);
- connection of unauthorized network equipment or loss of connection with the target device while the VPN client is active.
- Limit service user privileges to the bare minimum required for work. For example, for Windows systems, it's advisable to impose the following restrictions:
- prohibit the launch of standard utilities for working with the certificate store;
- Leave read-only permission for critical registry branches - the HKEY_LOCAL_MACHINE\Software subbranches related to the ATM UPR, as well as the HKEY_CURRENT_USER\SOFTWARE\Microsoft\SystemCertificates branch.
Replacement of infrastructure elements
Substitution of the processing center (PT-ATM-421)
By changing secure connection settings, an attacker can interfere with data exchange between the ATM and the processing center. This is done using an emulator, which connects to the system unit or network equipment via a patch cable and allows arbitrary responses to ATM requests. The legitimate processing center, however, does not even receive requests from the device. This allows for the desired withdrawal of funds without debiting the attacker's card. One of the weaknesses that allows for theft by spoofing the processing center is the ability to disable necessary checks on behalf of the service user. For example, while investigating a variant of the UPO implementation, specialists discovered the ability to launch a service utility used to change its settings. By modifying security flags, they disabled signature verification of the processing center's messages. This allowed the emulator to be used to send commands to the ATM. Another variant also allowed for disabling additional security checks when interacting with the processing center. For example, to disable cryptogram verification, a modified HTTP response is sent to the ATM request from the processing center emulator. In the response, the verification parameter is set to false. This allows a random PIN to be entered upon card presentation, after which the emulator immediately sends a request to the ATM to dispense funds, skipping the data verification step.
The result of the request for cash withdrawal in the emulator logs.
The full scenario for issuing funds by replacing the processing center may look like this:
- Having gained access to the ATM's service area, the attacker connects a USB keyboard to it.
- The attacker exits kiosk mode and gains the ability to execute OS commands.
- The attacker modifies one of the Windows registry values used by the ATM to modify secure connection parameters. The ATM is then rebooted to ensure the changes are saved.
- The attacker connects the ATM to his own workstation with a deployed infrastructure of emulators.
- The attacker emulates bank processing for the targeted ATM. At the same time, they or their accomplice tap their bank card on the contactless reader and withdraw money.
Substituting the monitoring server (PT-ATM-417)
Another example of a network attack involves spoofing the monitoring server used for remote diagnostics and downloading updates. In more than half of the analyzed configurations, the UPO established a connection to the monitoring server without verifying the legitimacy of the connected host. This allows an attacker to create and use an emulator of the server to remotely execute code on an ATM.One of the analyzed monitoring server implementations allowed downloading ZIP archives to the ATM and remotely executing plugins of a specific format. This could allow a hacker with access to the ATM network to transfer malware disguised as plugins with the required extension and initiate their remote execution.
Result of downloading and remotely executing the plugin.
Remote monitoring software may be capable of executing arbitrary OS commands, such as instantly rebooting an ATM using the shutdown command. While studying such software, we discovered that, to quickly reboot an ATM, the monitoring server is passed the path to the shutdown.exe executable file and its execution parameters. The file is then launched using the CommandExecute method (name changed).
Since the software does not verify the authenticity of the endpoint with which the ATM establishes a connection, our specialists developed a monitoring server emulator. Based on a previously discovered principle of using third-party utilities, we passed the path to the cmd.exe executable file to the required object, then launched the file using the CommandExecute method. This gave us access to execute OS commands.
In the first attack scenario involving spoofing a processing center, the hacker must first bypass kiosk mode. The vulnerability described above, in turn, allows for initial access to the OS through an alternative method if the attacker has network access. Here, for example, is one of the scenarios implemented by the researchers:
- An attacker with access to the ATM network emulates a monitoring server and gains the ability to execute commands on the device being examined.
- The attacker modifies one of the registry values used by the UPO to disable message signature verification. The ATM is then rebooted to ensure the changes are saved.
- The hacker emulates bank processing for the targeted ATM. At the same time, they or their accomplice tap their bank card on the contactless reader and withdraw funds.
A similar example has been encountered internationally. In 2023, researchers from the Synack Red Team identified critical vulnerabilities in ScrutisWeb software, designed for remote monitoring and management of ATMs. Four vulnerabilities allowed any external attacker access to the web administration interface. The system allowed remote reboots of ATMs, file uploads, and device configuration changes.
Due to its narrow specialization, patching the UPO vulnerabilities can take a long time. It's worth implementing mitigating measures without waiting for patches: for example, using a VPN client makes network attacks more difficult, and a properly configured firewall will protect ports used by network services.
Recommendations for protecting against the substitution of infrastructure elements
- Implement integrity control of requests to the processing center to prevent the possibility of their modification, for example, by adding an impersonation insert to the request or using a MAC (Message Authentication Code).
- Perform additional verification of data returned by the processing center. Disabling security checks performed on the ATM side should not be possible either from the processing center or locally on behalf of the service user.
- Implement authentication and authorization mechanisms for ATM network services:
- Requests to ATM network services must be made using a digital signature, especially for services whose standard functionality includes writing and executing files;
- Remote diagnostics and installation of updates on the ATM should be available only from a specially designated installation server (jump server), access to which is limited to a limited number of employees.
The Future of ATM Attacks
The logical attack scenarios discussed demonstrate how ATMs can be hacked today. At the same time, technological advancements aren't bypassing these devices — they're acquiring new features, leading to the emergence of additional attack vectors. Let's try to make some predictions about what ATM attacks will look like in the near future.Bypassing new authentication methods
ATMs offering biometric authentication are becoming increasingly popular: facial, fingerprint, and even vein recognition technologies are used. While card data theft using overlay and embedded devices was once common, the goal is now to collect and subsequently use biometric data. A bank card can be reissued if compromised. And if biometric data is leaked, for example as a result of a hack into the banking infrastructure, the user will not be able to change these essential physical characteristics.
ATMs with facial recognition (left) and finger vein pattern (right). Sources: CaixaBank and The Guardian.
This is especially dangerous given that some devices use biometric authentication instead of PIN entry. For example, in 2020, the Spanish bank CaixaBank introduced ATMs that do not require PIN verification upon successful facial recognition.
ATMs as a link in fraudulent schemes
ATMs are increasingly becoming not so much direct targets as intermediate stages in fraudulent schemes. In some cases, a user can withdraw money by simply generating a QR code in a bank's mobile app and scanning it at the ATM. Fraudsters have already taken advantage of this innovation, adapting a standard social engineering scheme. Victims are informed of a fictitious unauthorized transaction and are urged to send a QR code to cancel it. In reality, the scammers scan the generated code at the ATM and withdraw money from the victim's account.
ATMs with QR code-based cash withdrawals
Modified NFCGate software is also used in ATM attacks . Similar campaigns have been reported in Russia since October 2024. The final stage of these attacks involves intercepting and retransmitting NFC traffic between the user's card and their device to the attacker's smartphone. The hacker then taps their device on the contactless reader and withdraws money from the victim's account. According to data for the first quarter of 2025, damages from such attacks have already exceeded 432 million rubles.
Network attacks through banking infrastructure
Back in 2017, Trend Micro, in collaboration with Europol, noted a shift in logical attack vectors in a report (PDF): instead of interventions requiring physical access to the service area, attackers are increasingly accessing ATMs from within the bank's network. With insufficient network segmentation, compromising a bank's internal infrastructure allows attackers to develop attacks on connected ATMs. One example is an incident in Thailand, recorded in late 2016. Having gained access to the bank's corporate network, attackers compromised a server used to deliver updates and, through it, downloaded malware to several ATMs. That same year, a similar attack in Taiwan resulted in the theft of approximately 80 million New Taiwan dollars (approximately US$2.5 million). The attackers also used access to the bank's network to deliver malware, which enabled remote control of ATMs via the Telnet protocol.Attacks on cryptocurrency ATMs
As interest in cryptocurrency grows, the number of crypto ATMs continues to grow: by 2024, their number increased by 3%, reaching 37,700 devices worldwide. Crypto ATMs (or crypto ATMs) allow both the purchase and sale of cryptocurrency. To use the terminal, simply enter the wallet address by scanning its QR code from the screen of a mobile device. Crypto ATM fraud is largely similar to QR code attacks that target regular ATMs, but with a key difference: the victim does not provide the code to the scammer. Instead, the attacker sends them a pre-generated QR code containing the crypto wallet address and, under the pretext of an urgent need — for example, transferring funds to a secure account — persuades them to deposit cash at the nearest crypto ATM. The deposited funds are automatically converted to cryptocurrency and transferred to the criminal's wallet. What makes these schemes especially dangerous is that cryptocurrency transactions are more difficult to track and stolen funds are more difficult to recover.
Conclusions
The rise of new ATM malware and the lower barrier to entry for attackers have made logical attacks on these devices more relevant than ever. Previously, attackers focused on stealing card data using techniques that didn't affect the device's logic. This provided a one-time benefit. Now, a single logical attack can immediately provide an attacker with a large sum of cash.Ready-made solutions offered on shadow marketplaces are accessible to low-skilled attackers. Despite this, the focus on ATM security remains on physical protection of the safe and network security. As a result, the devices remain vulnerable to simple but effective cash theft scenarios.
As technology advances, logical attack scenarios will become more and more common. Modern devices are no longer simply cash dispensers; they are full-fledged mini-offices through which one can pay for services, transfer money, and repay loans. Using a card is no longer necessary thanks to NFC modules, biometrics, and QR code payments: a smartphone or even a smile is all it takes to get started. It's likely that instead of cash theft, we'll increasingly see funds transferred to a hacker's account, and card data theft will give way to bypassing biometric authentication and NFC attacks.
In this article, we've covered the most common ATM theft scenarios and the vulnerabilities that lead to them. The likelihood of these scenarios in real-world situations shouldn't be underestimated simply because logic attacks are more complex than traditional methods of stealing cash. Some of the described schemes take no more than ten minutes to execute, yet they are significantly more difficult to detect quickly.
What are some tips for protection? First and foremost, our research has demonstrated the importance of monitoring system events that may signal unwanted access to the ATM operating system. Furthermore, it's essential to promptly update the software installed on the device and to work with hardware vendors to obtain patches if any flaws in the firmware are discovered.
A comprehensive approach to device security is essential. It should equally prioritize network and local security, as well as physically restricting access to the ATM's service area, which is used by attackers to connect third-party devices to the embedded computer.
(c) Source
