DESMANTELANDO O BLACKENERGY, PARTE 3 – TODOS A BORDO!

Abordagem  – the act of embarque um inimigo navio as parte of an ataque.

In today’s post, I will describe a part of investigation of one cyber security incident that has eventually evolved into a global investigation connected with an attack based on BlackEnergy that has hit a number of industries in Ukraine. As we progressed through investigation and performed a systematic retrospective analysis, we have mapped the attack to the Lockheed Martin’s Cyber Kill Chain methodology and thus I will refer to its structure during my story.

PRÓLOGO

Aqui começa a história. Tenho que manter um certo nível de discrição, então os nomes dos usuários e dos servidores de infraestrutura estão mascarados e alterados. Datas e endereços IP externos, no entanto, não foram alterados e eu os compartilho do mesmo jeito que apareceram nos arquivos de log. Tínhamos o seguinte plano de ação: ao descobrir qualquer Indicador de Compromisso (IOC), cruzamos com os dados de log e, com base em descobertas adicionais, corrigimos nossos filtros e, então, lançamos outra busca. Passamos sistematicamente por gigabytes de logs e a visão geral começou a aparecer mais claramente para nós, que agora vou compartilhar com você neste artigo.

Na manhã de domingo, 25 de outubro, recebi uma ligação do nosso departamento de administração de TI com a mensagem de que os servidores controladores de domínio desligaram repentinamente durante a noite e nunca mais voltaram a funcionar. Quando nossa equipe chegou ao local, a primeira coisa que pedimos foram as imagens dos servidores “destruídos” (claro que tínhamos imagens virtuais). A análise inicial indicou claramente que ambos os servidores tiveram seu MBR sobrescrito. Conseguimos recuperar o MBR aplicando algum TestDisk mágico (https://en.wikipedia.org/wiki/TestDisk) e prosseguimos com a análise. As coisas ficaram mais interessantes. A maioria dos arquivos no disco estava preenchida com zeros, então todos pareciam os mesmos arquivos com o mesmo tamanho, mas dentro havia apenas zeros! Entre os arquivos que sobreviveram, alguns arquivos de log de eventos serviram como nosso ponto de partida para começar a mapear todos os eventos anômalos na linha do tempo. Descreverei os indicadores descobertos em ordem inversa, desde o momento em que o incidente ocorreu até o início (penetração).

CAPÍTULO 1. AÇÕES E OBJETIVOS DO ATAQUE

Enquanto trabalhávamos com dados de log dos controladores de domínio recuperados, recebemos outra ligação informando que outro servidor havia sido “infectado” com sintomas semelhantes, desta vez, no entanto, era um servidor de aplicação. Assim, também obtivemos uma imagem deste servidor:
Analisamos os eventos que ocorreram pouco antes do “crash” e os mapeamos na nossa linha do tempo:Deixe-me explicar um pouco sobre o que está exatamente exibido aqui. Uma área com borda azul marca os resultados das ações que testemunhamos como falhas no servidor. Pouco antes do desligamento, tentativas de logon não autorizadas de contas de administrador de domínio foram registradas. As ações realizadas incluem modificação do svchost.exe serviço e geração do serviço filho msDefenderSvc:

https://www.virustotal.com/en/file/f52869474834be5a6b5df7f8f0c46cbc7e9b22fa5cb30bee0f363ec6eb056b95/analysis/À esquerda, há outro evento de interesse que prova que a política global foi modificada:

Sem um chute difícil e observando o conteúdo do script, vemos que quando um usuário faz logon no seu PC, um arquivo chamado ololo.exe (que eu parcialmente reverti e descrevi aqui: https://socprime.com/en/blog/dismantling-killdisk-reverse-of-the-blackenergy-destructive-component/) será automaticamente baixado de um compartilhamento de rede.

Além disso, analisando os logs das estações de trabalho (adiantando um pouco, quero dizer que verificamos registros de mais de cem estações de trabalho) descobrimos a seguinte anomalia: um conjunto de eventos originados de usuários privilegiados que modificaram tarefas agendadas nos PCs dos usuários:

Foi assim que o evento parecia nos logs do controlador de domínio:

Além disso, foi assim que parecia no PC do usuário:

Isso foi basicamente um “golpe mortal”, caso o controlador de domínio não conseguisse concluir sua tarefa e falhasse antes de poder enviar a política de grupo para as estações de trabalho. Como resultado, podemos mapear claramente essa parte do ataque para as “Ações em Objetivos” do modelo Kill Chain. Neste caso, o objetivo é destruir dados na quantidade máxima possível de PCs.

CAPÍTULO 2. “INSTALAÇÃO E EXPLORAÇÃO” TAMBÉM CONHECIDO COMO IMPLANTANDO BLACKENERGY EXPLORANDO VULNERABILIDADES.

Então, o que aconteceu antes dos adversários obterem acesso aos servidores? Analisando os logs de eventos, descobrimos a seguinte sequência dos eventos:Descrição das etapas numeradas do ataque:

1 & 2 – acesso VPN não autorizado e acesso RDP imediato aos controladores de domínio

3 – instalação de VBoxDrv.sys (CVE-2008-3431) serviço. Este passo foi necessário para contornar o DSE (Aplicação de Assinatura de Driver é uma verificação obrigatória de assinaturas de drivers) sem uma reinicialização ( http://www.coresecurity.com/content/virtualbox-privilege-escalation-vulnerability ).

4 – já que o DSE foi neutralizado como parte do passo anterior, a instalação de drivers autoassinados adpu320.sys and amdide.sys não será mais um problema.

Ambos os arquivos .sys produzem o mesmo valor hash. Em 06.11.2015, apenas 2 soluções antivírus poderiam detectá-los, mas mesmo naquela época estava claro que estávamos lidando com BlackEnergy (ambos controladores de domínio tinham uma solução antivírus rodando, mas não era uma daquelas 2 AVs que poderia pegá-lo):4 dias depois, 12 antivírus detectaram essas amostras.

Assim, podemos concluir que esta fase do ataque pode ser mapeada com sucesso para as etapas do Cyber Kill Chain de “Instalação” e “Exploitation”.

CAPÍTULO 3. “AÇÕES EM OBJETIVOS”, “RECONHECIMENTO”

É óbvio que as contas de administrador foram comprometidas e é razoável suspeitar que suas estações de trabalho também foram sujeitas a acesso não autorizado. Com base na análise dos logs de suas estações de trabalho (e de algumas centenas de outras estações de trabalho) foi descoberta uma atividade anômala relacionada ao uso da utilidade de gerenciamento remoto da suíte Sysinternals PsExec PsExec foi descoberto:

A linha do tempo acima descreve um fragmento da atividade relacionada à coleta de dados das estações de trabalho.

E é assim que o evento se parece nos logs das estações de trabalho:

Esta fase pode ser mapeada para o modelo Cyber Kill Chain novamente, correspondendo respectivamente ao “Reconhecimento” e “Ações em Objetivos” (os objetivos sendo a coleta de dados sobre infraestrutura e usuários). Também mapeei esta fase para “Reconhecimento”, já que há uma alta suspeita de que os adversários tenham coletado dados adicionais das estações de trabalho para avançar em seu ataque.

CAPÍTULO 4. “COMANDO E CONTROLE (C2)”, COMUNICAÇÃO COM SERVIDORES BLACKENERGY

Realizamos uma análise paralela dos logs das estações de trabalho e firewall. Desde que ficou claro que BlackEnergy foi usado para nos atacar, usamos toda a pesquisa e artigos publicados sobre este assunto para checar nas comunicações com centros de comando conhecidos:Como visto nesta parte da linha do tempo, rastreamos o histórico do ataque até maio de 2015! 15.05.2015 é o dia em que ocorreu a primeira comunicação com um dos servidores de comando e controle conhecidos que também faz parte da rede Tor (5.149.254.114).

Infelizmente, uma estação de trabalho que realizou a comunicação com este centro de comando também continha um arquivo com senhas para vários perfis do YouTube e em 22.05.2015 essas contas foram sequestradas. O hacking foi conduzido de outros dois servidores 185.61.138.143 and 46.28.68.158 (novamente nós do Tor), endereços de email falsos e números de telefone de recuperação foram usados. Não houve qualquer dano particular causado pelo ataque e, na época, nem parecia um hack direcionado. As contas foram rapidamente recuperadas, uma autenticação de dois fatores foi adicionada, conclusões foram feitas, e o incidente foi mantido fechado até novembro de 2015 – o dia em que claramente se tornou uma peça de um quebra-cabeça maior!

Acredito que esta fase do ataque pode ser categorizada como “Comando & Controle (C2)”:

CAPÍTULO 5. “ENTREGA” DOS MÓDULOS BLACKENERGY

Recuperamos uma lista de todas as estações de trabalho que realizaram comunicação com os servidores de comando a partir dos logs do firewall e criamos um filtro com base nos endereços IP dessas estações de trabalho, esse filtro foi usado para procurar por toda a atividade que essas máquinas conduziram em todo o ano de 2015 com o objetivo de encontrar anomalias e padrões. Os padrões foram encontrados. Um elo comum (além de um número de servidores comuns como Google ou Facebook/VK/Twitter, etc.) parecia ser um único servidor com um IP de 176.53.127.194 (e novamente este é um nó Tor!):

Em 23.04.2015, um dos funcionários recebeu um e-mail comum, que exibia alguns detalhes interessantes após um olhar mais atento (claro que durante o tempo da investigação, mais de meio ano após o e-mail ter sido aberto):
Primeiro, vamos olhar para os cabeçalhos do e-mail:

Recebido: de mx1-mail.com (mx1-mail.com [5.149.248.67]) Qui, 23 Abr 2015 09:43:45 +0300

Recebido: de webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

por mx1-mail.com [5.149.248.67] com esmtp (envelope-from <info@rada.gov.ua>)

De: «info@rada.gov.ua» <info@rada.gov.ua>

Mail de retorno: info@rada.gov.ua

5.149.248.67 – um endereço IP já conhecido que foi usado para enviar e-mails semelhantes para outras organizações (https://cys-centrum.com/ru/news/black_energy_2_3).

Em relação ao anexo, um arquivo .xls contém a seguinte macro:

By putting together all 864 elements of the array А, as an output we will receive vba_macro.exe, que é, de fato, um dropper BlackEnergy

https://www.virustotal.com/ru/file/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525/analysis/1458721530/

https://www.hybrid-analysis.com/sample/ca7a8180996a98e718f427837f9d52453b78d0a307e06e1866db4d4ce969d525?environmentId=1O Dropper inicia uma conexão com um centro de comando já conhecido por nós:Em seguida, o malware recebe mais “instruções”, forma um arquivo chamado FONTCACHE.DAT, e o carrega usando rundll32.exe já que FONTCACHE.DAT é, de fato, uma variação de packet.dll – de volta do Hackers Encyclopedia 2002, desenvolvido pela Whirlwind Software para Windows OS:C:WINDOWSsystem32rundll32.exe C:WINDOWSsystem32rundll32.exe" "C:Documents and Settings<USER>Local SettingsApplication DataFONTCACHE.DAT"Então, ele escreve isso no Inicializar:C:Documents and Settings<USER>Start MenuProgramsStartup{22A16F66-CB92-4B66-8BDE-26B5CD34553F}.lnkAgora, vamos dar uma olhada mais detalhada na imagem de rodapé de e-mails que não conseguiu carregar:Um link para nossa “imagem” parece com isso:src=”http://176.53.127.194/bWFpbF9pdmFub3YuaXZhbkBkb21lbi51YQ==.pngApós alguma decodificação Base64, transforma-se em:src=”http://176.53.127.194/mail_ivanov.ivan@domen.ua.pngPortanto, este é um alerta para os adversários que confirma o fato de que Ivan Ivanov abriu com sucesso um e-mail e está pronto para “receber mais instruções”.

Quero mais uma vez sublinhar que houve apenas um e-mail em abril e tinha apenas um destinatário.

Agora vamos olhar para os e-mails que foram recebidos em julho (mala direta para mais de 2000 endereços). Um padrão comum é que todos os e-mails continham o mesmo “beacon” que relatava de volta para o mesmo IP (176.53.127.194) e identificou precisamente o destinatário. Então, isso não foi apenas uma campanha de spam, mas uma campanha direcionada, e a única parte que era diferente é a ausência do prefixo “mail_” na mensagem decodificada:

O mesmo endereço IP no cabeçalho:

Received: from mx1-mail.com (mx1-mail.com [5.149.248.67]) por

Received: from webmail.rada.gov.ua (port=80 helo=webmail.rada.gov.ua)

by  mx1-mail.com [5.149.248.67] com esmtp (envelope-from  <pravyysektor@rada.gov.ua>)

De: “pravyysektor@rada.gov.ua” <pravyysektor@rada.gov.ua>

Data: Ter, 28 Jul 2015 09:08:38 +0200

Caminho de Retorno: pravyysektor@rada.gov.ua

Conteúdo da carta que mostra claramente nosso “beacon”:Apesar do fato de que a mala direta endereçou toda a empresa, obviamente, um spam e que e-mail com tal texto são proibidos de abrir, ainda assim alguns usuários abriram o e-mail, o que causou uma explosão de comunicação com um centro de comando e controle conhecido:Conforme observado na linha do tempo, a primeira comunicação baixou 28 863 bytes, a próxima já 359 276 bytes etc. As comunicações tinham clara sequência e clara estrutura:

Não há dúvida em classificar esta fase do ataque como “Delivery”:

Como podemos ver, o ataque tem todos os sinais de uma estrutura APT que pode ser descrita claramente usando a metodologia Cyber Kill Chain.

AVALIAÇÃO DAS CONSEQUÊNCIAS

Pelo lado negativo: os dados foram destruídos em dois controladores de domínio, um servidor de aplicação e um pouco mais de uma dúzia de PCs.Pelo lado positivo das coisas:  ganhamos um teste de penetração gratuito, experiência inestimável de investigação de APT real, criamos/ajustamos uma série de ferramentas que não só automatizam nosso trabalho com processamento de logs, mas também a análise de malware (mas estou me adiantando, este é um assunto para um outro artigo inteiro). A gerência obteve uma compreensão muito melhor sobre o propósito do InfoSec (inestimável!). Esta única demonstração de uma ameaça real e a investigação que se seguiu nos ajudou mais do que alertas anteriores ou ameaças hipotéticas. O trabalho em equipe minucioso com administradores de TI elevou nossa colaboração profissional para o próximo nível. Assim, considero estes eventos um verdadeiro treinamento de combate cibernético e as melhores lições para obter um entendimento real dos métodos e técnicas do adversário.

Concluindo, quero dizer que muitas coisas foram deixadas de fora do artigo e algumas partes ainda estão sendo estudadas detalhadamente.

Há dois objetivos que quero alcançar ao publicar esta investigação:

1. Para mostrar que, por um lado, BlackEnergy não é um mega-monstro que pode ser lançado em um planeta inabitado e que pode meio ano depois construir sua própria base de operações que pode sustentar sua sobrevivência 🙂 Por outro lado, é uma ferramenta poderosa e especializada que pode, nas mãos de um especialista, causar um dano maciço à vítima do ataque.
2. Para sublinhar que um ataque que aproveita o BlackEnergy é apenas um dos exemplos da evolução das tecnologias que são ativamente usadas por cibercriminosos. Estes não são simples ataques cibernéticos, estamos lidando com operações bem organizadas e precisamente planejadas, semelhantes às conduzidas por forças especiais militares (a imagem do artigo foi escolhida por essa associação).

Com base no exposto, podemos construir um dos cenários de uso de tal informação: por que alguém precisaria hackear um banco quando pode simplesmente comprar acesso a uma infraestrutura de qualquer empresa da cadeia de suprimentos, que possui uma conectividade VPN site-a-site constante e obter um acesso “oficialmente autorizado” (podemos nos referir ao desenho animado sobre um banco e um zelador: https://www.youtube.com/watch?v=fB2b-lTjCQA ).

Como de costume, ficaria grato a todos que checarem seus dados de log para os indicadores mencionados (IOC’s) após a leitura do artigo.

Nos artigos seguintes compartilharei alguns métodos que permitem detectar certos indicadores das atividades do adversário que foram descritas e permitem construir um conjunto de medidas organizacionais e técnicas voltadas a minimizar a probabilidade de tais incidentes ocorrerem em uma organização, ou pelo menos aumentar a probabilidade de sua rápida descoberta.

CRÉDITOS

Agradecimentos enormes aos meus colegas por seu entusiasmo, persistência e pelo trabalho bem feito. Quero expressar uma gratidão dedicada a Marina Krotofil e à equipe de Andrii Bezverkhyi por sua assistência na preparação da análise e do artigo. Agradecimentos adicionais vão para HPE , LanTec and SOC Prime pela ajuda material e técnica com hardware e software que foram fornecidos durante a investigação e combate ao ataque.

Traduzido do original por Andrii Bezverkhyi | CEO SOC Prime