Sednit añade dos exploits 0-day usando el ataque de Trump a Siria como señuelo

Sednit añade dos exploits 0-day usando el ataque de Trump a Siria como señuelo

El grupo de espionaje Sednit ha vuelto; ahora usa dos 0-day insertados en un correo de phishing titulado Trump's_Attack_on_Syria_English.docx.

El grupo de espionaje Sednit ha vuelto; ahora usa dos 0-day insertados en un correo de phishing titulado Trump’s_Attack_on_Syria_English.docx.

Sednit, también conocido como APT28, Fancy Bear y Sofacy, es un grupo de atacantes que operan desde al menos 2004 y cuyo objetivo principal es robar información confidencial de objetivos específicos. En octubre de 2016, ESET publicó un white paper titulado “En Route with Sednit“, donde analiza detalladamente las tácticas empleadas y su arsenal; además, en este video se describe su modo de operar:

El mes pasado, el grupo volvió a mostrar actividad, aparentemente para interferir en las elecciones francesas y atacar al candidato centrista Emmanuel Macron. En este mismo período, nos llamó la atención un correo electrónico de phishing que contenía un archivo adjunto llamado Trump’s_Attack_on_Syria_English.docx (Ataque de Trump a Siria en inglés).

El análisis del documento reveló su objetivo real: descargar el archivo Seduploader, la conocida herramienta de Sednit empleada para detectar sus objetivos de ataque. Para lograr su propósito, utilizaron dos exploits 0-day: uno para aprovechar una vulnerabilidad de ejecución remota de código en Microsoft Word (CVE-2017-0261) y otro para escalar privilegios de usuarios locales en Windows (CVE-2017-0263). ESET informó sobre ambas vulnerabilidades a Microsoft, que ayer lanzó parches como parte de su programa habitual de revisiones de los martes.

En este artículo se describe el ataque en sí y las vulnerabilidades utilizadas para infectar a los objetivos.

Del exploit de Word al dropper Seduploader

El siguiente gráfico muestra que este ataque específico coincide perfectamente con los métodos de ataque habituales de Sednit, ya que usa un correo electrónico de phishing dirigido que contiene un archivo adjunto malicioso para instalar un payload conocido, lo cual constituye la primera etapa del ataque.

En esta ocasión, el correo electrónico de phishing usaba la temática del ataque de Trump a Siria.

El archivo adjunto infectado es un documento señuelo que contiene una copia literal de un artículo titulado “Trump’s Attack on Syria: Wrong for so Many Reasons” (Ataque de Trump a Siria: un error por muchísimas razones), publicado el 12 de abril de 2017 en The California Courier:

Aquí es donde el ataque se pone interesante. El documento señuelo contiene dos exploits que permiten la instalación de Seduploader, como se muestra en el siguiente esquema:

Estos dos exploits se pueden agregar a la lista de vulnerabilidades 0-day utilizadas por Sednit durante los últimos dos años, como se muestra en la línea de tiempo:

Una vez abierto, el documento señuelo primero aprovecha una vulnerabilidad del filtro EPS en Microsoft Office, conocida como CVE-2017-0261. En este caso, el archivo EPS malicioso lleva el nombre image1.eps dentro del archivo .docx:

El archivo del exploit de EPS está ofuscado por un simple XOR. EPS proporciona la funcionalidad a variables XOR y evalúa source (exec). La clave utilizada aquí es 0xc45d6491 en una cadena hexadecimal grande y exec se llama en el búfer descifrado.

Una vez descifrado, el exploit luce muy sumilar al que fue bien documentado por FireEye en 2015. La vulnerabilidad usada en ese entonces era CVE-2015-2545. La principal diferencia se resalta en el siguiente bloque, y es cómo ejecuta la corrupción de memoria con la instrucción forall.

Una vez que se obtiene la ejecución del código, carga un shellcode que recupera algunas API de Windows indocumentadas como NtAllocateVirtualMemoryNtFreeVirtualMemory y ZwProtectVirtualMemory.

