ATM & POS Penetration Testing

Many fielded ATMs still run Windows 10 IoT, older Windows Embedded builds, or a locked-down kiosk shell. POS terminals run vendor firmware on ARM. Standard scanners produce noise and miss the interesting failures: a debug UART left live, an unsigned firmware update path, a maintenance menu reachable with a default code. We test the device as the embedded system it is.

The dangerous scenarios are hybrids. Someone opens the fascia with a common key sold online, exposes the USB ports on the ATM core, boots off external media or attaches a malicious device, and then issues dispense commands. On the shop floor, an attacker swaps a POS terminal for a tampered clone or drops a network implant behind the counter. We reproduce these chains under controlled conditions so you see the full route, not an isolated finding.

A web bug leaks data. An ATM bug dispenses cash on the spot and the loss is booked the same night. That changes how we prioritize: anything that ends in cash-out, card cloning or a pivot to the transaction host is treated as critical and reported to you the day we confirm it, not at the end of the engagement.

We start by mapping the estate: ATM make and model, dispenser and reader vendors, the software stack (Kalignite, ProBase, a vendor multivendor layer, or a custom app), the POS terminal models, the payment application, and how each device reaches the network. From that we build a threat model specific to your hardware and pick the attacks worth spending time on.

With physical access agreed, we assess the enclosure locks, the separation between the top box and the safe, exposed USB and serial interfaces, and boot security. We check whether the machine boots from external media, whether BIOS or UEFI is password-protected, whether the disk is encrypted, and whether the maintenance and diagnostic modes are reachable without proper authentication.

This is the core. We attempt black-box dispensing by injecting commands into the CEN/XFS stack, test whether the middleware authenticates the source of a dispense request, and check the encryption between the ATM PC and the dispenser controller where the vendor supports it. On the transaction side we manipulate EMV and magstripe flows, replay and alter messages, and probe the card reader and encrypting PIN pad for tamper response and data leakage.

We trace the path from the terminal to the switch, the store server and the acquirer. Where a link is unencrypted we demonstrate man-in-the-middle on transaction traffic. On the host we test application whitelisting and its bypasses, local privilege escalation, credential reuse across the estate, patch state, and whether a compromised terminal can pivot into the wider corporate or store network. For POS we review the payment application and any P2PE implementation against the relevant PCI requirements.

You get an executive summary written for leadership and a full technical report. Every finding carries an impact statement, a CVSS score, exact reproduction steps, and a prioritized, practical fix. Once your team has remediated, we retest the affected items at no extra cost and confirm the fixes hold.

The dispenser accepts XFS commands without verifying they came from legitimate bank software. Someone with brief internal access to the top box can dispense the full cassette contents. This is the classic jackpotting outcome and it remains the highest-impact finding on many ATMs.

USB and serial ports live inside a top box protected only by a widely available key. Combined with a machine that boots from external media or has an unlocked BIOS, that gives an attacker code execution on the ATM core in minutes.

Whitelisting products such as vendor lockdown tools are often deployed with gaps: misconfigured rules, writable paths, or a signed interpreter that runs arbitrary script. We routinely get code running despite a whitelist that was assumed to be airtight.

Card readers without proper anti-tamper detection, missing or defeatable jitter, and PIN pads that do not respond correctly to tampering all allow card data and PIN capture. On POS we find terminals that store or transmit cardholder data outside the intended P2PE boundary.

A compromised terminal that sits on the same segment as the store server, or transaction messages sent without strong encryption, let an attacker intercept or alter payments and move deeper into the environment. Segmentation failures are one of the most common and most fixable issues we report.

Penetration testing of cardholder-data environments is required under PCI DSS 4.0, including requirement 11.4 for regular internal and external testing and segmentation validation. For the device hardware itself we align findings to PCI PTS POI expectations for tamper resistance and PIN protection, and we assess P2PE deployments against the SPoC and P2PE control objectives where they apply.

Transaction testing references the EMV specifications and ISO 8583 message handling, and we map dispenser and terminal findings to recognized ATM security guidance and the ATM industry association’s fraud-prevention recommendations. Where relevant we tie technical issues to MITRE ATT&CK for ICS and enterprise techniques so your blue team can build detection.

For banks and payment institutions across Europe, cash and payment hardware falls squarely inside operational resilience obligations under DORA, and testing evidence feeds the ICT risk-management and threat-led testing programmes that DORA expects. We can align the report to those needs on request.