CVE-2018-20753

Falha no Kaseya VSA (RMM usado por MSPs para gerenciar centenas de endpoints) que permite a um atacante remoto, sem autenticação, executar payloads PowerShell com privilégios de sistema em todos os dispositivos geridos pelo servidor VSA comprometido. O risco não é teórico: foi explorada ativamente em janeiro de 2018, antes da correção oficial, para distribuir malware de mineração de criptomoeda em massa através da própria infraestrutura de gestão dos MSPs.

A descrição oficial do fornecedor é genérica — 'permite que atacantes remotos não privilegiados executem payloads PowerShell em todos os dispositivos gerenciados' — sem detalhar o componente exato do VSA nem o tipo de falha (CWE) envolvido. Não há advisory técnico público detalhado que descreva o vetor de entrada no servidor VSA (autenticação quebrada, endpoint sem controle de acesso, ou falha na validação de comandos enviados aos agentes); o que se sabe com certeza é o efeito: alguém sem credenciais válidas consegue fazer o servidor VSA empurrar comandos PowerShell para os endpoints geridos, que os executam com privilégios de Local System.

A exploração documentada por pesquisadores (Huntress) em janeiro de 2018 não usava a CVE como vetor de acesso inicial isolado descrito passo a passo publicamente — o que se observou foi o resultado: agentes VSA de MSPs comprometidos passaram a rodar um comando PowerShell único que baixava e executava um script hospedado em Dropbox, sem interação do usuário local. O script verificava arquitetura (32 ou 64 bits) via tamanho de ponteiro, armazenava payloads ofuscados em Base64 dentro de chaves de registro e criava persistência via Scheduled Tasks com nomes gerados combinando path e nome de tarefas legítimas do Windows, para dificultar a detecção manual. O payload observado era um minerador de criptomoeda, não ransomware.

Após a Kaseya publicar um script de remoção automática, os atacantes atualizaram o malware em 29/01/2018 para trocar as chaves de registro usadas (de HKLM\SOFTWARE\Microsoft\Powershell\Scripts para HKLM\SOFTWARE\Microsoft\Policies\System) e passaram a backdoorar a tarefa agendada legítima 'sihboot' do Windows, evadindo a assinatura do removedor original. Isso demonstra reação ativa e coordenada dos operadores à resposta do fornecedor, não um ataque único e estático.

Importante não confundir com o incidente muito mais conhecido de julho de 2021 envolvendo REvil e Kaseya VSA — aquele caso explorou outras vulnerabilidades (zero-days distintos, não esta CVE-2018-20753) para distribuir ransomware em cadeia de suprimentos. O catálogo KEV da CISA marca esta CVE como 'conhecida por uso em campanhas de ransomware', mas a documentação técnica pública disponível sobre a exploração original de 2018 descreve mineração de criptomoeda, não ransomware — vale tratar essa marcação com a ressalva de que pode refletir reclassificação genérica do catálogo, não evidência técnica publicada de uso em ransomware especificamente com esta falha.

A correção definitiva é atualizar o servidor Kaseya VSA para R9.3 build 9.3.0.35 ou superior, R9.4 build 9.4.0.36 ou superior, ou R9.5 build 9.5.0.5 ou superior — conforme publicado pelo próprio fornecedor. Não há mitigação de configuração equivalente à atualização: como o vetor está no lado servidor do VSA e afeta todos os agentes geridos, isolar ou restringir a rede dos endpoints não resolve a raiz do problema, apenas reduz a superfície de exposição do próprio console VSA.

Para hosts que já foram comprometidos antes da atualização, a Kaseya publicou procedimentos de remoção automática e manual específicos (referenciados no artigo do helpdesk oficial), que precisam ser aplicados porque a atualização do VSA não remove persistência já instalada nos endpoints (chaves de registro e scheduled tasks maliciosas continuam ativas). Se o ambiente já rodou versões vulneráveis em janeiro de 2018, tratar como possível comprometimento até verificar os indicadores de persistência, não assumir que a atualização por si só limpa o parque.

Nos endpoints geridos, procurar chaves de registro em HKLM\SOFTWARE\Microsoft\Powershell\Scripts (valores a, b, c, d) e HKLM\SOFTWARE\Microsoft\Powershell com valor ScriptInit (variante original de janeiro/2018), ou, na variante atualizada posterior a 29/01/2018, HKLM\SOFTWARE\Microsoft\Policies\System e HKLM\SOFTWARE\Microsoft\Policies com valor Start. Procurar Scheduled Tasks com nomes que combinam de forma incoerente o path de uma tarefa do Windows com o nome de outra (técnica de disfarce documentada), e verificar se a tarefa nativa 'sihboot' foi alterada para incluir uma ação Exec adicional.

Em nível de rede, tráfego de saída de estações de trabalho para domínios do Dropbox (dl.dropboxusercontent.com) originado por processos powershell.exe é um sinal forte, embora as URLs específicas usadas em 2018 já tenham sido removidas pelo Dropbox e não sirvam mais como IOC atual. Não há assinatura de exploração no lado do servidor VSA divulgada publicamente — a ausência de logs de acesso não autenticado ao console é esperada e não descarta exploração, já que o mecanismo exato de entrada nunca foi detalhado publicamente pelo fornecedor ou por pesquisadores.