IsaacWiper e HermeticWizard: um novo wiper e worm usados em ciberataques na Ucrânia

Quando os ataques entra a Rússia e Ucrânia começaram, pesquisadores da ESET descobriram várias famílias de malware direcionadas a organizações ucranianas.

• Em 23 de fevereiro de 2022, uma campanha destrutiva usou o HermeticWiper e teve como alvo várias organizações ucranianas.
• Este ciberataque ocorreu algumas horas após o início da invasão na Ucrânia pelas forças militares da Federação Russa.
• Os vetores de acesso inicial usados eram diferentes de uma organização para outra. Confirmamos um caso em que o wiper foi droppeado via GPO e que escondia um worm usado para propagar o wiper em outra rede comprometida.
• Elementos no malware sugerem que os ataques foram planejados durante vários meses.
• Em 24 de fevereiro de 2022, houve um segundo ataque com intenção destrutiva contra uma rede do governo ucraniano, usando um wiper que batizamos como IsaacWiper.
• O ESET Research ainda não foi capaz de atribuir estes ataques a um ator de ameaças.

Ciberataques destrutivos na Ucrânia

Assim como foi revelado pela equipe ESET Research no Twitter e também em um artigo anteriormente publicado no WeLiveSecurity, descobrimos um ataque com intenções destrutivas contra computadores na Ucrânia que começou em 23 de fevereiro de 2022 por volta das 14:52 UTC. O incidente ocorreu após os ataques de Negação de Serviço Distribuído (DDoS) contra alguns dos principais sites ucranianos e algumas horas após a invasão militar russa.

Estes ataques destrutivos usaram pelo menos três componentes:

• HermeticWiper: faz com que um sistema se torne inoperante ao corromper seus dados.
• HermeticWizard: distribui o HermeticWiper através de uma rede local via WMI e SMB.
• HermeticRansom: ransomware escrito em Go.

O HermeticWiper foi detectado em centenas de sistemas e em pelo menos cinco organizações ucranianas.

Em 24 de fevereiro de 2022, detectamos outro malware do tipo wiper em uma rede do governo ucraniano. Batizamos a ameaça de IsaacWiper e estamos atualmente avaliando suas ligações, se houver, com o HermeticWiper. É importante notar que o IsaacWiper foi detectado em uma organização que não tinha sido afetada pelo HermeticWiper.

Atribuição

Até o momento, não identificamos nenhuma conexão tangível com um ator de ameaça. O HermeticWiper, o HermeticWizard e o HermeticRansom não compartilham nenhuma semelhança significativa de código com outras amostras na coleção de malware da ESET. O IsaacWiper também não foi atribuído.

Cronologia

O HermeticWiper e o HermeticWizard foram assinados através de um certificado de assinatura de código (mostrado na Figura 1) atribuído à Hermetica Digital Ltd, emitido em 13 de abril de 2021. Pedimos à autoridade de certificação (DigiCert) que revogasse o certificado, o que acabou ocorrendo em 24 de fevereiro de 2022.

Figura 1: Certificado de assinatura de código atribuído à Hermetic Digital Ltd.

De acordo com um relatório da  agência de notícias britânica Reuters, aparentemente, este certificado não foi roubado da Hermetica Digital, mas é possível que os cibercriminosos tenham se passado pela empresa chipriota para obter este certificado da DigiCert.

Os pesquisadores da ESET afirmam que as organizações afetadas foram comprometidas muito antes da distribuição desses wiper. Essa afirmação se baseia em vários fatos:

• De acordo com a linha do tempo de compilação do PE do HermeticWiper, o mais antigo é de 28 de dezembro de 2021.
• A data de emissão do certificado de assinatura do código é 13 de abril de 2021.
• A distribuição do HermeticWiper via GPO em pelo menos uma das instâncias sugere que os cibercriminosos tiveram acesso prévio a um dos servidores do Active Directory da vítima.

Confira um resumo dos eventos na Figura 2:

Figura 2: Cronologia dos principais eventos.

Acesso inicial

HermeticWiper

O vetor de acesso inicial é atualmente desconhecido, mas observamos artefatos para realizar movimentos laterais uma vez dentro das organizações atacadas. Em uma das instituições, por exemplo, o wiper foi implementado através da política de domínio padrão (GPO, pela sigla em inglês), como mostra o caminho no sistema:

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

