El grupo de espionaje Sednit ahora usa un exploit kit a medida

Durante los últimos cinco años, el grupo Sednit ha estado atacando sin piedad a varias instituciones, la mayoría en Europa Oriental. Para llevar a cabo estos ataques dirigidos, empleaba diversos programas de malware avanzado, particularmente el llamado Win32/Sednit, también conocido como Sofacy.

Hace poco encontramos casos de sitios web financieros legítimos que estaban siendo redirigidos a un exploit kit hecho a medida. Según nuestras investigaciones y la información aportada por el Equipo de Seguridad de Google, logramos establecer que este kit es utilizado por Sednit. Resulta ser una estrategia completamente novedosa para este grupo, que, hasta el momento, solía basarse en gran medida en correos electrónicos dirigidos (spear-phishing).

En este post, primero examinaremos los casos recientes de correos electrónicos dirigidos que usan el exploit CVE-2014-1761 de Microsoft Word. Luego nos enfocaremos en el exploit kit, que parece seguir aún en la etapa de desarrollo y de prueba, y describiremos su payload (o carga) real.

De correos electrónicos dirigidos...

En abril de 2014, el malware Win32/Sednit se distribuía mediante una vulnerabilidad 0-day de los documentos RTF de Microsoft Word: CVE-2014-1761. Era una entre varias familias de malware que se distribuían a través de esta vulnerabilidad, como BlackEnergy y MiniDuke, que también se usan para realizar ataques dirigidos.

Éstos son dos documentos señuelo que el malware mostraba a las víctimas mientras aprovechaba la vulnerabilidad de sus equipos. Ambos documentos presentan opiniones de la OTAN con respecto al conflicto en Ucrania:

... al exploit kit hecho a medida

Observamos que las redirecciones al exploit kit se realizaban desde sitios web pertenecientes a una importante institución financiera polaca. Se carga a través de un simple IFRAME, que se agrega cerca del final del documento HTML; por ejemplo, hXXp://defenceiq.us/2rfKZL_BGwEQ, en la captura de pantalla mostrada abajo. También podemos ver un IFRAME con características muy similares cargando la URL hXXp://cntt.akcdndata.com/gpw?file=stat.js, cuyo nombre de dominio se registró el 18 de septiembre. No logramos recuperar el contenido de esta página, pero sospechamos que su objetivo es recopilar estadísticas sobre el número de redirecciones:

Cuando visitábamos en forma directa la URL hXXp://defenceiq.us, éramos redirigidos a defenceiq.com, un sitio legítimo que se describe a sí mismo como "una fuente de noticias autoritaria con comentarios exclusivos de calidad, análisis sobre las defensas globales y temas militares":

Descubrimos que el dominio defenceiq.us resolvía en 76.73.47.90. También hay otros dominios sospechosos que resuelven en esta dirección IP y que muestran el mismo comportamiento de redirección cuando se los visita, lo que indica con claridad qué grupo de sectores está actualmente atacando. La redirección desde los sitios web financieros polacos a un nombre de dominio relacionado con la defensa, no es para nada la mejor opción para un ataque dirigido, pero probablemente se deba a la mezcla de dos campañas paralelas en curso.

El exploit kit, que se llamó Sedkit como referencia a Sednit, tiene una conducta similar a otros de uso frecuente en la actualidad, como Angler o Nuclear. El siguiente es un ejemplo de la cadena de aprovechamiento de vulnerabilidades. Primero se envía el navegador a la página de destino, que usa JavaScript para detectar cuál es el navegador y qué versiones de complementos (plugins) tiene instalados:

Cabe notar que la llamada a DetectJavaForMSIE() queda excluida. De esta forma, continúa la tendencia actual de los exploit kits de no atacar a Java, debido a que sus versiones recientes y los navegadores emiten advertencias antes de cargar applets. Por el momento, solo Internet Explorer parece ser el objetivo de los ataques: cuando hicimos las pruebas con Chrome y Firefox, siempre fuimos redirigidos al localhost.

A continuación, el navegador devuelve la información del plugin mediante una solicitud POST. Según esta información, el exploit kit redirige al navegador ya sea a otra URL que contiene un exploit, o a http://localhost. El kit usa un solo exploit por visita.

