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.
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.
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.
Exposure of sensitive Information
Malware Hash (MD5/SHA1/SH256)
Block all threat indicators at your respective controls.