04.12.2025
8 min
532
In this article, we explain in simple terms what jackpotting is, why attackers have returned to targeting ATMs themselves, and what risks this creates for financial institutions. The material combines real-world cases with a practical view of the threat, without going into unnecessary technical complexity.
Criminals are no longer interested only in customer data. More and more often, they are once again targeting the machines themselves. ATM jackpotting is a cyberattack at the intersection of the digital and physical worlds that forces an ATM to dispense all of its cash. Today, local and community banks are the ones most often in the crosshairs.
While most banks are well familiar with digital fraud or card skimming, jackpotting poses a far more direct and dangerous threat to physical cash assets. Unlike traditional schemes focused on stealing personal data or payment details, ATM jackpotting targets the ATM itself, bypassing software protections and interfering with hardware in ways that standard security controls often fail to detect in time.
ATM jackpotting is a method of manipulating an ATM, both physically and through software, to make it dispense large amounts of cash on command. The name comes from the image of an ATM literally “spitting out” money like a slot machine hitting a jackpot. But unlike gambling, in real life the odds are often stacked against the bank if its defences are not strong enough.
These attacks usually begin with access to the ATM cabinet and its internal components. Once inside, attackers install malicious software or connect an external device such as a black box that takes control and bypasses normal operating mechanisms. This allows them to completely empty the cash cassettes within minutes, sometimes stealing more than $100,000 from a single machine.
The key difference between ATM jackpotting and skimming or classic digital fraud is that attackers do not steal customer data or withdraw funds from individual accounts. They steal directly from the bank, creating an immediate financial loss and a serious reputational risk for the financial institution.
In April 2025, the Kansas Community Bankers Association issued an urgent warning after a series of ATM attacks in Salina and Wichita. These were not crude “smash and grab” incidents. The attackers operated with specialised tools and careful preparation. In particular, they:
quietly gained access to the ATM cabinet
disconnected the standard cash dispenser hardware
installed black box devices with preconfigured jackpotting software
The incidents took place late at night and targeted standalone ATMs in areas with weaker oversight. Even when video surveillance and alarm systems were in place, there was often not enough time to respond and prevent the theft.
These events highlight an uncomfortable but important reality. ATM jackpotting is not a theory and not a problem limited to large cities. These attacks are already happening at community banks, in small towns, and in places where the risk once seemed minimal.
Although the exact details may vary, most jackpotting attacks follow the same basic logic and go through several consecutive stages:
Physical access. The attacker opens the ATM cabinet using tools, often disabling or bypassing tamper sensors.
Hardware manipulation. The cash dispenser is disconnected from the ATM’s standard controller.
Black box connection. An external device is connected to the dispenser, interacting directly with the hardware and bypassing software protection.
Cash dispensing. After control is taken, the ATM begins dispensing cash continuously. The entire process often takes less than ten minutes.
In some cases, attackers disguise themselves as technicians or security staff to avoid suspicion during working hours and calmly complete the attack.
Not all ATMs face the same level of risk. Several warning signs can indicate increased exposure to jackpotting attacks:
Outdated operating systems. ATMs running unsupported systems, such as Windows 7, no longer receive critical security updates and remain exposed to known vulnerabilities.
Lack of tamper protection. No physical alarms, intrusion sensors, or strong locks to prevent unauthorised access to the cabinet.
Minimal monitoring. Standalone or drive-up ATMs are not under constant observation through video surveillance, telemetry, or third-party monitoring services.
Irregular IT and physical inspections. No scheduled reviews of firmware, hardware condition, or log analysis for suspicious activity.
Community banks do not need to urgently rebuild their entire ATM infrastructure. But if we look at the situation realistically, without basic and well-thought-out measures the risk of attacks remains fairly high. To reduce the likelihood of jackpotting, it is worth starting with simple but important steps:
Software updates: ATMs should run on supported operating systems, and all security updates must be installed on time. If an ATM is still using an outdated version of Windows, it should be upgraded or its network access should be strictly limited.
ATM monitoring: Continuous monitoring of ATM activity helps detect unusual behaviour early, such as unexpected reboots or the connection of unauthorised devices.
Physical security: In practice, many attacks succeed because of weak physical controls. Strong locks, cabinet opening sensors, proper lighting, and cameras significantly complicate access to the ATM.
Staff awareness: Employees should understand what normal ATM operation looks like and what should raise concern. Even small details can sometimes be critical.
Incident response: When suspicious activity appears, it is important not to improvise but to follow a prepared plan, from quickly taking the ATM offline to preserving technical evidence.
Partner cooperation: ATM manufacturers and specialised IT providers usually know the weak points of their solutions and can offer additional protection mechanisms specifically against jackpotting.
For community banks, ATMs are often a key element of customer trust. A single successful attack can destroy that trust very quickly. That is why prevention, regular checks, and incident readiness matter far more than they may seem at first glance.
Yes, especially if at least one of the following conditions applies:
you operate drive-up or standalone ATMs without 24/7 monitoring
the ATM operating system is outdated or lacks modern security controls
physical break-in and response scenarios have never been tested
staff are not trained to recognise social engineering or signs of tampering
Community banks are often pillars of their local communities, but that trust can be easily lost after a successful jackpotting attack, especially if it turns out that basic security measures were not in place.
ATM jackpotting is no longer a problem limited to international crime groups or large cities. It is a local, well-prepared, and very real threat to community banks that lack modern approaches to IT and physical security.
Now is the right time to review the condition of your ATMs, assess existing safeguards, and prepare your team. If needed, bring in external experts to strengthen defences before attackers find the weak spot.
We have seen attacks like these many times in films and read about them in cybersecurity reports. And yet one question remains open: what does it really take to carry out a jackpotting attack against a real, live bank ATM?
As part of one engagement with a large commercial bank, we were asked to assess the security of an ATM protected by a well-known security solution designed to block unauthorised code execution on critical systems. We were given full network and physical access to an NCR-manufactured ATM, one of the most widely used ATM platforms in the world. The main goal was to identify possible attack vectors.
To move forward, it was first necessary to understand how a modern ATM actually works. That is where it makes sense to start, before moving on to questions of bypassing protective software and the later stages of an attack.
A typical ATM is built around a Windows-based computer and includes many hardware components. These include the banknote and coin dispenser, camera, touchscreen, card reader, and other modules. Each ATM manufacturer develops its own drivers and service components to operate this hardware. In theory, a shared middleware layer known as XFS, which most ATM vendors follow, makes it possible to run the same application on devices from different manufacturers. XFS is responsible only for passing commands to hardware components and does not include built-in security mechanisms. If an attacker manages to execute compiled code on an ATM, this effectively means full control over the machine. We used this middleware layer to force the dispenser to repeatedly eject banknotes until the cash cassettes were empty.
Since we had no prior experience developing software with XFS, we first tried to find documentation and code examples in open sources. Unfortunately, apart from general CEN materials, there was very little available, and most of the documentation we found was incomplete or fragmented. Fortunately, we were not the first to attempt this kind of attack. There are several well-known examples of ATM malware capable of dispensing cash from NCR-manufactured ATMs. While the source code of such malware is not publicly available, there are many detailed write-ups and analyses of ATM malware online that help fill in the gaps when it comes to understanding how XFS is implemented on NCR ATMs. We even turned to analyses of malware known as GreenDispenser, simply to see which arguments are passed in XFS API calls.
Eventually, we were able to outline the following sequence of actions:
Import msxfs.dll Call WFSStartUp Call WFSOpen with the name of the cash dispenser device (obtained from the ATM registry) Call WFSExecute with the WFS_CMD_CDM_DISPENSE command and WFSCDMDISPENSE structure with the desired amount to be dispensed set Call WFSExecute with the WFS_CMD_CDM_PRESENT command to present the cash notes Loop until cash cassettes are empty
Once we had decided which compiled code we wanted to run on the ATM, the hardest part still remained. We needed to bypass the endpoint protection software. At first glance, this looked like a serious obstacle. All executable files on the system were whitelisted, and any attempt to run something unauthorised was immediately blocked.
However, there was one important detail in this setup. The bank allowed the use of PowerShell because scripts with the .ps1 extension are used during the ATM startup process. This meant we could load a compiled DLL into memory via PowerShell using reflective loading. A similar technique is used in tools such as Invoke-Mimikatz. An additional advantage of this approach is its low visibility, since the malicious code is never written to disk. That is why this method is considered fileless.
This fileless approach clearly shows how sophisticated modern ATM attacks have become. As demand for ATM malware source code grows on the black market, organisations increasingly need to focus on proactive defence. This includes regular code reviews, stronger endpoint controls, and full-scale penetration testing of ATM systems. These measures make it possible to uncover hidden attack paths before real attackers exploit them.
To put everything together, our malware took the form of a PowerShell script that loaded an embedded DLL encoded in base64. This DLL then used the XFS middleware layer to control the cash dispenser. Some implementation details are deliberately omitted, and no code examples are provided, as the bank quite reasonably considered this information sensitive. At the same time, the overall logic of this approach should now be clear.
With the malware ready, we identified two possible attack vectors:
attackers with access to the bank’s ATM network could remotely connect to an ATM and execute the malicious code
attackers with physical access to the ATM could plug in a device such as a Rubber Ducky with a preloaded script and launch it within minutes
The first scenario was fairly straightforward. With a sufficient level of access, any ATM can be attacked remotely from within the bank’s internal network. How difficult it is to obtain that level of access depends on the bank’s network security architecture, which is outside the scope of this article. In our case, we were granted remote desktop access to a lab ATM and were able to successfully execute the malicious code. The ATM started dispensing test banknotes, much to the surprise of the technical specialists present in the lab.
The second attack vector turned out to be even more interesting. To our surprise, we discovered that the ATM was running with a local administrator account already logged in. All that was required was to connect a keyboard. Of course, gaining access to an exposed USB port on an ATM is not trivial, but it is entirely possible. Insider-driven attacks are also far from rare. Once the keyboard was connected, we were able fairly quickly to find the key combination that exits kiosk mode and provides a full Windows desktop session.
After the security assessment was completed, the bank quite reasonably decided to replace the existing security software with a different solution. Among other protection mechanisms, the new solution places PowerShell into Constrained Language Mode. This significantly limits what scripts can do when interacting with the Win32 API and makes reflective loading of compiled executables much more difficult. As a result, the malicious approach we described lost its effectiveness and could no longer be used in practice.
