Java + Icefog = Javafog

0

En Septiembre de 2013 publicamos nuestro artículo que describía el funcionamiento de Icefog, una APT o amenaza persistente avanzada y enfocada, principalmente, en la cadena de suministro: afectando a instituciones gubernamentales, contratistas militares, marítimos y grupos de construcción de navíos. 

Icefog, también conocido como “Dagger Panda”, infectó objetivos principalmente de Corea del Sur y Japón. Podéis consultar sus detalles específicos en este artículo.

Desde la publicación del primer reportaje, los atacantes responsables de la amenaza han estado completamente “callados”, sin operar y destruyendo cualquier conexión a centros de Comando y control (C2). Su descubridor, el laboratorio de Kaspersky, ha continuado monitorizando la red en busca de actividad relacionada, introduciendo trampas en dominios revisando datos de usuarios afectados.

Países afectados en Asia (en función de número de IPs) por la amenaza Icefog

Durante dicho seguimiento, han notado un interesante tipo de conexión que parecía indicar que existe una versión Java de Icefog: Javafog.

Las operaciones de Icefog han estado presentes desde, al menos, 2011, con múltiples versiones circulando en este período de tiempo. Para PCs con Microsoft Windows, se han identificado al menos 6 generaciones:

  1. El viejo Icefog de 2011: envía los datos almacenados por email. Esta versión fué usada contra la Cámara de los representantes japonesa en 2011.
  2. El tipo “1” o Icefog normal: interactúa con centros de comando y control mediante scripts “.aspx”.
  3. El tipo “2” de Icefog: interactúa con un servidor proxy basado en scripts que redireccionan comandos desde los atacantes a otra máquina.
  4. El tipo “3” de Icefog: variante que emplea ciertos tipos de servidores C&C con scripts llamados “view.asp” y “update.asp”.
  5. El tipo “4” de Icefog: variante qu emplea ciertos tipos de servidores C&C con scripts llamados “upfile.asp”.
  6. Icefog-NG: se comunica directamente por conexiones TCP al puerto 5600.

Además de estos, se ha identificado otro como “Macfog“, una implementación nativa de Icefog para sistemas Mac OS X, que ha infectado algunos cientos de víctimas en el mundo.

Haciendo una correlación de registros entre diferentes dominios usados por las muestras de malware, se ha podido identificar 72 servidores de Comando y control, de los cuales Kaspersky ha sido capaz de “infiltrarse” en 27.

un dominio particularmente interesante ha sido “lingdona[punto]com”, que expiró en Septiembre de 2013 y se neutralizó en Octubre de 2013. Ahora mostramos como aparecía la información de contacto:

Domain Name: LINGDONA.COM
Registrant Contact:
lin ming hua
lin ming kevistin@qq.com
telephone: +86.031185878412
fax: +86.031185878412
fuzhoushi Fuzhou Shi Fujian Sheng 412141
CN

El dominio estaba originalmente alojado en Hong Kong, con la IP 206.161.216.214 y 103.20.195.140, y parecía sospechosa porque en los datos de registro, parecía haber similitudes con otros dominios conocidos de Icefog. Tan pronto se escuchó dicho servidor, se observaron varias conexiones sospechosas, casi cada 10 segundos:

69.59.x.x www.lingdona.com – [26/Oct/2013:23:59:39 +0000] “POST /news/latestnews.aspx?title=2.0_1593925273 HTTP/1.1” 404 345 “-” “Java/1.7.0_25”
69.59.x.x www.lingdona.com – [26/Oct/2013:23:59:45 +0000] “POST /news/latestnews.aspx?title=2.0_1593925273 HTTP/1.1” 404 345 “-” “Java/1.7.0_25”
38.100.x.x www.lingdona.com – [26/Oct/2013:23:59:48 +0000] “GET /news/latestnews.aspx?title=1.1_1254592001 HTTP/1.1” 404 345 “-” “Java/1.7.0_40”

Resulta interesante que la cadena “user agent” indicara que el cliente era una aplicación Java, sin embargo, esto era algo poco habitual, porque todas las versiones restantes de Icefog usaban cadenas de User Agent normales de Internet Explorer.

Encontrando la muestra

Se sospechó entonces que había una muestra de malware en activo y conectándose al dominio “lingdona[punto]com“, no se tenía una versión similar del troyano Icefog.

Entonces los expertos tuvieron algo de suerte y recibieron un envío JSUNPACK de Java que parecía interesante.

Archivos decodificados de Icefog

En Noviembre de 2012, alguien envió una curiosa URL al servicio público JSUNPACK que estaba alojada en el servidor “sejonng[punto]org“, un conocido dominio malicioso de la red. También había referencias a un segundo dominio infectado: “starwars123[punto]net“.

Resulta además curioso, que la página HTML se refiera al applet de Java “policyapplet.jar” con una cadena de parámetros hexadecimal larga llamada “jar”. Desafortunadamente, no se pudo recuperar dicho archivo, que tenía pinta de ser un exploit de la plataforma Java. Decodificando la cadena hexadecimal, se encontró otro applet de Java con la siguiente información:

