AI Hacking - Como os hackers utilizam a inteligência artificial nos ciberataques

Ler agora
Utilizamos inteligência artificial para as traduções dos sítios e, embora nos esforcemos por garantir a exatidão, estas podem nem sempre ser 100% precisas. Agradecemos a sua compreensão.

Como o ataque Supply Chain da SolarWinds poderia ter sido evitado usando o MetaDefender™ Sandbox

Análise dinâmica Adaptive e Threat Intelligence para a defesa Supply Chain dia zero
por OPSWAT
Partilhar esta publicação

Introdução: A violação que redefiniu a cibersegurança

No final de 2020, o ataque à cadeia de abastecimento da SolarWinds abalou a comunidade da cibersegurança.

Ao injetar código malicioso em uma atualização assinada digitalmente da plataforma Orion da SolarWinds, os adversários obtiveram acesso secreto a milhares de organizações dos setores público e privado. O que parecia ser uma atualização de software confiável continha uma backdoor que possibilitou uma das campanhas de espionagem cibernética mais devastadoras da história.

Este incidente revelou uma verdade dolorosa: as defesas baseadas em assinatura e reputação não são suficientes contra ameaças sofisticadas e furtivas de dia zero. Mas e se as organizações da cadeia de abastecimento tivessem implementado OPSWAT MetaDefender™ Sandbox?

Com a mais recente MetaDefender Sandbox 2.4.0, OPSWAT traz uma sandbox adaptativa, baseada em emulação, com integração de inteligência de ameaças que é capaz de detetar as anomalias subtis que o malware SolarWinds tentou esconder.

Este blogue irá explicar como o ataque se desenrolou e, mais importante, como MetaDefender Sandbox o poderia ter impedido.

Como funcionou o ataque da SolarWinds

O ataque à cadeia de abastecimento da SolarWinds foi ativado através do comprometimento de uma DLL legítima utilizada na plataforma de gestão de TI Orion (SolarWinds.Orion.Core.BusinessLayer.dll). Os agentes da ameaça modificaram furtivamente este componente, incorporando código malicioso diretamente no mesmo.

O que parecia ser uma alteração menor e inofensiva, com algumas linhas discretas numa base de código familiar, acabou por introduzir uma ameaça significativa. Esta DLL fazia parte de uma plataforma amplamente utilizada por organizações do sector público e privado, tornando o alcance do ataque sem precedentes.

Escondida na DLL comprometida estava uma backdoor totalmente funcional, criada a partir de cerca de 4.000 linhas de código. Este código concedia aos atacantes acesso secreto aos sistemas afectados, permitindo um controlo persistente sobre as redes das vítimas sem dar alarmes.

Um dos aspectos mais críticos desse ataque foi sua colocação no próprio processo de criação de software. A DLL adulterada continha uma assinatura digital válida, indicando que os atacantes haviam se infiltrado na infraestrutura de desenvolvimento ou distribuição de software da SolarWinds. Isso fez com que o código malicioso parecesse confiável e permitiu que ele executasse ações privilegiadas sem acionar os controles de segurança padrão.

Para manter a discrição, os atacantes evitaram perturbar a funcionalidade original da DLL. A carga útil injectada consistia numa modificação ligeira: lançava um novo método numa thread separada, assegurando que o comportamento da aplicação anfitriã permanecia inalterado. A chamada do método foi incorporada numa função existente, RefreshInternal, mas executada em paralelo para evitar a deteção.

A lógica do backdoor residia numa classe chamada OrionImprovementBusinessLayer, um nome escolhido deliberadamente para se assemelhar a componentes legítimos. Essa classe abrigava a totalidade da lógica maliciosa, incluindo 13 classes internas e 16 funções. Todas as cadeias de caracteres foram ofuscadas, tornando a análise estática significativamente mais difícil.

Porque é que a segurança tradicional falhou

  • As assinaturas digitais não são suficientes: A DLL foi assinada, pelo que as ferramentas AV e de endpoint trataram-na como legítima.
  • A análise estática falhou: A ofuscação e as cadeias de caracteres encriptadas camuflaram a lógica suspeita.
  • As verificações em tempo de execução evitavam a deteção: O facto de a backdoor não ser detectada significa que não desencadeou anomalias até que se verificassem condições muito específicas.
  • Ponto cego da cadeia de abastecimento: As equipas de segurança confiam frequentemente nas actualizações de software sem as detonarem numa caixa de areia.

Não se tratava apenas de malware; era um compromisso da cadeia de abastecimento concebido para ser invisível.

Como é queSandbox MetaDefender a poderia ter detectado

