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:

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
}