Análisis de un malware de infección automática, caso @Hack_x_Crack – Parte I

Hace unos días me encontraba revisando mi TimeLine en twitter cuando un anuncio de los amigos @hack_x_crack donde promocionaban un nuevo cuadernos sobre algoritmos y estructuras de datos llamó mi atención, al entrar en el enlace que proporcionaban, el NoScript me advirtió de la ejecución de un posible código JAVA, al investigar un poco el caso y revisar el código fuente de la pagina, me encontré con un iframe bastante sospechoso.

El iframe malicioso cargaba tan pronto entrabamos a la web de Hack X Crack e inmediatamente avisé a los administradores de la comunidad HackxCrack para que solucionaran el problema, ya que muy seguramente se trataba de un ataque automatizado que explotaba algún fallo en alguno de sus servicios o aplicaciones web para poder añadir este iframe e infectar el mayor numero de personas silenciosamente (me niego a creer que fuera puesto intencionalmente)..

(click para agrandar)

Afortunadamente la rapida y eficiente reacción de overload, puso fin a esta amenaza en menos de media hora para luego pasar a recomendar a sus usuarios revisar a fondo sus equipos por si fueron infectados por el malware. Después de este susto nuestro amigo @seifreed me propuso que analizaremos este malware y al ver que era poco detectado decidimos hacerlo, comenzamos con el con el applet malicioso en Java que se ejecutaba tan pronto ingresábamos a la web de HackXCrack, sin saber hasta donde llegaríamos con este tema… (aún no lo sabemos jejeje)

Así que para iniciar analizando el Java pasamos a descargarlo y descompilarlo para ver que es lo que hacia el archivo Alakazam.jar.

Después de una rápida revisión del código llegamos a la conclusión que se trata de un downloader (bastante silencioso por cierto), cuya tarea principal era descargaba de un servidor un ejecutable malicioso y ejecutarlo en el sistema.

(Click par ver código)

El applet malicioso tiene muy poca detección como nos muestra el reporte de VirusTotal

(click para ver reporte de virustotal)

Al entrar directamente a la web donde estaba hospedado el applet de Java, te ofrecía para la descarga directa un archivo llamado Updater.exe, cambiaba de nombre con cada petición directa a la pagina, pero el hash del archivo era el mismo en las pruebas hecha lo que posiblemente sea indicios de una posible prueba del delincuente para infectar con variantes diferentes a cada visitante en un futuro y dificultar las tareas de las casa antivirus.

Seifreed se encargó del análisis dinámico de este ejecutable y para esto decidió bajarlo con curl, descubriendo que estaba alojado en smallfiles, un servicio de alojamiento de ficheros gratuito tipo megaupload.com, no es la primera vez que los creadores de malware utilizan servicios de alojamiento para hospedar malware estos han sido utilizados ampliamente por las mafias de malware por el anonimato ofrecido (no es necesario crear una cuenta en hosting gratuito, o comprarlo con una CC robada, ni de vulnerar un servidor ajeno para alojar el malware en el).

Una vez Seifreed consigue una copia del binario, también lo subimos a VirusTotal para ver cuantos antivirus lo detectaban.

(click para ver informe de virustotal)

Aunque la detección era mas alta que la del applet java, este no era detectado ni por la mitad de motores antivirus que soporta virustotal, esto puede ser debido a que hayan implementado algún tipo de protección en el binario y pasamos a revisarla.

Con peid podemos comprobar si el malware contiene un packer y como suponíamos en este caso se contaba con uno, posible causa de la pobre detección por parte de los motores antivirus.

Al ejecutar el archivo malicioso en un entorno controlado, nos dimos cuenta que realizaba varias conexiones a un dominio intentando descargar algo de el..

Si echamos un vistazo a los puertos del servidor al que realiza las peticiones, encontramos que cuenta con muchos servicios arriba y varios fallos de seguridad, posiblemente sea un servidor con un uso legitimo que los delincuentes han vulnerado para hacer uso de el ..

Y revisando un poco mas el server al que hacia la petición, incluso podríamos acceder por Terminal Server (si quieres probar los ataques de fuerza bruta, o explotar el fallo de seguridad detectado en nessus puedes intentarlo bajo tu responsabilidad)

Volviendo a la parte del binario, y a las peticiones DNS hacia el dominio que realiza una vez que es ejecutado

Notamos el siguiente comportamiento del binario tan pronto realiza las conexiones remotas, primero hace una copia de si mismo en varias carpetas del equipo y asegura su ejecución futura en el sistema.

Comprobamos con VirusTotal (msdcsc.exe y Updater.exe)que los archivos generados eran los mismos y que no tratamos con un malware polimórfico, arrojando como resultado que efectivamente tienen el mismo hash MD5 y se trata del mismo binario.

Ver informes de virustotal (msdcsc.exe y Updater.exe)

Este a su vez descarga otro ejecutable de internet que analizaremos mas adelante, pero en esta primera parte solo veremos un fragmento del primer análisis realizado, en la segunda entrega realizaremos el unpack del ejecutable y analizaremos tanto la copia descargada inicialmente por el apple de java, como la que el ejecutable baja después de estar en el sistema.

Si te ha gustado el post, compartelo y ayudanos a crecer.

Tweet