Ao contrário das sandboxes baseadas em VM, que são fáceis de contornar,Sandbox MetaDefender utiliza emulação ao nível da instrução e análise adaptativa de ameaças. Isto permite-lhe descobrir comportamentos ocultos mesmo quando os atacantes os tentam disfarçar.

Uma caixa de areia desempenha um papel crucial na descoberta deste tipo de ataque. Mesmo que a DLL maliciosa seja assinada digitalmente e cuidadosamente criada para imitar o comportamento legítimo, uma caixa de areia pode detetar o backdoor inserido analisando anomalias no nível binário.

As regras YARA e as verificações de reputação foram intencionalmente desactivadas para esta análise sandbox para simular as condições originais do ataque da SolarWinds, uma vez que nenhuma delas estava disponível na altura.

À esquerda, vemos o arquivo legítimo SolarWinds.Orion.Core.BusinessLayer.dll. À direita está a versão trojanizada responsável pelo infame incidente da SolarWinds.

Passemos em revista as principais conclusões reveladas pela análise da caixa de areia:

  • Encriptação de cadeias de caracteres: o código utiliza uma técnica de ofuscação típica encontrada em vários programas maliciosos: compressão seguida de codificação base64.

As consultas WMI estão normalmente associadas à recolha de impressões digitais do sistema. Neste caso, as cadeias de caracteres relacionadas foram encriptadas para evitar a deteção.

Múltiplos indicadores ligados ao aumento de privilégios, falsificação da identidade do utilizador e adulteração do controlo de acesso.

O .NET PE apresenta provas significativas de operações com privilégios elevados e foge às restrições de acesso
.NET PE Importa funções não geridas para modificar os privilégios do processo
Referências encontradas a privilégios críticos do Windows
O .NET PE utiliza referências de membro para enumeração ou falsificação de contextos de utilizador do Windows
O .NET PE utiliza referências de membro para modificação de ACL

Está presente uma grande matriz estática de bytes (1096 bytes), normalmente utilizada para incorporar ou preparar uma carga útil oculta. Neste caso, armazena valores inteiros que representam hashes de nomes de processos, provavelmente para reconhecimento ou filtragem. Uma vez que a caixa de areia assinalou esta anomalia, os analistas poderiam investigar mais.

O .NET PE contém uma grande matriz estática

Em resumo, uma classe com 4.000 linhas de código pode parecer grande, mas num grande projeto de software com milhares de ficheiros, é muito fácil falhar. É aqui que a área restrita se revela inestimável. Ela destaca comportamentos estranhos e diz aos analistas onde procurar, o que realmente importa.

Como é que umaSandbox Adaptive com Threat Intelligence teria impedido o ataque

1. Análise da estrutura profunda (DSA)

Antes do tempo de execução, Sandbox desmonta os binários para extrair a lógica incorporada. No caso da SolarWinds, teria sido sinalizada:

  • A grande matriz estática de 1096 bytes utilizada para organizar os hashes do processo.
  • Strings comprimidas + codificadas em base64, típicas de malware.
  • A invulgar classe OrionImprovementBusinessLayer e as suas funções ofuscadas.

2. Motor anti-invasão de última geração

MetaDefender Sandbox 2.4.0 aborda especificamente as tácticas utilizadas no SolarWinds:

  • Expor cargas úteis apenas de memória → Detecta código que nunca grava no disco.
  • Desofuscação do fluxo de controlo para .NET → Perfeito para descompactar DLLs ofuscadas como o Orion.
  • Descodificação automatizada Base64 → Desmascara as cadeias encriptadas utilizadas pelos atacantes.

3. Enriquecimento Threat Intelligence

A deteção não pára na caixa de areia. MetaDefender Sandbox integra-se com o MetaDefender Threat Intelligencefornecendo:

  • Mais de 50 mil IOCs (IPs, URLs, domínios, hashes) para enriquecimento.
  • Pesquisa de similaridade para detetar variantes de malware conhecido - mesmo quando modificado.
  • Pontuação de ameaças para dar prioridade a esta DLL como de alta gravidade.

A vantagem MetaDefender Sandbox 2.4.0

A versão mais recente acrescenta capacidades diretamente relacionadas com ameaças semelhantes às da SolarWinds:

  • Exposição de carga útil somente na memória → Teria revelado a execução furtiva da SolarWinds na memória.
  • Desempacotamento de malware empacotado → Identifica cargas úteis escalonadas escondidas dentro de matrizes estáticas.
  • Binários Pseudo-Reconstruídos → Permite que os analistas vejam uma imagem completa das DLLs ofuscadas.
  • Extração melhorada de YARA e configuração → Extrai configurações de malware apesar da encriptação.
  • Desempacotamento do carregador .NET → Diretamente relevante para a lógica .NET ofuscada da DLL do Orion.

