Análisis de Erebus. Un ransomware para Linux

Esta semana hemos conocido que la empresa surcoreana NAYANA, proveedora de servicios web, sufrió un ataque de una variante del ransomware Erebus. El caso llamó la atención dado que infectó a 153 servidores, todos ellos con sistema operativo Linux, en el cual más de 3.400 archivos se han visto afectados.

En este artículo vamos a llevar a cabo un análisis sobre una muestra del ejecutable encargado de llevar a cabo la infección en esta última campaña de Erebus:

sha256: 0b7996bca486575be15e68dba7cbd802b1e5f90436ba23f802da66292c8a055f

Lo primero que podemos encontrar en el main del binario es la llamada a la función sym.log_init, donde se llevará a cabo la creación de un fichero de log (./{5f58d6f0-bb9c-46e2-a4da-8ebc746f24a5}//log.log). A lo largo del binario se puede encontrar de forma recurrente la llamada a la función sym.log_write.

Primer bloque de instrucciones de la función main

Seguidamente se inicializan tres objetos importantes en el almacenamiento de información del sistema por parte del ransomware. El primero de ellos es GARG (desde la función sym.g_init_arg), en el cual se almacenará la información intrínseca del proceso asociado a Erebus.

A continuación se inician los objetos GCONF y GINFO. Mientras que el objeto GCONF se encarga de almacenar la información que se remitirá al servidor de C&C para una posterior gestión de descifrado de archivos, el objeto GINFO almacena las características asociadas a la máquina infectada. Ambas son gestionadas desde la función sym.g_init.

Estos son los parámetros asociados a cada objeto:

GARG.process_name
GARG.instance_name
GARG.work
GARG.time_run
GCONF.id
GCONF.seed_sys
GCONF.seed_hash
GCONF.password
GCONF.key_app
GCONF.rsa_pub
GCONF.key_rsa_size
GCONF.cc_server_size
GCONF.timeout
GCONF.cc_timeout_conn
GCONF.url_list_size
GCONF.url_dn_list_size
GINFO.work_path
GINFO.self_path
GINFO.self_hash
GINFO.os
GINFO.os_version
GINFO.os_arch
GINFO.nic
GINFO.locale
GINFO.timezone

 

Una vez inicializadas todas las variables necesarias para el funcionamiento del ransomware, se empieza la primera de las cuatro partes de la gestión del demonio asociado desde sym.platform_daemon, función en la cual se asignará un session id al proceso, además de los permisos necesarios:

Extracto de la función sym.platform_daemon

Tras ello, nuestro ransomware ejecuta la segunda parte del demonio, es decir, la relacionada con la persistencia del mismo.

Esta función se lleva a cabo desde la función sym.platform_pre, almacenando la información del directorio de trabajo del malware en la variable GINFO.work_path y ejecutando posteriormente la función sym.platform_install.

Creará la persistencia del malware en el sistema de dos modos distintos, como un servicio bluetooth y mediante el cron, ejecutándose cada hora.

Creación del servicio asociado a Erebus.

 

Automatización de la ejecución cada hora mediante cron

Una vez ha logrado la persistencia, sólo le queda arrancar el demonio mediante la función sym.work_daemon, que, dentro de ella, podemos encontrar diferentes funciones asociadas al correcto funcionamiento.

 La función sym.work_start es la función principal del programa, la cual se encarga en primer lugar del escaneo de todo el sistema de ficheros desde la función sym.elib_fs_scan, como también del posterior cifrado a través de la función sym.elib_fw_scan_dir_result_encrypt.

Extracto de la función sym.work_start. Se observa la llamada a las funciones de escaneo y cifrado.

Es también en esta fase en la cual se comunica con el servidor C&C, utilizando peticiones http. El proceso se inicia tras la llamada a la función sym.cc_instance, el cual lleva a cabo la creación de un objeto de tipo JSON donde almacenar toda la información recopilada hasta el momento. Finalmente llamará a la función sym.cc_broadcast_mt y, tras ello, a sym.cc_broadcast_do. Esta última será finalmente la encargada de llamar a sym.cc_http, que llevará a cabo el envío de los objetos JSON a través de peticiones POST , haciendo uso de la herramienta curl.

Llamada a la función encargada de la comunicación con el servidor CnC.

La dirección IP contra la que lleva a cabo estas peticiones es 216.126.224.128 y éstos, los diferentes dominios TOR asociados a la campaña:

7fv4vg4n26cxleel.onion.to
7fv4vg4n26cxleel.onion.nu
7fv4vg4n26cxleel.hiddenservice.net
7fv4vg4n26cxleel.gbe0.top
qzjordhlw5mqhcn7.onion.to
qzjordhlw5mqhcn7.onion.nu
qzjordhlw5mqhcn7.hiddenservice.net
qzjordhlw5mqhcn7.gbe0.top
7fv4vg4n26cxleel.onion
qzjordhlw5mqhcn7.onion

El listado de extensiones contra las que actúa nuestro ransomware:

3g2,3gp,7z,7zip,accdb,aoi,asf,asp,aspx,asx,avi,bak,cer,cfg,class,config,css,csv,db,dds,dwg,dxf,flf,flv,html,idx,js,key,kwm,laccdb,ldf,lit,m3u,mbx,md,mdf,mid,mlb,mov,mp3,mp4,mpg,obj,odt,pages,php,psd,pwm,rm,safe,sav,save,sql,srt,swf,thm,vob,wav,wma,wmv,xlsb,3dm,aac,ai,arw,c,cdr,cls,cpi,cpp,cs,db3,docm,dot,dotm,dotx,drw,dxb,eps,fla,flac,fxg,java,m,m4v,max,mdb,pcd,pct,pl,potm,potx,ppam,ppsm,ppsx,pptm,ps,pspimage,r3d,rw2,sldm,sldx,svg,tga,wps,xla,xlam,xlm,xlr,xlsm,xlt,xltm,xltx,xlw,act,adp,al,bkp,blend,cdf,cdx,cgm,cr2,crt,dac,dbf,dcr,ddd,design,dtd,fdb,fff,fpx,h,iif,indd,jpeg,mos,nd,nsd,nsf,nsg,nsh,odc,odp,oil,pas,pat,pef,pfx,ptx,qbb,qbm,sas7bdat,say,st4,st6,stc,sxc,sxw,tlg,wad,xlk,aiff,bin,bmp,cmt,dat,dit,edb,flvv,gif,groups,hdd,hpp,log,m2ts,m4p,mkv,mpeg,ndf,nvram,ogg,ost,pab,pdb,pif,png,qed,qcow,qcow2,rvt,st7,stm,vbox,vdi,vhd,vhdx,vmdk,vmsd,vmx,vmxf,3fr,3pr,ab4,accde,accdr,accdt,ach,acr,adb,ads,agdl,ait,apj,asm,awg,back,backup,backupdb,bank,bay,bdb,bgt,bik,bpw,cdr3,cdr4,cdns3,ns4,nwb,nx2,nxl,nyf,odb,odf,odg,odm,orf,otg,oth,otp,ots,ott,p12,p7b,p7c,pdd,pem,plus_muhd,plc,pot,pptx,psafe3,py,qba,qbr,qbw,qbx,qby,raf,rat,raw,rdb,rwl,rwz,s3db,sd0,sda,sdf,sqlite,sqlite3,sqlitedb,sr2,srf,srw,st5,st8,std,sti,stw,stx,sxd,sxg,sxi,sxm,tex,wallet,wb2,wpd,x11,x3f,xis,ycbcra,yuv,mab,json,ini,sdb,sqlite-shm,sqlite-wal,msf,jar,cdb,srb,abd,qtb,cfn,info,info_,flb,def,atb,tbn,tbb,tlx,pml,pmo,pnx,pnc,pmi,pmm,lck,pm!,pmr,usr,pnd,pmj,pm,lock,srs,pbf,omg,wmf,sh,war,ascx,tif

Además, destacar que evita el cifrado de los siguientes directorios:

bin boot dev etc lib lib64 proc run sbin srv sys tmp usr var .gem .bundle .nvm .npm

Finalmente, el ransomware se elimina a sí mismo una vez recibidas las instrucciones desde el C2 a través de la función sym.platform_post, borrando cualquier rastro de los directorios destinados a la persistencia del mismo.

Borrado de los ficheros de persistencia del ransomware.

Adjuntamos una regla yara para la identificación del malware, la cual se puede encontrar en el repositorio link yara-rules:

rule Erebus: MALW
{
	meta:
		description = "Erebus Ransomware"
		author = "Joan Soriano / @joanbtl"
		date = "2017-06-23"
		version = "1.0"
		MD5 = "27d857e12b9be5d43f935b8cc86eaabf"
		SHA256 = "0b7996bca486575be15e68dba7cbd802b1e5f90436ba23f802da66292c8a055f"
		ref1 = "http://blog.trendmicro.com/trendlabs-security-intelligence/erebus-resurfaces-as-linux-ransomware/"
	strings:
		$a = "/{5f58d6f0-bb9c-46e2-a4da-8ebc746f24a5}//log.log"
		$b = "EREBUS IS BEST."
	condition:
		all of them
}

Comments

  1. ¿Cual sería el vector de infeccion?

  2. Al parecer no está demasiado claro dadas las importantes vulnerabilidades presentes en su página web.
    Ésta se ejecuta sobre una versión del kernel de Linux 2.6.24.2, la cual sería vulnerable, por ejemplo, a Dirty Cow, además de estar presentes las versiones de Apache2 1.3.36 y PHP 5.1.4, las cuales salieron a la luz en 2006.

    Un saludo

  3. Si claro corriendo como root…¿Cómo se expande?

  4. En la muestra analizada no se ha encontrado ningún tipo de propagación, de ahí que algunas informaciones apunten a que pueda tratarse de un ataque dirigido, además de que el foco del ataque está situado, sobre todo, en Corea del Sur.

    Un saludo

  5. Será un ataque automatizado con bots recorriendo google en busca de wordpress, joomlas, etc. y una vez infectada la cuenta de usuario escala privilegios en el kernel antiguo.

  6. Hola KaR]V[aN,
    eso tendría sentido si no fuera porque no ha afectado de manera uniforme a todos los países, sino a objetivos concretos.

    Un saludo

  7. Entonces Erebus, no supondría un peligro si uno sigue las buenas prácticas, ya que no se propaga como Wannacry o Non-Petya. Ahora, ¿la ejecución de Erebus solo se realiza con privilegios root?

    Saludos,

  8. Hola Ignacio,

    según hemos podido observar durante el análisis dinámico de la muestra, Erebus se instala en el crontab del usuario independientemente de si tiene permisos de root, por lo que podría ejecutarse sin dichos privilegios, obviamente, con mucho menor alcance.

    Un saludo

    PD: Si no estoy equivocado, la propagación de Non-Petya parece ser únicamente dentro de una red interna, a diferencia de WannaCry, que sí escaneaba Internet en búsqueda de vulnerabilidades ;)

Deja un comentario