ATM Security: Jackpotting and Black Box Defences

An ATM is a Windows PC bolted to a cash safe, and logical attacks succeed when it is secured like a kiosk rather than like a high-value endpoint. Jackpotting (malware that makes the machine dispense cash on command) and black box attacks (an unauthorised device wired to the cash dispenser) both exploit the gap between the hardened safe and the far softer computer above it. This guide covers the ATM architecture, the logical threat model, the hardening baseline for the operating system, BIOS, disk, peripherals and network, and how to monitor a fleet and respond. It is written for bank and independent ATM deployer security teams, ATM operations and the engineers who manage multivendor fleets. It is defensive throughout and does not describe attack procedures beyond what is needed to choose controls.

Key takeaways

Treat the top hat as a privileged endpoint: the PC core in the upper cabinet is usually far less protected than the safe, so lock, alarm and monitor it as a security boundary.
Allowlisting beats antivirus on a fixed-function device: an ATM runs a small, known set of software, so application control in enforced mode is the main defence against jackpotting malware.
Encrypt the disk with pre-boot protection so a removed or swapped hard drive cannot be altered offline, and secure the BIOS so the machine cannot be booted from external media.
Authenticate the dispenser: black box attacks work when the dispenser accepts commands from whatever is plugged into it; dispensers that require an authenticated, encrypted session with the PC core defeat them.
Service access is an identity problem: shared engineer passwords, default credentials and unmanaged remote management tools are how many fleets are reached. Give every technician and every management tool its own identity.

How an ATM is put together

Understanding the components explains where the controls go. Most modern ATMs, whatever the manufacturer, share the same layout.

Component	Where	Security relevance
PC core (computer, hard drive or SSD, USB ports)	Upper cabinet ("top hat"), often a lighter lock than the safe	Runs Windows and the ATM application; target of malware, drive replacement and USB attacks
Multivendor or vendor ATM application and XFS layer	On the PC core	Sends device commands (dispense, card read, PIN entry) through the CEN/XFS interface to device drivers
Cash dispenser	Inside the safe, cabled to the PC core	Target of black box attacks if the link to the PC core is not authenticated and encrypted
Encrypting PIN pad (EPP)	Fascia	Holds PIN encryption keys; certified under PCI PTS; key management falls under PCI PIN Security
Card reader	Fascia	Target of skimming and shimming; physical anti-skimming controls
Network connection to host or switch	Upper cabinet, often via a router or modem	Target of man-in-the-middle and host emulation if not encrypted and authenticated
Remote management agent	On the PC core	Software distribution and monitoring; a powerful privileged channel

NCR Atleos describes the logical threats to ATMs as continuing to evolve and including malware, DMA and man-in-the-middle attacks, and both major manufacturers present a layered model in which each control assumes another may be bypassed. For the general principles of fixed-function device hardening see the Embedded Device Security Guide; this guide focuses on what is specific to ATMs.

The logical threat model

Attack class	What the attacker needs	Primary defences
Jackpotting malware on the PC core	Ability to run code on the PC: physical access to USB or the drive, or a compromised network or management channel	Application control in enforced mode, disk encryption, BIOS lock, USB device control, top hat alarm
Hard drive swap or offline modification	Access to the top hat and a prepared drive	Full disk encryption with pre-boot authentication or network unlock; boot integrity checks
Black box attack on the dispenser	Access to the dispenser cable, often by drilling or opening the fascia	Authenticated and encrypted dispenser communication, physical protection of cables, safe sensors
Network man-in-the-middle or host emulation	Access to the ATM's network segment or router	TLS with mutual authentication to the host, message authentication, locked down router, segmentation
Abuse of remote management or service tools	Stolen or default engineer credentials, exposed management service	Per-person credentials, MFA on management consoles, allowlisted management agents, logging
Card skimming and shimming	Access to the fascia	Anti-skimming devices, EMV chip, fascia inspection, PIN shields

In January 2018 KrebsOnSecurity reported a US Secret Service alert on jackpotting attacks against stand-alone Diebold Nixdorf Opteva 500 and 700 series front-loading ATMs, typically at pharmacies, large retailers and drive-throughs. The reported pattern combined people posing as ATM technicians, physical access to the PC core and Ploutus.D malware triggered remotely, and the Secret Service urged operators to move off Windows XP. The lessons are still current: physical access to the top hat, weak service controls and an outdated operating system together were enough.

Hardening the PC core

ATMs typically run a Windows edition locked down by the manufacturer or deployer. The controls below use Microsoft features as examples because most fleets run Windows; equivalent vendor security suites provide the same functions.

Application control

