The FBI’s February 19, 2026 FLASH advisory (FLASH-20260219-001) documented something that should prompt a serious conversation in every bank, credit union, and fintech security team: over 700 ATM jackpotting incidents occurred in the United States in 2025 alone, resulting in more than $20 million in direct losses. Since 2020, roughly 1,900 incidents have been logged. The Department of Justice puts the total losses attributed to jackpotting since 2021 at approximately $40.7 million.
These aren’t theoretical numbers pulled from a threat model. They represent cash physically emptied from machines by organized criminal operations using methods that have been documented and studied for over a decade.
Where This Started#
The Ploutus malware family was first observed in the wild in Mexico in 2013. Early versions required an attacker to physically attach an external keyboard to the compromised ATM and enter a time-limited eight-digit activation code, delivered by their handler. A subsequent variant, Ploutus.B, added the ability to trigger cash dispensing via SMS sent from a USB-connected mobile phone attached during the initial install. That was considered operationally sophisticated at the time.
By 2017, a new iteration called Ploutus-D had been engineered to interact with Kalignite, KAL’s multivendor ATM platform, which runs across roughly 40 ATM manufacturers in 80 countries. Mandiant’s analysis of Ploutus-D noted that minimal code changes would be sufficient to target a wide range of ATM vendors beyond the initial Diebold targets. The attacker who built this malware clearly had intimate knowledge of ATM software architecture, almost certainly from access to physical machines purchased through legitimate channels or reverse-engineered vendor middleware.
In January 2018, the U.S. Secret Service began warning domestic financial institutions that Ploutus-D had arrived on American soil. The attacks at that time focused on older Diebold Opteva series machines. The warning received attention, some hardening guidance went out to vendors, and the industry largely moved on.
It never went away.
The current U.S. wave is being driven by organized criminal networks operating with a clear division of labor. In January 2026, the Department of Justice announced charges against 54 individuals in connection with jackpotting operations across multiple states. The operations reflect a well-developed criminal supply chain: technical personnel who develop and maintain the malware, recruiters who source money mules, installers who execute the physical attacks, and a logistics layer handling cash collection and laundering, including through cryptocurrency wallets that federal prosecutors have since frozen.
What the Malware Actually Does#
Understanding why jackpotting is so effective requires a look at how ATM software is structured, because the exploit is as much architectural as it is technical.
Most ATMs run on a version of Microsoft Windows. Windows was never designed to run ATMs, so the industry developed eXtensions for Financial Services (XFS), an open-standard API that creates a uniform software layer between the Windows host and the ATM’s physical hardware: the cash dispenser, card reader, PIN pad, and receipt printer. ATM vendors typically add a middleware layer between their application software and XFS. NCR uses Aptra; Diebold uses Agilis; KAL’s Kalignite is cross-vendor.
Under normal operation, a customer transaction follows this path: card inserted, PIN entered, bank authorization received, XFS instructed to dispense cash. Authorization from the bank’s backend system is a required step before the dispenser releases anything.
Ploutus bypasses this entirely.
Once installed on an ATM, Ploutus communicates directly with the XFS layer, using libraries such as MSXFS.dll and Kalignite’s K3A.Platform.dll, and issues dispense commands directly to the hardware. There’s no bank authorization step. There’s no transaction record on the backend. The machine simply opens the cash cassette and pushes out bills until the attacker stops it or the cassette is empty.
From the FBI advisory: the malware can be used across ATMs of different manufacturers with very little adjustment, because it exploits the Windows operating system rather than targeting vendor-specific code. This is the detail that makes it a systemic concern rather than a vendor-specific problem.
Ploutus-D also achieves persistence. It installs itself as a Windows service, commonly named with generic or deceptive labels like “DIEBOLDP,” and modifies Windows registry keys under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon to ensure it survives reboots. The FBI advisory specifically lists these persistence mechanisms as indicators of compromise.
How Attackers Get In#
Every known Ploutus attack requires physical access to the ATM’s internal components. There’s no remote exploitation pathway. This is simultaneously the malware’s biggest limitation and the reason it has proven so difficult to stop at scale.
The typical attack sequence, based on the FBI advisory and industry reporting, looks like this:
The attacker opens the ATM cabinet using a generic maintenance key. These keys are widely available for purchase online, the same keys that allow legitimate technicians to service the machines. The FBI advisory specifically calls out this vulnerability, recommending that institutions replace standard locks with non-generic alternatives.
Once inside, the attacker either removes the hard drive, connects it to a laptop, copies the malware to the drive, and reinstalls it; or replaces the drive outright with one preloaded with the malicious payload. The machine is rebooted. The attacker leaves. A mule returns later, triggers the cash-out, and collects the bills.
The physical indicators from the FBI advisory are worth documenting for any security team that manages or monitors ATMs: door open alerts outside of planned maintenance windows, unexpected out-of-service status, unusually fast cash depletion, unauthorized devices connected to the machine, and any evidence of hard drive removal.
On the digital side, the advisory provides specific file names to hunt for, including Newage.exe, Levantaito.exe, NCRApp.exe, WinMonitor.exe, and Anydesk1.exe. Associated scripts include Restaurar.bat, Restauraropteva.bat, and Borrar_beta.txt. These names should be incorporated into any endpoint monitoring policy for ATM environments.
The FBI also provides an attack timeline for log correlation:
| Step | Windows Event ID |
|---|---|
| USB device inserted | 6416 |
| Malware copied to drive | 4663 |
| Malware executed | 4688 |
| Service installed | 4697 |
| Logs cleared | 1102 |
That event sequence, if observable in a SIEM, is an unambiguous indicator of a jackpotting attack in progress or recently completed.
A Global Problem emerging into the US#
The U.S. is seeing the sharpest increase right now, but jackpotting has a longer and wider history than the domestic headlines suggest.
Europe dealt with significant jackpotting activity for years. In 2017, Europol publicly warned that ATM malware attacks were increasing across the region and coordinated multiple enforcement actions. As recently as late 2025, Europol arrested two Belarusian nationals in Warsaw who had conducted black-box jackpotting attacks across at least seven European countries, stealing an estimated 230,000 euros.
The contrast to the current U.S. situation is worth examining carefully. The European Association for Secure Transactions (EAST) reported that confirmed ATM malware attacks across Europe dropped from three incidents in the second half of 2024 to effectively zero in the first half of 2025. The contributing factor cited was adoption of coordinated ATM hardening guidance. Physical attacks continued, but the software-based variant became significantly less viable as institutions followed through on implementing software controls.
That’s a meaningful data point. Hardening works, and Europe’s trajectory demonstrates it in the aggregate. The U.S. hasn’t yet crossed that threshold.
Southeast Asia has also seen jackpotting activity. ATM attacks in Indonesia and other parts of the region have been documented, and the GoldFactory criminal cluster, associated with malware families including Gigabud.RAT and MMRat, has been linked to financial fraud operations across the region. The global picture is of a threat that migrates toward softer targets, and right now, the United States qualifies.
The Software Layer Is the Battlefield#
The attack surface for jackpotting isn’t a firewall configuration or a web application. It’s the software stack running inside the ATM cabinet: the operating system, the firmware, the middleware, and the application layer. The criminal groups exploiting this stack have studied it carefully. The defenses need to match that level of focus.
ATM manufacturers don’t develop security guidance in isolation. The PCI Security Standards Council, formed by the major payment card brands, has worked with ATM manufacturers, integrators, and operators to define security requirements and guidance across the full ATM ecosystem. In January 2013, the PCI SSC published its ATM Security Guidelines as a supplement to the PCI PTS (PIN Transaction Security) standard. The document was authored specifically for ATM manufacturers, software integrators, application developers, deployers, and operators.
More than a decade later, the attack patterns documented in the FBI’s February 2026 FLASH advisory map precisely to the threat scenarios that 2013 guidance was written to address. Section 4.2 of the PCI SSC ATM Security Guidelines covers security of basic software, with targets explicitly including the operating system, BIOS, and middleware layers: XFS, CEN XFS, CEN J/XFS, multivendor software, and open protocols. The section defines ten security objectives covering everything from OS hardening to remote access controls to audit logging.
The attacks happening today are the attacks that document warned about. The guidance was accurate. It hasn’t been universally applied.
The Ten Software Security Objectives#
The PCI SSC framework describes what software security for an ATM actually requires. These objectives aren’t aspirational; they describe the attack surface that Ploutus and similar malware exploit when they aren’t met.
B1: Prevent OS and software abuse. The operating system should be hardened to prevent privilege escalation, exploitation of default accounts, installation of malicious software, and unauthorized access to resources including USB ports, CD/DVD drives, and hard disks. Application separation should be enforced at runtime. It shouldn’t be possible to install unauthorized software with or without physical access, and the OS vendor’s own hardening guidance should be followed strictly. Ploutus-D exploits every gap in this objective: it installs as a service, modifies autorun registry keys, and places itself in paths that may be whitelisted by antivirus because they mimic legitimate vendor tooling.
B2: Prevent exploitation of public domain vulnerabilities in open protocols. The minimum set of protocols in use should be subject to regular security review and patching. XFS is an open standard, and its attack surface has been documented publicly since at least 2013. Vulnerabilities in how ATM vendors implement XFS interfaces have been studied and exploited by criminal groups that purchase commercial ATMs to analyze them before deploying attacks in the field.
B3: Reduce the attack surface from public and private networks. The ATM’s communication interface should be hardened. ATMs connected to networks represent a remote access pathway that, while not the primary vector for Ploutus, has been used in other jackpotting campaigns. Remote management tools like AnyDesk and TeamViewer appear in the FBI’s IOC list because attackers use them to maintain post-compromise remote access after initial physical installation.
B4: Prevent abuse by third-party software suppliers. Software from middleware vendors and other third parties should be tested before installation or use. Several Ploutus variants disguise themselves as legitimate vendor management tools. Ploutus-D’s main executable was named AgilisConfigurationUtility.exe; the Ploutus-I variant observed in Latin American attacks used a filename mimicking an Itautec management tool. If third-party software isn’t tested and inventoried against a known baseline, these impersonations are difficult to detect.
B5: Use effective network isolation and intrusion detection. ATMs are frequently placed on network segments shared with general corporate infrastructure, which creates unnecessary exposure. Proper segmentation limits lateral movement and makes anomalous ATM network behavior detectable.
B6: Log OS activity. The OS should be configured to log all relevant events, including those described in the FBI advisory’s attack timeline. Log data should be stored in a way that can’t be changed or deleted without proper authorization. Ploutus-D is documented to clear the Windows Security log (Event ID 1102) to cover its tracks. If logs are stored only locally on the ATM, that step succeeds. If logs are forwarded to a centralized SIEM in near-real-time, log clearing becomes an indicator rather than effective cover.
B7: Protect sensitive functions and key-loading procedures. Access to the ATM controller should require administrator rights. Firmware loading and initial key loading should be controlled through appropriate dual-control procedures. This objective governs a class of attacks that go beyond jackpotting but share the same physical access threat model.
B8: Protect against unauthorized changes. This objective directly addresses the malware threat. Software configuration, including the operating system, drivers, libraries, and applications, should be protected against unauthorized modification. In practice, this means cryptographic integrity verification: file hashes validated against a controlled baseline, on a schedule, with results shipped off-device. This is what the FBI advisory calls “gold image integrity validation,” and it’s the single most effective software-level control against Ploutus-family malware.
B9: Prevent unauthorized remote control. Strict access-control procedures should govern any remote access for service purposes. The FBI advisory flags unauthorized instances of TeamViewer and AnyDesk as indicators of compromise. This objective provides the governance framework for ensuring that any legitimate remote access tool is explicitly whitelisted, requires authentication, and generates logs that are monitored.
B10: Prevent unauthorized software installation. ATMs operate a defined multi-layer software stack: the operating system, the platform with hardware drivers and XFS support, and the application layer. Each layer should be protected against unauthorized additions. Software whitelisting, where only approved executables are permitted to run, is the technical control most directly aligned with this objective. Combined with B8’s integrity verification, it represents a layered defense that forces any attacker to defeat both controls independently.
What Good ATM Security Actually Requires#
The FBI advisory’s recommendations span physical security, hardware controls, logging, auditing, network security, and endpoint protection. Several controls merit particular attention because they address the highest-impact points in the Ploutus attack chain.
Gold image integrity validation carries the highest detection value. Each ATM should be deployed from a controlled baseline containing cryptographically verified executables and configuration files. Deviations from that baseline, especially the presence of unsigned or newly introduced binaries, should trigger immediate investigation. As the FBI advisory notes, jackpotting threats rely on locally introduced files that bypass traditional network-based detection. Network monitoring alone won’t catch this.
Physical lock replacement sounds almost insultingly basic, but the current wave of attacks exploits the fact that generic ATM maintenance keys are purchasable online. Replacing standard locks with non-standard alternatives raises the barrier to entry in a concrete and immediate way.
USB port controls through hardware whitelisting remove the most common initial access vector. Disabling or physically blocking USB ports that aren’t required for operation eliminates a significant portion of the Ploutus infection pathway. The PCI SSC guidelines call this out directly under objective B1, and it maps to the FBI advisory’s hardware security recommendations.
Disk encryption at the hardware level prevents malware from being written to a disconnected hard drive. This control would eliminate the most common Ploutus infection method outright: remove the drive, connect it to a laptop, write the payload offline, reinstall.
Centralized log retention is the countermeasure to Ploutus-D’s documented log-clearing behavior. Logs forwarded off-device to a SIEM in near-real-time can’t be erased by clearing the local Windows Security log. Without this, the attacker’s cleanup step works.
Default credential changes are basic hygiene that the FBI advisory calls out explicitly, because compromised ATMs have been found retaining factory default administrative credentials. Physical access plus vendor default credentials equals elevated privileges without any additional exploitation.
The Structural Problem#
There’s a larger issue sitting underneath all of this. It’s not a vendor problem or a software problem in isolation. It’s a lifecycle and investment problem.
A significant portion of the global ATM fleet runs on Windows versions that have reached end of support. ATM software is certified against specific operating system versions, and migrating to a newer OS isn’t a simple patch deployment. It requires extensive testing, vendor coordination, and recertification. Banks with large fleets face multi-year upgrade programs that are expensive and operationally complex.
The criminal groups exploiting these machines understand this perfectly well. They don’t need zero-days. They need machines that haven’t been hardened, running operating systems without current security updates, accessible through generic keys, and logging nothing useful. Those machines still exist in large numbers.
Europe’s trajectory offers a realistic model. Coordinated adoption of hardening guidance produced measurable results within a relatively short window. The malware-based attack surface didn’t disappear, but it became substantially less exploitable.
The PCI SSC ATM Security Guidelines from 2013 remain a valid reference for anyone building or reviewing an ATM security program. The FBI advisory from February 2026 addresses the same threat scenarios that document anticipated. The gap between published guidance and operational reality isn’t a knowledge problem. It’s an implementation problem, and it’s costing the industry tens of millions of dollars annually.
For any financial institution or ATM operator that hasn’t reviewed its endpoint security posture against FLASH-20260219-001, that review is overdue. The IOCs, the event IDs, and the mitigation list are publicly available, TLP:CLEAR, and actionable without a vendor engagement or a consulting project to get started.
Resources#
- FBI FLASH Alert FLASH-20260219-001 (TLP:CLEAR) — Report suspicious ATM activity to your local FBI field office or the IC3
- PCI SSC ATM Security Guidelines Information Supplement, January 2013
- European Association for Secure Transactions (EAST) ATM Crime Reports
FLASH-20260219-001 is published TLP:CLEAR and is intended for broad distribution to encourage defensive action. The PCI SSC ATM Security Guidelines referenced are publicly available at the link above.
