Pierluigi Paganini May 07, 2019

Early April, experts at Yoroi-Cybaze ZLab spotted a new interesting malware sample, likely active since 2017, that was linked to ATMitch attacks. 

In the first days of April, our threat monitoring operations spotted a new interesting malware sample possibly active in the wild since 2017. Its initial triage suggests it may be part of an advanced attacker arsenal targeting the Banking sector, possibly related to the same APT group Kaspersky Lab tracked two years ago after the compromise of a Russian bank, where a particular malware tool dubbed ATMitch has been unveiled. In the past, this piece of malware was manually installed on the victim ATM after a wide enterprise network intrusion, enabling the cyber-criminals to manipulate the cash-withdrawal process on the machine.

The recent, unattended discovery of such kind of sample within the Info-Sec community led us to a deep dive into this particular malware tool, spearhead of a sophisticated cyber arsenal.

Technical Analysis

The executable sample is a PE32 x86 file named “tester.exe”. It seems to be custom loader for the real malicious payload able to take control of the target machine.

Table 1: Information about Dropper/Loader of ATMitch

The static data about this sample reveal the sample has been compiled on 8th Oct 2017, months later than the Kaspersky disclosure of the ATMitch attack operation. This element is not enough to date the sample with 100% accuracy due to possible tampering, anyway the other static details suggest the date could be genuine due to the absence of scrambled artifacts.

When started, the executable creates a new folder on “C:\intel” and then starts inspecting all the running processes. It looks for a really particular one: “fwmain32.exe”. This lookup reveals how deeply environmental aware is this implant. In fact, the “fwmain32” process is part of the software services produced by Wincor Nixdorf International GmbH, one of the major vendors providing retail and banking hardware such as ATMs.

Once the “fwmain32.exe” process is found, the loader injects the actual payload in its own memory, infecting it. The payload DLL, initially stored into the loader resources section, will be implanted into the target process using the “SetThreadContext” injection technique (Thread Hijacking). 

The figure above shows the sample calls on the OpenThread and the SuspendThread functions to pause the current execution. After allocating the right memory amount in the target process, it writes the shellcode target memory space using the WriteProcessMemory function and sets up the new process context with SetThreadContext. Finally, using the ResumeThread function the payload is able to start its malicious execution.

When the loader succeeded to inject the payload into the “fwmain” process, it also shows a popup window reporting the outcome of the injection phases.

ATMitch Payload

Table 2: Information about the payload (DLL contained as resource in the Dropper/Loader)

The injected DLL has a very characteristic dependency: it requires the “msxfs.dll”. This library provides access to the EXtension for Financial Service (XFS) API, the communication interface needed to interact with AMT components such as PIN pad and cash dispenser. Again, this is a very particular dependency can only be resolved on special purpose Windows environment, like the Wincor machines.

The malware is quite simple: it reads commands from a file included into “c:\intel” folder and interacts with the ATM drivers in order to retrieve information about the current amount and to dispense money at the right time. In the following screen is shown a function used to initiate the communication with the PinPad and Dispenser ATM components.

Using the functions provided by “msxfs.dll” library, the malware can easily interact with these components. For example, using the WFSExecute function it is possible to send one of the supported commands to the dispenser, like OPEN_SHUTTER or OPEN_SAFE_DOOR.

In the specific case, the malware uses the function to dispense money through the command WFS_CMD_CDM_DISPENSE, as shown in figure:

The core of the malware is the following switch structure: after reading the new command from the specific file, it compares the command code with the embedded ones, such as “code 2” for retrieving information or “code 7” for dispensing money.

Moreover, the malware provides a well-structured logging system: all actions are traced and logged into “c:\intel\__log.txt”. In relation to the action that needs to be logged, it is able to set a specific logging level (FATAL, ERROR, DEBUG etc.).

Conclusion

This recently discovered ATMitch sample is one of the key assets used by advanced attackers during bank cyber-robberies, potentially even by the Carbanak or the GCMAN group. Who manually install it within segregated hosts and write commands directly into the target machine, without any command and control traffic. The usage of Remote Desktop to directly connect to the target machine is also supported by the presence of a prompt window (Figure 4) which shows the correct execution of the first stage. Probably the last steps of an attack flow involving ATMitch are the following:

1. The attacker connects to the ATM machine using Remote Desktop;
2. The attacker transfers the loader EXE and runs it: the prompt window shows if everything went well;
3. The attacker deletes the initial file in order to remove tracks;
4. The attacker writes commands in the appropriate file;
5. The malware executes the new commands and writes in the log file;
6. The attacker examines the log file to know the state of the command execution.

So, the eventual presence of this malware could be the tip of the iceberg of a more complex and articulated attack perpetrated by advanced cyber-criminals.

Technical details, including IoCs and Yara Rules, are available in the analysis published on the Yoroi blog.

https://blog.yoroi.company/research/atmitch-new-evidence-spotted-in-the-wild/

Pierluigi Paganini

(SecurityAffairs – ATMitch, ATM)

[adrotate banner=”5″]

[adrotate banner=”13″]