Incidentes não detectados, ameaças persistentes e desafios de resposta: análise dos projetos do Kaspersky Compromise Assessment

Este artigo apresenta as principais conclusões dos projetos do Kaspersky Compromise Assessment realizados em 2025. O Kaspersky Compromise Assessment é um serviço especializado e independente voltado para a identificação de indicadores de comprometimento nas redes corporativas. No escopo desse serviço, analisamos dados de ameaças (incluindo informações provenientes de diversas fontes na dark web), realizamos a varredura de endpoints com ferramentas especializadas e executamos uma análise abrangente dos logs de eventos de segurança e do tráfego de rede. Quando necessário, também conduzimos a resposta inicial a incidentes e a análise forense.

O relatório aborda incidentes que passaram despercebidos por semanas, meses ou até anos.

Principais tendências identificadas nos projetos concluídos do Kaspersky Compromise Assessment

• A busca por ameaças realizada no âmbito da avaliação de comprometimento (compromise assessment) ajuda a reduzir o número de incidentes de alta criticidade que passam despercebidos. A maior proporção desses incidentes foi identificada em organizações que solicitaram esse serviço após a contenção de um incidente de segurança já conhecido. Em contrapartida, a menor proporção de incidentes de alta criticidade foi observada em organizações que realizavam auditorias de segurança regularmente. Do total de incidentes analisados, 20% foram detectados por meio de análise manual, enquanto cerca de 60% deles não foram detectados pelas organizações devido à ausência de alertas confiáveis nas soluções de proteção em uso.
• Quase um terço dos incidentes registrados foi identificado mais de três meses após a intrusão inicial. Quanto mais tempo a ameaça permanecia no ambiente-alvo, maior era a probabilidade do incidente ter alta criticidade. Em 30,8% dos casos, foram encontrados indicadores de atividade dos invasores com duração superior a três meses e, entre as infecções de alta criticidade, essa proporção chegou a 52%. O incidente mais antigo identificado por nós em 2025 havia permanecido sem detecção por quatro anos.
• Não é raro que arquivos maliciosos permaneçam nos backups e sejam restaurados após a adoção das medidas de resposta ao incidente. Assim, 40% dos web shells detectados estavam em backups e permaneceram sem detecção até a realização de uma busca completa de indicadores de comprometimento.
• Os invasores preferem ferramentas de acesso remoto e programas legítimos já instalados (conhecidos como LOLBins). Esse tipo de ferramenta foi utilizado em todos os incidentes detectados na busca por indicadores de comprometimento.
• Ter ferramentas de monitoramento e proteção não é suficiente por si só: a maturidade dos processos operacionais é um fator decisivo. As soluções de monitoramento precisam ser configuradas corretamente e adaptadas ao cenário de ameaças, que muda constantemente. Além disso, os alertas com baixo nível de confiança devem ser analisados por especialistas. A ausência de monitoramento contínuo e de busca ativa por ameaças elevava a probabilidade de incidentes de criticidade média e alta para 84% a 86%. Em contrapartida, os incidentes de alta criticidade eram menos frequentes em organizações cujas equipes tinham competências de engenharia reversa de malware.
• Falhas de comunicação levam à omissão de incidentes. Quase um terço das avaliações de comprometimento realizadas revelou falhas de comunicação que afetaram a eficácia das medidas de resposta a incidentes.
• Playbooks de resposta a incidentes precisam ser flexíveis. Para que a resposta seja eficaz, é necessário revisá-los regularmente à medida que surgem novos artefatos. Ao atualizar constantemente o plano de resposta, as organizações reduzem a probabilidade de não detectar ameaças.

Perfil dos clientes do Kaspersky Compromise Assessment

Nosso serviço de busca por indicadores de comprometimento é utilizado por empresas de diferentes países. Cerca de 71% dos incidentes identificados em 2025 corresponderam a clientes da região META (Oriente Médio, Turquia e África); os 29% restantes dividiram-se entre a região Ásia-Pacífico e à Comunidade dos Estados Independentes (CEI).

Distribuição geográfica dos incidentes identificados em 2025 nos projetos de busca por indicadores de comprometimento (download)

Recebemos solicitações de organizações de diversos setores econômicos. O setor governamental concentrou 29% dos incidentes, seguido pelo setor educacional (19%) e pelo setor financeiro (17%).

Distribuição dos incidentes identificados em 2025 nos projetos de busca por indicadores de comprometimento, por setor econômico (download)

Categorias de indicadores de ataque

O serviço Kaspersky Compromise Assessment baseia-se em um catálogo de indicadores de ataque (IoA) atualizado constantemente. Como a lista completa de IoAs é detalhada demais para um relatório geral, nós a agrupamos em um conjunto limitado de famílias de lógicas de detecção. De acordo com as estatísticas, três famílias predominam entre os incidentes:

• credenciais extraídas de dumps, com 12,4% de todos os incidentes;
• utilitários LOLBin específicos, com 11,2%;
• famílias específicas de malware, com 11,2%.

Essas três famílias são indicadores confiáveis e altamente precisos de comprometimento de uma infraestrutura, abrangendo desde ameaças de arquivos inativas até ataques multiestágio com persistência no sistema.

Distribuição das famílias de lógicas de detecção (download)

Motivos da contratação do serviço Kaspersky Compromise Assessment

A análise dos projetos de busca por indicadores de comprometimento realizados em 2025 revelou uma correlação clara entre os motivos declarados para a contratação dos nossos especialistas e o perfil de risco identificado. Na maioria dos casos, as organizações contratam o serviço no âmbito de uma auditoria planejada (56%), seguida da elaboração de relatórios para órgãos reguladores (19%), da auditoria após um incidente de segurança (17%) e da aquisição de uma nova empresa (9%).

Estatísticas sobre os motivos da contratação do serviço de busca por indicadores de comprometimento (download)

Ao correlacionar os motivos da solicitação do serviço com a criticidade dos incidentes detectados, observa-se que a maior proporção de incidentes de alta criticidade (40,7%) corresponde às organizações que solicitaram o serviço após um incidente. Uma análise mais detalhada é apresentada a seguir.

Empresas que sofrem incidentes geralmente nos procuram após a adoção das primeiras medidas de resposta. A elevada proporção de incidentes de alta criticidade detectados indica que as medidas de resposta, geralmente concentradas em conter as consequências de um incidente conhecido, não oferecem uma visão abrangente do estado da infraestrutura. Como resultado, as ameaças podem permanecer sem detecção após essas medidas até que uma busca por indicadores de comprometimento em larga escala seja realizada.

Em fusões e aquisições, somos acionados para avaliar a rede da organização adquirida em busca por ameaças ocultas antes da integração dos dois ambientes. Nesses casos, o panorama de riscos é equilibrado: 28,6% dos achados correspondem a incidentes de baixa criticidade, 42,8% a incidentes de média criticidade e 28,6% a incidentes de alta criticidade. Isso indica um perfil de risco misto nas infraestruturas adquiridas, que costumam ser verificadas tanto em relação a vulnerabilidades conhecidas quanto a atividades maliciosas ocultas. Outras categorias de solicitações preventivas, como auditorias planejadas e a elaboração periódica de relatórios para órgãos reguladores, apresentam distribuição semelhante, o que indica que a busca regular de indicadores de comprometimento ajuda a identificar problemas graves nos estágios iniciais do ciclo de vida do ataque, reduzindo a probabilidade de evolução para incidentes de alta criticidade.

A maior proporção de incidentes de baixa criticidade (36%) e a menor proporção de incidentes de alta criticidade (28%) foram observadas em organizações que realizavam auditorias regularmente. Conclui-se, com moderado grau de confiança, que a busca proativa e regular de ameaças é mais eficaz na redução da probabilidade de incidentes críticos do que a busca reativa pós-incidente. As estatísticas de 2025 confirmam nossa hipótese. Isso significa que integrar aos processos de gestão uma busca regular de indicadores de comprometimento, conduzida por especialistas independentes, pode reduzir a probabilidade de incidentes inesperados de alta criticidade e diminuir o nível geral de risco.

Para ilustrar as diferenças entre as abordagens reativa e proativa, veja o exemplo a seguir de nossa prática, no qual uma ameaça persistente permaneceu “inativa” na rede do cliente e só foi detectada durante uma busca abrangente de indicadores de comprometimento realizada após a aplicação das medidas de resposta iniciais.

Estudo de caso: ameaça “inativa” detectada somente após busca por indicadores de comprometimento

Uma empresa de médio porte sofreu um incidente de alta criticidade. A equipe interna de resposta conseguiu conter e remediar a ameaça utilizando o conhecimento disponível no momento do alerta inicial. Após a contenção do incidente, a organização decidiu verificar se não havia focos adicionais de comprometimento na rede. Para isso, contratou os especialistas do Kaspersky Compromise Assessment, que realizaram uma análise forense em larga escala da infraestrutura, indo além do escopo do incidente inicial.

Nossos especialistas coletaram metadados forenses, logs de eventos de segurança e configurações do Active Directory em toda a infraestrutura. Após consolidar a telemetria obtida, realizaram uma busca por ameaças nesses dados por meio de diversas consultas focadas em indicadores de persistência, propagação na rede e atividade anômala de processos. Como resultado, foram identificadas e documentadas várias ameaças graves, incluindo os seguintes mecanismos de persistência no sistema:

1. Tarefa cron que baixa web shell
   Em um servidor web Linux crítico, foi detectada uma tarefa cron configurada para baixar automaticamente uma cópia de um web shell em PHP de um repositório público no GitHub e armazená-la em um diretório acessível via internet. Mesmo quando o arquivo malicioso era removido pela equipe de segurança, a tarefa cron o baixava novamente, garantindo aos invasores persistência estável no servidor web e a possibilidade de execução remota de código.
   