Luego de más instancias de descifrado, el dropper Seduploader se carga y ejecuta. Ten en cuenta que toda esta ejecución se produce dentro del proceso WINWORD.EXE que se ejecuta con los privilegios del usuario actual.

El dropper Seduploader

Seduploader está conformado por dos componentes distintos: un dropper y un payload persistente (consulta la página 27 de nuestro whitepaper “En Route with Sednit”).

Por más que el dropper utilizado en este ataque evolucionó desde la última versión que analizamos, su objetivo final sigue siendo el mismo: entregar el payload Seduploader. Esta nueva versión del dropper ahora contiene código para integrar el exploit LPE y usarlo en la vulnerabilidad CVE-2017-2063. El análisis detallado de esta vulnerabilidad se describe en la próxima sección de este artículo; por ahora nos ocuparemos de Seduploader.

En primer lugar, el nuevo código del dropper comprueba si el proceso se está ejecutando en una versión de Windows de 32 o 64 bits. Dependiendo del resultado, se cargará la versión correcta del exploit en la memoria.

 

Una vez que el exploit se ejecuta correctamente, el dropper Seduploader se volverá a cargar a sí mismo en el espacio de memoria de WINWORD y llamará a CreateRemoteThread con la dirección del punto de entrada UpLoader, que ejecutará el código encargado de instalar el payload de Seduploader. Este código se ejecutará con privilegios del sistema, gracias al exploit.

El payload Seduploader

El payload Seduploader es un downloader utilizado por los operadores de Sednit como malware de reconocimiento y está compuesto por dos partes. La primera parte es la responsable de inyectar la segunda parte en el proceso correcto, dependiendo de si se carga en el proceso WINWORD.EXE o no. La segunda parte es el downloader en sí.

Si Seduploader se ejecuta en WINWORD.EXE, su primera parte creará un mutex denominado flPGdvyhPykxGvhDOAZnU y abrirá un identificador en el proceso actual. Dicho identificador se utilizará para asignar memoria y escribir en ella el código de la segunda parte del componente payload, que luego será ejecutado mediante una llamada a CreateRemoteThread. De lo contrario, si no se está ejecutando en WINWORD.EXE, Seduploader utilizará CreateThread para iniciar su segunda parte.

El downloader contiene las funciones habituales de Seduploader y el algoritmo de cifrado de strings. Sin embargo, tiene algunos cambios que describimos a continuación.

En primer lugar, el algoritmo de hash utilizado para identificar los nombres de DLL y las funciones de la API que se deben resolver fue reemplazado por uno nuevo. Los lectores de nuestro white paper recordarán que el algoritmo de hash anterior había estado basado en gran parte en el código encontrado en Carberp. Bueno, el nuevo algoritmo tampoco fue creado desde cero: esta vez, Sednit usó código muy similar a PowerSniff.

Por otro lado, se agregó una nueva etiqueta img al mensaje del informe de Seduploader. Esta etiqueta permite extraer capturas de pantalla:

 

[…]
keybd_event(VK_SNAPSHOT, 0x45u, KEYEVENTF_EXTENDEDKEY, 0u);
Sleep(1000u);
keybd_event(VK_SNAPSHOT, 0x45u, KEYEVENTF_EXTENDEDKEY|KEYEVENTF_KEYUP, 0u);
OpenClipboard(0u);
hData = GetClipboardData(CF_BITMAP);
CloseClipboard();
if ( !hData )
  return 0;
