Nova versão do malware Industroyer é usada em ataque a fornecedor de energia na Ucrânia

Está publicação está em construção e será atualizada à medida que haja novas informações disponíveis.

Resumo executive

Este artigo apresenta a análise de um ataque cibernético direcionado a um fornecedor de energia ucraniano.

Industroyer2: Industroyer reloaded

Pesquisadores da ESET responderam a um incidente de segurança que afetou a um fornecedor de energia na Ucrânia. Trabalhamos de perto com a CERT-UA (Centro de resposta a incidentes da Ucrânia) a fim de remediar e proteger a essa rede de infraestrutura crítica.

A colaboração resultou na descoberta de uma nova variante do malware Industroyer, que juntamente com a CERT-UA batizamos de Industroyer2 – clique aqui e veja a publicação da CERT-UA. O Industroyer é um malware que foi usado em 2016 pelo grupo APT Sandworm para cortar o fornecimento de energia elétrica na Ucrânia.

Neste caso, os atacantes por trás do Sandworm tentaram implantar o malware Industroyer2 contra subestações elétricas de alta tensão na Ucrânia.

Além do Industroyer2, o grupo Sandworm usou várias famílias de malware destrutivas, incluindo a CaddyWiper, ORCSHRED, SOLOSHRED e AWFULSHRED. Descobrimos pela primeira vez o CaddyWiper no último dia 14 de março quando ele foi usado contra um banco ucraniano. Uma variante do CaddyWiper foi usada novamente em 08 de abril deste ano, às 14h58, contra o fornecedor de energia ucraniano mencionado anteriormente.

Até o momento, não sabemos como os atacantes conseguiram obter o comprometimento inicial nem como eles passaram da rede de TI para a rede do Sistema de Controle Industrial (ICS). A Figura 1 mostra uma visão geral dos diferentes malwares usados neste ataque.

Figura 1. Visão geral dos componentes.

A figura 2 resume a cadeia de acontecimentos.

Figura 2. Linha do tempo dos acontecimentos.

m 2017, pesquisadores da ESET revelaram que um malware que chamamos de Industroyer foi responsável pelo apagão que afetou a capital da Ucrânia, Kiev, em dezembro de 2016.

Como explicamos em nosso white paper sobre o Industroyer, no qual detalhamos como essa ameaça funciona em sistemas de controle industrial. Este malware é capaz de interagir com sistemas de controle industrial tipicamente encontrados em sistemas de energia elétrica. Isto inclui as seguintes tecnologias: IEC-101, IEC-104, IEC 61850 e OPC DA.

Naquela época, dissemos que "seria muito improvável que alguém pudesse escrever e testar um malware como esse sem ter acesso ao equipamento especializado usado em um ambiente industrial específico". Isto foi confirmado em 2020 pelo governo dos Estados Unidos quando seis oficiais da Unidade Militar 74455 da Direção Principal de Inteligência (GRU) da Rússia foram indiciados por seu papel em diversos ciberataques, incluindo o Industroyer e o NotPetya. Para mais informações, veja a acusação no site justiça.gov e nosso resumo histórica das operações do Sandworm.

O malware recentemente descoberto é uma nova variante do Industroyer, por isso a ameaça foi batizada de Industroyer2.

Industroyer2

O Industroyer2 foi implantado como um único executável do Windows chamado 108_100.exe e foi executado através de uma tarefa agendada em 08 de abril deste ano, às 16h10 - UTC. A ameaça foi compilada em 03 de março deste ano, de acordo com o timestamp do PE, sugerindo que os atacantes tinham planejado seu ataque durante mais de duas semanas.

Figura 3. Timestamp e informações do compilador.

O Industroyer2 implementa apenas o protocolo IEC-104 (também conhecido como IEC 60870-5-104) para se comunicar com equipamentos industriais. Isto inclui relés de proteção usados em subestações elétricas. Esta é uma pequena mudança em relação à variante Industroyer de 2016, que é uma plataforma totalmente modular com payloads para múltiplos protocolos de sistemas de controle industrial.