2. Reverse shell ativo
   No servidor em que a aplicação web estava hospedada, foi detectado na lista de processos um reverse shell ativo implementado via Bash.
   
   Ele era executado pelo usuário apache, a mesma conta usada para executar a aplicação web. Provavelmente, o invasor explorou uma vulnerabilidade da aplicação web para obter execução remota de código e estabelecer um canal de controle confiável capaz de contornar o firewall, já que a conexão era iniciada de dentro da rede.
3. Stealer ClipBanker com persistência via registro do Windows
   Na estação de trabalho de um usuário, foi detectada uma variante do stealer ClipBanker que se mantinha no sistema por meio da chave de registro HKU\S-1-5-21-[OCULTO]-500\Software\Microsoft\Windows\CurrentVersion\Run\9Er6IIp.
   
   Antes de estabelecer a persistência, a pasta com o malware foi adicionada às exclusões do Windows Defender, e os atributos “oculto” e “sistema” foram aplicados ao arquivo para evitar detecção por usuários comuns.
   
   
4. Consumidor de eventos WMI malicioso com falsificação de nome de exibição
   Também foi detectado um consumidor de eventos WMI malicioso que baixava e executava um script PowerShell. Esse consumidor criava o nome de exibição “kaspersky” para o comando Invoke-Expression, mascarando sua atividade como legítima e reduzindo a chance de detecção em uma análise superficial. O script baixado (atualmente inacessível), conforme confirmado pelos especialistas do Kaspersky Threat Intelligence, continha uma carga maliciosa responsável por propagar ainda mais a infecção.
   

A resposta concentrou-se na contenção rápida e eficaz do incidente específico que acionou o alerta. No entanto, a busca por indicadores de comprometimento em maior escala revelou múltiplos backdoors no ambiente, cada um com sua própria técnica de persistência: tarefas cron, execução programada via registro e assinaturas WMI. Os hosts infectados não estavam cobertos pela resposta inicial, portanto as ameaças associadas a eles permaneceram sem detecção até que uma análise em larga escala fosse realizada.

A prioridade dos especialistas em resposta a incidentes é eliminar rapidamente a ameaça evidente para garantir a continuidade dos processos corporativos após o incidente identificado. Já a busca por indicadores de comprometimento é uma verificação abrangente que permite identificar até mesmo indicadores de infecção ocultos e pouco evidentes, onde quer que estejam. Quando a resposta ágil é complementada por uma busca ativa por ameaças em toda a rede, a organização alcança tanto a contenção reativa de incidentes quanto a eliminação proativa de indicadores ocultos de atividade maliciosa. A análise realizada possibilitou identificar pontos de apoio adicionais dos invasores, aumentar a visibilidade da infraestrutura e reduzir a probabilidade de um novo incidente.

Incidentes antigos não detectados

Muitos incidentes permanecem sem detecção por longos períodos, como demonstram as estatísticas de tempo médio de detecção (MTTD) dos incidentes nos projetos de busca por ameaças. Em 2025, por exemplo, identificamos um incidente que havia permanecido sem detecção por aproximadamente quatro anos.

Em 30,8% dos casos, os indicadores de comprometimento abrangiam um período superior a três meses. Um período de exposição tão prolongado pode ter consequências graves para a organização. Além disso, a diversidade desses incidentes, que variam desde ameaças de arquivos inativas até comprometimentos persistentes, reforça a necessidade de mecanismos robustos de detecção e resposta.

Distribuição de incidentes por criticidade em função do MTTD (download)

Para analisar a relação entre a demora na detecção e a criticidade dos incidentes, agrupamos os resultados de acordo com o MTTD.

• Nos incidentes detectados durante o primeiro mês, o nível de criticidade se distribui de forma relativamente uniforme entre as categorias baixa, média e alta.
• À medida que o MTTD aumenta, observa-se um deslocamento em direção a uma criticidade mais alta. Destaca-se que a maioria dos incidentes detectados entre 30 e 60 dias após o comprometimento corresponde à categoria de criticidade média (78,57%), enquanto os incidentes com tempo de detecção entre 60 e 90 dias são predominantemente de alta criticidade (71,43%).
• Entre os incidentes identificados depois de mais de 90 dias, os casos de alta criticidade também representam uma proporção significativa (52%).

No geral, 52% de todos os incidentes de alta criticidade só são detectados após 90 dias de presença sem detecção. O risco é evidente: quanto maior a demora na detecção, maior a probabilidade de comprometimento grave. As organizações que implementam monitoramento contínuo, práticas de busca ativa por ameaças e busca regular por indicadores de comprometimento podem reduzir o MTTD, limitar a progressão dos ataques e diminuir o nível geral de risco.

