Nueva investigación sobre Carbon, el backdoor que usa el grupo Turla

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/nueva-investigacion-sobre-carbon-el-backdoor-que-usa-el-grupo-turla/
TAGS: Backdoor, Carbon, Turla

El grupo de espionaje Turla ha estado apuntando a varias instituciones durante muchos años. Recientemente encontramos varias nuevas versiones de Carbon, un backdoor que participa en la segunda instancia del proceso de infección y forma parte de su arsenal.

El año pasado, el GovCERT.ch de Suiza hizo un análisis técnico de este componente como parte de su reporte, detallando el ataque que una firma de defensa propiedad del gobierno suizo, RUAG, había sufrido anteriormente.

En este artículo remarcamos las innovaciones técnicas que encontramos en las últimas versiones de Carbon que descubrimos.

Echando un vistazo a sus diferentes números, está claro que Carbon todavía está siendo desarrollado activamente. A través de las versiones internas embebidas en el código, vemos que las nuevas se lanzan en forma regular. El grupo también es conocido por cambiar sus herramientas una vez que fueron expuestas; hemos visto que entre dos grandes lanzamientos, los mutexes y nombres de archivo están cambiando.

Vectores de infección

El grupo Turla es muy cuidadoso y trabaja en etapas, primero haciendo un reconocimiento en el sistema de su víctima antes de liberar allí sus herramientas más sofisticadas, como Carbon.

El proceso clásico que involucra a este componente comienza cuando el usuario recibe un correo de phishing dirigido (spear phishing) o visita un sitio web previamente comprometido, generalmente uno que visita regularmente y es factible de levantar menos sospechas; esta técnica se denomina ataque watering hole.

Si el ataque es exitoso, se instala en la máquina un backdoor de primera instancia como Tavdig o Skipper. Cuando termina la fase de reconocimiento, se instala un backdoor de segunda instancia, como Carbon, en los sistemas clave.

Análisis técnico

Carbon es un backdoor sofisticado usado para robar información sensible de objetivos que resultan de interés para Turla.

Este malware comparte algunas similitudes con Uroburos, un rootkit que usa este mismo grupo. La coincidencia más relevante está en la estructura de comunicación, ya que ambos proveen canales de comunicación entre diferentes componentes del malware. Los objetos se implementan de la misma manera y las estructuras y tablas virtuales lucen idénticas, excepto que hay menos canales de comunicación provistos por Carbon. De hecho, Carbon podría ser una versión limitada de Uroburos, sin componentes de kernel y sin exploits.

En resumen: para que Turla decida instalar Carbon en un sistema, generalmente se envía una herramienta de reconocimiento de “fase 1” al blanco, la cual recolecta información diversa sobre la máquina de la víctima y su red, como es el caso de Tavdig o Skipper, por ejemplo. Si se considera a este objetivo lo suficientemente interesante, recibirá un malware más sofisticado, como Carbon o Uroburos.

Entonces, la estructura de Carbon está compuesta por:

  • Un dropper que instala sus componentes y su archivo de configuración
  • Un componente que se comunica con el C&C
  • Un despachador que maneja las tareas, las despacha a otras computadoras de la red e inyecta en un proceso legítimo al DLL que se comunica con el C&C
  • Un loader que ejecuta al despachador

Archivos de Carbon

Los archivos de la estructura de Carbon pueden tener diferentes nombres dependiendo de la versión, pero mantienen el mismo nombre interno (de los metadatos) sin importar la versión:

  • El dropper: “SERVICE.EXE”
  • El loader: “SERVICE.DLL” o “KmSvc.DLL”
  • El despachador: “MSIMGHLP.DLL”
  • La librería inyectada: “MSXIML.DLL”

Cada uno de estos archivos existen en 32 bits y 64 bits.

Directorio de trabajo

Carbon crea varios archivos para mantener registros, tareas a ejecutar y configuración que modificará el comportamiento del malware. El contenido de la mayoría de estos archivos se cifra con el algoritmo CAST-128.

