SolarWinds e o backdoor SUNBURST: o que há dentro desta campanha APT





Imagine que todo mundo que tem um alto-falante inteligente Amazon Echo em casa (Yandex Alice, Maroussia - substitua por um adequado) saberia que nos últimos 6 meses ela destrancou a casa e deixou ladrões entrarem. Como você pode se sentir seguro agora se os invasores podem fazer cópias de suas chaves, documentos, mídia de armazenamento ou, por exemplo, envenenar o sistema de abastecimento de água?



Esta é a situação hoje para milhares de organizações afetadas pelo ataque de malware Sunburst na cadeia de suprimentos de software da SolarWinds. As empresas afetadas estão procurando desesperadamente por sinais de comprometimento, conduzindo uma auditoria de segurança de infraestrutura não programada e algumas podem até mesmo suspender uma série de serviços enquanto se aguarda uma investigação.



Em 8 de dezembro, a FireEye anunciou que havia sido hackeada e lançou uma investigação envolvendo o governo dos Estados Unidos e a Microsoft.



Em 13 de dezembro, a FireEye divulgou um relatório detalhado do comprometimento , que descreve como o código malicioso é distribuído por meio do software Orion da SolarWinds.



Em 17 de dezembro, a Agência de Segurança Cibernética e Infraestrutura (CISA) emitiu um anúncio de emergência, que solicitou a todas as empresas que usam o software SolarWinds que atualizassem ou mesmo desconectassem o SolarWinds Orion da rede (na Etapa 2 da postagem acima). Desde então, o Varonis Security Incident Investigation Service notou um aumento nas investigações forenses relacionadas à campanha e identificou vários ataques ativos.



Embora grande parte do material até o momento tenha se concentrado na correção de versões comprometidas da solução SolarWinds Orion, de acordo com a CISA , há evidências de vetores de intrusão adicionais associados a esta campanha.



Ataques à cadeia de suprimentos são difíceis de se defender



Em um ataque à cadeia de suprimentos, o invasor tem como alvo um fornecedor ou produto confiável em vez de atacar diretamente seus alvos. Nesse caso, os invasores injetaram um backdoor preparado ("backdoor") em um produto de software confiável (SolarWinds Orion), que foi enviado automaticamente a milhares de clientes, disfarçado como uma atualização regular.



As más notícias não param por aí - os invasores se revelaram sofisticados o suficiente para passar despercebidos por meses. Eles tiveram tempo para deixar backdoors adicionais e obter acesso a uma variedade de sistemas e dados. Atualmente, as organizações que receberam uma atualização mal-intencionada são forçadas a investigar absolutamente tudo: começando com sistemas e contas diretamente associados ao SolarWinds e continuando a investigação mais adiante na cadeia.



Detecção primária



Quer você seja um cliente Varonis ou não, a primeira etapa é verificar se há uma versão vulnerável do software SolarWinds. SolarWinds identificou versões vulneráveis e, a partir de 16 de dezembro de 2020, lançou atualizações e patches para substituir os componentes comprometidos.



Se sua versão for vulnerável, aqui estão as etapas que você deve seguir:



  1. avsvmcloud [.] com ,

    DNS avsvmcloud [.] com, , (C2) SolarWinds Sunburst.

    Varonis , , Varonis Edge .

  2. , SolarWinds

    Varonis , SolarWinds, . , Active Directory, SolarWinds , .



    Varonis SolarWinds – :





  3. , ( , SolarWinds)

    () , , (Azure Active Directory).

    , , Varonis DatAlert.



APT- ( )



Este ataque foi realizado sem explorar uma vulnerabilidade de dia zero (pelo menos a mesma vulnerabilidade que conhecemos no momento). A teoria dominante, ainda não validada pela SolarWinds, é que os invasores usaram credenciais de servidor FTP público descobertas no GitHub em 2018 para obter acesso à infraestrutura de atualização de software da empresa.