O exemplo a seguir, de nossa prática, demonstra a importância da detecção e da resposta ágeis para evitar que um incidente atinja a categoria de alta criticidade.

Estudo de caso: quatro anos de mineração oculta de criptomoedas em controladores de domínio

Em maio de 2025, especialistas em busca por ameaças identificaram que três controladores de domínio na rede do cliente estavam infectados com arquivos maliciosos que permaneceram sem detecção por quase quatro anos. Esses arquivos maliciosos estavam ocultos na pasta C:\Windows\Fonts\Mysql, na qual usuários comuns visualizam apenas arquivos de fontes. No local, foram encontrados arquivos com os nomes nei.bat, dl1host.exe, bat.bat e cmd.bat, além de um svchost.exe falsificado, criados entre junho e julho de 2021.

Segundo dados do Kaspersky Threat Intelligence, esses arquivos estão vinculados a uma campanha de cryptojacking chamada NSABuffMiner. O malware correspondente se propaga pelo protocolo SMB explorando a vulnerabilidade EternalBlue (MS17-010). O patch para essa vulnerabilidade foi disponibilizado em março de 2017, quatro anos antes do comprometimento inicial; ou seja, houve tempo mais do que suficiente para atualizar os sistemas. Esse caso reforça a importância de processos bem estruturados de gerenciamento de patches e do monitoramento de feeds de dados sobre ameaças.

A pedido do cliente, os arquivos maliciosos foram coletados juntamente com a imagem do sistema para uma posterior análise forense, a qual revelou o seguinte:

• Os arquivos bat.bat e cmd.bat geram endereços IP de forma aleatória e os escaneiam por meio de um scanner de portas leve, renomeado como taskhost.exe, para identificar hosts ativos e vulneráveis com as portas SMB 445 e NetBIOS 139 abertas.
• Os endereços IP vulneráveis identificados são repassados aos scripts auxiliares poad.bat, poab.bat, load.bat e loab.bat, que executam os componentes maliciosos mance.exe, Eter.exe e puls.exe. Esses componentes injetam as bibliotecas DLL maliciosas Eternalblue2.dll e Doublepulsar2.dll nos processos lsass.exe e explorer.exe para viabilizar o mecanismo de propagação adicional.
• Em seguida, para obter persistência no sistema, são criadas tarefas agendadas que executam os scripts de propagação e infecção, além de serviços que iniciam o criptominerador. Essas tarefas e serviços são chamados de MicrosoftMysql, MicrosoftFonts e MicrosoftMSSql. No agendador também foram encontradas tarefas com os nomes At1 e At2, criadas com o mesmo propósito.
• Após o comprometimento e a instalação dos mecanismos de persistência, um procedimento de limpeza remove os arquivos temporários e os componentes maliciosos do disco.

Devido à ausência de procedimentos adequados de monitoramento e busca por ameaças, a organização não sabia que, durante quatro anos, os invasores estiveram minerando criptomoedas em seus controladores de domínio.

Preservação não intencional de componentes maliciosos

Durante a busca por ameaças, frequentemente encontramos web shells que persistem nos sistemas ou são restaurados na infraestrutura-alvo. De acordo com os dados registrados pelo serviço Compromise Assessment em 2025, 64% dos incidentes com web shells foram classificados como de alta criticidade, 7% como de baixa criticidade (nesse caso há possibilidade de comprometimento, embora os arquivos identificados também possam ser legítimos) e 29% como de criticidade média (nesse caso, os arquivos precisam ser removidos).

Distribuição de incidentes com web shells por nível de criticidade (download)

Uma das formas dos web shells persistirem no sistema é a infecção dos backups. Segundo as estatísticas dos incidentes identificados em nossos projetos, 60% dos web shells foram encontrados em sistemas ativos e 40% em backups. A restauração desses backups pode acarretar o recomprometimento do ambiente muito tempo após a infecção original.

Localização dos web shells (download)

Outro problema frequente são as deficiências no inventário de ativos, observadas em 25% dos casos. Trata-se de sistemas não cadastrados, incluindo servidores Linux em nuvem fora do Active Directory, que ficam invisíveis para os mecanismos de varredura padrão.

Problemas com inventário de ativos (download)

Invasores podem implantar web shells em servidores em nuvem ausentes nos inventários, mas dos quais são feitos backups regularmente. Como resultado, o web shell pode permanecer nesse servidor por muito tempo e, mesmo que seja removido em algum momento, o servidor de backup restaurará posteriormente os arquivos infectados, tornando o web shell acessível novamente a partir do exterior. Isso evidencia que, sem um inventário de ativos completo e atualizado, as capacidades de detecção e resposta ficam significativamente limitadas.

Em um dos casos, o web shell estava oculto em um servidor de arquivos interno (e não em um servidor web) dentro de um arquivo RAR, no seguinte caminho: D:\backup\[OCULTO].rar/wwwroot/<…>/[OCULTO].aspx.

