10 years of virtual dynamite: A high-level retrospective of ATM malware
POSTED BY VANJA SVAJCE via Talos Intelligence
It has been 10 years since the discovery of Skimer, first malware specifically designed to attack automated teller machines (ATMs). At the time, the learning curve for understanding its functionality was rather steep and analysis required specific knowledge of a manufacturer’s ATM API functions and parameters, which were not publicly documented.
Before the discovery of Skimer, anti-malware researchers’ considered ATMs secure machines containing proprietary hardware, running non-standard operating systems, and implementing a number of advanced protection techniques designed to prevent attacks using malicious code. Researchers eventually discovered that the most popular ATM manufacturers use a standard Windows operating system and add on some auxiliary devices, such as a safe and card reader.
Over time, actors behind some of the newer ATM malware families such as GreenDispenser and Tyupkin realized that there is a generic Windows extension for Financial Services API (CEN/XFS) that can be used to make malware that runs independent of the underlying hardware platform, as long as the ATM manufacturer supports the framework. This malware can trick the machines into dispensing cash, regardless of whether the attacker has a legitimate bank card.
ATM malware has evolved to include a number of different families and different actors behind them, ranging from criminal groups to actors affiliated with nation states. The significance of ATM malware stems from the fact that it can bring significant financial benefits to attackers and as a consequence cause a significant damage to targeted banks, financial institutions and end users.
Now that this type of malware has been around for more than 10 years, we wanted to round up the specific families we’ve seen during that time and attempt to find out if the different families share any code.
ATM malware overview
ATM malware provided criminals with a subtler alternative to physically breaking into the safe built into the ATM. Before the appearance of ATM malware, criminals typically had to employ traditional ways of robbing ATMs, often pulling the physical device out of the ground or blowing it to pieces with dynamite. Obviously, these methods would quickly draw the attention of law enforcement and passersby.
Over the past 10 years, we have seen a steady increase in the number of ATM malware samples discovered. Still, the number of discovered samples is very small compared to almost any other malware category.
Number of ATM malware samples discovered year over year based on the year of first submission to VirusTotal.
As a digital substitute for dynamite, ATM malware allows criminals to employ money mules and instruct them how to dispense money from targeted ATMs. Typically, it happens by supplying a special authorisation code or card created to authorise the transaction.
Before that, criminals had to infect the targeted ATM to install the code, which more often than not meant that they had to physically open the device to access its optical media reading devices or USB ports.
There have been many reported attacks on various banking organizations throughout the world, but they seem to be more prevalent in Latin America and Eastern Europe, where the ATM infrastructure is older and are not regularly updated with security software or tamper-proof sensors. The damage caused by ATM malware to banks and individuals is rarely disclosed but it likely reaches millions of dollars a year.
ATM malware affects banks and other financial institutions, as well as the reputation of ATM manufacturers and individuals and companies whose account details are stolen in ATM malware attacks.
There are several different ways we can classify ATM malware families. Based on its functionality, we can classify ATM malware into virtual skimmers and cash dispensers. The purpose of skimmers is to steal card and transaction details and individual PINs if the encryption keys used by pin pad are successfully retrieved.
Cash-dispensing malware uses functions to allow for so-called “jackpotting” of ATMs where money is dispensed by attackers without the authorisation from the bank. But there are malware families that can steal card details and dispense cash.
As far as the installation process is concerned, we again have two major groups. The first one requires the attacker to physically access the device. The second group assumes that the attacker installs malware indirectly, typically by compromising the internal network of the bank and then targeting ATMs using stolen credentials.
These types of malware will also either target specific models of ATMs, or will be more generic. Recently, ATM malware typically deploys generic functions.
The most common framework is the CEN/XFS framework, which allows the developers of the ATM applications to compile and run their code regardless of the ATM model or the manufacturer but there are others, such as Kalignite framework built on top of XFS.
The XFS API contains high-level functions for communicating with the various ATM modules such as the cash dispensing module (CDM), PIN pad (EPP4) or printer. The high-level functions are provided through a generic SDK, while the lower level functions, supplied through service providers, are developed by ATM manufacturers. The architecture is quite similar to Win32 architecture where the developers use the high-level API to communicate with the OS kernel and various device drivers provided by the manufacturers of the individual hardware components.
High-level CEN/XFS architecture.
Most ATM samples require physical access to the targeted ATM. ATMs are not typically connected to the internet and communicate with bank’s central systems through specialized lines. However, most of the ATMs are connected to internal networks for their maintenance and administration so the second, smaller group of ATM malware may be introduced by compromising the internal network first. This technique requires a higher level of sophistication but potentially brings higher returns if successful.
Some generic hacking tools, such as Cobalt Strike, have reportedly been used for attacking ATMs and the transaction systems. This method has been more commonly used by more advanced groups such as Carbanak, Cobalt Gang and Lazarus (Group 77), whose Fastcash attack affects IBM AIX operating system, which is rarely targeted by malware.
NOTABLE ATM MALWARE FAMILIES AND THEIR FUNCTIONALITY
Over the past 10 years, we have seen more than 30 different ATM malware families. In this section, we will briefly describe some of the more notable ones.
Number of ATM malware samples per family.
PloutusPloutus is the malware family with the largest number of discovered samples. The majority of them having been reported in Mexico. Ploutus is a standard ATM-dispensing malware. The attackers need to be able to access physical ports or a CD-ROM drive to be able to boot from it and modify the ATM system image to install the malware.
Attackers allegedly used newer Ploutus variants to attack some U.S.-based ATMs. Ploutus.D communicates with the ATM using the multi-vendor KAL Kalignite framework, which allows it to work with ATMs from different vendors with minimal changes to its code base.
One of the Ploutus variant’s interface.
SkimerSkimer is one of the first ATM attacks, and bears all of the features of well-developed malware. Skimer functions as a virtual skimming device that attempts to steal bank card numbers and details of the account and owner details stored on the magnetic stripe tracks 1 and 2. A recent review of its functionality also indicates that it may also attempt to steal users’ PINs by retrieving the encrypted pin pad encryption keys from the system.
Apart from the virtual skimming function, Skimer acts as a backdoor to the ATM functionality for its operators — money mules employed to collect stolen data and dispense cash.
Main code loop for servicing Skimer’s operators with cash.
If the user knows the secret code to activate the backdoor, the malware displays a menu, which allows the operator to empty one of the four cash-dispensing modules (CDMs).
The code locking the dispenser module and dispensing cash.
Most of the other ATM malware families follow a similar principle. The attackers need to be able to physically access the ATM, which requires a key or drilling a hole to access specific ports or devices. Once the malware is deployed, the money mules need a specific code to access the menu and dispense cash.
Tyupkin (Padpin)The most interesting characteristic of Tyupkin is that it has the ability to limit its operation to specific hours and days of the week. It was reported that some Tyupkin instances can only be used on Sundays and Mondays at night.
Tyupkin function for checking the hours of operation.
Before dispensing cash, Tyupkin disables any network connections, presumably to prevent administrators from shutting down the ATM if a suspicious activity is detected.
Some members of Tyupkin family are developed using C# and the .NET framework and some using Microsoft Visual C++. The family uses XFS API to manage infected ATMs and dispense cash in multiple currencies. Tyupkin has been active since 2014 and the associated gangs reportedly target Eastern European countries.
Alice follows a similar pattern to other ATM malware. It is installed by attackers and requires physical access to the system. When the operator launches it, Alice displays a window requiring a PIN.
First Alice screen.
If the code is correct, Alice will access the dispenser module and allow the operator to retrieve cash.
Main Alice UI window.
CutletCutlet, or Cutlet Maker, has been sold as a do-it-yourself ATM malware kit on some underground markets since 2016. The bundle contains detailed instructions in Russian and English on how to infect systems and how to acquire codes required to dispense cash.
Main Cutlet Maker user interface.
The Cutlet manual details operational security practices required to avoid being caught by law enforcement officers and shows where to drill holes in the ATM enclosure in order to access USB ports of a specific ATM model. The kit also contains a testing application named “Stimulator” for users to practice before they decide to conduct real attacks.
Cutlet follows a similar pattern to the previous ATM malware. The owner of the kit has the ability to generate codes per ATM required for its operation.
FastcashThe significance of Fastcash malware is its mode of operation and its targeting of IBM AIX operating system. Fastcash consists of a process injector and shared objects presumably injected into the process space of compromised bank payment authorization systems. The malware monitors ISO8583-based transactions using code from a fairly old open-source library for parsing ISO8583 packets.
If an ATM transaction contains the attackers’ codes, the data will not be forwarded to the original payment authorisation application and the transaction approval will be sent back to the target ATM system allowing attackers to dispense cash.
This mode of operation is similar to some rootkits, where malware attempts to hide its presence on the system by modifying the responses sent back from the operating system to the application that attempts to list system objects such as files or processes. The returned list is usually modified to remove names of processes that belong to the malware.
Fastcash has been attributed to the Lazarus Group and it is an example of a nation-state-related actor targeting financial systems for the attacker’s financial benefit. Fastcash shows a level of sophistication and knowledge that is not seen in other, run-of-the-mill, ATM malware.
CODE SHARING BETWEEN FAMILIES
Thanks to Xylitol and the ATM Cybercrime tracker, it was easy to retrieve a fairly complete ATM malware data set, with the addition of the few files connected with the Fastcash campaign.
The data set contains 121 files and it is well suited for analysis and clustering. Out of 121 files, there are 114 PE files and those were used for clustering using the static analysis techniques. Out of 114 PE files there were 37 packed files which may not be suitable for static analysis techniques and 20 DLLs.
While investigating various methods for clustering, we stumbled upon an interesting book, “Malware Data Science” by Joshua Saxe and Hillary Sanders. This book shows basic and more advanced methods for classifying and clustering malicious files and used some of the ideas to cluster our own set.
In our case, the clustering was conducted by extracting the following attributes of each sample:
- Strings extracted from the file
- Disassembled code from the entry point of the file
- File entropy and the presence of a known packer
- Imported or exported functions
- Embedded resources
After collecting the attributes from each sample, Jaccard distance is calculated for every pair of the files in the set. The Jaccard index is a measure of similarity between two sets. The more similar the two samples are, the higher their Jaccard index will be. The index is a number between 0 and 1. For example, the Jaccard index of 0.5 indicates 50 percent overlap between the two sets.
Clusters with Jaccard index threshold of 0.7.
We need to set the threshold required for two samples to be connected as a part of a single cluster. The higher the Jaccard threshold we choose, the more related will be the members of the defined cluster. By varying the threshold we come to the optimal value for our purpose. For example, for correct classification of samples we should choose the value higher than 0.7, and for code sharing purposes, higher than 0.3.
As expected, the results show that as we lower the thresholds we see more clusters appear and some of the clusters show overlap between distinct ATM malware families.
Clusters with Jaccard index threshold of 0.3.
The width of the lines in the graph show how strongly the files in the clusters are related. For example, we see that the members of individual GreenDispenser, Tyupkin or DispCash clusters are very closely related, while mixed Ligsterac/Skimer, Tyupkin/Dispcash and ATMtest/Helloworld clusters show weaker connections that likely indicate some overlap in the malware code.
Protection and detection best practices
When considering protection and detection of attacks with ATM malware, it is important to consider the physical security of ATMs, the security of software running on the system and the security of any segment of the organization’s network that communicates with ATMs.
Here are 15 best practices that organizations should follow when considering protection of ATMs networks and successful and timely detection of attacks when they happen.
- Ensure ATMs and all related systems run up-to-date software and the latest operating system versions with the latest security patches applied.
- Disable Windows AutoPlay and configure BIOS to disable the ability to boot software from USB sticks and CD/DVD drives. Set strong BIOS password protection to prevent boot settings from being changed.
- Disable access to the Windows desktop at the ATM, ensure RDP sessions are secured with multiple authentication factors such as Duo Authentication for Windows Logon and RDP.
- Remove any unused services and applications from the system to reduce the attack surface. Implement other measures to harden the underlying ATM operating system.
- Monitor the operation of ATMs, as well as their physical integrity. Look for unusual patterns of resets, communication failures and transaction volume.
- Implement strong encryption between the ATM and the host.
- Ensure access to the ATM cabinet is restricted to authorized persons and that such access is electronically logged.
- Perform a security assessment of ATMs, including their physical locations and any networks connecting to them.
- Ensure that firewalls and anti-malware protection are correctly configured.
- Configure whitelisting solutions or operating system features to allow only known, trusted software to run. Make sure that whitelisting cannot be disabled without generating a remote log entry.
- Prevent unauthorized USB devices from being installed using a device control function.
- Educate employees about how they can avoid introducing malware into operational systems.
- Maintain a physically and logically segmented network environment throughout the organization using segmentation technology such as Cisco TrustSec.
- Ensure visibility over network traffic to ATM systems and payment authorisation servers using technology that enhance network visibility, such as Cisco Stealthwatch.
- Monitor threat intelligence feeds to learn about newly detected ATM malware threats.
ATM malware is a niche area attacks, but it potentially brings significant benefits to actors that successfully manage to deploy it. Over 10 years since the discovery of the first specialized malicious code targeting the Diebold Agilis line of ATMs, we have seen over 30 other malware families with varying degrees of sophistication, complexity and success. Most of the successful attacks are reported in countries where the ATMs are older, such as some Latin American countries and Eastern Europe.
While the majority of actors behind ATM malware seem to be less sophisticated criminal actors, the potential of being able to dispense large amounts of cash also attracts more sophisticated criminal groups such as Carbanak and Cobalt Gang, as well as some state-sponsored actors such as Lazarus.
Although the number of known malware samples for ATMs has been very low there has been a steady increase in the trendline for number of discovered samples year over year.
Financial organizations and banks have to be particularly vigilant when considering protection against malware for ATMs and payment systems. Enterprises and individuals may also experience financial loss due to potential of their card details being used for illegal transactions after being skimmed by ATM malware. Best practices should be followed to ensure the highest possible level of protection and organizations should invest into increasing user awareness about the dangers of ATM malware.
Additional ways our customers can detect and block these threats are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. Below is a screenshot showing how AMP can protect customers from this threat. Try AMP for free here.
Cisco Cloud Web Security (CWS) orWeb Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such asNext-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.
AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Open Source SNORTⓇ Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
To read the Atricle in Cisco Talos Blog click here
Leave a Reply