Pierluigi Paganini
July 30, 2019
Recently our attention was caught by a really particular malware sample most probably linked
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
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,
| Hash | 0149667c0f8cbfc216ef9d1f3154643cbbf6940e6f24a09c92a82dd7370a5027 |
| Threat | Java ATM Dispenser |
| Brief Description | Java ATM Malware |
| Ssdeep | 6144:gm/yO7AN3q8QjcAcZ7qFx6Jo7tpYRC3ivnZj+Y5H:2O7AN35QYJZ2TlSkivZjR |
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:
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:
| HTTP Method | Path | Query string | Body | Description |
| POST | / | – | Base64-encoded command | Execute the specified command through cmdline |
| POST | /d | – | i={id}&d={amount} | Dispense the specified {amount} from the Dispenser cash unit identified by {id} |
| POST | /d | – | q=1 | Return the current amount of each cash unit |
| POST | /eva | JS script | – | Execute the script using Java ScriptEngine |
| GET | /mgr | className1&className2 | – | Return info about the specified running Java classes |
| POST | /mgr | className | method | Invoke the method belonging to the specified Java class |
| GET | /core | – | – | Display an HTML form to insert info about a JAR to load |
| POST | /core | – | 0={Base64EncodedJAR}&1={mainClass}&2={method}&3={args}&4={type} | Load a new JAR file and execute the specified method |
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
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
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:
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.
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
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/
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(Security Affairs – Java ATM malware, hacking)
[adrotate banner=”5″]
[adrotate banner=”13″]
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