Recuperamos 3 exploits diferentes utilizados por el kit: todos atacan Internet Explorer. Están listados abajo, indicando la versión específica de IE que ataca cada uno. Es interesante destacar que, al parecer, los populares no usan la vulnerabilidad CVE-2014-1776; asimismo, el uso de las otros dos también es limitado:

No obstante, los demás aspectos del kit carecen de perfeccionamiento. A diferencia de la mayoría de los exploit kits contemporáneos, no usa la ofuscación de JavaScript. Incluso encontramos comentarios en el código de JavaScript sobre las cadenas de programación orientada a instrucciones de retorno (ROP) de los exploits. Esto nos hace creer que aún sigue en su fase de prueba.

Imagen 1 del código del exploit para la vulnerabilidad CVE-2013-3897

Imagen 2 del código del exploit para la vulnerabilidad CVE-2014-1776

Al descomprimir el archivo de Flash utilizado para la vulnerabilidad CVE-2014-1776, se puede ver una ruta. Esta información no está presente en las muestras anteriores que tenemos del exploit:

Tras un aprovechamiento exitoso de la vulnerabilidad, se descarga el payload; si está o no cifrado depende del mismo exploit.

Payload

El archivo binario desplegado en el equipo infectado se llama “runrun.exe”. Tiene como único objetivo desplegar un segundo programa (inicialmente cifrado y comprimido) en la máquina y asegurar su persistencia en el sistema. El segundo programa es una biblioteca de Windows llamada “splm.dll”. De acuerdo a nuestros datos, este malware se viene usando en ataques dirigidos al menos desde 2009.

Para resumirlo en pocas palabras, esta carga se creó en C++. Gracias a la Información de tipos en tiempo de ejecución (RTTI, por sus siglas en inglés), es posible reconstruir una parte de la arquitectura del programa con los nombres elegidos por el programador. El malware contiene módulos agente que implementan las actividades maliciosas y canales para la comunicación entre los módulos y los controladores remotos. En este ejemplo, encontramos los siguientes módulos agente, identificados por un ID de 16 bits:

También crea la instancia de un canal de comunicación externo denominado WinHttp, que descifra tres nombres de dominio utilizados como Comando y Control: msonlinelive.com, windows-updater.com y azureon-line.com.

Conclusión

En los últimos años, los exploit kits se convirtieron en un método muy utilizado para la propagación del crimen informático,  malware de distribución masiva para facilitar el fraude financiero y hacer mal uso de los recursos del sistema infectado con diversos propósitos, como enviar spam, extraer bitcoins, recopilar credenciales, etc.

Desde 2012, observamos que esta estrategia se usa en actividades de espionaje, en lo que se conoce como “ataques watering-hole” o “ataques web estratégicos”. Un ataque watering-hole se caracteriza por redirigir el tráfico desde sitios web que suelen ser visitados por miembros de una organización o industria que constituyen el objetivo deseado del ataque.

En la Retrospectiva de ESET sobre el aprovechamiento de vulnerabilidades de Windows en 2013, Artem Baranov escribió: “El año pasado bien podría llamarse el año de los ataques dirigidos y de los ataques watering-hole”.

Mientras que muchas instancias de dichos ataques documentadas se atribuyen a las mismas bandas criminales, como explica Symantec en su Informe sobre el Proyecto Elderwood, descubrimos que otra banda criminal está adoptando este tipo de ataques, y es probable que más grupos sigan sus pasos.

Si quieres más detalles sobre el funcionamiento de Sednit, no te pierdas este video:

Indicadores de sistemas comprometidos

A continuación mostramos algunos indicadores que pueden ayudar a identificar la muestra de carga maliciosa que entrega el exploit kit descrito en esta publicación:

• Presencia del identificador CLSID {d702b440-b130-47f7-a94c-c1fae33d2820} bajo la llave de registro HKLM\Software\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
• Mutex llamado “XSQWERSystemCriticalSection_for_1232321”
• Buzón interproceso llamado “\\.\mailslot\check_mes_v5555”
• Archivos en carpetas temporales (como los devuelve %GetTempPath()) llamados “edg6EF885E2.tmp” y “tmp”
• Comunicaciones de red con los dominios llamados com, windows-updater.com, or azureon-line.com

Hashes

Traducción del post del equipo de investigación de ESET en We Live Security.