Size: 8697 bytes
MD5: d26af487534c1d575e747ff240ee6357

Después, se descubrió que el applet extraído también era subido a la red mediante un servicio de escaneo de virus (al mismo tiempo).

 

Javafog

El applet .jar llamó la tención de los expertos, por lo que decidieron analizar su comportamiento.

Dicho jar usa compresión ZIP para almacenar los datos en forma compacta. La cabecera del zip usa timestamps (marcas horarias” para rastrear cuando se añaden archivos al fichero. Esto ayuda a entender cúando el archivo JAR podría haber sido creado. Aquí mostramos la información recabada sobre el applet:

Date Time Attr Size Compressed Name
–––––––––- ––- –––––– –––––– ––––––––––––
2012-10-30 16:47:50 ….. 129 115 META-INF/MANIFEST.MF
2012-10-30 16:47:50 ….. 259 206 META-INF/B8228E45.SF
2012-10-30 16:47:50 ….. 5365 3610 META-INF/B8228E45.RSA
2010-10-29 22:44:06 ….. 7726 4226 JavaTool.class

Esto significa que el archivo JAR fué probablemente creado el 30 de Noviembre de 2012, cuando la clase principal JavaTool.class había sido compilada 2 años antes, en 2010.

Una vez iniciado, intenta registrarse a sí mismo como entrada de arranque para adquirir persistencia. El módulo escribe un valor en el registro para asegurarse de que es cargado automáticamente por Windows.

[HKEY_CURRENT_USERsoftwaremicrosoftwindowscurrentversionrun]
JavaUpdate=%TEMP%update.jar

No vale de nada que el módulo no se copie a si mismo en dicha localización. Es posible que el archivo que falta (policyapplet.jar) contenga las partes de dichas rutinas de instalación.

Cadena policyapplet.jar presente en Javafog

Después, entra en un bucle en el que continúa llamando a su principal servidor de control, con retardos de 1000 milisegundos. El loop principal contacta con el servidor de Icefog: “www.lingdona[punto]com/news” e interactúa con él.

Segunda parte de la cadena class de Javafog

Antes de nada, envía un archivo completo de información de sistema, que los atacantes emplearán para determinar si la víctima es interesante o posee algún valor. Aquí tenéis un archivo PCAP de la negociación:

Archivo PCAP que muestra la negociación producida durante la infección

En las capturas superiores, “title=2.0_1651809722“indica una ID de victima única, que es computada mediante el hash de nombre de servidor. Esto se usa por los operadores para identificar de forma inequívoca y enviar comandos al dispositivo.

Como respuesta a la información remitida, la backdoor espera una “orden”, que puede tener diferentes valores:

Comandos:

  • upload_* – Envía un archivo local específico tras producirse el comando “%C&C server URL%/uploads/%file name%” desde el servidor C&C. Los datos enviados son cifrados mediante una simple operación XOR con la clave 0x99.
  • cmd_UpdateDomain – Migra a una nueva URL de servidor C&C especificada tras el comando. La nueva url se escribe además en el archivo “%TEMP%update.dat”.
  • cmd_* – Ejecuta la cadena especificada mediante el comando “cmd.exe /c”. Los resultados son enviados al srevidor C&C mediante la url “%C&C server URL%/newsdetail.aspx?title=2.0_%host name%”.

Al margen de lo anterior, la backdoor no hace mucho más. Permite a los atacantes tomar el control del sistema infectado y descargar archivos del mismo. Simple pero efectivo.

Distribución geográfica

Alguien podría preguntarse cual es el propósito de algo como Javafog. Lo cierto es que, incluso en estos momentos, las detecciones de Java suponen 3 de 47 en VirusTotal, un valor muy pobre. El malware basado en Java no es ni de lejos tan popular como el basado en Windows, y puede ser más difícil de localizar.

Durante las operaciones de escucha del dominio “lingdona[dot]com” se observaron 8 IPs correspondientes a 3 víctimas únicas de Javafog, todas en EEUU

Basándonos en las direcciones IP, una de las víctimas fué identificada como una compañía muy importante, dedicada el sector del Crudo y el Gas, con operaciones a nivel mundial.

Todas las víctimas han sido notificadas ya del suceso, y 2 de las 3 han conseguido ya subsanarlo.

Conclusiones

Con Javafog, estamos pasando una nueva página en la historia de Icefog, mediante el descubrimiento de una nueva generación de backdoors empleadas.

Un caso particular tuvo comienzo mediante eluso de un exploit para Microsoft Office, seguido de un intento de los atacantes de instalar y ejecutar Icefog, con un C&C diferente. Podemos asumir que, según su experiencia, los atacantes han averiguado que la backdoor basada en Java es más difícil de detectar y más silenciosa, haciéndola más atractiva para operaciones a largo plazo. La mayoría de operaciones de Icefog hasta ahora habían sido de tipo “golpea y corre”, muy puntuales.

 

Compartir.

Sobre el Autor

Alejandro es técnico micro-informático, experto en seguridad de las TIC y apasionado de la tecnología. Colabora habitualmente en diferentes publicaciones de seguridad, software y análisis de hardware entusiasta.

Dejar una Respuesta

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR