LockFile es una nueva familia de ransomware que surgió en julio de 2021 tras el descubrimiento en abril de 2021 de las vulnerabilidades de ProxyShell en los servidores de Microsoft Exchange. El ransomware LockFile parece aprovechar las vulnerabilidades de ProxyShell para entrar en los objetivos con servidores de Microsoft Exchange sin actualizar, seguido de un ataque de retransmisión NTLM PetitPotam para tomar el control del dominio.
En este análisis detallado del ransomware LockFile, revelamos su novedoso enfoque para el cifrado de archivos y cómo el ransomware intenta eludir el comportamiento y la protección contra el ransomware basada en comportamiento y estadísticas.
Este artículo analiza los siguientes datos clave en profundidad:
- El ransomware LockFile cifra cada 16 bytes de un archivo. A esto lo llamamos “cifrado intermitente” y esta es la primera vez que los investigadores de Sophos han visto que se utiliza este enfoque. El cifrado intermitente ayuda al ransomware a evadir la detección de algunas soluciones de protección contra ransomware porque un documento cifrado se ve estadísticamente muy similar al original sin cifrar.
- Al igual que WastedLocker y Maze, LockFile utiliza entrada/salida (E/S) mapeada en memoria para cifrar un archivo. Esta técnica permite que el ransomware cifre de forma transparente los documentos almacenados en caché en la memoria y hace que el sistema operativo escriba los documentos cifrados, con una E/S de disco mínima que detectarían las tecnologías de detección.
- El ransomware no necesita conectarse a un centro de comando y control para comunicarse, lo que también ayuda a mantener sus actividades bajo el radar de la detección.
- Además, LockFile cambia el nombre de los documentos cifrados a minúsculas y agrega una extensión de archivo .lockfile, y su nota de rescate HTA es muy similar a la de LockBit 2.0.
Disección 101
La investigación de Sophos se basa en una muestra de LockFile con el hash SHA-256: bf315c9c064b887ee3276e1342d43637d8c0e067260946db45942f39b970d7ce. Este archivo se puede encontrar en VirusTotal.
Si cargas esta muestra en Ghidra, notarás que solo tiene tres funciones y tres secciones.
El binario parece estar empaquetado de forma dual por UPX y mal formado para eliminar el análisis estático del software de protección de endpoints. Además, los nombres de las secciones originales se modificaron de UPX0 y UPX1 a OPEN y CLSE.
La primera sección, denominada OPEN, tiene un tamaño de 592 KB (0x94000) pero no contiene datos, solo ceros.
La segunda sección, CLSE, tiene un tamaño de 286 KB (0x43000) y las tres funciones se encuentran en la última página de esta sección. El resto de los datos es código codificado que se decodifica más tarde y se coloca en la sección “OPEN”.
La función entry() es simple y llama a FUN_1400d71c0 ():
La función FUN_1400d71c0() decodifica los datos de la sección CLSE y los coloca en la sección OPEN. También resuelve las DLL y funciones necesarias. Luego manipula los valores de IMAGE_SCN_CNT_UNINITIALIZED_DATA y salta al código colocado en la sección OPEN.
Analizando la sección OPEN
Debido a que el resto del código se descomprime en la sección OPEN, es decir, se genera en tiempo de ejecución, usamos WinDbg y .writemem para escribir la sección OPEN en el disco, por lo que podemos analizar el código estáticamente en Ghidra, por ejemplo:
.writemem c:\[redacted]\LockFile\sec_open.bin lockfileexe+1000 L94000
Después de cargar el archivo en Ghidra para su análisis, encontramos una función de inicio principal:
Esta es CRT, la biblioteca en tiempo de ejecución de C, no la función principal real que estamos buscando. Sin embargo, después de investigar, la encontramos:
Le cambiamos el nombre a main_000861() y mantenemos la dirección a mano para poder usarla como referencia al depurar en WinDbg.
La primera parte inicializa una biblioteca de cifrado:
Encontramos cadenas en el código, como “Los algoritmos criptográficos se desactivan después”, que también se utilizan en Crypto ++Library, disponible de forma gratuita en GitHub, por lo que es seguro asumir que el ransomware LockFile aprovecha esta biblioteca para sus funciones de cifrado.
Luego crea un mutex para evitar que el ransomware se ejecute dos veces al mismo tiempo:
Terminación de procesos críticos
Luego se decodifica una cadena, que es un parámetro para la llamada al system() en la línea 161.
La cadena es un parámetro para la llamada system() en la línea 161. Esto termina todos los procesos con vmwp en su nombre. Para hacer esto, se aprovecha la herramienta de línea de comandos de la Interfaz de administración de Windows (WMI) WMIC.EXE, que forma parte de cada instalación de Windows. Esta acción se repite para otros procesos comerciales críticos asociados con el software de virtualización y las bases de datos:
| Proceso | Comando |
| Hyper-V virtual machines | Proceso de wmic donde la llamada termina “nombre como ‘%vmwp%'” |
| Oracle VM Virtual Box Manager | Proceso de wmic donde la llamada termina “nombre como ‘%virtualbox%'” |
| Oracle VM Virtual Box services | Proceso de wmic donde la llamada termina “nombre como ‘%vbox%'” |
| Microsoft SQL Server, también utilizado por SharePoint | Proceso wmic donde termina la llamada “nombre como ‘%sqlservr%'” |
| MySQL database | Proceso wmic donde la llamada termina “nombre como ‘%mysqld%'” |
| Oracle MTS Recovery Service | Proceso wmic donde termina la llamada “nombre como ‘%oracle%’” |
| Oracle RDBMS Kernel | Proceso wmic donde termina la llamada “nombre como ‘%sqlservr%'” |
| Oracle TNS Listener | Proceso wmic donde termina la llamada “nombre como ‘%tnslsnr%’” |
| VMware virtual machines | Proceso wmic donde termina la llamada “nombre como ‘%vmware%’” |
Al aprovechar WMI, el ransomware en sí no se asocia directamente con la terminación abrupta de estos procesos críticos comerciales típicos. La finalización de estos procesos garantizará que se libere cualquier bloqueo en los archivos/bases de datos asociados, de modo que estos objetos estén listos para el cifrado malicioso.
El código continúa recuperando todas las letras de unidad con GetLogicalDriveString () en la línea 692 y las recorre en iteración.
En el bucle, determina el tipo de unidad a través de GetDriveType(). Cuando se trata de un disco fijo (tipo tres = DRIVE_FIXED en la línea 703), genera un nuevo hilo (en las líneas 705, 706), con la función 0x7f00 como dirección de inicio.
La nota de rescate es una aplicación HTML
La función en 0x7f00 primero crea la nota de rescate HTA, por ejemplo, “LOCKFILE-README-[hostname]-[id].hta” en la raíz de la unidad. En lugar de dejar una nota en formato TXT, LockFile formatea su nota de rescate como un archivo de aplicación HTML (HTA). Curiosamente, la nota de rescate de HTA utilizada por LockFile se parece mucho a la utilizada por el ransomware LockBit 2.0:
En su nota de rescate, el ciberdelicuente de LockFile pide a las víctimas que se pongan en contacto con una dirección de correo electrónico específica: contact@contipauper.com. El nombre de dominio utilizado, “contipauper.com” parece ser una referencia despectiva a un grupo de ransomware competidor llamado Conti. El nombre de dominio hasido creado el 16 de agosto de 2021.
Cifrar directorios
Luego, se llama a EncryptDir_00007820() en la línea seis. La primera parte de la función de cifrar directorio no es muy notable:
Pero la segunda parte es:
El ransomware usa FindFirstFile() en la línea 63 y FindNextFile() en la línea 129 para recorrer en iteración el directorio en param_1.
En la primera parte (líneas 66-91), comprueba si el nombre del archivo no contiene:
- “.Lockfile”
- “\Windows”
- “LOCKFILE”
- “NTUSER”
Luego, recorre dos listas de extensiones de tipo de archivo conocidas de documentos que no ataca (líneas 92-102).
Lista 1:
.a3l .a3m .a4l .a4p .a5l .abk .abs .acp .ada .adb .add .adf .adi .adm .adp .adr .ads .af2 .afm .aif .aifc .aiff .aim .ais .akw .alaw .tlog .vsix .pch .json .nupkg .pdb .ipdb .alb .all .ams .anc .ani .ans .api .aps .arc .ari .arj .art .asa .asc .asd .ase .asf .xaml .aso .asp .ast .asv .asx .ico .rll .ado .jsonlz4 .cat .gds .atw .avb .avi .avr .avs .awd .awr .axx .bas .bdf .bgl .bif .biff .bks .bmi .bmk .book .box .bpl .bqy .brx .bs1 .bsc .bsp .btm .bud .bun .bw .bwv .byu .c0l .cal .cam .cap .cas .cat .cca .ccb .cch .ccm .cco .cct .cda .cdf .cdi .cdm .cdt .cdx .cel .cfb .cfg .cfm .cgi .cgm .chk .chp .chr .cht .cif .cil .cim .cin .ck1 .ck2 .ck3 .ck4 .ck5 .ck6 .class .cll .clp .cls .cmd .cmf .cmg .cmp .cmv .cmx .cnf .cnm .cnq .cnt .cob .cpd .cpi .cpl .cpo .cpr .cpx .crd .crp .csc .csp .css .ctl .cue .cur .cut .cwk .cws .cxt .d64 .dbc .dbx .dc5 .dcm .dcr .dcs .dct .dcu .dcx .ddf .ddif .def .defi .dem .der .dewf .dib .dic .dif .dig .dir .diz .dlg .dll .dls .dmd .dmf .dpl .dpr .drv .drw .dsf .dsg .dsm .dsp .dsq .dst .dsw .dta .dtf .dtm .dun .dwd .dwg .dxf .dxr .eda .edd .ede .edk .edq .eds .edv .efa .efe .efk .efq .efs .efv .emd .emf .eml .enc .enff .ephtml .eps .epsf .epx .eri .err .esps .eui .evy .ewl .exc .exe .f2r .f3r .f77 .f90 .far .fav .fax .fbk .fcd .fdb .fdf .fft .fif .fig .fits .fla .flc .flf .flt .fmb .fml .fmt .fnd .fng .fnk .fog .fon .for .fot .fp1 .fp3 .fpt .frt .frx .fsf .fsl .fsm .ftg .fts .fw2 .fw3 .fw4 .fxp .fzb .fzf .fzv .gal .gdb .gdm .ged .gen .getright .gfc .gfi .gfx .gho .gid .gif .gim .gix .gkh .gks .gna .gnt .gnx .gra .grd .grf .grp .gsm .gt2 .gtk .gwx .gwz .hcm .hcom .hcr .hdf .hed .hel .hex .hgl .hlp .hog .hpj .hpp .hqx .hst .htt .htx .hxm .ica .icb .icc .icl .icm .idb .idd .idf .idq .idx .iff .igf .iif .ima .imz .inc .inf .ini .ins .int .iso .isp .ist .isu .its .ivd .ivp .ivt .ivx .iwc .j62 .java .jbf .jmp .jn1 .jtf .k25 .kar .kdc .key .kfx .kiz .kkw .kmp .kqp .kr1 .krz .ksf .lab .ldb .ldl .leg .les .lft .lgo .lha .lib .lin .lis .lnk .log .llx .lpd .lrc .lsl .lsp .lst .lwlo .lwob .lwp .lwsc .lyr .lzh .lzs .m1v .m3d .m3u .mac .magic .mak .mam .man .map .maq .mar .mas .mat .maud .maz .mb1 .mbox .mbx .mcc .mcp .mcr .mcw .mda .mdb .mde .mdl .mdn .mdw .mdz .med .mer .met .mfg .mgf .mic .mid .mif .miff .mim .mli .mmf .mmg .mmm .mmp .mn2 .mnd .mng .mnt .mnu .mod .mov .mp2 .mpa .mpe .mpp .mpr .mri .msa .msdl .msg .msn .msp .mst .mtm .mul .mus .mus10 .mvb .nan .nap .ncb .ncd .ncf .ndo .nff .nft .nil .nist .nlb .nlm .nls .nlu .nod .ns2 .nsf .nso .nst .ntf .ntx .nwc .nws .o01 .obd .obj .obz .ocx .ods .off .ofn .oft .okt .olb .ole .oogl .opl .opo .opt .opx .or2 .or3 .ora .orc .org .oss .ost .otl .out .p10 .p3 .p65 .p7c .pab .pac .pak .pal .part .pas .pat .pbd .pbf .pbk .pbl .pbm .pbr .pcd .pce .pcl .pcm .pcp .pcs .pct .pcx .pdb .pdd .pdp .pdq .pds .pf .pfa .pfb .pfc .pfm .pgd .pgl .pgm .pgp .pict .pif .pin .pix .pjx .pkg .pkr .plg .pli .plm .pls .plt .pm5 .pm6 .pog .pol .pop .pot .pov .pp4 .ppa .ppf .ppm .ppp .pqi .prc .pre .prf .prj .prn .prp .prs .prt .prv .psb .psi .psm .psp .ptd .ptm .pwl .pwp .pwz .qad .qbw .qd3d .qdt .qfl .qic .qif .qlb .qry .qst .qti .qtp .qts .qtx .qxd .ram .ras .rbh .rcc .rdf .rdl .rec .reg .rep .res .rft .rgb .rmd .rmf .rmi .rom .rov .rpm .rpt .rrs .rsl .rsm .rtk .rtm .rts .rul .rvp .s3i .s3m .sam .sav .sbk .sbl .sc2 .sc3 .scc .scd .scf .sci .scn .scp .scr .sct01 .scv .sd2 .sdf .sdk .sdl .sdr .sds .sdt .sdv .sdw .sdx .sea .sep .ses .sf .sf2 .sfd .sfi .sfr .sfw .shw .sig .sit .siz .ska .skl .slb .sld .slk .sm3 .smp .snd .sndr .sndt .sou .spd .spl .sqc .sqr .ssd .ssf .st .stl .stm .str .sty .svx .swa .swf .swp .sys .syw .t2t .t64 .taz .tbk .tcl .tdb .tex .tga .tgz .tig .tlb .tle .tmp .toc .tol .tos .tpl .tpp .trk .trm .trn .ttf .tz .uwf .v8 .vap .vbp .vbw .vbx .vce .vcf .vct .vda .vi .viff .vir .viv .vqe .vqf .vrf .vrml .vsd .vsl .vsn .vst .vsw .vxd .wcm .wdb .wdg .web .wfb .wfd .wfm .wfn .xml .acc .adt .adts .avi .bat .bmp .cab .cpl .dll .exe .flv .gif .ini .iso .jpeg .jpg .m4a .mov .mp3 .mp4 .mpeg .msi .mui .php .png .sys .wmv .xml
Lista 2:
.acc .adt .adts .avi .bat .bmp .cab .cpl .dll .exe .flv .gif .ini .iso .jpeg .jpg .m4a .mov .mp3 .mp4 .mpeg .msi .mui .php
Nota: Curiosamente, este ransomware no ataca los archivos de imagen JPG, como las fotos.
Si la extensión del archivo de un documento encontrado no está en la lista, el código concatena el nombre del archivo y la ruta (línea 103) y llama a EncryptFile_00007360() para cifrar el documento.
La función EncryptFile_00007360() cifra el documento a través de E/S mapeadas en memoria:
El documento se abre primero en la línea 164 y en la línea 177 la función CreateFileMapping() asigna el documento a la memoria. En la línea 181, lVar17 apunta al documento ahora mapeado en memoria.
El código continúa agregando el blob de descifrado al final del documento en la memoria. A continuación, se muestra un ejemplo de un documento de prueba que comprende el carácter “a” (0x61), 128 veces:
Después de agregar el blob de descifrado, el documento mapeado en memoria se ve así:
Más adelante, el documento se cifra, 16 bytes a la vez, a través de la función EncryptBuffer_0002cbf4() en la línea 271:
EncryptBuffer_0002cbf4() cifra 16 bytes en el búfer recibido lVar15. Se establece en lVar7 en la línea 268, que apunta al documento mapeado en memoria.
Curiosamente, luego agrega 0x20 (32 bytes) a lVar15, omitiendo 16 bytes. Esto hace que el cifrado sea intermitente:
La característica notable de este ransomware no es el hecho de que implementa un cifrado parcial. LockBit 2.0, DarkSide y BlackMatter ransomware, por ejemplo, son conocidos por cifrar solo una parte de los documentos que atacan (en su caso, los primeros 4096 bytes, 512 KB y 1 MB respectivamente) solo para terminar la etapa de cifrado del ataque más rápido.
Lo que distingue a LockFile es que no cifra los primeros bloques. En cambio, LockFile cifra cada 16 bytes restantes de un documento. Esto significa que un documento de texto, por ejemplo, permanece parcialmente legible.
Hay una ventaja interesante al adoptar este enfoque: el cifrado intermitente sesga el análisis estadístico y confunde algunas tecnologías de protección basadas en comportamiento.
Evadir la protección contra ransomware sesgando el análisis estadístico
El enfoque de cifrado intermitente adoptado por LockFile sesga el análisis, como el chi al cuadrado (chi^2) utilizado por algunos programas de protección contra el ransomware.
Un archivo de texto sin cifrar de 481 KB (digamos, un libro) tiene una puntuación chi^2 de 3850061. Si el documento fue cifrado por el ransomware DarkSide, tendría una puntuación chi^2 de 334, lo que es una clara indicación de que el documento ha sido cifrado. Si el mismo documento está cifrado por el ransomware LockFile, aún tendría una puntuación chi^2 significativamente alta de 1789811.
Las siguientes representaciones gráficas (distribución de bytes/caracteres) muestran el mismo documento de texto cifrado por DarkSide y LockFile.
|
|
|
|
Como puedes ver, la representación gráfica del documento de texto cifrado por LockFile es muy similar al original. Este truco tendrá éxito contra el software de protección contra ransomware que realiza una inspección de contenido con análisis estadístico para detectar el cifrado.
No hemos visto antes el uso de cifrado intermitente en ataques de ransomware.
Conservación del documento cifrado en el disco
Después del cifrado, el documento se cierra (línea 279-281) y el archivo se renombra:
La cadena “% s.lockfile” se decodifica (en las líneas 284-298) y luego se pasa a la función sprintf() en la línea 300 para agregar “.lockfile” al nombre del archivo. I
En la línea 301, el nombre de archivo original se cambia por el nuevo nombre de archivo. Curiosamente, el nombre del archivo se cambia a minúsculas y es poco probable que un descifrador LockFile pueda restaurar el nombre del archivo a su estado original, es decir, las mayúsculas en el nombre del archivo se pierden para siempre.
Dado que el ataque aprovecha CreateFileMapping(), el proceso del sistema de Windows, PID 4, escribe (conserva) el documento cifrado mapeado en memoria en el disco. Esto se puede comprobar mediante Sysinternals Process Monitor. En la siguiente figura, eliminamos el filtro Monitor de proceso que excluye la actividad del proceso del sistema (PID 4):
Al aprovechar las E/S asignadas en memoria, el ransomware puede acceder más rápidamente a los documentos que se almacenaron en caché y permitir que el proceso del sistema de Windows realice la acción de escritura. Al permitir que el proceso del sistema realice la operación WriteFile, el propio sistema operativo escribe los bytes cifrados reales, separados del proceso malicioso real.
En el ejemplo anterior, esto ocurre seis segundos después de que el ransomware cifre el documento, pero en sistemas grandes este retraso puede extenderse a minutos. Este truco por sí solo puede tener éxito en eludir la detección mediante algunas soluciones anti-ransomware basadas en el comportamiento.
El uso de E/S mapeadas en memoria no es común entre las familias de ransomware, aunque fue utilizado por el ransomware Maze y por el ransomware WastedLocker (visto con menos frecuencia).
No hay ransomware que eliminar
Una vez que ha cifrado todos los documentos en la máquina, el ransomware se borra con el siguiente comando:
cmd /c ping 127.0.0.1 -n 5 && del “C:\Users\Mark\Desktop\LockFile.exe” && exit
El comando PING envía cinco mensajes ICMP al localhost (es decir, a sí mismo), y esto simplemente tiene la intención de ser una suspensión de cinco segundos para permitir que el proceso de ransomware se cierre antes de ejecutar el comando DEL para eliminar el binario de ransomware.
Esto significa que después del ataque de ransomware, no hay binario de ransomware para que los expertos en seguridad o el software antivirus lo encuentren o limpien.
Nota: Como la mayoría de ransomware operado por humanos en la actualidad, LockFile ransomware no necesita ponerse en contacto con un servidor de comando y control (C2) en Internet para operar. Esto significa que puede cifrar datos en máquinas que no tienen acceso a Internet.
Sophos quiere agradecer a los investigadores de SophosLabs Alex Vermaning y Gabor Szappanos por sus contribuciones a este informe.
Dejar un comentario