# O comprometimento da SolarWinds: como uma atualização assinada virou o maior ataque à cadeia de suprimentos já registrado

> A partir de setembro de 2019 um intruso ficou dentro do sistema de build da SolarWinds, testou em outubro e, a partir de fevereiro de 2020, inseriu um backdoor na plataforma de monitoramento Orion que a própria SolarWinds assinou e distribuiu. Menos de 18.000 clientes o instalaram; um punhado foi invadido de fato. Descoberto em dezembro de 2020 por uma vítima que investigava a própria invasão, atribuído ao SVR russo em abril de 2021 e ainda em juízo em 2024 pelo que a empresa dissera sobre a própria segurança.

Source: https://ronutz.com/pt-BR/learn/the-solarwinds-compromise  
Updated: 2026-10-06

---

## O que era o Orion, e por que valia o esforço

O SolarWinds Orion era uma plataforma de monitoramento: a base sobre a qual se instalavam o Network Performance Monitor, o NetFlow Traffic Analyzer, o Network Configuration Manager, o Server & Application Monitor e seus irmãos, nos servidores do próprio cliente. Um servidor de monitoramento desse tipo guarda credenciais de tudo o que observa e fica onde alcança todos os segmentos, porque alcançar todos os segmentos é sua função. Quem o controla controla um ponto de observação que nenhuma estação de trabalho comprometida oferece sozinha. A SolarWinds atendia mais de 300.000 clientes; cerca de 33.000 deles eram clientes do Orion com manutenção ativa no período que importou.

Esse é o contexto da decisão que o atacante tomou. Em vez de invadir 18.000 redes uma a uma, invadiu a única empresa em cujo software essas redes já confiavam e deixou que o próprio mecanismo de atualização do fornecedor entregasse o implante, assinado com o certificado do próprio fornecedor.

## A linha do tempo, pelo relato da própria empresa

O CEO da SolarWinds, Sudhakar Ramakrishna, expôs a sequência em 11 de janeiro de 2021. A atividade suspeita mais antiga nos sistemas internos da empresa identificada por suas equipes forenses data de setembro de 2019. A versão de outubro de 2019 do Orion Platform parece ter contido modificações destinadas a testar a capacidade dos perpetradores de inserir código nos builds da empresa: um ensaio, sem carga. Uma versão atualizada da fonte maliciosa de injeção de código inseriu então o código SUNBURST nos lançamentos do Orion Platform a partir de 20 de fevereiro de 2020. Os perpetradores permaneceram sem ser detectados e removeram o código SUNBURST do ambiente de build em junho de 2020. Em 12 de dezembro de 2020 a empresa foi informada do ataque.

O mecanismo de injeção foi identificado pela KPMG e pela CrowdStrike trabalhando com a própria equipe da SolarWinds, e a CrowdStrike publicou sua análise no mesmo dia em que Ramakrishna escreveu. O implante, que a CrowdStrike batizou SUNSPOT, rodava no servidor de build e monitorava os processos em execução à procura dos envolvidos na compilação do produto Orion; ao ver um build, substituía um dos arquivos-fonte, InventoryManager.cs, por uma versão com o backdoor SUNBURST, e depois restaurava o original. Trazia uma verificação de hash, para substituir apenas um arquivo-fonte que reconhecesse e nunca trocá-lo por lixo de uma descriptografia falha, e vários salvaguardas foram acrescentados para evitar que os builds do Orion falhassem, o que poderia alertar os desenvolvedores para a presença do adversário. A CrowdStrike rastreou a atividade como StellarParticle e, na época, não a atribuiu a nenhum adversário conhecido.

Duas coisas nesse relato merecem destaque. O código-fonte no repositório da SolarWinds nunca foi modificado; a substituição acontecia em memória na máquina de build, entre o repositório e o compilador, de modo que uma revisão do fonte não encontraria nada. E o atacante testou primeiro, em outubro de 2019, com uma alteração inofensiva, para saber se um build modificado seria distribuído e se alguém notaria. Ninguém notou.

## O que foi distribuído