Isso indica que os atacantes provavelmente assumiram o controle do servidor do Active Directory.

Em outros casos, o HermeticWiper pode ter sido implantado através do Impacket. Um post do blog da Symantec observa que o wiper foi implantado usando a seguinte linha 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

A última parte é a mesma que o comportamento padrão no wmiexec.py do Impacket. Veja no GitHub.

Para finalizar, um worm personalizado, que chamamos de HermeticWizard, foi usado para propagar o HermeticWiper através das redes comprometidas via SMB e WMI.

IsaacWiper

O vetor de acesso inicial também é desconhecido até o momento. É provável que os atacantes tenham usado ferramentas como o Impacket para se mover lateralmente. Em algumas máquinas também observamos uma ferramenta de acesso remoto chamada RemCom, que foi distribuída ao mesmo tempo que o IsaacWiper.

Análisis técnico

HermeticWiper

O HermeticWiper é um executável para Windows com quatro controladores embutidos em seus recursos. Eles são controladores legítimos do software EaseUS Partition Master assinado pela CHENGDU YIWO Tech Development Co. e implementam operações de baixo nível no disco. Os seguintes arquivos foram observados:

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

Dependendo da versão do sistema operacional, um destes quatro controladores é escolhido e droppeado no :\Windows\System32\drivers\<4 random letters>.sys. Ele é carregada criando um serviço.

O HermeticWiper então passa a desativar o serviço de Volume Shadow Copy (VSS) e se auto-apaga do disco substituindo seu próprio arquivo por bytes aleatórios. Esta medida anti-forense provavelmente seja para evitar a análise do wiper após o incidente.

É interessante notar que a maioria das operações com arquivos são realizadas em um nível baixo através de chamadas ao DeviceIoControl.

Os seguintes locais são sobrescritos com bytes aleatórios gerados pela função da API do Windows CryptGenRandom:

• master boot record (MBR)
• A tabela de arquivos mestre  (MFT)
• $Bitmap e $LogFile em todas as unidades
• Os arquivos que contém as chaves de registro (NTUSER*)
• C:\Windows\System32\winevt\Logs

Além disso, a ameaça também apaga recursivamente pastas e arquivos no Windows, Program Files, Program Files (x86), PerfLogs, Boot, System Volume Information e pastas AppData usando uma operação FSCTL_MOVE_FILE. Esta técnica parece ser bastante incomum e muito semelhante ao que é implementado no projeto Windows Wipe no GitHub (veja a função wipe_extent_by_defrag). A ameaça também apaga links simbólicos e arquivos grandes nas pastas My Documents e Desktop, substituindo-os por bytes aleatórios.

Para finalizar, a máquina é reinicializada. No entanto, o computador poderá ser inicializado porque o master boot record, a tabela de arquivos mestre  e a maioria dos arquivos foram apagados. Acreditamos que não seja possível recuperar as máquinas afetadas.

HermeticWizard

Ao procurar por outras amostras assinadas pelo mesmo certificado de assinatura de código (Hermetica Digital Ltd), encontramos uma nova família de malware que chamamos de HermeticWizard.

Trata-se de um worm que foi implantado em um sistema na Ucrânia às 14:52:49 do dia 23 de fevereiro de 2022 UTC. É um arquivo DLL desenvolvido em C++ que exporta as funções DllInstall, DllRegisterServer, e DllUnregisterServer. Seu nome é Wizard.dll. Ele contém três recursos, que são arquivos PE criptografados:

• Uma amostra do HermeticWiper (912342F1C840A42F6B74132F8A7C4FFE7D40FB77).
• exec_32.dll, responsável pela propagação da ameaça para outros computadores locais via WMI (6B5958BFABFE7C731193ADB96880B225C8505B73).
• dll, responsável pela propagação do wiper para outros computadores locais via SMB (AC5B6F16FC5115F0E2327A589246BA00B41439C2).

Os recursos são criptografados usando um loop XOR invertido. Cada bloco de quatro bytes é XORedado com o bloco anterior. Finalmente, o primeiro bloco é XORedado com um valor hardcodeado: 0x4A29B1A3.