Use App Control for Business (formerly WDAC) or a vendor allowlisting suite: Microsoft describes App Control as restricting which applications run and which code runs in the kernel, covering scripts, MSI packages and batch files, with PowerShell in Constrained Language Mode. On an ATM the allowed set is small: the OS, the ATM application, XFS service providers and drivers, and the management agent.
Audit, then enforce: run the policy in audit mode on a pilot group to capture every binary the ATM application actually needs, including during cash replenishment and maintenance flows, then switch to enforced mode.
Protect the policy itself: use signed policies so that an attacker with administrative rights cannot simply remove the allowlist.

Disk encryption and boot integrity

Encrypt the whole drive: with BitLocker, the TPM measures the boot chain (by default PCR 7 for Secure Boot state) and does not release the key if firmware, boot manager or boot configuration change, which stops a modified or swapped drive from being used.
Choose the unlock method for unattended devices: Microsoft recommends TPM plus PIN against skilled attackers with lengthy physical access, but notes that PINs complicate unattended reboots. BitLocker Network Unlock can unlock TPM plus PIN systems on a wired network with a Windows Deployment Services server, which fits ATMs on a private network. Many vendor suites instead bind the disk to the specific PC core hardware.
Secure Boot and BIOS password: enable Secure Boot, set a unique BIOS administrator password per device (stored in a vault, not a shared sheet), disable booting from USB and optical media, and lock the boot order. Microsoft lists a BIOS password as defence in depth for BitLocker.
Protect DMA ports: the BitLocker countermeasures guidance points to the policy Disable new DMA devices when this computer is locked and to Kernel DMA Protection where hardware supports it.

Peripherals and USB

Restrict device installation: under Computer Configuration, Administrative Templates, System, Device Installation, Device Installation Restrictions, enable Prevent installation of devices not described by other policy settings and list only the ATM's own peripherals in Allow installation of devices that match any of these device IDs. Microsoft warns that upstream hubs and controllers must also be allowed or keyboards and other devices stop working, so test on a lab ATM first.
Physically block unused ports inside the top hat and fit tamper evident seals that engineers must record when broken.

Accounts and services

Run the ATM application as a restricted account, remove interactive logon for local accounts, and disable unused services, shares and remote desktop.
Keep the OS supported: plan OS migrations years ahead. Machines on unsupported Windows versions were the specific concern in the 2018 alert.

Dispenser, PIN pad and network protection

Dispenser authentication: configure the highest protection level the dispenser supports so that it accepts only encrypted, authenticated commands from its paired PC core, and requires a physical authentication step (for example a safe-side action) to pair a new PC core. This is the control that defeats black box attacks, and it is often available but not enabled on older fleets.
Encrypting PIN pad and keys: use PCI PTS approved EPPs and run remote or manual key loading under PCI PIN Security, which covers key creation, transfer, loading, use and administration.
Host communication: use TLS with certificate validation between the ATM and the host or switch, plus message authentication of transaction messages where the host protocol supports it, so host emulation from the local segment fails.
Network segmentation: place ATMs on a dedicated network that can reach only the host, the management servers and update servers; deny ATM to ATM traffic; lock down and monitor the branch router or 4G modem.
Physical layer: stronger top hat locks with unique keys, door and vibration sensors on the upper cabinet wired to the alarm system, and cable protection between the PC core and dispenser.

Where identity fits

Many fleet compromises start with access, not malware. ATMs are serviced by internal engineers, manufacturer technicians, cash-in-transit crews and independent service organisations, and managed by remote tools running with high privilege.

Identity	Typical weakness	Control
Engineer and supervisor mode passwords	Shared across the fleet, rarely rotated, known to former contractors	Per-person or per-visit credentials, one-time codes issued by a back office, automatic expiry
Local Windows administrator	Same password on every ATM	Unique per-device password managed centrally (for example Windows LAPS) and vaulted
BIOS administrator password	Factory default or one value per model	Unique per device, stored in a vault, retrieved with approval
Remote management and software distribution service accounts	Broad rights across the whole fleet, long-lived credentials	Least privilege, MFA on the console, signed packages, change approval and logging
Host and key-loading certificates	Long validity, unclear ownership	Inventory, owner, expiry monitoring and documented renewal

In the 2018 alert the attackers posed as technicians, which is why physical visit verification matters as much as technical controls: schedule every visit, verify identity on arrival and alert on top hat openings without a matching ticket. See the Privileged Access Management Guide for vaulting and approval workflows, and the Local Administrator Password Solution (LAPS) Guide for unique local administrator passwords.

Monitoring and response

A fleet produces two useful signal streams: device and application events from the ATM software and Windows logs from the PC core. Forward both to the SOC, not only to the ATM operations team.