Durante a investigação, os administradores do servidor informaram que a pasta havia sido copiada de um servidor web desligado no momento da busca por ameaças. Devido a um inventário de ativos incompleto, a equipe interna de segurança não detectou o comprometimento do servidor web e, após a execução dos procedimentos de backup, o web shell acabou sendo transferido para o servidor de arquivos interno. A análise forense do servidor web desligado mostrou que os invasores implantaram backdoors na maioria dos servidores Windows da infraestrutura, configurando neles contas de administrador local com a mesma senha.

Durante o ataque, os invasores executaram via PsExec, em todos os servidores listados em um arquivo TXT, um script CMD que alterava a senha da conta de administrador local para o valor indicado no script:

Legítimos, mas suspeitos: ferramentas de administração remota e utilitários LOLBin

Em 2025, em todos os projetos de busca por indicadores de comprometimento, identificamos o uso de ferramentas de administração remota não padronizadas. Além disso, em todos os projetos foram encontrados arquivos executáveis legítimos que podem ser usados com fins maliciosos (living-off-the-land binaries, LOLBins). A presença de ambos os elementos dificulta a detecção por parte dos centros de operações de segurança e resposta (SOC), que precisam diferenciar a administração legítima de atividades maliciosas.

Entre as ferramentas de administração remota, foram identificadas diversas plataformas proprietárias, como TeamViewer e AnyDesk, além de soluções de distribuição gratuita, incluindo PsExec, servidores VNC e frameworks de código aberto. Em muitos ambientes, esses executáveis são usados diariamente para resolução de problemas, implantação de software e suporte remoto. No entanto, essas mesmas ações (criar novas contas administrativas locais, copiar arquivos para recursos remotos, executar varreduras de portas de rede) também são realizadas pelos invasores após o comprometimento. Nossos analistas frequentemente encontram situações em que ações legítimas de administradores se confundem com tentativas de movimentação lateral na infraestrutura, portanto o simples fato de usar uma ferramenta de acesso remoto não basta para vincular essa atividade a um incidente. Nesses casos, o comportamento deve ser avaliado em relação ao perfil de referência de uso da ferramenta na organização específica. Construir esse perfil exige compreensão contextual profunda sobre quem está autorizado a usar a ferramenta, a partir de quais endpoints e sob quais condições. Trata-se de um processo trabalhoso, que exige uma abordagem individualizada.

Os utilitários LOLBin integrados ao sistema operacional ou frequentemente instalados pelos usuários, como certutil, bitsadmin, regsvr32 e wmic, também apareceram regularmente em incidentes de todos os projetos. Embora sejam componentes de sistema confiáveis, de acordo com nossos dados de inteligência de ameaças, eles costumam ser utilizados por invasores para propagação adicional, exfiltração de dados e persistência no sistema. A distribuição por criticidade dos incidentes nos quais foram usados programas indesejados (riskware) ou utilitários LOLBin é apresentada no gráfico abaixo. A proporção relativamente alta de incidentes de criticidade média (40%) e alta (31%) evidencia que o uso de utilitários legítimos costuma ser um vetor-chave que permite aos invasores expandir o ataque além do ponto de apoio inicial.

Distribuição por criticidade dos incidentes em que foram utilizados softwares indesejados ou legítimos em 2025 (download)

Para identificar o possível uso de utilitários LOLBin e ferramentas de administração remota por parte de invasores, recomendamos adotar uma abordagem em várias camadas, consideravelmente mais eficaz do que as listas estáticas de aplicativos bloqueados:

1. Elabore uma política que liste as ferramentas de administração remota autorizadas. Recomendamos aplicá-la em conjunto com o envio obrigatório de logs desses programas a um SIEM ou agregador de logs dedicado. O monitoramento contínuo desses dados permite ao SOC identificar desvios em relação aos perfis padrão de uso autorizado.
2. Realize inventários periódicos de software para identificar ferramentas de administração remota não autorizadas. Sempre que possível, colete dados das seguintes chaves de registro em todos os hosts:
   • HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
3. Enriqueça os hashes (MD5/SHA-256) de cada executável com uma categoria funcional, como “Acesso remoto”, “Imagem de referência” ou “Software de proteção”. Correlacionar a categoria ao caminho de execução permite identificar executáveis iniciados em locais atípicos, por exemplo, um programa da categoria “Acesso remoto” executado a partir de %TEMP% ou da pasta de downloads do usuário.
4. Implemente regras de detecção baseadas em padrões conhecidos de abuso de utilitários LOLBin, como certutil -decode, bitsadmin -transfer, regsvr32 -i <dll> e wmic process call create. Essas regras devem ser sempre comparadas a um perfil de referência da atividade normal do utilitário na organização, construído com base em uso legítimo verificado. Quando surgem novos casos de uso legítimo, esse perfil deve ser atualizado. Os alertas devem ser gerados somente quando o comportamento observado se desvia da norma estabelecida, o que reduz o ruído nos alertas sem perder a sensibilidade a ameaças reais.