O HermeticWizard se inicia através da linha de comando regsvr32.exe /s /i <path>.

Primeiro, o HermeticWizard tenta encontrar outras máquinas na rede local. Ele coleta endereços IP locais conhecidos usando as seguintes funções do Windows:

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

Em seguida, tenta conectar-se a esses endereços IP (e somente se forem endereços IP locais) para ver se eles ainda estão acessíveis. Caso o argumento -s tenha sido fornecido ao iniciar o HermeticWizard (regsvr32.exe /s /i:-s <path>), ele também escaneia toda a gama /24. Portanto, se 192.168.1.5, por exemplo, for encontrado no cache DNS, ele escaneia incrementalmente de 192.168.1.1 a 192.168.1.254. Para cada endereço IP, ele tenta abrir uma conexão TCP nas seguintes portas:

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

Os portos são escaneados em uma ordem aleatória, portanto não é possível identificar o tráfego do HermeticWizard dessa forma.

Ao encontrar uma máquina acessível, a ameaça droppea o componente WMI spreader (detalhado abaixo) no disco e cria um novo processo com a linha de comando rundll32 <current folder>\<6 random letters>.ocx #1 -s <path to HermeticWizard> – i <target IP>.

A ameaça faz o mesmo com o componente SMB spreader (detalhado abaixo), que também é droppeado no <current folder>\<6 random letters>.ocx, mas com letras aleatórias diferentes.

Para finalizar, ele dropea o HermeticWiper no <current folder>\<6 random letters>.ocx  e o executa.

Componente WMI spreader

O componente WMI spreader, nomeado como exec_32.dll por seus desenvolvedores, tem em conta dois argumentos:

• -i: o endereço IP da vítima.
• -i: o arquivo para copiar e rodar na máquina da vítima.a

Primeiro, ele cria uma conexão com o recurso compartilhado remoto ADMIN$ da vítima através do WNetAddConnection2W. O arquivo fornecido no argumento -s é então copiado usando o CopyFileW. O arquivo remoto tem um nome aleatório gerado com CoCreateGUID (por exemplo, cB9F06408D8D2.dll) e um formato de string c%02X%02X%02X%02X%02X%02X.

Em segundo lugar, ele tenta executar o arquivo copiado, o HermeticWizard, na máquina remota usando DCOM. Chama para CoCreateInstance com o CLSID_WbemLocator como argumento. Em seguida, ele usa o WMI Win32_Process para criar um novo processo na máquina remota, com a linha de comando C:\windows\system32\cmd.exe /c start C:\windows\system32\\regsvr32.exe /s /i C:\windows\<filename>.dll.

Note que o argumento -s não é passado para o HermeticWizard, o que significa que ele não irá varrer novamente a rede local a partir desta máquina recentemente comprometida.

Se a técnica WMI falhar, ele tenta criar um serviço usando o OpenRemoteServiceManager com o mesmo comando que antes.

Caso ele consiga executar a DLL remota de alguma forma, ela é colocada em espera até que o arquivo remoto possa ser apagado.

Componente SMB spreader

O spreader SMB, chamado de romance.dll por seus desenvolvedores, aceita os mesmos dois argumentos que o WMI spreader. Seu nome interno provavelmente seja uma referência ao exploit EternalRomance, mesmo quando não utiliza nenhuma exploit.

Primeiro ele tenta conectar-se às seguintes canalizações no recurso compartilhado SMB remoto (na porta 445):

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

Estas são as canalizações conhecidas por serem utilizadas em movimento lateral. O componente spreader tem uma lista de credenciais harcodeadas que são usadas para tentar autenticar via NTLMSSP nos recursos compartilhados do SMB:

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

-- passwords --
123
Qaz123
Qwerty123

Esta lista de credenciais é surpreendentemente curta e é pouco provável que funcione, mesmo nas redes menos protegidas.

Se a conexão for bem sucedida, ele tenta droppear o arquivo referenciado pelo argumento -s no recurso compartilhado ADMIN$ da vítima. Quanto ao componente WMI spreader, o nome do arquivo remoto é gerado por uma chamada ao CoCreateInstance.

Em seguida, ele executa, via SMB, a linha de comando cmd /c start regsvr32 /s /i ..\\<filename>  & start cmd /c \”ping localhost -n 7 & wevtutil cl System\”.