A divulgação da FireEye em 13 de dezembro de 2020 descreveu o que os clientes haviam recebido. Atualizações adulteradas do software SolarWinds Orion, assinadas digitalmente pela SolarWinds, carregavam um backdoor que a FireEye chamou de SUNBURST dentro de SolarWinds.Orion.Core.BusinessLayer.dll, um componente assinado do framework Orion. Após um período inicial dormente de até duas semanas, o backdoor recuperava e executava comandos que chamava de jobs: transferir arquivos, executar arquivos, perfilar o sistema, reiniciar a máquina, desabilitar serviços. Localizava seu servidor de comando e controle por um algoritmo de geração de domínios que construía um subdomínio de avsvmcloud[.]com, sob hosts como appsync-api.eu-west-1 e appsync-api.us-east-2. Em pelo menos um caso os atacantes implantaram então um dropper residente só em memória, nunca visto antes, o TEARDROP, para carregar o Cobalt Strike BEACON. A FireEye rastreou o ator como UNC2452 e vira a atividade em entidades de governo, consultoria, tecnologia, telecomunicações e extrativas na América do Norte, Europa, Ásia e Oriente Médio.

Os lançamentos afetados, nas palavras da diretiva que a CISA emitiu no mesmo dia, eram Orion Platform 2019.4 HF5, 2020.2 RC1 e RC2, 2020.2 e 2020.2 HF1. O próprio comunicado regulatório da SolarWinds de 14 de dezembro falou em atualizações lançadas entre março e junho de 2020, e deu o número que todos citam desde então: dos aproximadamente 33.000 clientes do Orion com manutenção ativa durante e após o período relevante, acreditava-se que menos de 18.000 haviam instalado uma atualização afetada. O mesmo documento registrou que a empresa fora informada de um vetor de ataque usado para comprometer seu e-mail, que podia ter dado acesso a outros dados de suas ferramentas de produtividade, e prometeu um segundo hotfix até 15 de dezembro. Descreveu o incidente como provável resultado de um ataque à cadeia de suprimentos altamente sofisticado, dirigido e manual por um Estado estrangeiro.

Os 18.000 precisam da ressalva toda vez que são repetidos. É o número de instalações que receberam um backdoor, não o número de organizações em que o atacante entrou. O backdoor dormia por até duas semanas, depois pedia instruções, e o ator escolhia onde prosseguir. A declaração da Casa Branca de abril de 2021 falou na capacidade de espionar ou potencialmente perturbar mais de 16.000 sistemas no mundo; as intrusões subsequentes foram muito menos numerosas e muito mais seletivas.

## Como foi descoberto

Não pela SolarWinds, e não pelo governo. Em 8 de dezembro de 2020 a FireEye anunciou que suas próprias ferramentas de red team haviam sido roubadas por um atacante que acreditava ser patrocinado por um Estado, e publicou contramedidas para elas. Investigando como fora invadida, a FireEye encontrou o backdoor do Orion e, cinco dias depois, o revelou ao mundo. A National Security Agency, que usa software da SolarWinds, não se sabe ter tido conhecimento do ataque antes da notificação da FireEye; os atacantes haviam escapado do sistema Einstein do Departamento de Segurança Interna usando endereços de comando e controle nos Estados Unidos e malware novo. Antes, durante 2019 e 2020, a empresa de resposta a incidentes Volexity observara um atacante que chamou de Dark Halo abusando de produtos Microsoft dentro da rede de um think tank, e em junho e julho de 2020 o viu usando o trojan do Orion, sem conseguir identificá-lo.

Uma empresa de segurança encontrou o maior ataque à cadeia de suprimentos da história porque investigou direito a própria invasão. É a frase a guardar.

## A resposta

A Diretiva de Emergência 21-01 da CISA, emitida em 13 de dezembro de 2020, disse aos órgãos civis federais o que fazer, e a ordem das instruções é a lição. Primeiro: desconectar ou desligar imediatamente da rede os produtos SolarWinds Orion, versões 2019.4 a 2020.2.1 HF1. Depois: fazer imagem forense da memória e dos sistemas operacionais dos hosts de cada instância do Orion; analisar o tráfego de rede armazenado em busca de indícios de comprometimento; bloquear todo o tráfego de e para hosts externos onde qualquer versão do Orion estivesse instalada; e reportar qualquer evidência de comprometimento à CISA como incidente até o meio-dia do leste dos Estados Unidos da segunda-feira, 14 de dezembro. Orientações suplementares vieram em 6 de janeiro de 2021 e, como versão 4, em 22 de abril de 2021. Desconectar veio antes de corrigir, porque um servidor corrigido que já fora usado como ponto de apoio continuava sendo um ponto de apoio.