A Industroyer2 compartilha várias semelhanças de código com o payload 104.dll do Industroyer. Avaliamos que a nova variante foi construída usando o mesmo código fonte.

O Industroyer2 é altamente configurável. Ele contém uma configuração detalhada e codificada em seu corpo, que impulsa as ações do malware. Isto é diferente do Industroyer, que armazena a configuração em um arquivo .INI separado. Portanto, os atacantes precisam recompilar o Industroyer2 para cada nova vítima ou ambiente. Entretanto, dado que a família de malware Industroyer* só foi implantada duas vezes, com um intervalo de cinco anos entre cada versão, isto provavelmente não seja uma limitação para os operadores do Sandworm.

O novo formato de configuração é armazenado como uma string que é fornecida para a rotina de comunicação IEC-104 do malware. O Industroyer2 é capaz de se comunicar com vários dispositivos ao mesmo tempo. Especificamente, a amostra analisada contém oito diferentes endereços IP de dispositivos - veja a Figura 4.

Figura 4. Configuração hardcodeada que encontramos na amostra do Industroyer2.

A configuração contém valores que são usados durante a comunicação via protocolo IEC-104, tais como endereço ASDU (Application Service Data Unit), endereços de Objetos de Informação (IOA), timeouts, etc.

Antes de se conectar aos dispositivos alvo, o malware põe fim a um processo legítimo que é usado em operações diárias padrão. Além disso, a ameaça renomeia este aplicativo adicionando .MZ ao nome do arquivo – isso ocorre a fim de impedir o reinício automático deste processo legítimo.

A análise ainda está em andamento para determinar quais são as ações exatas tomadas para cada dispositivo. Acreditamos que este componente é capaz de controlar sistemas de controle industrial específicos para provocar um corte de energia elétrica.

O Industroyer2 pode produzir um arquivo de registro ou enviar seu progresso para a janela do console. Entretanto, ao invés de mensagens de texto significativas como na versão anterior, o malware escreve vários códigos de erro - veja a Figura 5. Acreditamos ser uma tentativa de ofuscação por parte dos desenvolvedores do Sandworm para dificultar a análise.

Figura 5. Output produzido pela Industroyer2 (endereços IP redactted by ESET).

CaddyWiper

Em coordenação com a implantação do Industroyer2 na rede de um Sistema de Controle Industrial (ICS), os atacantes implantaram uma nova versão do malware CaddyWiper. Acreditamos que o objetivo era retardar o processo de recuperação e impedir que os operadores da empresa de energia recuperassem o controle dos consoles do ICS. Ele também foi implantado na máquina onde o Industroyer2 foi executado, provavelmente para excluir rastros da ameaça.

A primeira versão do CaddyWiper foi descoberta por pesquisadores da ESET na Ucrânia em 14 de março deste ano, quando foi implantado na rede de um banco. Ele foi implantado através do Group Policy Object (GPO), indicando que os atacantes tinham controle prévio da rede da vítima. O wiper apaga os dados do usuário e as informações armazenadas nas partições das unidades conectadas, tornando o sistema inoperante e irrecuperável.

Nova cadeia para o carregamento do CaddyWiper

Na rede do fornecedor de energia, os atacantes implantaram uma nova versão do CaddyWiper que usa um novo loader, denominado ARGUEPATCH pela CERT-UA. O ARGUEPATCH é uma versão corrigida de um componente legítimo do software Hex-Rays da IDA Pro, especificamente o debugger do servidor remoto do IDA win32_remote.exe. O IDA Pro não se destina a ser usado em um ambiente ICS, pois seu objetivo principal é a engenharia reversa de software, incluindo a análise de malware. Não sabemos por que os atacantes optaram por trojanizar este software - ele pode ser um troll para os defensores.

