Español | English
rss facebook linkedin Twitter

ATS: el mejor amigo de Slave

Hace unos días comentábamos en este blog la aparición del troyano Slave, Un nuevo malware que se diferencia por sus webinjects en formato JSON. En este post vamos a diseccionar el sistema de transferencias automáticas (ATS) que trabaja conjuntamente con Slave el cual está configurado para atacar a determinadas entidades bancarias.
El ATS que inyecta Slave resulta sencillo en su funcionamiento pero a la vez muy efectivo; en nuestra investigación pudimos analizar el código del script ejecutado en el navegador de la victima. Este está diseñado de forma modular permitiendo la adaptación a diferentes "sites" de banca online de manera rápida y sencilla. En el momento del análisis el ATS afectaba a tres bancos con distintas inyecciones para cada tipo de acceso (empresas o particulares). También se encontraron nuevas entidades que aunque no estaban presentes en la configuración de Slave, parecían estar preparadas para su activación en próximas fechas.

Para identificar la página de la banca online en la que se encuentra el usuario el script hace uso de diferentes técnicas como inspeccionar la URL actual o buscar elementos en el objeto DOM de la página.

En función de la página en la que se encuentra el usuario, el scritp es capaz de realizar diferentes acciones. Las páginas con código mayor de 100 se corresponde a los formularios de "login", que dependiendo del banco puede haber 1 o 2 diferentes. En estás páginas el script recoge las credenciales del usuario y las almacena en el sessionStorage del navegador. Si además de la contraseña la entidad pide algunos dígitos de una clave de paso, el script es capaz de reconocer los dígitos solicitados y enviar la máscara de dicha clave. Sin embargo para su funcionamiento el ATS no necesita robar las credenciales y la única acción que realiza con ellas es enviarlas al C&C, posiblemente para una revisión manual. Este comportamiento permite deducir que su prioridad no es realizar dicha captura, sino modificar transferencias en tiempo real, como veremos más adelante.

En caso de capturar correctamente correctamente las credenciales del usuario, el script pasa a ejecutar las siguientes acciones en el resto de la web:

  • Acción 1 (landing page), se limita a enviar los datos de usuario y contraseña como log. Dependiendo del banco, esta acción puede ser ignorada, ya que no contiene datos de interés.
  • Acción 2 (accounts info), busca la información relativa a las cuentas del usuario, extrae los datos y los envia al C&C en el siguiente formato:
Nombre Titular*Número de Cuenta*Saldo*-*|
  • Acción 3 (new transfer), se encarga de modificar la transferencia legítima para enviar el dinero a una mula en lugar del destinatario original. Antes de hacerlo se realizan varias comprobaciones, entre ellas que la cuenta tenga suficientes fondos (mas de 2 cifras) y que no se haya realizado ya una transferencia fraudulenta. Si la víctima pasa estos controles, se realiza una petición de mula al C&C.

La respuesta del ATS a esta petición incluye los datos del nuevo destinatario de la transacción y la cantidad a enviar. Con dicha información, el script falsifica la transferencia, mostrando al usuario los datos que espera ver (la transferencia que cree realizar) y enviando al banco los ilegítimos. De esta forma es el propio usuario quién realiza los pasos de verificación. Ya sea introduciendo valores de la tarjeta de coordenadas, el PIN enviado al móvil o cualquier otro factor de doble autenticación.
De forma adicional, Una vez se ha realizado la transferencia ilegítima se ejecuta la función fixBalance?()en todas las páginas donde aparezca el saldo de la cuenta. Esta función modifica el valor del saldo visualizado para ocultar el robo, siendo incluso persistente a sesiones, por lo que mientras el usuario este infectado la transferencia fraudulenta y el saldo real serán completamente indetectables en la web de su banco.
Respecto a la comunicación del script con el panel de control, si bien no fue posible replicar este proceso, un análisis preliminar permitió extraer las siguientes conclusiones:
  • Para comunicarse con el C&C el script utiliza JSONP, dependiendo de la inyección puede llegar a cargar la librería JQuery para realizar las peticiones.
  • En todas ellas se añade un campo "key" que viene hardcoded en el propio binario y resulta necesario para la comunicación.
  • Más allá de esta comprobación y de la capa SSL, las comunicaciones script-C&C no parecen incluir ninguna otra clase de cifrado u ofuscación.
Finalmente estos son los MD5 que identifican las muestras analizadas:
1a621d205e984f92a42e00dd250e4ca0
4da23d28b515ff7cc1e51821895fea7a
b5d5c2782b078f4148f5a102dde5dc8b
ea593dc3d2056c5c1a2c060cc77c4990
1bbd341d8fa51f39c7f8df7753b72b00
50fc29042f8c54d99a6ec3dfd82b40e0
b9d28002e69f87e1f407a501d2bf5c3c
fab771fb164e54c6982b7eb7ba685500
3153be649d0d868c77a064e19b000d50
594fa3dd37c9b720c24bf34cf4632c20
c892c191a31f4a457ff1546811af7c09
3bd78217be4e455c107f81543de51bf0
9db30f3d2a0d68f575c79373cded12c0
ced7970f13c40448895967d4c47843e0
400fbcaaac9b50becbe91ea891c25d71
a86bd976ce683c58937e47e13d3eb448
e03512db9924f190d421ff3d3aaa92f0

(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login