O que o ator fez depois do backdoor é a parte que a diretiva só podia insinuar. O relato da enciclopédia, apoiado nas investigações, é que o acesso aos servidores Orion ajudou os intrusos a caçar certificados que lhes permitissem assinar tokens SAML, de modo a se passar por usuários legítimos perante serviços locais e serviços em nuvem como o Azure Active Directory da Microsoft; vulnerabilidades no VMware Access e no VMware Identity Manager foram usadas para pivotar e persistir. O servidor de monitoramento de rede era a porta; a identidade era a casa. Entre as vítimas nomeadas no registro público estão o Tesouro dos Estados Unidos e a National Telecommunications and Information Administration do Departamento de Comércio. O National Cyber Security Centre do Reino Unido disse em 18 de dezembro que ainda apurava o impacto no país, e o Information Commissioner's Office mandou em 23 de dezembro que as organizações britânicas verificassem de imediato se haviam sido afetadas.

## Atribuição

A FireEye deu ao ator um nome provisório, UNC2452; a Volexity o chamou de Dark Halo; autoridades americanas disseram que o grupo específico era provavelmente o SVR ou o Cozy Bear, também conhecido como APT29. Em 15 de abril de 2021 a Casa Branca formalizou: os Estados Unidos nomearam o Serviço de Inteligência Externa da Rússia, o SVR, também conhecido como APT 29, Cozy Bear e The Dukes, como perpetrador da ampla campanha de espionagem cibernética que explorou a plataforma SolarWinds Orion e outras infraestruturas de tecnologia da informação. O mesmo anúncio designou seis empresas russas de tecnologia que apoiam o programa cibernético dos serviços de inteligência russos, sancionou 32 entidades e indivíduos por tentativas de influenciar a eleição presidencial de 2020, proibiu instituições financeiras americanas de participar do mercado primário de nova dívida soberana russa e expulsou dez funcionários da missão diplomática russa em Washington.

## O processo judicial sobre o que a empresa dissera

O último capítulo é sobre palavras e não sobre código. Em 30 de outubro de 2023 a Securities and Exchange Commission acusou a SolarWinds e seu diretor de segurança da informação, Timothy G. Brown, de fraude e falhas de controles internos relativas a riscos e vulnerabilidades de cibersegurança supostamente conhecidos, da oferta pública inicial da empresa em outubro de 2018 até pelo menos seu anúncio de dezembro de 2020. A acusação alegou que a empresa exagerou suas práticas de cibersegurança e minimizou ou deixou de divulgar riscos conhecidos, e citou a própria gente da empresa: a apresentação de um engenheiro em 2018 descrevendo o arranjo de acesso remoto como não muito seguro, em que alguém podia fazer o que quisesse sem ser detectado até ser tarde demais; as apresentações do próprio Brown em 2018 e 2019 dizendo que o estado atual da segurança deixava a empresa em situação muito vulnerável e que o acesso e os privilégios a sistemas e dados críticos eram inadequados; uma nota de junho de 2020 de que era muito preocupante que os back ends não fossem tão resilientes; e um documento de setembro de 2020 alertando que o volume de problemas de segurança identificados superara a capacidade das equipes de engenharia de resolvê-los. A SEC pediu liminares, devolução de ganhos, multas civis e a proibição de Brown atuar como diretor ou conselheiro.

