Security Highlight: ATM Jackpotting as a Case for Hardware-Rooted Trust

ATM jackpotting is an attack technique that combines physical access with software compromise to force cash machines to dispense money without a legitimate transaction or bank authorization. Recent FBI reporting shows a sharp rise in these incidents, with more than 700 confirmed cases in 2025 alone and total losses exceeding $20 million.

In response, the FBI has issued updated guidance outlining indicators of compromise (IoCs) and recommended controls spanning physical security, hardware protection, and system integrity. Critically, this guidance emphasizes that jackpotting is not simply a malware problem. At its core, it represents a breakdown of device trust.

This security highlight examines how physical access and operational design choices amplify risk, framing ATM jackpotting as a broader device security failure—with lessons that extend well beyond the financial sector.

Incident Analysis: How Jackpotting Works

The primary enabler of ATM jackpotting attacks is physical access. In many documented cases, attackers gain entry to ATM internals using widely available, generic physical master keys. Once access is achieved, threat actors typically compromise the system using one of two methods:

• Hard drive manipulation: Removing the ATM’s hard drive, connecting it to an external laptop to install malware, and reinstalling it.
• Drive replacement: Fully replacing the original hard drive with a rogue device preloaded with malicious software.

These attacks succeed because ATM designs have historically prioritized protection of the cash vault over protection of the electronic systems that control cash dispensing.

The most common malware observed in these incidents belongs to the Ploutus family. Ploutus targets the Extensions for Financial Services (XFS) layer, the software interface that converts digital commands into physical actions such as dispensing cash.

By issuing direct instructions to XFS, the malware bypasses bank authorization and customer account checks entirely. Because it exploits the underlying Windows operating system used by many ATMs, Ploutus can be deployed across different vendors with minimal customization. These “cash‑out” operations often take only minutes, limiting opportunities for real‑time detection.

Recommended Mitigation Strategies

The FBI recommends a layered defense approach that mandates a 360^O view on physical security and focuses on device level integrity.

1. Physical Security Controls

Because many attacks begin by opening the ATM cabinet, physical hardening is the first line of defense. This should consider all assets not just those with high monetary value such as the cash vault.

• Locks and access controls
  Replace standard manufacturer locks with unique, high security locks. Adding PIN‑based keypads further reduces the risk posed by generic keys that can be purchased online or via social engineering.
• Tamper and environmental sensors
  Install vibration, temperature, and door sensors inside the ATM and surrounding vestibule. These controls provide real‑time alerts when drilling, heating, or forced access attempts occur.
• Port protection and device whitelisting
  Attackers often connect unauthorized phones or removable drives through exposed USB or serial ports. Hardware whitelisting ensures only approved, authenticated peripherals can interact with the system.

2. Establishing Root of Trust and Data Integrity

A central weakness exploited in jackpotting attacks is the ability to remove, modify, or replace storage media. All critical operations should be subject to proving a chain of trust exists to the infrastructure provider.

• Full‑disk encryption (FDE)
  Encrypting the hard drive prevents offline malware injection if the drive is removed and connected to another system.
• Firmware integrity verification
  Use a Trusted Platform Module (TPM) to perform cryptographic signature checks during boot, ensuring firmware and boot components have not been altered.
• Hardware level permissions
  Enforce strict trust boundaries between internal components so that critical interfaces like XFS only accept commands from authorized processes.
• Automatic protective shutdown
  Configure ATMs to enter an out‑of‑service or shutdown state when a defined combination of jackpotting IoCs is detected, limiting potential cash loss.

3. Operational and Monitoring Controls

Technical defenses must be reinforced by strong operational practices.

• Conduct targeted audits of removable media usage, file access, and process creation to detect early malware staging.
• Validate system integrity against known good “gold images.”
• Perform penetration testing focused specifically on physical intrusion paths, unattended ports, and enclosure weaknesses.
• Assess new hardware models pre‑deployment for device level security gaps.

Implications for Device Security in Critical Industries

ATM jackpotting exposes a systemic flaw in how high‑value automated devices are assessed and secured. In high-risk public or otherwise uncontrolled environments, physical access must be treated as part of the threat model. Once attackers can reach internal components, gaps in storage security, boot verification, interface control, and tamper detection can quickly escalate into full device compromise.

A fundamental deliverable in security assessment is a TARA (Threat Analysis and Risk Assessment) model. A robust TARA maps the attack paths an adversary may follow by identifying the system’s assets, the threats those assets face, and the vulnerabilities that could be exploited. Effective assessment must look beyond cybersecurity alone and account for physical, technical and personnel security, because real-world attacks often succeed by combining weaknesses across these domains.

Resilient device security is built on trust at every layer. Confidentiality, integrity, and availability should work together as part of a unified security architecture. That foundation begins with a hardware root of trust (HRoT), which establishes a chain of trust from core infrastructure to remote devices and helps maintain it throughout the device lifecycle. HRoTs can be discrete devices or integrated on a SoC. In both cases, devices or IP cores must be certified to a high level of assurance using industry standard protection profiles. Certification provides evidence of resistance to attacks that seek to break the chain of trust. An emerging approach is open source and the Caliptra™ HRoT offers full transparency and an assessment framework to audit designs using it.

What This Means in Practice

For existing designs, the FBI bulletin shows that security controls may be present but not enabled — or could be bypassed using an alternative vector. Security assessments should verify not only that protections exist, but whether they are enabled, correctly configured, and resilient against realistic attack paths.

For new designs, physical access should be treated as part of the threat model, with security anchored in a hardware root of trust to establish integrity from the start.

As more systems move into public and uncontrolled environments, the future of device security depends on enforceable trust, rooted in hardware, firmware integrity, and encryption.

If your team is adopting Caliptra™, we can help assess your design and support you through Caliptra trademark audits. Reach out to our team at [email protected].

Want more stories like this? Subscribe to the Keysight Device Security Bulletin for monthly highlights on device security trends and practical insights — brought to you by the Keysight device security team.

Related Posts