Un directorio de trabajo base contendrá los archivos/carpetas relacionados a Carbon; se elige en forma aleatoria entre las carpetas en %ProgramFiles% pero excluyendo “WindowsApps”.

Los nombres de archivo están codificados en el despachador y se usan los mismos en la variante 3.7x; dado que la librería inyectada accede a los mismos archivos que el despachador, es otra forma fácil de enlazar una versión de librería con un despachador.

Vista del árbol de archivos de Carbon 3.7x:
\%carbon_working_folder\%   // carpeta base
├── 0208 // resultados de tareas y registros de archivos
│   ├── C_56743.NLS // contiene la lista de archivos a enviar al servidor de C&C; no está comprimido ni cifrado
├── asmcerts.rs
├── getcerts.rs
├── miniport.dat  // archivo de configuración
├── msximl.dll    // librería inyectada (x32)
├── Nls // contiene tareas (comandos a ser ejecutados o archivo PE) y sus archivos de configuración
│   ├── a67ncodc.ax  // tareas a ser ejecutadas por el despachador
│   ├── b9s3coff.ax  // tareas a ser ejecutadas por la librería inyectada
├── System   // carpeta de plugins
│   ├── bootmisc.sdi // no utilizado
├── qavscr.dat    // registro de errores
├── vndkrmn.dic   // log
└── ximarsh.dll   // librería inyectada (x64)

Desde la versión 3.80, todos los nombres de archivo han cambiado.

Vista del árbol de archivos de Carbon 3.8x:
\carbon_working_folder\%   // carpeta base
├── 0409  // contiene tareas (comandos a ser ejecutados o archivo PE) y sus archivos de configuración
│   ├── cifrado.xml    // tareas a ser ejecutadas por la librería inyectada
│   ├── encodebase.inf // tareas a ser ejecutadas por el despachador
├── 1033 // resultados de tareas y registros de archivos
│   ├── dsntype.gif // contiene la lista de archivos a enviar al servidor de C&C; no está comprimido ni cifrado
├── en-US  // carpeta de plugins
│   ├── asmlang.jpg // no utilizado
├── fsbootfail.dat  // registro de errores
├── mkfieldsec.dll  // librería inyectada (x32)
├── preinsta.jpg    // log
├── wkstrend.xml    // archivo de configuración
├── xmlrts.png
└── zcerterror.png

Acceso a archivos

En la mayoría de los archivos de la carpeta de trabajo de Carbon, cuando el malware accede a uno, se dan los siguientes pasos:

  • Se usa un mutex específico para asegurar su acceso exclusivo
  • Se descifra el archivo (CAST-128)
  • Cuando las operaciones en el archivo terminaron, se vuelve a cifrar (CAST-128)
  • Se libera el mutex

Mutexes

En Carbon 3.7x el despachador crea los siguientes mutexes:

  • “Global\\MSCTF.Shared.MUTEX.ZRX” (usado para asegurar acceso exclusivo a “vndkrmn.dic”)
  • “Global\\DBWindowsBase” (usado para asegurar acceso exclusivo a “C_56743.NLS”)
  • “Global\\IEFrame.LockDefaultBrowser” (usado para asegurar acceso exclusivo a “b9s3coss.ax”)
  • “Global\\WinSta0_DesktopSessionMut” (usado para asegurar acceso exclusivo a “a67ncodc.ax”)
  • “Global\5FA3BC02-920F-D42A-68BC-04F2A75BE158” (usado para asegurar acceso exclusivo a nuevos archivos creados en la carpeta “Nls”)
  • “Global\\SENS.LockStarterCacheResource” (usado para asegurar acceso exclusivo a “miniport.dat”)
  • “Global\\ShimSharedMemoryLock” (usado para asegurar acceso exclusivo a “asmcerts.rs”)

