Español | English
rss facebook linkedin Twitter

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:

1a621d205e984f92a42e00dd250e4ca0
4da23d28b515ff7cc1e51821895fea7a
b5d5c2782b078f4148f5a102dde5dc8b
ea593dc3d2056c5c1a2c060cc77c4990
1bbd341d8fa51f39c7f8df7753b72b00
50fc29042f8c54d99a6ec3dfd82b40e0
b9d28002e69f87e1f407a501d2bf5c3c
fab771fb164e54c6982b7eb7ba685500
3153be649d0d868c77a064e19b000d50
594fa3dd37c9b720c24bf34cf4632c20
c892c191a31f4a457ff1546811af7c09
3bd78217be4e455c107f81543de51bf0
9db30f3d2a0d68f575c79373cded12c0
ced7970f13c40448895967d4c47843e0
400fbcaaac9b50becbe91ea891c25d71
a86bd976ce683c58937e47e13d3eb448
e03512db9924f190d421ff3d3aaa92f0

0 comentarios:


(+34 902 222 521)


24 hours a day, 7 days a week



© Copyright S21sec 2013 - All rights reserved


login