Tyupkin ATM Malware: Take The Money Now Or Never! [source: lastline]

Tyupkin ATM Malware: Take The Money Now Or Never!

A Sandbox is a dynamic file analysis system that allows a researcher to analyze the behavior of potentially malicious code in a virtualized environment without damaging a real host system. In some cases, a sandbox has to analyze an attack without seeing the full chain (for example when it analyzes a dropped file without the corresponding dropper component) or must work with limited information about the target environment (for example when an attack targets a particular operating system or runtime). In the worst-case scenario, these missing pieces can completely hinder the sandbox’s ability to successfully run an application.

Lastline Sandbox

In today’s blog post, we are going to dive deep into one such example and show how the Lastline sandbox can still classify malware despite an incomplete environment, and even how a security researcher or incident responder can still be able to elicit behavior from a malware sample. This can be done via the so-called application bundles. These bundles allow the user to extend, customize, and tailor the analysis environment to the needs of the particular attack and allow us to analyze and dissect an application requiring non-existent Windows DLLs, file path or registry values.

ATM Malware

For today’s case study, we use a Tyupkin malware sample, a .Net application for bank automated teller machines (ATM) running on the Microsoft Windows operating system. Tyupkin’s aim is to steal cash by sending a specific command to the cash dispenser of the compromised ATM. During the analysis, our sandbox will trick the malware into believing that our analysis environment is an ATM itself. We will achieve this by submitting our sample bundled with a few specific DLLs that provide programmer’s interfaces to a Windows-based ATM, Extensions for Financial Services (XFS).

Delivery Vectors

Interestingly, this malware family seems to be delivered to the ATM manually. In other words, to install the malware, the attacker requires physical access to an ATM via an exposed USB port or other input/output bus. Note that this is not usually necessary as some attackers have been known to install ATM malware as part of an internal software update processes.

Anti-Analysis

As with many malware families, ATM malware actively tries to hinder incident response and evade dynamic analysis systems by using well-known, off-the-shelf code protectors and packers, such as .NET Reactor, .Net Confuser, VMProtect, and Themida. This is a common self-defense mechanism. For example, one of the previously seen ATM infectors packed with the Themida packer makes use of several anti-debug and anti-sandbox tricks (as shown below in the analysis overview of the sample SHA1: 3022e60790e17303def03761c8fa7e7393a0ad26): IsDebuggerPresent, CheckRemoteDebuggerPresent, RDTSC timing evasions, and Windows class names to name a few.

For more, click here.