Pierluigi Paganini July 30, 2019

Experts spotted a Java ATM malware that was relying on the XFS (EXtension for Financial Service) API to “jackpot” the infected machine

Introduction

Recently our attention was caught by a really particular malware sample most probably linked toa recent cybercriminal operation against the banking sector.

This piece of malicious code is a so-called ‘ATM malware‘: a malicious tool that is part of a criminal arsenal able to interact with Automatic Teller Machine. ATM malware are used in modern bank robberies due to their ability to access the cash dispenser hardware, such as ATMitch malware we analyzed on last May. In that case, the malware was relying on the XFS (EXtension for Financial Service) API to “jackpot” the infected machine.

Instead, this particular ATM malware does not rely on standard communication interfaces. It is using other more specific techniques, suggesting an increased level of customization, maybe achieved by leveraging knowledge from the inside of the target organizations.

For this reason, Yoroi-Cybaze ZLAB team decided to dig into this malicious tool.

Technical Report

Table 1. Info about the sample

The malware makes extensive use of Java Instrumentation techniques in order to manipulate the control flow of a legit Java-based ATM management software. The first action it performs is to identify the proper running Java Virtual Machine (JVM) used by the ATM software. The malware has the capability to:

• display the list of all the JVM registered on the system
• attach to a specific JVM defined in the arguments list
• choose an arbitrary JVM which attaches to

This is done using the Java Attach API, a Sun Microsystems extension that provides a mechanism to attach to a Java virtual machine.

Once identified the target JVM, the malware forces the loading of a Java agent in it using the “vm.loadAgent(path_to_jar, options)” method.

The loader identifies the agent class in the specified JAR file using the “MANIFEST.MF” file embedded into it, then it loads the class into the target JVM’s context.

At this point, the main class terminates printing the banner “Freedom and glory” in different languages, as shown in Figure 2. Now, the control flow moves to the “agentmain” method belonging to Agent class. Its only goal is to invoke the “startagent” method through the following code line:

getDeclaredMethod(“startagent“, String.class, Instrumentation.class).invoke((Object)null, agentArgs, ints);

The malicious intents of the malware are exhibited starting from this method. It deploys an HTTP server which acts as an interface between the attacker and the ATM under attack.

Exploring the HTTP handler class, in fact, some suspicious information immediately emerges. In the following figure it is possible to see a hardcoded IP address “150.100.248[.]18” which will be used later. Moreover, this class embeds three static variables containing Javascript code (one of this is Base64 encoded).

Continuing the code analysis, we encounter the server logic, which provides several functionalities that can be triggered by the attacker using simple HTTP requests.

It is possible to summarise all the malware capabilities, exposed through the HTTP server instance, in the following table:

Table 2. Malware capabilities

In the following screen, we report part of the server logic in which are highlighted the functions used by the malware to retrieve information about the ATM cash dispenser.

Most malicious actions are executed using Javascript code running on top of a JavaScript engine instance (included into the “runjs” method). For example, to retrieve the amount of cash stored in the dispenser the following code is invoked:

First of all, the malware retrieves the Java class associated with the Dispenser from the list of all the running classes. Then, for each dispenser’s cash unit, it invokes the “getValue” and “getActual”methods to obtain the right information from the dispenser interface.

A similar thing is done for money dispensing: after retrieving the associated object, the malware removes the “AnomalyHandler” using the “removeAnomalyHandler” method in order to stealthily achieve its objectives.

After that, it iterates the cash units dispensing the number of bills specified by the criminals through the following function calls sequence:

• setDispense(amount);
• dispense();
• present();
• waitForBillsTaken(30);

At the end of the theft, the malware restores the “AnomalyHandler”. The complete Javascript code is shown in the following figure.

On return, the malware communicates the success of the dispense operation connecting to the abovementioned IP (“150.100.248[.]18”) stored in the “urlreport” variable.

This ATM malware has also additional capabilities increasing its flexibility and dangerousness. It is able to execute arbitrary batch commands, to invoke methods directly into the memory of the running Java classes and also to run new JAR applications. The “jscmd” variable, shown in Figure 5, contains the Base64-encoded Javascript snippet useful to load the commands in the Windows cmdline:

Before launching the JS script, the malware replaces the following patterns:

• %%shell%% with cmd.exe
• %%arg%%with /c
• %%cmdb64%% with the Base64-encoded command coming from the HTTP request

Then, it invokes the “java.lang.Runtime.getRuntime().exec()” function.

Instead, in the JAR loading case the attacker preconfigured an HTML form to make the upload easier. In it, the criminal can specify which JAR to load, which is the main class and which method they want to execute first. A set of tools to ensure the criminals will be able to overcome eventual technical faults in their ATM cashouts.

Conclusion

Cyber criminals are threatening financial and banking sector for a long time. During the years, criminal groups evolved their operation and developed more sophisticated arsenals, achieving customization capabilities making them able to target specific organizations, even if they are not leveraging known Industry Standards. 

As recently pointed by Kaspersky, these criminals reached such sophistication and customization levels by leveraging deep knowledge of the target systems, making the malware work just on a small fraction of the AMTs. How the crooks accessed this knowledge is the Question.

At the moment it’s not clear how the technical information required to develop ad hoc malware have been accessed. A wide range of scenario are possible, such as the involvement of an insider, the long term compromise of the whole target network or just a small subset of mailboxes, or maybe a compromise of the Software Development Supply Chain. A set of scenarios that need to be seriously taken into account by the financial and banking organizations aiming to tackle modern bank thieves.

Technical details, including Indicator of compromise and Yara rules are reported in the analysis published on the Yoroi blog:

https://blog.yoroi.company/research/java-amt-malware-the-insider-threat-phantom/

Pierluigi Paganini

(Security Affairs – Java ATM malware, hacking)

[adrotate banner=”5″]

[adrotate banner=”13″]

Pierluigi Paganini

(SecurityAffairs – Java ATM malware, malware)

[adrotate banner=”5″]

[adrotate banner=”13″]