Ausência de monitoramento contínuo e de busca proativa por ameaças

A análise de projetos recentes de busca por indicadores de comprometimento revelou um ponto cego sistemático em organizações que estruturam sua proteção pelo princípio de “comprar e esquecer”. Na ausência de monitoramento contínuo conduzido por especialistas ou programa dedicado de busca por ameaças, o nível de criticidade dos incidentes detectados desloca-se acentuadamente para valores mais altos:

Frequentemente, o problema não está na falta de ferramentas, mas no uso ineficiente delas. Muitas organizações implementam soluções de segurança modernas, mas as operam no modelo “configurar e esquecer” ou estruturam seus processos exclusivamente em torno da resposta a alertas. Essas organizações costumam apresentar os seguintes problemas:

• Fadiga de alertas: uma alta taxa de falsos positivos reduz a atenção dos analistas, levando-os a conduzir a triagem de eventos com base em indicadores superficiais em vez de realizar uma investigação aprofundada e contextualizada.
• Distribuição fragmentada de tarefas: sem uma equipe dedicada à busca ativa por ameaças, um mesmo analista pode receber dezenas de alertas não relacionados entre si, o que limita o tempo disponível para formular e verificar as hipóteses necessárias para identificar pontos de acesso ocultos dos invasores.

Na prática, isso faz com que os invasores permaneçam mais tempo no sistema e possam se mover lateralmente e exfiltrar dados antes que a organização perceba a violação. Trata-se de um risco mensurável que gera consequências negativas diretas para o negócio. O exemplo a seguir mostra que implementar uma solução de proteção não garante, por si só, a detecção de ameaças. Ele reforça a importância do monitoramento contínuo, da validação periódica de alertas e de uma busca por ameaças estruturada para reduzir o tempo de permanência dos invasores na rede e minimizar o impacto no negócio.

Estudo de caso: um ambiente “seguro por design” sem monitoramento contínuo

A empresa havia adquirido soluções de segurança e, após implantá-las, presumiu que seu ambiente agora estava “seguro por design” (secure by design). No entanto, os controles de segurança só são eficazes se estiverem configurados corretamente, forem ajustados continuamente durante a operação e contarem com monitoramento ativo. As soluções estavam implantadas, mas sem supervisão de configuração, revisão de alertas por analistas ou procedimento agendado de revisão de logs.

Quando a organização decidiu recorrer ao serviço Compromise Assessment, os especialistas da Kaspersky coletaram e analisaram os logs de eventos de segurança. O objetivo era simples: determinar o que realmente havia acontecido na rede nos últimos meses.

Os logs continham indicadores claros de atividade maliciosa. Em particular, foram detectados vestígios do uso do Impacket para implantar o Cobalt Strike e do uso do Mimikatz em vários servidores críticos, incluindo os controladores de domínio. Todas essas ações ocorreram três meses antes da detecção, e a empresa não tinha ciência delas devido à falta de monitoramento ininterrupto eficaz.

O Impacket é um conjunto de scripts Python para interação de baixo nível com protocolos e pacotes de rede, frequentemente usado por invasores para propagação. Veja a seguir um exemplo dos artefatos do Impacket detectados na rede:

Por meio do Impacket, os invasores executaram um comando do PowerShell que baixou um executável de um servidor de comando e controle remoto. Esse servidor estava associado à infraestrutura do Cobalt Strike. O Cobalt Strike é usado pelos invasores na etapa pós-comprometimento e oferece recursos de execução remota de comandos e movimentação dentro da rede comprometida. A execução foi orquestrada por uma tarefa agendada disfarçada de atualização legítima do Google Chrome.

A análise da cronologia dos eventos também confirmou a presença, no sistema comprometido, de um binário do Mimikatz e um dump de memória vinculados ao mesmo incidente, confirmando o roubo de credenciais.

A organização não suspeitava do comprometimento. A atividade maliciosa passou despercebida por três meses porque ninguém monitorava os controles de segurança implementados. Ao tomar conhecimento dos resultados da avaliação, a organização iniciou medidas de resposta a incidentes em larga escala para eliminar os pontos de presença dos invasores, rotacionar as credenciais e reforçar a segurança da infraestrutura.

Os controles de segurança não são autossuficientes: instalar um firewall ou uma solução EDR não garante proteção automática. Sem a configuração correta, sem a criação e a manutenção de um perfil de referência de atividade e, sobretudo, sem o monitoramento contínuo de logs e busca ativa por ameaças, esses controles podem ser inúteis. O monitoramento contínuo — próprio ou terceirizado — com correlação de eventos, identificação de uso anômalo de ferramentas de pentest (testes de intrusão) e utilitários de hacking, além da investigação de outras atividades suspeitas, pode ser o fator decisivo entre um incidente se transformar em um comprometimento prolongado ou ser detectado em questão de minutos.

