ATS: Slave´s best friend

A few days ago we commented in this blog the discovery of the Slave Trojan. A new malware differentiated by their webinjects in JSON format. In this post we will dissect the automatic transfer system (ATS) that works together with Slave , which is configured to target certain banks.
 The ATS injected by Slave is simple in its operation but very effective at the same time; in our research we were able to analyze the script code executed in the browser of the victim. This is designed in a modular way allowing adaptation to different “sites” of online banking in a quick and easily way. At the time of analysis, the ATS concerned three banks with different injects for each type of access (companies or individuals). New entities were also found, although they had not a presence at the Slave config, seemed to be ready for activation in the near future.

To identify the online banking page where the user is located, the script makes use of different techniques such as inspecting the current URL or search for specific items in the website´s DOM.
According to the website where the user is located, the scritp is able to perform different actions. The websites that have a code larger than 100 it corresponds to the longin forms, which depending on the bank may be 1 or 2 different matches. In these pages the script collects the user credentials and stores them in the sessionStorage browser. If the entity ask for more digits than for some digits of a second password, the script is able to recognize the requested digits and send the mask of that pass. However, for its operation the ATS does not need to steal credentials and the only action performed with them is send to the C & C, possibly for a manual review. This behavior allows to deduce that his priority is not to make the catch, but to modify transfers on real-time, as discussed below.
If user credentials are captured correctly, the script starts executing the following actions on the rest of the web:
  • Action 1 (landing page), it simply sends the user data and password to log. Depending on the bank, this action can be ignored. 
  • Action 2 (accounts info), looking for information on user accounts, extracts data and sends to the C & C in the following format:

               Owner Name * Account Number * Balance * – * |

  • Acción 3 (new transfer), It is responsible for changing the legitimate transfer for redirecting the money to a money mule instead of the original recipient. Before performing, various checks are done, including if the account has enough funds and a fraudulent transfer isn´t already made. If the victim passes these checks, a money mule is request to the C&C.
ATS´s answer to this request includes the new reciver of the transaction and the amount to send. With this information, the script falsifies the transfer, showing the data wich the user espects to see and sen the false data to the bank . ATS´s response to this request includes personal details from the new recipient of the transaction and the amount sent. With this information, the script tampers the transfer, showing the user the data expected to see (the transfer believed performed) and sending to the bank illegitimate.
On this way is the user who makes the verification steps. Either introducing card values coordinates, the PIN sent to the mobile or any other TAN factor.
Additionally, when illegitimate transfer has been made, the fixBalance?() function is executed at all sites where the account balance appears. This function changes the value of the balance displayed to hide the theft. This functionality of the Trojan is even sessions persistent, so while the user is infected fraudulent transfer and the actual balance will be completely undetectable on banking´s website.

Regarding the communication script – C&C, although it was not possible to replicate this process, a preliminary analysis showed the following conclusions:
  • To contact the C & C, the script uses JSONP, depending on the injection can load the jQuery library to make requests.
  • In all of them a field “key” that is hardcoded in the binary itself and necessary for communication is added.
  • Beyond this check and the SSL layer, communications script C&C do not appear to include any other kind of encryption or obfuscation.
Finally these are the MD5 identifying the samples analyzed:


Deja un comentario