IsaacWiper y HermeticWizard: un nuevo wiper y worm utilizados en ciberataques a Ucrania

Cuando comenzaron los ataques entre Rusia y Ucrania, los investigadores de ESET descubrieron varias familias de malware dirigidas a organizaciones ucranianas.

• El 23 de febrero de 2022, una campaña con fines destructivos utilizó HermeticWiper y apunto contra varias organizaciones ucranianas.
• Este ciberataque fue unas horas después del inicio de la invasión a Ucrania por parte de las fuerzas de la Federación Rusa
• Los vectores de acceso inicial utilizados fueron diferentes de una organización a otra. Confirmamos un caso en el que el wiper fue droppeado mediante GPO y que ocultaba un worm utilizado para propagar el wiper en otra red comprometida.
• Elementos en el malware sugieren que los ataques habían sido planeados durante varios meses.
• El 24 de febrero de 2022, comenzó un segundo ataque con intenciones destructivas contra una red gubernamental ucraniana, utilizando un wiper al que hemos llamado IsaacWiper.
• ESET Research aún no ha podido atribuir estos ataques a un actor de amenazas conocido.

Ciberataques destructivos en Ucrania

Como reveló el equipo de ESET Research en este tweet y también en este artículo publicado en WeLiveSecurity, descubrimos un ataque con intenciones destructivas dirigido a computadoras en Ucrania que comenzó el 23 de febrero de 2022 alrededor de las 14:52 UTC. Esto ocurrió después de los ataques distribuidos de denegación de servicio (DDoS) contra algunos de los principales sitios web ucranianos y pocas horas después de la invasión militar rusa.

Estos ataques con objetivos destructivos utilizaron al menos tres componentes:

• HermeticWiper: hace que un sistema quede inoperativo al corromper sus datos
• HermeticWizard: distribuye HermeticWiper a través de una red local vía WMI y SMB
• HermeticRansom: ransomware escrito en Go

HermeticWiper fue detectado en cientos de sistemas y en al menos cinco organizaciones ucranianas.

El 24 de febrero de 2022 detectamos otro nuevo malware del tipo wiper en una red gubernamental ucraniana. Lo llamamos IsaacWiper y actualmente estamos evaluando sus vínculos, si es que los hay, con HermeticWiper. Es importante señalar que IsaacWiper se detectó en una organización que no había sido afectada por HermeticWiper.

Atribución

Hasta el momento no hemos identificado ninguna conexión tangible con un actor de amenazas conocido. HermeticWiper, HermeticWizard y HermeticRansom no comparten ninguna similitud de código significativa con otras muestras que componen la colección de malware de ESET. Por su parte, IsaacWiper tampoco ha sido atribuido.

Cronología

HermeticWiper y HermeticWizard fueron firmados mediante un certificado de firma de código (que se muestra en la Figura 1) asignado a Hermetica Digital Ltd emitido el 13 de abril de 2021. Solicitamos a la autoridad certificadora ​​(DigiCert) que revocara el certificado, lo cual hizo el 24 de febrero de 2022.

Figura 1. Certificado de firma de código asignado a Hermetic Digital Ltd

Según un informe de Reuters, parece que este certificado no fue robado de Hermetica Digital, sino que probablemente los atacantes se hicieran pasar por la empresa chipriota para obtener este certificado de DigiCert.

Los investigadores de ESET aseguran con mucha confianza que las organizaciones afectadas fueron comprometidas mucho antes de que se distribuyeran estos wiper. Esto se basa en varios hechos:

• Según las marcas de tiempo de compilación del PE de HermeticWiper la más antigua es del 28 de diciembre de 2021
• La fecha de emisión del certificado de firma de código es del 13 de abril de 2021
• La distribución de HermeticWiper a través de GPO en al menos una de las instancias sugiere que los atacantes tenían acceso previo a uno de los servidores de Active Directory de esa víctima.

Un resumen de cómo fueron los hechos puede observarse en la Figura 2.

Figura 2. Cronología de los eventos más importantes

Acceso inicial

HermeticWiper

Actualmente se desconoce el vector de acceso inicial, pero hemos observado artefactos para realizar el movimiento lateral una vez dentro de las organizaciones atacadas. En una entidad, por ejemplo, el wiper se desplegó a través de la política de dominio predeterminada (GPO, por sus siglas en inglés), como se muestra en su ruta en el sistema:

C:\Windows\system32\GroupPolicy\DataStore\0\sysvol\<redacted>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\cc.exe

Esto indica que probablemente los atacantes tomaron el control del servidor de Active Directory.

En otros casos, es posible que HermeticWiper haya sido desplegado utilizando Impacket. Una publicación en el blog de Symantec apunta que el wiper se desplegó utilizando la siguiente línea de comando:

cmd.exe /Q /c move CSIDL_SYSTEM_DRIVE\temp\sys.tmp1 CSIDL_WINDOWS\policydefinitions\postgresql.exe 1> \\127.0.0.1\ADMIN$\__1636727589.6007507 2>&1

La última parte es la misma que el comportamiento predeterminado en wmiexec.py de Impacket. Ver en GitHub.

Finalmente, se utilizó un worm personalizado, al que hemos denominado HermeticWizard, para propagar HermeticWiper a lo largo de las redes comprometidas a través de SMB y WMI.

IsaacWiper

El vector de acceso inicial también se desconoce actualmente. Es probable que los atacantes hayan utilizado herramientas como Impacket para moverse lateralmente. En algunas máquinas también hemos observado una herramienta de acceso remoto llamada RemCom, la cual se distribuyó al mismo tiempo que IsaacWiper.

Análisis técnico

HermeticWiper

HermeticWiper es un ejecutable de Windows con cuatro controladores embebidos en sus recursos. Son controladores legítimos del software EaseUS Partition Master firmado por CHENGDU YIWO Tech Development Co. e implementan operaciones de bajo nivel en el disco. Se observaron los siguientes archivos:

• 0E84AFF18D42FC691CB1104018F44403C325AD21: x64 driver
• 379FF9236F0F72963920232F4A0782911A6BD7F7: x86 driver
• 87BD9404A68035F8D70804A5159A37D1EB0A3568: x64 XP driver
• B33DD3EE12F9E6C150C964EA21147BF6B7F7AFA9: x86 XP driver

Según la versión del sistema operativo se elige uno de esos cuatro controladores y se droppea en C:\Windows\System32\drivers\<4 random letters>.sys. Luego se carga creando un servicio.

Luego, HermeticWiper continúa por deshabilitar el servicio de Volume Shadow Copy (VSS) y se borra del disco a sí mismo sobrescribiendo su propio archivo con bytes aleatorios. Esta medida antiforense probablemente sea con la intención de evitar el análisis del wiper posterior al incidente.

Es interesante notar que la mayoría de las operaciones con archivos se realizan a bajo nivel mediante llamadas a DeviceIoControl.

Las siguientes ubicaciones son sobrescritas con bytes aleatorios generados por la función de la API de Windows CryptGenRandom:

• El master boot record (MBR)
• La tabla maestra de archivos (MFT)
• $Bitmap y $LogFile en todas las unidades
• Los archivos que contienen las claves de registro (NTUSER*)
• C:\Windows\System32\winevt\Logs

Adicionalmente, también borra recursivamente carpetas y archivos en Windows, Program Files, Program Files(x86), PerfLogs, Boot, System Volume Information y carpetas AppData usando una operación FSCTL_MOVE_FILE. Esta técnica parece ser bastante inusual y muy similar a lo que se implementa en el proyecto Windows Wipe en GitHub (ver la función wipe_extent_by_defrag). También borra links simbólicos y archivos grandes en las carpetas My Documents y Desktop sobrescribiéndolos con bytes aleatorios.

Finalmente, la máquina es reiniciada. Sin embargo, no podrá arrancar porque el master boot record, la tabla maestra de archivos y la mayoría de los archivos fueron borrados. Creemos que no es posible recuperar las máquinas afectadas.

HermeticWizard

Buscando otras muestras firmadas por el mismo certificado de firma de código (Hermetica Digital Ltd), encontramos una nueva familia de malware que llamamos HermeticWizard.

Se trata de un gusano que fue desplegado en un sistema en Ucrania a las 14:52:49 del 23 de febrero de 2022 UTC. Es un archivo DLL desarrollado en C++ que exporta las funciones DllInstall, DllRegisterServer, y DllUnregisterServer. Su nombre es Wizard.dll. Contiene tres recursos, los cuales son archivos PE cifrados:

• Una muestra de HermeticWiper (912342F1C840A42F6B74132F8A7C4FFE7D40FB77)
• exec_32.dll, responsable de propagar la amenaza a otras computadoras locales a través de WMI (6B5958BFABFE7C731193ADB96880B225C8505B73)
• romance.dll, responsable de propagar el wiper a otras computadoras locales a través de SMB (AC5B6F16FC5115F0E2327A589246BA00B41439C2)

Los recursos están cifrados mediante un loop XOR inverso. Cada bloque de cuatro bytes es XOReado con el bloque anterior. Finalmente, el primer bloque es XOReado con un valor hardcodeado: 0x4A29B1A3.

HermeticWizard se inicia usando la línea de comando regsvr32.exe /s /i <path>.

Primero, HermeticWizard intenta encontrar otras máquinas en la red local. Recopila direcciones IP locales conocidas utilizando las siguientes funciones de Windows:

• DNSGetCacheDataTable
• GetIpNetTable
• WNetOpenEnumW(RESOURCE_GLOBALNET, RESOURCETYPE_ANY)
• NetServerEnum
• GetTcpTable
• GetAdaptersAddresses

Luego intenta conectarse a esas direcciones IP (y solo si son direcciones IP locales) para ver si aún están accesibles. En caso de que se haya proporcionado el argumento -s cuando se inicia HermeticWizard (regsvr32.exe /s /i:-s <path>), también analiza el rango completo /24. Por lo tanto, si se encuentra 192.168.1.5, por ejemplo, en la caché de DNS, escanea de forma incremental desde 192.168.1.1 hasta 192.168.1.254. Para cada dirección IP intenta abrir una conexión TCP en los siguientes puertos:

• 20: ftp
• 21: ftp
• 22: ssh
• 80: http
• 135: rpc
• 137: netbios
• 139: smb
• 443: https
• 445: smb

Los puertos son escaneados en un orden aleatorio, por lo que no es posible identificar el tráfico de HermeticWizard de esa manera.

Cuando ha encontrado una máquina accesible, droppea el componente WMI spreader (detallado a continuación) en el disco y crea un nuevo proceso con la línea de comando rundll32 <current folder>\<6 random letters>.ocx #1 -s <path to HermeticWizard> - i <target IP>.

Hace lo mismo con el componente SMB spreader (detallado a continuación) que también es droppeado en <current folder>\<6 random letters>.ocx, pero con diferentes letras aleatorias.

Finalmente, dropea HermeticWiper en <current folder>\<6 random letters>.ocx y lo ejecuta.

Componente WMI spreader

El componene WMI spreader, nombrado por sus desarrolladores exec_32.dll, toma dos argumentos:

• -i: la dirección IP de la víctima
• -i: el archivo para copiar y ejecutar en la máquina víctima

En primer lugar, crea una conexión con el recurso compartido remoto ADMIN$ de la víctima mediante WNetAddConnection2W. El archivo proporcionado en el argumento -s luego se copia usando CopyFileW. El archivo remoto tiene un nombre aleatorio generado con CoCreateGUID (por ejemplo, cB9F06408D8D2.dll) y un formato de string c%02X%02X%02X%02X%02X%02X.

En segundo lugar, intenta ejecutar el archivo copiado, HermeticWizard, en la máquina remota utilizando DCOM. Llama a CoCreateInstance con CLSID_WbemLocator como argumento. Luego usa WMI Win32_Process para crear un nuevo proceso en la máquina remota, con la línea de comando  C:\windows\system32\cmd.exe /c start C:\windows\system32\\regsvr32.exe /s /i C:\windows\<filename>.dll.

Nótese que el argumento -s no se pasa a HermeticWizard, lo que significa que no volverá a escanear la red local desde esta máquina recientemente comprometida.

Si la técnica de WMI falla, intenta crear un servicio utilizando OpenRemoteServiceManager con el mismo comando que antes.

Si tiene éxito en la ejecución de la DLL remota de alguna manera, queda a la espera hasta poder eliminar el archivo remoto.

Componente SMB spreader

El spreader SMB, llamado por sus desarrolladores romance.dll, toma los mismos dos argumentos que WMI spreader. Es probable que su nombre interno sea una referencia al exploit EternalRomance, incluso si no utiliza ningún exploit.

Primero intenta conectarse a las siguientes canalizaciones en el recurso compartido SMB remoto (en el puerto 445):

• samr
• browser
• netlogon
• lsarpc
• ntsvcs
• svcctl

Estas son las canalizaciones que se sabe que se utilizan en el movimiento lateral. El componente spreader tiene una lista de credenciales harcodeadas que son utilizadas para intentar autenticarse a través de NTLMSSP en los recursos compartidos de SMB:

-- usernames --
guest
test
admin
user
root
administrator
manager
operator

-- passwords --
123
Qaz123
Qwerty123

Esta lista de credenciales es sorprendentemente corta y es poco probable que funcione, incluso en las redes menos protegidas.

Si la conexión es exitosa, intenta droppear el archivo al que hace referencia el argumento -s en el recurso compartido ADMIN$ de la víctima. En cuanto al componente WMI spreader, el nombre de archivo remoto se genera mediante una llamada a CoCreateInstance.

Luego ejecuta, a través de SMB, la línea de comando cmd /c start regsvr32 /s /i ..\\<filename>  & start cmd /c \"ping localhost -n 7 & wevtutil cl System\".

HermeticRansom