Em 18 de julho de 2024 o juiz Paul Engelmayer, do Distrito Sul de Nova York, rejeitou a maior parte. As alegações sobre as divulgações da SolarWinds em seus relatórios anuais e trimestrais e em seus 8-K não bastavam para sustentar acusações de fraude de valores mobiliários; os comunicados e posts de blog eram puffery não acionável; e o tribunal rejeitou categoricamente a tese da SEC de que sua autoridade sobre controles contábeis internos se estende aos controles de cibersegurança de uma empresa, chamando essas acusações de mal formuladas. Sobreviveram as acusações de fraude baseadas no Security Statement do site da empresa, contra a empresa e contra Brown: o tribunal entendeu que declarações falsas sobre controles de acesso e proteções de senha eram inegavelmente materiais, porque a cibersegurança era primordial para o negócio da empresa.

Assim, o desfecho regulatório, no estado em que está, é estreito e afiado ao mesmo tempo. Os relatórios e o marketing de uma empresa não foram fraude; a página de seu site descrevendo suas práticas de segurança pode ter sido. Todo diretor de segurança que escreve uma página dessas a escreve hoje de outro jeito.

## O que quem opera deve levar disto

**O build é parte da superfície de ataque.** O fonte estava limpo. O implante vivia no servidor de build, trocava um arquivo durante a compilação e o devolvia. Builds reprodutíveis, integridade do host de build e a comparação do que foi distribuído com o que foi commitado são os controles que teriam pego, e eram raros em 2020.

**Uma assinatura prova quem assinou, não o que foi assinado.** A DLL do SUNBURST trazia uma assinatura válida da SolarWinds porque a SolarWinds a compilou e assinou. A assinatura de código é necessária e insuficiente; ela move a pergunta de "este arquivo é genuíno" para "o pipeline de quem assinou está íntegro".

**O sistema de monitoramento é joia da coroa.** Guarda as credenciais, alcança tudo, e seu canal de atualização é confiável por definição. Segmente-o, restrinja o que ele pode alcançar para fora e trate as atualizações do fornecedor com a mesma desconfiança de qualquer outro código remoto.

**Dormência e seletividade derrotam defesas de volume.** Duas semanas de silêncio, depois tráfego para um domínio plausível, depois um humano escolhendo qual das 18.000 portas abrir. Foi a detecção comportamental nas poucas redes de fato invadidas, não a correspondência de assinaturas no perímetro, que acabou revelando o ataque.

**A identidade é o segundo estágio.** O ponto de apoio era uma ferramenta de rede; o objetivo era a capacidade de cunhar tokens SAML e ler o correio de qualquer um. Proteger as chaves de assinatura de tokens e vigiar autenticações impossíveis importa mais do que o servidor de onde o atacante partiu.

**Desconectar, depois fazer imagem, depois corrigir.** A ordem da diretiva é a ordem certa para o comprometimento de uma plataforma confiável, e é o oposto do instinto de atualizar primeiro.

**Diga o que você de fato faz.** A exposição legal que sobreviveu não foi a invasão; foi a descrição das práticas de segurança em uma página pública. Escrever essas páginas com verdade, nomeando as lacunas, é hoje matéria de valores mobiliários nos Estados Unidos e de reputação em toda parte.

## Fontes