Estatísticas de resposta a incidentes

Análises de projetos anteriores de busca por ameaças mostram que frequentemente existe uma lacuna entre playbooks de resposta baseados em melhores práticas e sua aplicação real em ambientes despreparados, especialmente quando há sistemas legados. O gráfico a seguir mostra a frequência com que cada ação foi aplicada durante a etapa inicial da resposta a incidentes, com base nos resultados da busca por indicadores de comprometimento.

Medidas de resposta aplicadas ao detectar incidentes durante a busca por indicadores de comprometimento (download)

Nessa distribuição, destacam-se claramente três ações, por serem as mais frequentes:

• a análise forense, que foi realizada na maioria dos incidentes, com a coleta e análise de pelo menos um conjunto de dados forenses em cerca de 59% dos casos;
• a remoção remota de malware, como arquivos ou chaves de registro, que foi aplicada em 39% dos casos;
• a revisão do plano de resposta, que foi adotada durante a investigação em 39% dos projetos, o que reflete a natureza iterativa do processo.

Por que a resposta costuma começar pela coleta de dados forenses

A coleta e a análise de conjuntos de dados forenses foram a etapa de resposta mais frequente, necessária em 59% dos casos. Isso se explica por dois fatores típicos desses projetos de busca por ameaças: 1) a disponibilidade limitada de eventos históricos nas organizações analisadas e 2) o fato de que boa parte dos incidentes havia ocorrido mais de 90 dias antes do início da busca por ameaças. Em muitos casos, os logs de eventos padrão já haviam sido sobrescritos ou perdidos, o que obrigava os investigadores a reconstruir a cronologia dos eventos a partir de artefatos residuais, como entradas da MFT, hives de registro e timestamps do sistema de arquivos.

Nossas observações indicam que a coleta remota de dados forenses é um pré-requisito, e não uma mera conveniência. O gráfico a seguir apresenta um resumo da capacidade das organizações de coletar remotamente conjuntos de dados forenses, segmentado pelo nível de criticidade dos incidentes. Os dados mostram que, em uma proporção considerável dos casos de alta criticidade, as organizações não tinham essa capacidade.

Capacidade das organizações de coletar dados forenses remotamente, segmentada por criticidade do incidente (download)

Contenção da ameaça: dificuldades na remoção correta de arquivos e chaves de registro

Medidas de neutralização de ameaças, como remoção de arquivos ou chaves de registro (necessárias em 39% dos casos), são uma etapa importante da resposta; contudo, sua implementação prática nas organizações frequentemente era insuficiente. Embora muitos clientes afirmassem ter capacidade de remoção remota via EDR, na prática essas operações eram delegadas a equipes de TI ou MSPs por sistemas de tickets, o que podia gerar atrasos e reduzir a qualidade do resultado. A remoção de malware exige precisão cirúrgica, especialmente em cenários multiestágio, sem arquivo ou com persistência profunda. Para que a erradicação seja completa e ágil, a capacidade técnica precisa estar combinada com conhecimento especializado, planejamento claro e execução criteriosa. Isso é especialmente relevante, já que os artefatos podem estar ocultos em cópias de sombra e backups, diretórios ocultos ou cadeias de downloaders.

Falhas de comunicação como fator de sobrecarga operacional adicional

Um achado relevante refere-se à comunicação. Em 32% dos projetos, problemas de comunicação interna da organização afetaram significativamente o processo de resposta. Os exemplos mais típicos incluíram:

• confirmação ambígua de ações: administradores de sistemas não conseguiam determinar rapidamente a legitimidade de arquivos suspeitos;
• atrasos na validação por parte dos responsáveis pelos sistemas: o processamento de incidentes ficava mais lento à espera de resposta dos responsáveis pelos sistemas;
• canais de comunicação comprometidos: contas de e-mail e portais de suporte também poderiam estar sob controle dos invasores quando havia suspeita de comprometimento do domínio;
• rotatividade de profissionais: a saída de colaboradores causava perda de conhecimento sobre as configurações base anteriores.

Isso reforça a necessidade de simulações práticas regulares (tabletop exercises), que permitam testar não apenas o aspecto técnico dos playbooks de resposta, mas também a interação entre os participantes do processo, além de verificar o cumprimento dos acordos de nível operacional (OLA) que regem a interação entre equipes e dos procedimentos operacionais padrão (SOP) usados para a documentação adequada.

Atualização iterativa do plano de resposta

Em 39% dos casos, os planos de resposta precisaram de ajustes com base em novos dados analíticos. Essa observação confirma a premissa de que a resposta a incidentes é, por natureza, um processo iterativo. Planos iniciais não conseguem contemplar todos os fatores que influenciam a resposta. A seguir estão as causas mais frequentes de revisão do plano de resposta:

• identificação de servidores de C2 previamente desconhecidos ou de novos padrões de comportamento a partir da engenharia reversa;
• novos achados forenses, como tarefas agendadas ocultas, artefatos em cópias de sombra e DLLs dormentes;
• identificação de caminhos adicionais de movimentação lateral a partir da análise do tráfego de rede;
• fator humano: indisponibilidade de responsáveis por sistemas, mudanças em processos de gestão ou espera por decisões da liderança.

A experiência mostra que tratar o plano de resposta como documento vivo (atualizando-o regularmente com novos artefatos, revisando as prioridades das ações e atualizando-o antes de cada etapa de contenção da ameaça) reduz o risco de deixar passar medidas críticas de erradicação. Por outro lado, seguir rigidamente o plano inicial, elaborado com um volume limitado de dados forenses, aumenta a probabilidade de que determinados pontos de persistência dos invasores passem despercebidos.

Distinção entre artefatos de ataques reais e vestígios de testes de intrusão

Por fim, outro problema persistente (12% dos casos) é a dificuldade de distinguir atividade de invasores de artefatos de pentests legítimos. Durante a busca por ameaças, vestígios de ferramentas legítimas são frequentemente encontrados, e nem sempre é possível determinar com certeza se um artefato específico está relacionado a uma intrusão real ou a um pentest autorizado. Os principais fatores que dificultam essa distinção são os seguintes:

• relatórios de pentest insuficientemente documentados e limpeza incompleta de artefatos nos sistemas;
• uso das mesmas ferramentas (por exemplo, SharpHound) tanto pelos especialistas em pentest quanto pelos invasores reais;
• realização simultânea de busca por ameaças e pentest ativo, o que dispersa a atenção dos analistas e aumenta o número de falsos positivos.

Embora seja fundamental cotejar os resultados da busca por indicadores de comprometimento com os relatórios de pentest, deve-se considerar que a busca por ameaças é um processo investigativo conduzido sob supervisão de analistas. Os artefatos gerados durante a simulação de ataques em um pentest podem induzir os analistas a erro, causando interpretação incorreta dos dados e reduzindo a eficácia da busca por indicadores de comprometimento.

Competências de resposta e seu impacto na criticidade dos incidentes

Nossos dados indicam a existência de uma correlação entre competências internas em análise forense digital e engenharia reversa de malware e a distribuição dos níveis de criticidade dos incidentes. Nos projetos de busca por indicadores de comprometimento realizados em 2025, a proporção de incidentes de baixa, média e alta criticidade diferiu notavelmente entre as organizações que possuíam essas competências e as que não possuíam. Os dados apresentados a seguir ilustram essa correlação e podem ajudar a avaliar o valor corporativo do desenvolvimento dessas capacidades internamente.

Gravidade dos incidentes que exigem análise forense, de acordo com a disponibilidade dessa capacidade na organização (download)

Organizações com capacidade própria de análise forense digital tiveram metade dos incidentes críticos e uma proporção maior de incidentes de baixa e média criticidade.

Gravidade dos incidentes que exigem análise de malware, de acordo com a disponibilidade dessa capacidade na organização (download)

Em nossa amostra, organizações com especialistas dedicados em engenharia reversa de malware não registraram incidentes críticos. A maioria dos incidentes pertencia à categoria média. Também foi observada uma quantidade maior de incidentes de baixa criticidade.

A análise dessas estatísticas permite inferir, com grau moderado de confiança, que a disparidade no perfil dos incidentes não decorre do tamanho da amostragem, mas reflete um impacto operacional real: as competências internas em análise forense digital e engenharia reversa de malware influenciam não apenas a eficiência do SOC, mas a resiliência cibernética global da organização.

Estudo de caso: malware LionTail operando em memória em servidores Windows críticos

Em um dos projetos de busca por indicadores de comprometimento, foi identificada uma ameaça persistente presente na memória RAM de vários servidores críticos. Essa ameaça estava associada ao framework LionTail, um conjunto sofisticado de loaders personalizados e implantes residentes baseados em shellcode. O LionTail explora recursos não documentados do driver HTTP.sys do Windows para entregar cargas maliciosas de forma furtiva por meio do tráfego HTTP de entrada, camuflando a atividade maliciosa como fluxos de rede legítimos.

Diversos exemplares detectados foram associados ao grupo Scarred Manticore, que cria um implante exclusivo para cada host comprometido e exfiltra dados, camuflando cuidadosamente as comunicações com os servidores de comando e controle como tráfego de rede comum.

A ameaça foi detectada por assinatura estática na memória RAM, no processo scrcons.exe. Embora scrcons.exe seja um executável legítimo do WMI localizado em C:\Windows\System32\wbem, invasores costumam injetar cargas maliciosas nesse processo, o que lhes permite executar código em memória sem chamar atenção.