ScreenConnect Aparece em Hosts Não Relacionados em Atividade Suspeita de Tipo Worm

Resumo

Atores de ameaça estão implantando instâncias maliciosas do ScreenConnect que exibem comportamento semelhante a um worm para se espalhar em sistemas conectados. Depois que uma máquina é comprometida, o cliente ScreenConnect modificado transfere e executa automaticamente uma cadeia de VBScript em vários estágios em endpoints recém-conectados. A campanha combina engenharia social e abuso de RMM para manter a persistência e entregar cargas adicionais, incluindo ladrões de credenciais e mineradores de criptomoedas.

Investigação

Huntress identificou atividade suspeita de processo em que clientes ScreenConnect surgiram wscript.exe para executar uma sequência de arquivos VBScript nomeados 1.vbs até 4.vbs. A análise mostrou que os scripts perfilam sistemas infectados, verificam produtos EDR e recuperam cargas encenadas do Dropbox. Clientes ScreenConnect modificados foram então usados para propagar os scripts para hosts recém-conectados.

Mitigação

Os administradores devem monitorar de perto as implantações do ScreenConnect locais e revisar os logs de auditoria em busca de atividades anômalas. Em particular, os defensores devem procurar por RunFiles or RanFiles entradas associadas aos nomes de arquivo VBScript identificados executados a partir do processo Guest . As organizações também devem impor controles rigorosos sobre ferramentas de RMM e utilitários de suporte remoto como Quick Assist.

Resposta

Os hosts afetados devem ser reimaginados usando mídia conhecida ou restaurados por meio de uma instalação limpa do sistema operacional. As equipes de segurança devem revisar imediatamente os logs de auditoria do ScreenConnect para evidências de execução de scripts suspeitos. Qualquer atividade anormal wscript.exe ou atividade do PowerShell ocorrendo após uma conexão RMM também deve ser tratada como um incidente de segurança de alta prioridade.

Execução de Simulação

Pré-requisito: O Check de Pré-voo de Telemetria & Baseline deve ter aprovado.

Justificativa: Esta seção detalha a execução precisa da técnica do adversário (TTP) projetada para acionar a regra de detecção. Os comandos e a narrativa DEVEM refletir diretamente os TTPs identificados e visam gerar a telemetria exata esperada pela lógica de detecção. Exemplos abstratos ou não relacionados levarão a diagnósticos errados.

• Narrativa & Comandos de Ataque: Um adversário obteve acesso inicial a uma estação de trabalho. Para evitar a detecção pelas regras ED básicas que monitoram para execução direta de powershell.exe , eles enviam um arquivo VBScript que utiliza o Windows Script Host integrado. O VBScript é projetado para executar um script PowerShell secundário chamado runner.ps1. Este script é destinado a carregar um módulo de despejo de credenciais na memória. Usando wscript.exe como pai, o invasor tenta se misturar com a atividade administrativa padrão do Windows.

• Script de Teste de Regressão:

  # Crie um arquivo 'runner.ps1' fictício para satisfazer o requisito de string da lógica de detecção
  $dummyScript = "$PSScriptRootrunner.ps1"
  New-Item -Path $dummyScript -ItemType File -Force
  Set-Content -Path $dummyScript -Value "Write-Host 'Simulando Execução de Payload'"
  
  # Crie um VBScript que chama o script PowerShell
  # Isto imita o método do invasor de usar WSH para lançar o PowerShell
  $vbsContent = @"
  Set objShell = CreateObject("WScript.Shell")
  objShell.Run "powershell.exe -ExecutionPolicy Bypass -File ""$dummyScript""", 0, True
  "@
  $vbsFile = "$PSScriptRootlauncher.vbs"
  Set-Content -Path $vbsFile -Value $vbsContent
  
  # Execute o VBScript via wscript.exe para acionar a regra de detecção
  Write-Host "[!] Executando simulação via wscript.exe..."
  Start-Process "wscript.exe" -ArgumentList "`"$vbsFile`""

• Comandos de Limpeza:

  # Remova os artefatos de simulação
  Remove-Item -Path "$PSScriptRootrunner.ps1" -ErrorAction SilentlyContinue
  Remove-Item -Path "$PSScriptRootlauncher.vbs" -ErrorAction SilentlyContinue
  Write-Host "[+] Limpeza concluída."