HermeticRansom

Os pesquisadores da ESET também detectaram o uso do HermeticRansom, um resgate escrito em Go, em ataques a Ucrânia, ao mesmo tempo em que ocorria a campanha do HermeticWiper. O HermeticRansom foi relatado pela primeira vez durante as primeiras horas de 24 de fevereiro de 2022 UTC, através de um tweet da AVAST. Nossa telemetria mostra uma distribuição muito menor do HermeticRansom em comparação com o HermeticWiper. Este ransomware foi distribuído ao mesmo tempo que o HermeticWiper, possivelmente para esconder as ações do wiper. Foi possível observar em uma das máquinas:

• 2022-02-23 17:49:55 UTC: implantou o HermeticWiper no C:\Windows\Temp\cc.exe
• 2022-02-23 18:06:57 UTC: implantou o HermeticRansom no C:\Windows\Temp\cc2.exe através do serviço netsvcs
• 2022-02-23 18:26:07 UTC: implantou o segundo HermeticWiper no C:\Users\com.exe

Em outro momento, observamos a distribuição do HermeticRansom via GPO, assim como com o HermeticWiper:

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

Os atacantes deixaram algumas strings no binário; elas se referem ao presidente dos Estados Unidos Biden e à Casa Branca:

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

Uma vez criptografados os arquivos, a mensagem mostrada na Figura 3 é exibida para a vítima.

Figura 3. Mensagem de resgate do HermeticRansom.

IsaacWiper

O IsaacWiper é encontrado em um arquivo DLL ou EXE do Windows sem assinatura Authenticode - ele apareceu em nossa telemetria em 24 de fevereiro de 2022. Como mencionado anteriormente, a linha do tempo de compilação do PE mais antiga que encontramos é a do dia 19 de outubro de 2021, o que significa que, se a linha do tempo de compilação do PE não foi manipulado, é possível que o IsaacWiper tenha sido usado meses atrás em operações anteriores.

No caso das amostras do DLL, o nome no diretório de exportação do PE é Cleaner.dll e tem o exportador _Start@4.

Observamos o IsaacWiper no %programdata% e no C:\Windows\System32 usando os seguintes nomes de arquivo:

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

Não tem semelhança de código com o HermeticWiper e é muito menos sofisticado. Dada a cronologia dos eventos, é possível que os dois estejam relacionados, mas ainda não encontramos nenhuma conexão sólida que nos permitisse afirmar essa suposição.

O IsaacWiper começa enumerando as unidades físicas e chama o DeviceIoControl com o IOCTL IOCTL_STORAGE_GET_DEVICE_NUMBER para obter seus números de dispositivos. Em seguida, apaga os primeiros 0x10000 bytes de cada disco usando o gerador pseudo-aleatório Mersenne Twister. O gerador é inicializado utilizando o valor GetTickCount.

Em seguida, enumera as unidades lógicos e apaga recursivamente todos os arquivos em cada disco com bytes aleatórios também gerados pelo Mersenne Twister PRNG. É interessante notar que ele apaga recursivamente os arquivos em um único fio, o que significa que demoraria muito tempo para apagar um disco grande.

Em 25 de fevereiro de 2022, os atacantes utilizaram uma nova versão do IsaacWiper com depuração de log. Isso pode indicar que os atacantes foram incapazes de executar a limpeza de dados em algumas das máquinas previamente visadas e adicionaram mensagens de registro para entender o que estava acontecendo. Os logs foram armazenados no C:\ProgramData\log.txt e algumas das mensagens dos logs são:

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

Conclusão

Este relatório detalha um ciberataque destrutivo que afetou organizações ucranianas em 23 de fevereiro de 2022 e um segundo ataque que afetou uma organização também ucraniana diferente que ocorreu de 24 a 26 de fevereiro de 2022. Neste momento, não temos nenhuma indicação de que outros países tenham sido atacados.

Entretanto, devido à crise atual na Ucrânia, ainda há o risco de que os mesmos cibercriminosos lancem novas campanhas contra países que apoiam o governo ucraniano ou sancionam instituições russas.

IoCs

Técnicas de MITRE ATT&CK 

Esta tabela foi criada através da versão 10 do framework do MITRE ATT&CK.