En Carbon 3.8x, los nombres de archivo y de mutex han cambiado:

  • “Global\\Stack.Trace.Multi.TOS” (usado para asegurar acceso exclusivo a  “preinsta.jpg”)
  • “Global\\TrackFirleSystemIntegrity” (usado para asegurar acceso exclusivo a “dsntype.gif”)
  • “Global\\BitswapNormalOps” (usado para asegurar acceso exclusivo a “cifrado.xml”)
  • “Global\\VB_crypto_library_backend” (usado para asegurar acceso exclusivo a “encodebase.inf”)
  • “Global\E41B9AF4-B4E1-063B-7352-4AB6E8F355C7” (usado para asegurar acceso exclusivo a nuevos archivos creados en la carpeta “0409”)
  • “Global\\Exchange.Properties.B” (usado para asegurar acceso exclusivo a “wkstrend.xml”)
  • “Global\\DatabaseTransSecurityLock” (usado para asegurar acceso exclusivo a “xmlrts.png”)

Estos mutexes también se usan en el DLL inyectado para asegurar que el despachador se ha ejecutado.

Archivo de configuración

El archivo de configuración afecta el comportamiento del malware. Su formato es similar a los “inf” usados en Windows.

Contiene, entre otras cosas:

  • Un “object_id” que es un uuid único usado para identificar a la víctima; cuando el valor no está fijado en el archivo, el malware lo genera en forma aleatoria
  • Una lista de procesos en la cual se inyecta código (iproc)
  • La frecuencia y hora de ejecución de tareas, registros de backup y conexiones al C&C ([TIME])
  • Las direcciones IP de otras computadoras en la red ([CW_LOCAL])
  • Las direcciones del servidor de C&C ([CW_INET])
  • Los atajos con nombre que se usan para comunicarse con la librería inyectada y con los otros componentes ([TRANSPORT])

Puede que este archivo se actualice más adelante.

De hecho, en la librería de comunicaciones, algunas llaves criptográficas se usan para cifrar/descifrar datos y se obtienen de la sección [CRYPTO] en el archivo de configuración, la cual no existe cuando el archivo se ejecuta desde los recursos del loader.

Archivo de configuración de Carbon 3.77:
[NAME]
object_id=
iproc = iexplore.exe,outlook.exe,msimn.exe,firefox.exe,opera.exe,chrome.exe
ex = #,netscape.exe,mozilla.exe,adobeupdater.exe,chrome.exe


[TIME]
user_winmin = 1800000
user_winmax = 3600000
sys_winmin = 3600000
sys_winmax = 3700000
task_min = 20000
task_max = 30000
checkmin = 60000
checkmax = 70000
logmin =  60000
logmax = 120000
lastconnect=111
timestop=
active_con = 900000
time2task=3600000


[CW_LOCAL]
quantity = 0

[CW_INET]
quantity = 3
address1 = doctorshand.org:80:/wp-content/about/
address2 = www.lasac.eu:80:/credit_payment/url/
address3 = www.shoppingexpert.it:80:/wp-content/gallery/

[TRANSPORT]
system_pipe = comnap
spstatus = yes
adaptable = no


[DHCP]
server = 135


[LOG]
logperiod = 7200

[WORKDATA]
run_task=
run_task_system=

Archivo de registro

Se usa para registrar acciones ejecutadas por el malware e información del sistema que puede ser útil para el atacante; por ejemplo, si se está ejecutando una herramienta de análisis como WireShark.

Su formato no ha cambiado desde Carbon 3.71:

  • Date|Time|Object-Id|Source|Message
Ejemplo:
[LOG]
start=1
20/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|OPER|New object ID generated '8hTdJtUBB57ieReZAOSgUYacts'|
20/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|ST|3/81|0|
20/02/17|12:48:24|8hTdJtUBB57ieReZAOSgUYacts|s|START OK

Este archivo se respalda periódicamente y se envía al C&C.

¿Te interesa conocer más detalles técnicos sobre Carbon? En el análisis completo, disponible en inglés, encontrarás mas información sobre el dropper, el loader, el despachador, la ejecución de tareas, los canales de comunicación, el envío de tareas a otros equipos, los componentes cifrados y más.

Fuente:https://www.welivesecurity.com

Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/nueva-investigacion-sobre-carbon-el-backdoor-que-usa-el-grupo-turla/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s