Logs do Windows expõem realidade de ataques 'sofisticados'
Relatos públicos tendem a descrever campanhas como sequências bem coreografadas de ações. Relatórios baseados em evidências forenses mostram o contrário: invasores testam, erram e adaptam-se — frequentemente de forma desordenada.
Descoberta e escopo
Pesquisadores da Huntress analisaram três incidentes entre novembro e dezembro de 2025 que ilustram como o comportamento real de operadores se afasta da imagem de máquinas perfeitas. As vítimas identificadas no relatório foram descritas genericamente como uma incorporadora residencial, uma empresa manufatureira e uma organização de serviços partilhados. Em todos os casos, a cadeia inicial envolveu vulnerabilidades em aplicações web que executavam sobre Microsoft IIS, permitindo execução remota de comandos via processo do servidor web.
Vetor técnico e ferramentas observadas
Os analistas relataram que os atacantes não usaram web shells tradicionais; em vez disso, exploraram falhas de programação nas próprias páginas da aplicação para injetar e executar comandos. Entre as atividades registradas nos logs do Windows e telemetria EDR havia execução imediata de comandos de enumeração (por exemplo, whoami, netstat), tentativas de download via certutil.exe e transferência/execução de binários com nomes como 815.exe.
Huntress identificou um Trojano escrito em Go chamado agent.exe como componente central em algumas das campanhas, além de variantes e outras ferramentas como SparkRAT. Em várias ocasiões o Windows Defender bloqueou cargas ou deteções de shellcode (por exemplo, identificações do mecanismo como ‘ShellcodeRunner’), e os atacantes adaptaram táticas subsequentes com base nesses bloqueios.
Adaptação observada — erros e reaprendizado
Os logs mostram tentativa de uso de certutil para baixar payloads — técnica conhecida como Living Off The Land — que foi bloqueada em um dos incidentes. Em ataques posteriores, os operadores emitiram comandos PowerShell para adicionar exclusões ao Windows Defender antes de tentar implantar novo malware, por exemplo:
powershell -command Add-MpPreference -ExclusionPath C -ExclusionExtension .exe, .bin, .dll -Force
Essa mudança indica aprendizado a partir de fracassos operacionais: em vez de descartar o acesso, os invasores tentaram contornar controles ajustando o host comprometido. Ainda assim, tentativas de estabelecer persistência via serviços do Windows frequentemente falharam devido a erros de configuração e limitações do sistema — outro ponto evidenciado pelos registros forenses.
Evidências e limites da investigação
- Fonte das descobertas: análise de logs do Windows e telemetria EDR coletada pela Huntress, reportada pelo veículo.
- Artefatos concretos citados: nomes de arquivos (815.exe, agent.exe), ações (uso de certutil, comandos de enumeração), e comandos PowerShell para exclusões do Defender.
- Limitações: o relatório público não detalha indicadores de comprometimento completos, escopo preciso (quantidade de hosts afetados por organização) ou atribuição a um grupo específico.
Implicações para defesa e detecção
Os achados reforçam pontos práticos para equipes de segurança:
- Monitorar logs do IIS e eventos de processo (Process Creation) que seguem imediatamente requisições POST a páginas de login ou endpoints administrativos;
- Correlacionar eventos de EDR com alterações de políticas do Windows Defender (Add-MpPreference) e exclusões impostas por comandos remotos;
- Inspecionar usos de binários legítimos (certutil.exe, PowerShell) seguidos de execuções de arquivos recém-criados no disco — padrão recorrente em tentativas de entrega;
- Auditar configurações de serviços do Windows e alertar para tentativas de criação/alteração de serviços como método de persistência.
Recomendações práticas
Com base no conjunto de técnicas observadas, é razoável priorizar regras de detecção que combinem telemetria de rede e host: sequência POST→processo do IIS invocando comandos do sistema; uso de certutil seguido por execução de binário desconhecido; adição de exclusões do Defender via PowerShell. A documentação do incidente não fornece IOCs completos; equipes que desejarem aplicar bloqueios devem buscar o relatório técnico completo da Huntress para obtenção de hashes, C2s e artefatos adicionais.
Conclusão
O caso reforça que defesa em profundidade e visibilidade de logs são cruciais. Ataques "desorganizados" que falham inicialmente podem ainda evoluir para compromissos persistentes caso os operadores aprendam com as falhas — exatamente o padrão documentado pela Huntress neste conjunto de incidentes.