Notes and thoughts around the gentle art of assessing ATMs
9 min
I must confess that ATMs have always intrigued me. Don’t misunderstand me though. I know that, in most cases, that would sound like a rather suspicious statement for obvious reasons, but trust me when I say that it is not about the money they hold. I genuinely find them fascinating devices for the way they are built, and not particularly for what they do.
This is why I couldn’t have been happier when I recently was given a chance to put my hands on a fairly broad set of ATM machines. It was in the context of a broad security auditing project aimed at evaluating the overall network and application security posture of the ATM base for one of the most important and renowned banks in the world. I thought it would be nice to share at least some notes from this fun and rewarding experience, since it is not exactly an everyday business case.
Determining the surface of exposure
As usual, preparation starts with defining how an ATM works in practice and what the critical components and interfaces are. More specifically, it is key to define what determines a target’s actual surface of exposure, which is why I started with the basics and studied the main elements of an ATM.
Front-End Components
From a front end perspective, most ATMs have two main inputs, card reader and keypad, and four outputs, screen, receipt printer, cash dispenser, and speaker. However, hacking into an ATM through these user interfaces would not be a recommended approach, unless there are significant logical flaws in the ATM application.
Back-End Components
The picture changes when looking at the back end. There are many additional input and output interfaces and connection points, such as connections to the financial host, administration systems, software updates, monitoring systems, and anti fraud mechanisms.
Ultimately, ATMs are not that different from any other network connected device. Any exposed service or interface could potentially be attacked by someone with access to the network. This was the core of my role as an ATM security assessor, identifying and testing these interfaces to determine whether unauthorized access could lead to cash being dispensed.
XFS and overall architecture
Before moving forward, I needed to understand the ATM specific architecture. Typically, the ATM application does not run directly on top of the operating system. Instead, there are intermediate layers involved.
A key component is the XFS, Extensions for Financial Services, middleware layer. This provides a client server architecture for financial applications running on Windows platforms.
The Role of XFS Middleware
An ATM architecture typically involves an XFS (eXtensions for Financial Services) middleware layer. This middleware provides a client-server architecture for financial applications on Windows platforms, specifically designed for devices like ATMs.
XFS is an international standard promoted by the European Committee for Standardization (CEN/XFS). It provides a common API for interacting with hardware regardless of manufacturer.
Understanding XFS was a crucial part of the preparation, and also one of the most time consuming, due to its complexity and often proprietary nature.
Why XFS Matters for Security
The ATM application communicates through the XFS layer, which is responsible for sending commands to hardware components such as the cash dispenser.
Because of this:
- Access to XFS commands must be tightly controlled
- Compromising XFS could allow direct hardware manipulation
- Understanding XFS is critical for ATM security assessments
This part of the preparation was by far the most time-consuming due to proprietary implementations and extensive documentation.
Pentest approaches
White-Box vs Grey/Black-Box
- White-box testing: Requires deep architectural knowledge
- Grey/black-box testing: Depends on whether access to the ATM OS or application is achievable
Standard Testing Mindset
Ultimately, ATMs should be treated like any network-connected device. This means testers often rely on standard techniques such as:
- Port scanning
- Vulnerability scanning
- Exploitation attempts
However, ATMs come with specific threat models that must be considered.
Network Traffic Sniffing
Another important testing activity is analyzing captured network traffic.
Challenges
Network traffic analysis can be extremely complex due to:
- Large volumes of data
- Proprietary and obscure protocols
- Lack of documentation
Benefits
Despite the challenges, it provides valuable insights:
- Detection of weak or plaintext communications
- Understanding system interactions
- Identification of hidden configurations
In fact, some of the most interesting findings came from this phase.
Defense in depth
Insights from network analysis led to a broader security consultancy effort.
Security Improvements Implemented
Together with the technical team, we developed tailored patch packages to achieve:
- Enable only necessary system and network services
- Prevent the ATM application from being exposed on network interfaces
- Harden the operating system and services according to industry standards
- Restrict inbound access using firewall policies
- Strengthen encryption settings and protocols
- Eliminate all plain text communication between systems
Happy Ending
By combining all these measures and adding additional controls such as:
- IP-based access restrictions
- Two-way certificate validation
The network-related attack surface was dramatically reduced. At this point, IT-based attacks became extremely unlikely, even with direct physical access to the ATM. In simple terms: if someone wants unauthorized cash now, they would need to resort to physical methods.