If you answered ‘c’ you might be correct! FireEye Labs discovered a new piece of ATM malware (4BDD67FF852C221112337FECD0681EAC) that we detect as Backdoor.ATM.Suceful (the name comes from a typo made by the malware authors), which targets cardholders and is able to retain debit cards on infected ATMs, disable alarms, or read the debit card tracks.
ATM malware is not new, back in 2013 and 2014 threats like Ploutus or PadPin (Tyupkin) were used to empty ATMs in Mexico, Russia and other countries, but SUCEFUL offers a new twist by targeting the cardholders.
SUCEFUL was recently uploaded to VirusTotal (VT) from Russia, and based on its timestamp, it was likely created on August 25, 2015. It might still be in its development phase; however, the features provided are shocking and never seen before in ATM malware.
Figure 1. SUCEFUL Testing Interface
By clicking on different buttons in the GUI shown in Figure 1. The malware authors can test if the malware operates properly; the word “SUCEFUL” is displayed in the text box indicating success.
Potential SUCEFUL capabilities in Diebold or NCR ATMs include:
- Reading all the credit/debit card track data
- Reading data from the chip of the card
- Control of the malware via ATM PIN pad
- Retention or ejection of the card on demand: This could be used to steal physical cards
- Suppressing ATM sensors to avoid detection
Similar to Ploutus and PadPin, SUCEFUL interacts with a middleware called XFS Manager which is part of the WOSA/XFS Standard that major vendors comply with. The XFS Manager is the interface between the application (malware in this case) and the peripheral devices (e.g., printer, dispenser, card reader, in pad) as shown at Figure 2.
Figure 2. WOSA/XFS Architecture
One benefit of the XFS Manager is that it is vendor independent, similar to Java’s “Write once, run anywhere” mantra. This means that it can be used maliciously by ATM malware, so that it can run transparently in multiple hardware vendors. This is the case of SUCEFUL, which is targeted for Diebold and NCR.
Every vendor has its own implementation of the XFS Manager with proper security controls in place; however, they also support the default XFS Manager template provided by WOSA/XFS Standard allowing the attackers to create their own interface with the ATM.
The Service Provider Interfaces (XFS SPIs) are vendor-dependent developed to provide the functionality of their own hardware.
Establishing a connection with the XFS Manager
As shown in Figure 3, the first step before starting interacting with the ATMs peripheral devices is to establish a connection with the XFS Manager via WFSStartup API.
Figure 3. Connecting with the XFS Manager via XFSStartUp API
Opening sessions with the peripheral devices
The next step is to open sessions with the peripheral devices via the Service Providers (XFS SPIs) through the XFS Manager by calling WFSOpen or WFSAsyncOpen APIs where the first parameter is the Logical Device Name.
In Figure 4, a session with Diebold Card Reader is being initiated where the logical device name is “DBD_MotoCardRdr”.
Figure 4. Diebold Card Reader
In Figure 5, a session with NCR Card Reader is being initiated where the logical device name is “IDCardUnit1”:
Figure 5. NCR Card Reader
In Figure 6, a session with the Sensors and Indicators Unit (SIU) is being initiated:
Figure 6. Sensors and Indicators Unit
The SIU provides functions to operate port (indicators) categories including but not limited to:
- Door Sensors: cabinet, safe, or vandal shield doors
- Alarm Sensors: tamper, seismic, or heat sensors
- Proximity Sensors
In Figure 7, a session with NCR PIN pad is being initiated where the device logical name is “Pinpad1”.
Figure 7. Connecting with the ATM PIN pad
By reading information from the PIN pad, the crooks could interact with the ATM malware.
Interacting with the peripheral devices
Once a session has been opened, the APIs WFSExecute or WFSAsyncExecute can be used to request specific operations to the peripheral devices where the second parameter is the command to be executed.
Reading debit card track data
In Figure 8, the WFS_CMD_IDC_READ_RAW_DATA command instructs the card reader to read all the track data and chip if a card is inserted or wait to read it as soon as the card has been inserted or pulled through.
Figure 8. WFS_CMD_IDC_READ_RAW_DATA Command
Track 1 & 2 contain information like cardholder’s name, account number, expiration date, encrypted PIN, etc.
Retain and/or Eject debit card
The WFS_CMD_IDC_RETAIN_CARD command in Figure 9 instructs the Card Reader to retain the card:
Figure 9. WFS_CMD_IDC_RETAIN_CARD
In Figure 10, the WFS_CMD_IDC_EJECT_CARD command instructs the Card Reader to eject the card:
Figure 10. WFS_CMD_IDC_EJECT_CARD
This RETAIN and EJECT commands suggest that the malware authors can retain debit cards inserted into the ATM and eject them whenever they want stealing the physical card from the victims.
Interact with the Malware via PIN pad
In Figure 11, the WFS_CMD_PIN_GET_DATA command is used to read the keystrokes entered by the cardholder (or attacker) in the PIN pad.
Figure 11. WFS_CMD_PIN_GET_DATA
Once the input is read, a loop will run to identify the keys typed in the Pin pad, which can be Key0-9, Key-ENTER, Key-CANCEL or KEY-CLEAR. In Figure 12, the Key-0 and Key-1 are being checked:
Figure 12. Pin pad Keys check
Disabling ATM Sensors
In Figure 13, the WFS_CMD_SIU_SET_PORTS command could be able to set or clear ATM output ports (indicators) in order to avoid triggering the alarms, some of the sensors that can be controlled are:
- Turn on/off the Audible Alarm device
- Turn on/off the Facial light
- Turn on/off the Audio indicator
- Turn on/off the Internal Heating device
Figure 13. WFS_CMD_SIU_SET_PORTS
In Figure 14 the WFS_CMD_SIU_SET_AUXILIARY command is used to set the status of an Auxiliary indicator including but not limited to:
WFS_SIU_VOLUME: Set the value of the volume control
WF_SIU_REMOTE_STATUS_MONITOR: Set the value of the Remote Status Monitor
WFS_SIU_AUDIBLE_ALARM: Set the value of the Audible Alarm
Figure 14. WFS_CMD_SIU_SET_AUXILIARY
Although DLL Hooking is not a novel technique, it is interesting to understand the reason this is being done inside an ATM. SUCEFUL is able to hook the WFSAsyncExecute API in order to control and monitor all the commands issued to the peripheral devices, this is done by replacing the first 6 bytes of the API Entry point with a classical push <malware_func>, ret instruction (see Figure 15) to redirect execution, as well as patching the RVA address in the Export Directory pointing to WFSAsyncExecute Entry point.
Figure 15. Hooking WFSAsyncExecute API
Since it is impossible to ascertain whether a retained card is due to this malware, keep the contact number for your bank in your phone and call it while keeping eyes on the ATM.
SUCEFUL is the first multi-vendor ATM Malware targeting cardholders, created to steal the tracks of the debit cards but also to steal the actual physical cards, which is definitely raising the bar of sophistication of this type of threats.
List of known MD5s
4bdd67ff852c221112337fecd0681eac - Backdoor.ATM.Suceful
f74755b92ffe04f97ac506960e6324bb - Backdoor.ATM.Suceful