O ARGUEPATCH foi executado por uma tarefa programada que deveria ser lançada uma vez em 08-04-2022, às 14:58 UTC, em uma máquina e, às 16:20 UTC, no computador onde o Industroyer2 foi implantada.

O binário corrigido carrega um shellcode criptografado de um arquivo e o descriptografa com uma chave, ambos são fornecidos na linha de comando. Uma chave XOR de byte único é derivada da chave de entrada e usada para decifrar o código shell.

O shellcode descriptografado é uma versão ligeiramente modificada do CaddyWiper. Uma comparação de suas principais rotinas pode ser vista nas Figuras 6 e 7. Note que eles não excluem o controlador de domínio, e apagam C:\Users e discos de D:\ a[:\. A rotina de exclusão também é quase idêntica: preenche todos os arquivos com 0.

Figura 6. Rotina principal da primeira amostra do CaddyWiper.

Figura 7. Rotina principal da amostra do CaddyWiper implantada nos sistemas do fornecedor de energia.

Finalmente, o CaddyWiper chama o DeviceIoControl com IOCTL_DISK_SET_DRIVE_LAYOUT_EX e um InputBuffer zerado para todos os discos de \\PHYSICALDRIVE9 a \\PHYSICALDRIVE0. Isto apaga informações ampliadas das partições da unidade: o registro de inicialização principal (MBR) ou a Tabela de partições do GUID (GPT, pela sigla em inglês). Isto faz com que a máquina não pode ser inicializada.

Enumeração do Active Directory

Ao lado do CaddyWiper, um script PowerShell foi encontrado tanto na rede do fornecedor de energia quanto no banco que foi comprometido anteriormente com este malware.

Este script enumera os objetos de políticas de grupo (GPO) usando a Interface de serviço do Active Directory (ADSI). O script, mostrado na Figura 8, é quase idêntico a um fragmento fornecido em um post do blog Medium.

Acreditamos que os atacantes implantaram o CaddyWiper via GPO e usaram o script para verificar a existência deste GPO.

Figura 8. Script do PowerShell para enumerar o GPO (embelezado).

Malwares destrutivos direcionados ao Linux e Solaris (ORCSHRED, SOLOSHRED, AWFULSHRED)

Malwares destrutivos adicionais para sistemas rodando o Linux e o Solaris também foram encontrados na rede da empresa de energia. Há dois componentes principais para este ataque: um worm e um wiper. Este último foi encontrado em duas variantes, uma para cada um dos sistemas operacionais alvo. Todo o malware foi implementado no Bash.

O worm

O primeiro componente lançado pelo atacante foi um worm, tendo seu arquivo chamado sc.sh. Este script do Bash começa adicionando uma tarefa agendada (cron job) para lançar o componente que excluir os dados às 14h58 UTC (assumindo que o sistema esteja no fuso horário local, UTC+3), a menos que tenha sido lançado com o argumento "owner". Esta é provavelmente uma maneira de evitar  a autodestruição do sistema inicial usado para lançar o worm.

Figura 9. Configuração da tarefa agendada para iniciar o wiper às 17h58. O wiper correto é escolhido de acordo com o sistema operacional instalado.

O script então itera através das redes acessíveis pelo sistema, olhando o resultado da rota ip ou ifconfig -a. Ele sempre assume que uma rede de classe C (/24) é alcançável para cada endereço IP coletado. Ele tentará conectar-se a todos os hosts dessas redes usando de SSH às portas TCP 22, 2468, 24687 e 522. Uma vez encontrado um servidor SSH alcançável, ele tenta credenciais a partir de uma lista fornecida com o script malicioso. Acreditamos que o atacante tinha credenciais antes do ataque para permitir a propagação do wiper.

Se o sistema ainda não tiver sido comprometido, o malware é copiado para o novo alvo e o worm é lançado. O worm não é iniciado com o argumento owner, portanto, o wiper está programado para começar às 14h58 - UTC e destruir todos os dados. Se esses sistemas foram configurados no fuso horário local, a destruição deve ter começado ao mesmo tempo que o sistema comprometido pelo CaddyWiper.

O wiper para Linux

A variante para Linux do wiper tem variáveis ligeiramente ofuscadas e os nomes das funções foram substituídos por palavras sem sentido de 8 letras. A maioria dos valores literais também foram substituídos por variáveis no início do arquivo.

Figura 10. Exceto pelo script ofuscado (espaço em branco otimizado).

Figura 11. Desobstrução da anterior que foi obtida através da renomeação de funções e variáveis e do uso de literais.

Em última análise, o wiper para Linux destrói todo o conteúdo dos discos conectados ao sistema, usando shred se disponíveis ou, caso contrário, simplesmente dd (com if=/dev/random). Se vários discos forem conectados, a exclusão de dados é feita em paralelo para acelerar o processo.

Dependendo do tamanho, pode levar horas para que o disco completo seja totalmente apagado. Para tornar o sistema inoperante mais rápido, a ameaça tenta parar e desativar os serviços HTTP e SSH. Ambos os serviços são desativados usando o systemctl disabled. Para garantir que o serviço não seja reativado, o arquivo da unidade systemd responsável por carregar o serviço é excluído do disco.

Os arquivos em /boot, /home e /var/log também são excluídos antes de destruir completamente as unidades. Isto torna o sistema inoperante mais rapidamente, elimina os dados do usuário e talvez remova os logs incriminatórios.

A última ação do script malicioso é iniciar uma reinicialização forçada usando o SysRq. Uma vez que todas as unidades são preenchidas aleatoriamente, nenhum sistema operacional será reinicializado.

O wiper para Solaris

Ao contrário do wiper para o Linux, a variante para o Solaris não é ofuscada.

Como a variante para o Linux, o script malicioso faz iterações sobre todos os serviços para pará-los e desativá-los se eles contiverem a palavra-chave ssh, http, apache e, adicionalmente, ora_ ou oracle. Esses serviços são muito provavelmente usados por aplicações utilizadas para controlar sistemas de controle industrial. Excluí-los impediria os operadores da empresa de energia de retomar o controle das subestações e reverter as ações do Industroyer2.

Usada tanto pelo systemctl quanto pelo svcadm, dependendo do que estiver disponível. Este último é o mais provável, uma vez que o Solaris não está rodando o sistemad.

A destruição de arquivos começa com a exclusão de bancos de dados. Ele remove, usando shred e depois rm, todos os arquivos e diretórios contidos nas variáveis de ambiente que começam com ORA. O O Oracle Database usa as seguintes variáveis para definir a localização dos arquivos e software do banco de dados: ORACLE_BASE, ORACLE_HOME e ORACLE_PATH. Note que o fragmento garante que a recuperação de dados (sem um backup) não seja possível.

Como a variante para Linux, os arquivos em /boot, /home e /var/log são excluídos com prioridade.

Em seguida, o script itera sobre discos conectados ao sistema, encontrados em /dev/dsk/. Ele ignora os segmentos (partições) e funciona apenas em discos completos. Para cada um deles, o script malicioso sobregrava o conteúdo completo utilizando fragmentos. Para minimizar o tempo necessário para realizar a limpeza, todos os discos são apagados em paralelo.

Por último, o script se autodestrói.

Conclusão

A Ucrânia está mais uma vez no centro dos ataques cibernéticos que visam sua infraestrutura crítica. Esta nova campanha do Industroyer segue múltiplas ondas de wipers que estão direcionados a vários setores na Ucrânia. Os pesquisadores da ESET continuarão monitorando o cenário de ameaças a fim de proteger as organizações contra esses tipos de ataques destrutivos.

Obrigado a @_CERT_UA que trabalhou conosco neste caso e forneceu amostras. Leia o comunicado completo sobre esta campanha.

Indicadores de Comprometimento