GdiplusStartupInput = (const int *)1;
v10 = 0;
v11 = 0;
v12 = 0;
GdiplusStartup(&token, &GdiplusStartupInput, 0);
if ( fGetEncoderClsid((int)L”image/jpeg”, &imageCLSID) )
{
  v4 = sub_10003C5F((int)hData, 0);
  ppstm = 0;
  CreateStreamOnHGlobal(0u, 1u, &ppstm);
  v5 = GdipSaveImageToStream(v4[1], ppstm, &imageCLSID, 0);
  if ( v5 )
    v4[2] = v5;
  (*(void (__thiscall **)(_DWORD *, signed int))*v4)(v4, 1);
  IStream_Size(ppstm, &pui);
  cb = pui.s.LowPart;
  v7 = ppstm;
  *a1 = pui.s.LowPart;
  IStream_Reset(v7);
  v1 = j_HeapAlloc(cb);
  IStream_Read(ppstm, v1, cb);
  ppstm->lpVtbl->Release(ppstm);
}
GdiplusShutdown(token);
return v1;
}

Como acostumbran, los operadores de Sednit no reinventaron la rueda: encontramos varias similitudes entre su implementación de la función de captura de pantalla y el código disponible en stackoverflow. En lugar de usar GetForegroundWindow para recuperar un identificador de la ventana de primer plano en la que el usuario está trabajando, Sednit eligió usar keybd_event para enviar una pulsación de tecla “Imprimir pantalla” y recuperar la imagen desde el portapapeles.

A continuación, codifica la imagen con Base64 y la adjunta al informe, cuya estructura ahora se ve así:

Etiqueta Valor
id= Número de serie del disco rígido*
w= Lista de procesos
None Información de la tarjeta de interfaz de red
disk= Llave de registro**
build= 4 bytes
inject Campo opcional***
img= Captura de pantalla codificada en Base64

* resultado de “import win32api;print hex(win32api.GetVolumeInformation(“C:\\”)[1])
** contenido de HKLM\SYSTEM\CurrentControlSet\Services\Disk\Enum
*** se activa si SEDUPLOADER usa la inyección en un navegador para conectarse a Internet

El grupo Sednit ya había usado antes las capturas de pantalla. En el pasado, la funcionalidad se creó como una herramienta separada y autónoma, a menudo invocada por Xtunnel en una etapa posterior de infección (consulta la página 77 de nuestro whitepaper), pero ahora está incorporada a Seduploader para usarla en la fase de reconocimiento.

Finalmente, se añadieron dos nuevas funciones en el Config: shell LoadLib. La función shell le permite al atacante ejecutar código arbitrario directamente en la memoria. La función LoadLib es un campo de bits que le permite ejecutar una Dll arbitraria llamando a rundll32.exe.

CVE-2017-0263: vulnerabilidad para escalar los privilegios de los usuarios

Cómo opera el exploit

Como se mencionó anteriormente, para desplegar el payload Seduploader, el dropper Seduploader obtiene privilegios de sistema mediante el aprovechamiento de una vulnerabilidad de LPE (Escalada de privilegios para usuarios locales) conocida como CVE-2017-0263. En esta sección, describiremos cómo Sednit aprovecha dicha vulnerabilidad.

En primer lugar, aunque la vulnerabilidad afecta a los sistemas Windows 7 y posteriores (al final de este post figura la lista completa de las plataformas afectadas), el exploit está diseñado para evitar su ejecución en las versiones de Windows 8.1 y posteriores.

Dado que el exploit puede atacar plataformas de 32 y 64 bits, primero determinará si el proceso se está ejecutando en WOW64. El exploit asignará varias páginas hasta llegar a una dirección alta (0x02010000). Luego creará la siguiente estructura:

 

A continuación, recuperará la dirección de HMValidateHandle. Esta función le permite al atacante obtener la dirección del kernel a partir de un objeto tagWND.

Aquí mostramos en líneas generales cómo funciona el resto del exploit:

El exploit creará 256 clases de ventanas aleatorias y sus ventanas asociadas. Cada ventana tendrá 512 bytes de memoria adicional. Esta memoria adicional es contigua al objeto tagWND en el espacio del kernel. Una vez creada la primera ventana (es decir, en la memoria extra), el exploit crea un objeto falso que contendrá principalmente su propia dirección para uso posterior, como se muestra en la imagen:

Cuando se crean todas las ventanas, el exploit asignará dos ventanas adicionales. El propósito de la primera es ejecutarse en un subproceso del kernel; vamos a llamar a esta ventana KernelWnd. La otra principalmente recibirá todos los mensajes necesarios requeridos por el exploit para completar su función, vamos a llamarla TargetWindow. A continuación, el exploit asocia este procedimiento con el objeto recién asignado, KernelWnd.

// …
TargetWindow = CreateWindowExW(0x80088u, MainWindowClass, 0, WS_VISIBLE, 0, 0, 1, 1, 0, 0, hModuleSelf, 0);
KernelWnd = CreateWindowExW(0, MainWindowClass, 0, 0, 0, 0, 1, 1, 0, 0, hModuleSelf, 0);
// …
SetWindowLongW(KernelWnd, GWL_WNDPROC, (LONG)Payload_0->WndProc);

Vamos a dar un poco de contexto para el comportamiento del componente win32k. Cada vez que se crea una nueva ventana mediante CreateWindowExW, el controlador asignará un nuevo objeto tagWND en el kernel. El objeto se puede describir de la siguiente forma (algunos campos fueron eliminados para mejorar la claridad):

Como se puede ver, tagWND→lpfnWindowProc contiene la dirección del procedimiento asociado con esta ventana. Por lo general, el controlador disminuye sus privilegios para ejecutar este procedimiento en el contexto del usuario. Este comportamiento está controlado por el bit tagWND→bServerSideProc. Si se establece este bit, el procedimiento se ejecutará con privilegios elevados, es decir, en el kernel. Para que funcione el exploit, es necesario invertir el bit tagWND→bServerSideProc. Lo único que debe hacer el atacante es encontrar la forma de invertirlo.

Durante la destrucción de los menús, el enlace previamente configurado comprobará si la clase del objeto es SysShadow, como se muestra en el siguiente bloque de código. De ser así, reemplazará el procedimiento asociado con el suyo propio.

 

En este procedimiento, se puede observar que el exploit busca el mensaje WM_NCDESTROY. Si se cumplen los requisitos, creará un objeto tagPOPUPMENU malicioso, descrito por el siguiente pseudocódigo:

Cabe notar que la dirección utilizada para crear el objeto se encuentra dentro de la memoria adicional asignada al final de nuestra primera ventana tagWND. A continuación, el exploit llama a NtUserMNDragLeave  con el fin de invertir el bit bServerSideProc de nuestra ventana KernelWnd. Para ello, la función recuperará un objeto tagMENUSTATE utilizando la estructura agTHREADINFO. El objeto tagMENUSTATE contiene la dirección del objeto del menú que se está destruyendo (tagMENUSTATE→pGlobalPopupMenu).

Como se puede ver,  tagPOPUPMENU es el objeto malicioso que hemos creado en el espacio de usuario antes de llamar a NtUserMNDragLeave. Al observar los campos en el tagPOPUPMENU malicioso, podemos ver que todos apuntan a la memoria extra excepto uno, que apunta a nuestro objeto KernelWnd.

De aquí en más, la ejecución alcanzará la función MNFreePopup, que tiene un puntero que apunta a un objeto tagPOPUPMENU. Eventualmente, esta función llamará a HMAssignmentUnlock, pasando por los campos spwndNextPopup y spwndPrevPopup como argumento:

Tras la ejecución de syscall, nuestra estructura tagWND asociada con nuestra ventana KernelWnd se verá así:

¡Todo está listo! Lo único que necesita hacer el exploit es enviar el mensaje correcto para activar la ejecución de nuestro procedimiento en modo kernel.

Por último, el procedimiento de ventana que se ejecuta con privilegios elevados robará el token del sistema y lo añadirá al proceso de llamada. Una vez que el exploit se ha ejecutado correctamente, FLTLDR.EXE debería ejecutarse con privilegios de sistema e instalar el payload Seduploader.