Los investigadores de ESET también detectaron el uso de HermeticRansom, un ransomware escrito en Go, en ataques a Ucrania al mismo tiempo que corría la campaña de HermeticWiper. HermeticRansom fue reportado por primera vez durante las primeras horas del 24 de febrero de 2022 UTC, a través de un tweet de AVAST. Nuestra telemetría muestra una distribución de HermeticRansom mucho más pequeña en comparación con HermeticWiper. Este ransomware se distribuyó al mismo tiempo que HermeticWiper, posiblemente para ocultar las acciones del wiper. En una de las máquinas se observó lo siguiente:

• 2022-02-23 17:49:55 UTC: se desplegó HermeticWiper en C:\Windows\Temp\cc.exe
• 2022-02-23 18:06:57 UTC: Se desplegó HermeticRansom en C:\Windows\Temp\cc2.exe mediante el servicio netsvcs
• 2022-02-23 18:26:07 UTC: Se desplegó el segundo HermeticWiper en C:\Users\com.exe

En una ocasión, observamos la distribución de HermeticRansom a través de GPO, al igual que con HermeticWiper:

C:\WINDOWS\system32\GroupPolicy\DataStore\0\sysvol\<redacted>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\Machine\cpin.exe

Los atacantes dejaron algunas strings en el binario; las mismas hacen referencia al presidente estadounidense Biden y a la Casa Blanca:

• _/C_/projects/403forBiden/wHiteHousE.baggageGatherings
• _/C_/projects/403forBiden/wHiteHousE.lookUp
• _/C_/projects/403forBiden/wHiteHousE.primaryElectionProcess
• _/C_/projects/403forBiden/wHiteHousE.GoodOffice1

Una vez que los archivos están cifrados, se despliega a la víctima el mensaje que se observa en la Figura 3.

Figura 3. Nota de rescate de HermeticRansom

IsaacWiper

IsaacWiper se encuentra en un archivo DLL o EXE de Windows sin firma Authenticode; apareció en nuestra telemetría el 24 de febrero de 2022. Como se mencionó anteriormente, la marca de tiempo de compilación del PE más antigua que encontramos es del 19 de octubre de 2021, lo que significa que, si no se manipuló la marca de tiempo de compilación del PE, es posible que IsaacWiper haya sido utilizado meses atrás en anteriores operaciones.

En el caso de las muestras de DLL, el nombre en el directorio de exportación del PE es Cleaner.dll y tiene el exportador _Start@4.

Hemos observado a IsaacWiper en %programdata% y en C:\Windows\System32 utilizando los siguientes nombres de archivo:

• clean.exe
• cl.exe
• cl64.dll
• cld.dll
• cll.dll

No tiene similitud de código con HermeticWiper y es mucho menos sofisticado. Dada la cronología de los acontecimientos, es posible que ambos estén relacionados, pero aún no hemos encontrado ninguna conexión sólida que nos permita afirmarlo.

IsaacWiper comienza enumerando las unidades físicas y llama a DeviceIoControl con el IOCTL IOCTL_STORAGE_GET_DEVICE_NUMBER para obtener sus números de dispositivo. Luego borra los primeros 0x10000 bytes de cada disco utilizando el generador pseudoaleatorio ISAAC. El generador es inicializado utilizando el valor GetTickCount.

Luego enumera las unidades lógicas y borra recursivamente todos los archivos de cada disco con bytes aleatorios también generados por ISAAC PRNG. Es interesante notar que borra recursivamente los archivos en un solo hilo, lo que significa que tardaría mucho tiempo en borrar un disco grande.

El 25 de febrero de 2022, los atacantes utilizaron una nueva versión de IsaacWiper con depuración de logs. Esto puede indicar que los atacantes no pudieron llevar a cabo el borrado en algunas de las máquinas apuntadas previamente y agregaron mensajes de log para comprender lo que estaba sucediendo. Los logs están almacenados en C:\ProgramData\log.txt y algunos de los mensajes de log son:

• getting drives...
• start erasing physical drives...
• –– start erasing logical drive
• start erasing system physical drive...
• system physical drive –– FAILED
• start erasing system logical drive

Conclusión

Este informe detalla lo que fue un ciberataque con fines destructivos que afectó a organizaciones ucranianas el 23 de febrero de 2022 y un segundo ataque que afectó a una organización ucraniana diferente y que ocurrió del 24 al 26 de febrero de 2022. En este momento, no tenemos indicios de que otros países hayan sido atacados.

Sin embargo, debido a la crisis actual en Ucrania, todavía existe el riesgo de que los mismos actores de amenazas lancen nuevas campañas contra países que respaldan al gobierno ucraniano o que sancionan a entidades rusas.

IoCs

Técnicas de MITRE ATT&CK 

Esta tabla fue creada utilizando la versión 10 del framework de MITRE ATT&CK