O invasor foi capaz de modificar o pacote de atualização de software e adicionar um backdoor malicioso a uma das DLLs de plug-in do SolarWinds Orion, SolarWinds.Orion.Core.BusinessLayer.dll.







Os invasores assinaram sua versão DLL maliciosa com a chave privada da SolarWinds. O certificado foi emitido pela Symantec.



Presumimos que o invasor foi capaz de assinar a DLL de uma das seguintes maneiras:



  1. O invasor entrou no processo de desenvolvimento, adicionou um backdoor e permitiu que a SolarWinds o assinasse como parte de um processo legítimo de criação e implantação de software.
  2. O invasor roubou a chave privada do certificado, assinou as DLLs e substituiu a DLL oficial por sua versão maliciosa. Isso é menos provável.







Qualquer organização que usa o software SolarWinds e recebe atualizações de seus servidores baixou e executou uma DLL maliciosa. Como a DLL foi assinada e entregue por meio dos servidores de atualização oficiais da SolarWinds, era extremamente difícil detectar conteúdo malicioso.



Análise do backdoor SolarWinds SUNBURST (BusinessLayer.dll)



Quando olhamos dentro da DLL maliciosa, vemos que os invasores confiaram em furtividade. Eles fizeram um grande esforço para escrever um código que se harmonizasse com o resto do código-fonte do Orion, usando argumentos bem escritos e nomes genéricos e desavisados ​​de classes e métodos, como "Inicializar" ou "Trabalho".







O backdoor SolarWinds Sunburst opera em vários estágios:





  1. 12-14 (C2). .









  2. C2 ( , IP-, , ), , .




  3. (DGA) IP- (C2). C2 — SolarWinds OIP (Orion Improvement Program).





  4. , .









  5. , , (), TEARDROP, .





Durante a primeira sessão de comunicação, o backdoor envia informações sobre o dispositivo e seu ambiente, criptografadas em pacotes DNS.



Excepcionalmente, o endereço IP no pacote DNS de resposta determina o próximo salto da porta dos fundos. Dependendo da faixa do endereço IP, o processo SUNBURST encerra ou ativa funcionalidades adicionais , por exemplo, desabilitar antivírus ou baixar e lançar novo malware.



Vamos dar uma olhada mais de perto no início da comunicação backdoor com C2.



  1. Depois que a DLL é carregada, o SUNBURST executa uma série de verificações para garantir que está sendo executado na rede corporativa e não em uma máquina isolada.
  2. , « ». . .
  3. FQDN C2, . (domain1 domain2) + , (domain3):







    :



    Domain1 = ‘avsvmcloud[.]com’ 

    Domain2 = ‘appsync-api’ 

    Domain3 = [‘eu-west-1’, ‘us-west-2’, ‘us-east-1’, ‘us-east-2’]

    GetStatus :







  4. (. 2) (. 3) DNS . , DNS , .



    4 :



    «GetCurrentString» «GetPreviousString» GUID / .



    «GetNextString» «GetNextStringEx» GUID.



    DNS-, C2 , .



    , SUNBURST:







    Prevasio , DNS, .

  5. , IP- DNS- SUNBURST. «IPAddressHelper» IP-, IP-, DNS-:







    , IP- , SUNBURST , HTTP .

  6. IP- DNS- C2, CNAME. , :





  7. , SUNBURST DNS- , / , 120 .
  8. SUNBURST HTTP- C2 URL- , HTTP JSON.



    URI:



    hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml 



    , SUNBURST, / , . .:







    DLL



    , SolarWinds (EDR), . , «» .







    SolarWinds Sunburst , TEARDROP, «gracious_truth.jpg» Cobalt Strike Beacon, «» .



    — , , .



    FireEye CISA , (IOC), . , . , , , , — , , (« ») FireEye.



    « » . DLL SolarWinds Orion . , . , , . , , , , .



    CASA , :



    « , , , , . , , ».



All Articles