- [SolarWinds, Sudhakar Ramakrishna, 11 de janeiro de 2021, "New Findings From Our Investigation of SUNBURST": atividade suspeita mais antiga em setembro de 2019; a versão de outubro de 2019 com modificações para testar a capacidade de inserir código nos builds; SUNBURST inserido nos lançamentos a partir de 20 de fevereiro de 2020; removido do ambiente de build em junho de 2020; a empresa informada em 12 de dezembro de 2020; KPMG e CrowdStrike localizaram a fonte da injeção](https://www.solarwinds.com/blog/new-findings-from-our-investigation-of-sunburst)
- [CrowdStrike, 11 de janeiro de 2021, análise técnica do SUNSPOT: o malware do StellarParticle que monitorava processos de compilação e substituía InventoryManager.cs para inserir o SUNBURST; a verificação de hash; os salvaguardas para evitar falhas de build que alertassem os desenvolvedores; sem atribuição a adversário conhecido na época](https://www.crowdstrike.com/en-us/blog/sunspot-malware-technical-analysis/)
- [FireEye (hoje Mandiant, publicado pelo Google Cloud), 13 de dezembro de 2020: a campanha UNC2452; atualizações adulteradas do Orion distribuindo o SUNBURST em SolarWinds.Orion.Core.BusinessLayer.dll; atualizações assinadas de março a maio de 2020; o período dormente de até duas semanas; os jobs; o algoritmo de geração de domínios sob avsvmcloud[.]com; TEARDROP e Cobalt Strike BEACON; vítimas em governo, consultoria, tecnologia, telecomunicações e setor extrativo em quatro regiões](https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor)
- [Diretiva de Emergência 21-01 da CISA, 13 de dezembro de 2020: as versões afetadas 2019.4 HF5, 2020.2 RC1 e RC2, 2020.2 e 2020.2 HF1; desconectar ou desligar; imagem de memória e hosts; análise do tráfego armazenado; bloqueio de tráfego a hosts Orion externos; reporte até o meio-dia de 14 de dezembro; orientações suplementares de 6 de janeiro e 22 de abril de 2021](https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise)
- [SolarWinds, Formulário 8-K, 14 de dezembro de 2020: uma vulnerabilidade inserida nos produtos Orion em atualizações lançadas entre março e junho de 2020; provável ataque à cadeia de suprimentos altamente sofisticado, dirigido e manual por um Estado estrangeiro; aproximadamente 33.000 clientes do Orion com manutenção, menos de 18.000 que teriam instalado as versões afetadas; mais de 300.000 clientes no total; o comprometimento do e-mail; o segundo hotfix até 15 de dezembro](https://www.sec.gov/Archives/edgar/data/1739942/000162828020017451/swi-20201214.htm)
- [A Casa Branca, 15 de abril de 2021, ficha informativa: os Estados Unidos nomeiam formalmente o Serviço de Inteligência Externa da Rússia (SVR), também conhecido como APT 29, Cozy Bear e The Dukes, como perpetrador; a capacidade de espionar ou potencialmente perturbar mais de 16.000 sistemas de computação no mundo; seis empresas russas de tecnologia designadas; 32 entidades e indivíduos sancionados; restrições à dívida soberana; dez funcionários diplomáticos expulsos](https://bidenwhitehouse.archives.gov/briefing-room/statements-releases/2021/04/15/fact-sheet-imposing-costs-for-harmful-foreign-activities-by-the-russian-government/)
- [Wikipedia, 2020 United States federal government data breach: o anúncio da FireEye de 8 de dezembro de 2020 sobre as ferramentas de red team roubadas e sua descoberta do ataque à cadeia de suprimentos ao investigar a própria invasão; o Dark Halo da Volexity; os certificados para tokens SAML e o Azure Active Directory; as vulnerabilidades do VMware Access e do Identity Manager; o Einstein driblado por comando e controle nos EUA; o uso do SolarWinds pela própria NSA; o Tesouro e a NTIA; as declarações do NCSC e do ICO britânicos de 18 e 23 de dezembro de 2020; as autoridades americanas sobre o SVR e o APT29](https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach)
- [Comunicado 2023-227 da SEC, 30 de outubro de 2023: SolarWinds e o CISO Timothy G. Brown acusados de fraude e falhas de controles internos da IPO de outubro de 2018 a dezembro de 2020; as apresentações e mensagens internas citadas; as medidas pedidas](https://www.sec.gov/news/press-release/2023-227)
- [Cooley, 23 de julho de 2024, sobre a decisão de 18 de julho de 2024 do juiz Paul Engelmayer, SDNY: as acusações baseadas nos relatórios, as declarações públicas como puffery e a tese dos controles contábeis internos rejeitadas; as acusações baseadas no Security Statement contra a empresa e contra Brown mantidas, com as declarações falsas sobre controles de acesso e proteções de senha consideradas inegavelmente materiais](https://www.cooley.com/news/insight/2024/2024-07-23-federal-court-dismisses-bulk-of-secs-complaint-against-solarwinds-in-cyberattack-case)
- [SolarWinds, a Orion Platform hoje: os módulos Orion auto-hospedados na SolarWinds Platform; a descrição que a própria plataforma faz do que o Orion era; Secure by Design](https://www.solarwinds.com/orion-platform)