Device state anomalies: an ATM showing "out of service" while the dispenser is active, dispense events with no matching host authorisation, or a dispenser reconnecting to a new PC core.
Top hat and safe sensors: openings outside scheduled visits, or network cable disconnections followed by reconnection.
Windows and allowlisting events: App Control block events, new device installations, service installs, local logons and reboots outside maintenance windows.
Management channel: software packages deployed outside change windows or by unexpected accounts.

Contain: on a suspected logical attack, take the ATM out of service remotely and block it at the host so it cannot authorise transactions.
Preserve evidence: keep the hard drive, application journals, electronic journal, logs and any foreign devices found; do not reimage before forensic capture. Check CCTV.
Check the fleet: query every ATM of the same model and configuration for the same indicators, since attacks are usually repeated.
Notify: law enforcement, the ATM manufacturer, the card schemes as their rules require, and banking regulators where an incident meets reporting thresholds.

Rolling out a hardening baseline

Inventory: list every ATM with model, OS version, application version, dispenser protection level, disk encryption state, BIOS settings and management agent.
Prioritise by exposure: stand-alone and off-premises machines (retail, drive-through) first, then through-the-wall units in branches.
Lab test: build the baseline on a lab ATM of each model, including application control in audit mode, device installation restrictions and dispenser protection, and run every business flow: withdrawals, deposits, replenishment, engineer mode and remote updates.
Pilot ring: deploy to 1 to 5 percent of the fleet, monitor availability and blocked events for two to four weeks.
Enforce in waves: move to enforced mode by model and region.
Rollback: keep a signed, known-good policy package and a field procedure for engineers to revert a device to audit mode under approval if a policy blocks the ATM application.

Deployer size: a bank with a single-vendor fleet can usually rely on the manufacturer's security suite and its managed services. An independent ATM deployer or a bank with a multivendor fleet needs a vendor-neutral baseline, its own key and credential management and contractual security requirements on service organisations.

Measuring it

Allowlisting coverage: percentage of ATMs with application control in enforced mode.
Disk and boot protection: percentage with full disk encryption, Secure Boot and a unique BIOS password.
Dispenser protection: percentage of dispensers at the highest supported authentication level.
Supported OS: percentage of the fleet on a supported operating system version.
Unmatched top hat openings: count of openings without a matching service ticket, and mean time to investigate.
Shared credentials: number of ATMs still using fleet-wide engineer, local admin or BIOS passwords.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK (Enterprise)
Application allowlisting	CM-7 Least Functionality, CM-14 Signed Components	PR.PS	Defends against T1204 User Execution and malware execution generally
Disk encryption and boot integrity	SC-28 Protection of Information at Rest, SI-7 Software, Firmware, and Information Integrity	PR.DS, PR.PS	T1542 Pre-OS Boot
USB and device control	MP-7 Media Use, CM-7	PR.PS	T1200 Hardware Additions, T1091 Replication Through Removable Media
Engineer and admin credentials	IA-5 Authenticator Management, AC-6 Least Privilege	PR.AA	T1078 Valid Accounts
Remote management channel	AC-17 Remote Access, CM-3 Configuration Change Control	PR.AA, PR.PS	T1219 Remote Access Tools
Host communication	SC-8 Transmission Confidentiality and Integrity, SC-23 Session Authenticity	PR.DS	T1557 Adversary-in-the-Middle
Physical protection of the top hat	PE-3 Physical Access Control, PE-6 Monitoring Physical Access	PR.AA, DE.CM	Not applicable

Common failure patterns

Antivirus only: signature-based tools on an ATM do little against custom jackpotting malware; allowlisting in enforced mode is the control that matters.
Dispenser protection left at the lowest level because it was the factory default or because pairing slowed down engineers.
Fleet-wide secrets: one engineer password, one BIOS password and one local admin password across thousands of ATMs.
Weak top hat: a generic key opens the upper cabinet on many machines, with no sensor on the door.
Unsupported operating systems kept running because the ATM application has not been certified on a newer version.
ATM events not in the SOC: device logs stay with ATM operations, so a dispense without authorisation is treated as a fault rather than an attack.

Practitioner checklist

Inventory every ATM with OS, application, dispenser protection, encryption and BIOS state.
Enforce application control on the PC core after an audit-mode pilot.
Encrypt disks with TPM-based protection and lock BIOS and boot order with unique, vaulted passwords.
Restrict device installation to the ATM's own peripherals and seal unused ports.
Set dispensers to the highest authenticated and encrypted communication level.
Use TLS with certificate validation to the host and segment the ATM network.
Replace shared engineer and local admin credentials with per-person or per-device credentials.
Alarm top hat openings and match every opening to a service ticket.
Send ATM device events and Windows logs to the SOC with jackpotting detections.
Keep a tested incident playbook covering remote shutdown, evidence preservation and fleet sweep.

ATM Security Guide: Hardening ATMs Against Jackpotting and Black Box Attacks