Resumen

Esta campaña nos muestra que el grupo Sednit no ha cesado sus actividades. Siguen manteniendo sus viejos hábitos: utilizan métodos de ataque conocidos, reutilizan código de otros programas maliciosos o de sitios web públicos, y cometen pequeños errores como los errores tipográficos en la configuración de Seduploader (shel en vez de shell).

También es habitual el hecho de que una vez más hayan mejorado su conjunto de herramientas, esta vez añadiendo algunas funciones integradas, como la capacidad de tomar capturas de pantalla y los dos exploits 0-day incorporados a su arsenal.

Plataformas afectadas por CVE-2017-0262 y CVE-2017-0263 (según Microsoft)

CVE-2017-0262

  • Microsoft Office 2010 Service Pack 2 (ediciones de 32 bits)
  • Microsoft Office 2010 Service Pack 2 (ediciones de 64 bits)
  • Microsoft Office 2013 Service Pack 1 (ediciones de 32 bits)
  • Microsoft Office 2013 Service Pack 1 (ediciones de 64 bits)
  • Microsoft Office 2013 RT Service Pack 1
  • Microsoft Office 2016 (edición de 32 bits)
  • Microsoft Office 2016 (edición de 64 bits)

CVE-2017-0263

  • Windows 7 para sistemas de 32 bits, Service Pack 1
  • Windows 7 para sistemas basados en x64, Service Pack 1
  • Windows Server 2008 R2 para sistemas basados en  x64, Service Pack 1 (instalación de Server Core)
  • Windows Server 2008 R2 para sistemas basados en Itanium, Service Pack 1
  • Windows Server 2008 R2 para sistemas basados en x64, Service Pack 1
  • Windows Server 2008 R2 para sistemas de 32 bits, Service Pack 2 (instalación de Server Core)
  • Windows Server 2012
  • Windows Server 2012 (instalación de Server Core)
  • Windows 8.1 para sistemas de 32 bits
  • Windows 8.1 para sistemas basados en x64
  • Windows Server 2012 R2
  • Windows RT 8.1
  • Windows Server 2012 R2 (instalación de Server Core)
  • Windows 10 para sistemas de 32 bits
  • Windows 10 para sistemas basados en x64
  • Windows 10 Versión 1511 para sistemas basados en x64
  • Windows 10 Versión 1511 para sistemas de 32 bits
  • Windows Server 2016
  • Windows 10 Versión 1607 para sistemas de 32 bits
  • Windows 10 Versión 1607 para sistemas basados en x64
  • Windows Server 2016 (instalación de Server Core)
  • Windows 10 Versión 1703 para sistemas de 32 bits
  • Windows 10 Versión 1703 para sistemas basados en x64
  • Windows Server 2008 para sistemas basados en Itanium, Service Pack 2
  • Windows Server 2008 para sistemas de 32 bits, Service Pack 2
  • Windows Server 2008 para sistemas basados en x64, Service Pack 2 o posterior
  • Windows Server 2008 para sistemas basados en  x64, Service Pack 2 (instalación de Server Core)

IoCs

También disponibles en la cuenta de Github de ESET.

SHA-1Nombre del archivoDetección de ESET
d5235d136cfcadbef431eea7253d80bde414db9dTrump's_Attack_on_Syria_English.docxWin32/Exploit.Agent.NWZ
18b7dd3917231d7bae93c11f915e9702aa5d1bbbimage1.epsWin32/Exploit.Agent.NWZ
6a90e0b5ec9970a9f443a7d52eee4c16f17fcc70joiner.dllWin32/Exploit.Agent.NWV
e338d49c270baf64363879e5eecb8fa6bdde8ad9apisecconnect.dllWin32/Sednit.BG
d072d9f81390c14ffc5f3b7ae066ba3999f80feenoneWin32/Exploit.Agent.NWV

Mutex

Clave de registro

Discusión