Enquanto começávamos a escrever este artigo, uma nova campanha contra a cadeia de suprimentos no ecossistema npm foi tornada pública (npm é um gerenciador de pacotes JavaScript incluído no Node.js, que permite que o JavaScript seja executado fora do navegador). Esta recente campanha envolveu um worm auto-replicante chamado "Shai-Hulud", que conseguiu comprometer centenas de pacotes de software. Este incidente foi analisado em pormenor na publicação OPSWAT "From Dune to npm: Shai-Hulud Worm Redefines Supply Chain Risk".

No entanto, esta nova campanha é particularmente relevante no contexto deste artigo, pois também demonstra que as capacidades de deteção do MetaDefender Sandbox estão actualizadas e são eficazes contra o comprometimento da cadeia de abastecimento. Veja o nosso relatório para o ficheiro malicioso bundle.js, que detecta o download de bibliotecas usando código ofuscado, rotulando esta atividade como "Provavelmente maliciosa".

.NET PE contains a big static array

Seguindo as melhores práticas descritas no post mencionado acima, todas as dependências de código aberto devem ser consideradas não confiáveis até que sua segurança tenha sido comprovada. Se as actualizações dos pacotes npm afectados tivessem sido analisadas previamente na MetaDefender Sandbox, o comportamento malicioso e suspeito teria sido identificado antes de se espalhar.

Juntas, essas caraterísticas mostram como MetaDefender Sandbox é construído especificamente para o tipo de furtividade e ofuscação em que os atacantes da SolarWinds e da NPM se basearam.

Exemplo de caso: Como teria sido o relatório Sandbox

1. Constatações estáticas

a. Nome de classe ofuscado suspeito (OrionImprovementBusinessLayer).

b. Grandes matrizes estáticas ligadas a valores hash.

c. Cadeias de caracteres Base64 encriptadas.

2. Conclusões dinâmicas

a. Consultas de sistema WMI.

b. Tentativa de chamadas de escalonamento de privilégios.

c. Criação de threads ocultas fora do fluxo de trabalho principal do Orion.

3. Correlação Threat Intelligence

a. A pesquisa de similaridade mostra >95% de correspondência com amostras APT conhecidas.

b. A correlação IOC identifica as sobreposições de infra-estruturas C2.

c. A pontuação de ameaças classifica a DLL como "Maliciosa de Alta Confiança".

Lições para os defensores: SolarWinds e muito mais

A violação da SolarWinds foi um sinal de alerta, mas os ataques à cadeia de abastecimento continuam a aumentar. De acordo com o relatório 2025 OPSWAT Threat Landscape Report, as infra-estruturas críticas continuam a ser um dos principais alvos e os carregadores ofuscados baseados em ficheiros são cada vez mais comuns.

MetaDefender Sandbox fornece aos defensores:

Resiliência de dia zero

Deteção de comportamentos que não depende de conhecimentos prévios.

Proteção da Supply Chain

Cada atualização, patch ou ficheiro fornecido pelo fornecedor pode ser detonado.

Garantia de conformidade

Cumpre os requisitos de deteção de dia zero do NIST, NIS2, HIPAA e NERC CIP.

Inteligência acionável

IOCs de alta fidelidade alimentados diretamente nos pipelines SIEM e SOAR.

Criar uma defesa pronta para o dia zero

O ataque à cadeia de suprimentos da SolarWinds não foi imparável - ele não foi detectado. Se MetaDefender Sandbox estivesse em vigor, a DLL ofuscada teria sido detonada, decodificada e sinalizada muito antes de chegar aos ambientes de produção.

Hoje em dia, à medida que os atacantes refinam as suas tácticas de evasão, o sandboxing baseado em emulação já não é opcional. Ele é a base de qualquer estratégia séria de defesa de dia zero.

Com o MetaDefender Sandbox 2.4.0 e o OPSWAT Threat Intelligence, as organizações podem deixar de reagir às violações para neutralizá-las proativamente - antes que elas aconteçam.

Saiba mais sobre o MetaDefender Sandbox.

Explorar OPSWAT Threat Intelligence

Contacte OPSWAT para preparar a sua organização para o Dia Zero.

Explorar OPSWAT Threat Intelligence

Contacte OPSWAT para preparar a sua organização para o Dia Zero.

Mantenha-se atualizado com OPSWAT!

Inscreva-se hoje para receber as últimas actualizações da empresa, histórias, informações sobre eventos e muito mais.