Percepções de projetos de avaliação de comprometimento

Incidentes não detectados, ameaças persistentes e lacunas de resposta: percepções de projetos de avaliação de comprometimento.

A análise a seguir apresenta as principais conclusões das avaliações de comprometimento da Kaspersky realizadas em 2025. Uma avaliação de comprometimento é um serviço independente, conduzido por especialistas, que examina se uma rede alvo foi comprometida. O serviço combina análise de inteligência de ameaças (incluindo fontes da darknet), varredura de endpoints com auxílio de ferramentas, revisão sistemática de logs de eventos de segurança e tráfego de rede e, quando necessário, resposta inicial a incidentes e investigação forense digital.

Este relatório centra-se em incidentes não detetados – ameaças que permaneceram indetectadas durante semanas, meses ou mesmo anos.

Principais tendências observadas durante as avaliações de compromisso

• A avaliação proativa de comprometimento reduz o número de incidentes de alta gravidade não detectados. As maiores proporções de incidentes de alta gravidade foram identificadas em organizações que solicitaram nosso serviço de avaliação de comprometimento após conterem um incidente conhecido. As menores proporções de incidentes de alta gravidade foram observadas em organizações que realizavam auditorias regulares. De todos os incidentes descobertos, 20% foram encontrados manualmente, enquanto as empresas deixaram de detectar 60% devido à ausência de alertas de alta confiabilidade nas ferramentas implementadas.
• Quase um terço dos incidentes descobertos levou mais de três meses para ser detectado. Quanto mais tempo uma ameaça persistiu no ambiente alvo, maior a probabilidade de o incidente ser grave. 30,8% de todos os incidentes descobertos e 52% das violações de alta gravidade apresentaram histórico de atividade superior a três meses. O incidente mais antigo descoberto, em 2025, passou despercebido por quatro anos.
• Arquivos maliciosos frequentemente permanecem em backups e são restaurados após as atividades de resposta a incidentes. 40% de todos os web shells descobertos estavam em backups e passaram despercebidos até que uma avaliação de comprometimento adequada fosse realizada.
• Os agentes de ameaças dependem de ferramentas de gerenciamento remoto e LoLBins. Esses tipos de ferramentas foram encontrados em todas as avaliações de comprometimento que resultaram na detecção de incidentes.
• As ferramentas e controles de monitoramento não são autossuficientes; a maturidade operacional faz a diferença. As ferramentas de monitoramento devem ser configuradas e adaptadas ao cenário de ameaças em constante mudança. Além disso, analistas humanos precisam revisar alertas de baixa confiabilidade. A falta de monitoramento contínuo e de atividades de busca ativa de ameaças aumentou a probabilidade de incidentes de alta e média gravidade para 84–86%. Ao mesmo tempo, incidentes de alta gravidade foram raros entre organizações com capacidade interna para realizar engenharia reversa de malware.
• Problemas de comunicação levam a incidentes não detectados. Quase um terço das avaliações de comprometimento revelaram problemas de comunicação que impactaram as atividades de resposta a incidentes.
• O manual de resposta a incidentes não é imutável. Para que a resposta a incidentes seja eficiente e eficaz, os manuais devem ser atualizados à medida que novos artefatos são descobertos. Tratar o plano de resposta a incidentes como um documento vivo reduz o risco de ameaças passarem despercebidas.

Sobre o serviço de Avaliação de Comprometimento da Kaspersky

O portfólio global de avaliação de comprometimento abrange diversas regiões. Em 2025, cerca de 71% dos incidentes que identificamos afetaram os clientes na região META, enquanto as regiões APAC e CEI representaram os 29% restantes.

Distribuição geográfica dos incidentes identificados durante os projetos de Avaliação de Comprometimento da Kaspersky em 2025 ( download )

Nosso serviço foi solicitado por organizações de diversos setores. O setor governamental representou cerca de 29% dos incidentes, seguido pelos setores de educação (19%) e financeiro (17%).

Distribuição de incidentes do setor econômico identificados durante os projetos de Avaliação de Comprometimento da Kaspersky em 2025 ( download )

Famílias de lógica de detecção

As avaliações de comprometimento operam com base em um catálogo continuamente atualizado de indicadores de ataque (IoAs). Como o conjunto bruto de IoAs é muito granular para relatórios de alto nível, mapeamos esses indicadores para um conjunto conciso de famílias de lógica de detecção. As estatísticas indicam que três famílias de detecção dominam o conjunto de incidentes:

• Credenciais obtidas a partir de despejos de memória: 12,4% de todos os incidentes;
• Ferramentas específicas para viver da terra (LOTL): 11,2%;
• Famílias específicas de malware: 11,2%.

Essas três famílias de lógica de detecção representam indicadores de alta fidelidade de ataque que sinalizam de forma confiável comprometimentos de infraestrutura, desde malware inativo baseado em disco até ataques persistentes e de múltiplos estágios.

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

Motivos para solicitar os serviços de Avaliação de Comprometimento da Kaspersky

A análise das avaliações de risco realizadas em 2025 revela uma clara correlação entre o objetivo declarado do trabalho e o perfil de risco das conclusões. Auditorias gerais predominam no portfólio, com 56% das solicitações, seguidas por relatórios para autoridades (19%), verificações pós-incidente (17%) e aquisições (9%).

Estatísticas sobre os motivos por trás das solicitações de projetos de CA ( download )

Quando os resultados são classificados por gravidade, a categoria de verificação pós-incidente apresenta a maior proporção de incidentes de alta gravidade (40,7%). A análise completa é mostrada abaixo.

As verificações pós-incidente são frequentemente iniciadas após uma resposta inicial a incidentes (IR). A elevada proporção de achados de alta gravidade sugere que as atividades de IR, que normalmente se limitam a conter um incidente conhecido, não fornecem uma visão completa do ambiente mais amplo. Consequentemente, outras ameaças podem permanecer indetectadas até que uma avaliação completa de comprometimento seja realizada.

As avaliações relacionadas a fusões e aquisições são avaliações proativas realizadas quando uma empresa adquire outra entidade. Isso envolve a varredura da rede da empresa-alvo em busca de ameaças ocultas antes da fusão dos dois ambientes. Essas avaliações demonstram uma distribuição equilibrada de gravidade: 28,6% baixa gravidade, 42,8% média gravidade e 28,6% alta gravidade. Isso reflete a postura de risco mista dos ambientes-alvo das aquisições, que frequentemente são avaliados tanto em relação a vulnerabilidades conhecidas quanto a atividades maliciosas ocultas. Da mesma forma, outras abordagens proativas, como avaliações de auditoria geral ou avaliações motivadas pela necessidade de enviar regularmente um relatório de conformidade a uma autoridade reguladora, apresentam proporções semelhantes. Isso indica que avaliações regulares, proativas e orientadas à conformidade tendem a revelar problemas substanciais mais cedo no ciclo de vida do ataque, reduzindo a probabilidade de que eles evoluam para incidentes de alta gravidade.

Organizações que realizam auditorias regulares apresentam a maior taxa de constatações de baixa gravidade (36%) e a menor taxa de problemas de alta gravidade (28%). Podemos assumir, com um nível moderado de confiança, que avaliações contínuas e proativas de comprometimento são mais eficazes para limitar o surgimento de comprometimentos de alta gravidade do que avaliações reativas, baseadas em incidentes. Os dados coletados em 2025 corroboram essa hipótese. Portanto, a integração de avaliações regulares de comprometimento por terceiros aos processos de governança pode reduzir a probabilidade de constatações inesperadas de alta gravidade e melhorar a postura geral de risco.

O estudo de caso a seguir ilustra o impacto de se adotar uma abordagem reativa em vez de proativa. Ele descreve uma ameaça persistente que permaneceu latente na rede de um cliente e só foi descoberta após uma avaliação de comprometimento abrangente realizada na sequência da atividade inicial de resposta a incidentes.

Estudo de caso: Ameaça latente descoberta apenas por meio de uma avaliação de compromisso.

Uma empresa de médio porte sofreu uma intrusão de alta gravidade que foi contida e remediada pela equipe de resposta a incidentes dentro do escopo definido no alerta inicial. Após a contenção, a organização solicitou uma verificação para determinar se existiam pontos de acesso adicionais em outras partes da rede. Para atender a essa necessidade, a organização contratou o serviço de Avaliação de Comprometimento (CA) da Kaspersky, que realizou uma análise forense completa do ambiente, além do escopo do incidente inicial.

Especialistas em avaliação de comprometimento coletaram metadados forenses, registros históricos de eventos de segurança e dados de configuração do Active Directory de toda a infraestrutura. Consultas de busca de ameaças foram executadas na telemetria agregada, com foco em mecanismos de persistência, artefatos de movimentação lateral e atividades anômalas de processos. Como resultado, diversas ameaças graves foram detectadas e relatadas; por exemplo, persistência maliciosa:

1 – Uma tarefa cron que recria um shell web.
Um sistema Linux crítico (servidor web) tinha uma tarefa cron que buscava automaticamente uma cópia de um shell web PHP de um repositório público do GitHub e a colocava em um diretório online. Mesmo que o arquivo fosse removido pela equipe de segurança, a tarefa cron simplesmente o baixaria novamente, dando ao atacante um ponto de execução remota de código persistente no servidor web.

2 – Um shell reverso ativo.
Em um servidor que hospedava uma aplicação web publicada, a lista de processos mostrava um shell reverso bash.Ele era executado por um usuário com o nome de usuário “apache”, que era a conta usada para executar a aplicação web. Isso pode indicar que o atacante explorou uma vulnerabilidade na aplicação web para obter execução remota de código, permitindo que ele estabelecesse um canal de comando e controle confiável que contornou o firewall por ter sido iniciado de dentro da rede.

3 – O ClipBanker, um ladrão de dados, persiste através do registro do Windows. Uma variante do ClipBanker foi detectada na estação de trabalho de um usuário, mantendo-se persistente ao se adicionar à chave de registro HKU\S-1-5-21-[REDACTED]-500\Software\Microsoft\Windows\CurrentVersion\Run\9Er6IIp. Isso foi feito após a adição da pasta do malware às exclusões do Windows Defender e a aplicação de atributos ocultos e de sistema ao arquivo para escondê-lo de usuários comuns.

4 – Consumidor malicioso de eventos WMI com alias enganoso.
Foi detectado um consumidor malicioso de eventos WMI que baixa e executa um script do PowerShell. Ele criou o alias “Kaspersky” para “Invoke-Expression” numa tentativa de se camuflar como uma atividade legítima, na esperança de que uma rápida olhada no script não levantasse suspeitas. A Inteligência de Ameaças Cibernéticas da Kaspersky confirmou que o script baixado (agora inacessível) era uma carga maliciosa usada para disseminar ainda mais a infecção.

A contenção do alerta de resposta a incidentes foi rápida, focada e eficaz para lidar com o incidente específico que o desencadeou. No entanto, a avaliação de comprometimento em larga escala revelou múltiplas portas de entrada (backdoors) em todo o ambiente, cada uma utilizando uma técnica de persistência diferente: tarefas cron, execuções agendadas do registro e assinaturas WMI. Os hosts infectados estavam fora do escopo original do alerta de resposta a incidentes, portanto, permaneceram ocultos até que uma busca abrangente fosse realizada.

A resposta a incidentes se destaca por estancar as perdas e garantir a continuidade dos negócios após um incidente conhecido. Uma avaliação de comprometimento fornece uma verificação completa que determina se existem outras vulnerabilidades. Ao combinar a resposta a incidentes em tempo hábil com avaliações de comprometimento de rede completas e regulares, a organização obteve tanto a agilidade reativa para conter incidentes quanto a visibilidade proativa para erradicar ameaças maliciosas onde quer que estivessem escondidas. A investigação revelou pontos de acesso adicionais não detectados, proporcionando uma visão mais clara do ambiente e reduzindo a probabilidade de recorrência do incidente.

Incidentes de longo prazo não detectados

As estatísticas sobre o tempo médio de detecção (MTTD) de incidentes identificados durante projetos de avaliação de vulnerabilidades são preocupantes. Muitos incidentes passam despercebidos por longos períodos. Por exemplo, em 2025, identificamos um incidente que tinha aproximadamente quatro anos!

Tempos de detecção tão prolongados podem levar a consequências graves, visto que 30,8% dos incidentes apresentam histórico de atividade superior a três meses. Esses incidentes podem variar de malware inativo a ameaças persistentes, o que destaca a necessidade de mecanismos robustos de detecção e resposta.

Distribuição da gravidade dos incidentes por MTTD ( download )

A relação entre a latência de detecção e a gravidade do incidente foi analisada agrupando os resultados de acordo com seu MTTD (Tempo Médio para Detecção):

• Para os incidentes detectados no primeiro mês, a gravidade está distribuída de forma mais ou menos uniforme entre as categorias baixa, média e alta.
• Contudo, à medida que o MTTD aumenta, a gravidade dos incidentes tende a aumentar. Notavelmente, uma alta proporção de incidentes que levaram entre 30 e 60 dias para serem detectados são de gravidade média (78,57%), enquanto aqueles detectados entre 60 e 90 dias são predominantemente de alta gravidade (71,43%).
• Entre os incidentes detectados após 90 dias, uma proporção significativa também são incidentes de alta gravidade (52%).

Em geral, 52% dos incidentes de alta gravidade só são identificados após 90 dias sem serem detectados. Isso representa um risco concreto: quanto mais tempo um incidente permanece sem ser detectado, maior a probabilidade de uma violação grave da segurança. Organizações que integram detecção contínua, atividades de busca de ameaças e avaliações regulares de comprometimento podem reduzir o MTTD (Tempo Médio para Detecção), limitar a escalada de ameaças e diminuir seu perfil de risco geral.

O estudo de caso a seguir destaca a importância da detecção e resposta oportunas para evitar que incidentes se transformem em eventos de alta gravidade.

Estudo de caso: Atividade de mineração de criptomoedas em controladores de domínio com quatro anos de duração.

Em maio de 2025, os especialistas em avaliação de comprometimento identificaram três controladores de domínio em uma rede de clientes que estavam infectados com arquivos maliciosos. Os arquivos permaneceram ocultos por quase quatro anos. Eles foram criados no diretório C:\Windows\Fonts\Mysql , explorando sua característica única de que apenas os arquivos de fonte nesse diretório são visíveis para usuários comuns. Foram encontrados arquivos com os nomes nei.bat , dl1host.exe , bat.bat , cmd.bat e uma versão falsificada do svchost.exe . Esses arquivos foram criados em junho e julho de 2021.

A Kaspersky Threat Intelligence confirmou que esses arquivos fazem parte de uma campanha de mineração de criptomoedas chamada NSABuffMiner, que se propaga pelo protocolo SMB explorando a vulnerabilidade EternalBlue ( MS17-010 ). Uma correção para essa vulnerabilidade foi lançada em março de 2017, quatro anos antes da invasão inicial. Esse tempo foi mais do que suficiente para corrigir os sistemas. Isso reforça a importância de implementar operações eficazes de gerenciamento de patches e manter-se informado por meio de notícias sobre ameaças.

A pedido da organização, os arquivos maliciosos foram coletados juntamente com uma imagem forense para análise, revelando o seguinte:

• Os arquivos bat.bat e cmd.bat geram IPs aleatórios e os escaneiam com um scanner de portas leve renomeado para taskhost.exe para localizar hosts ativos com a porta SMB 445 e a porta NetBIOS 139 abertas, buscando máquinas vulneráveis.
• Os IPs vulneráveis ​​descobertos são repassados ​​para scripts auxiliares chamados bat , poab.bat , load.bat e loab.bat , que executam os malwares mance.exe , Eter.exe e puls.exe para injetar as DLLs maliciosas Eternalblue2.dll e Doublepulsar2.dll em lsass.exe e explorer.exe , permitindo a movimentação lateral.
• A persistência é então estabelecida através da criação de tarefas agendadas para executar os scripts de propagação e infecção, e serviços são criados para executar o minerador de criptomoedas, com os nomes MicrosoftMysql , MicrosoftFonts e MicrosoftMSSql . Outras tarefas agendadas também foram observadas com os nomes At1 e At2 e criadas com a mesma finalidade.
• Após comprometer com sucesso a máquina e instalar os mecanismos de persistência, uma tarefa de limpeza é executada para excluir arquivos temporários e malwares instalados.

Devido à falta de procedimentos adequados de monitoramento e busca de ameaças, a organização desconhecia que uma operação de mineração vinha sequestrando seus recursos há quatro anos, operando em seus controladores de domínio.

preservação não intencional de malware

Um problema frequentemente descoberto durante as avaliações de comprometimento é a permanência ou restauração de web shells em sistemas-alvo. Com base em dados coletados durante avaliações de comprometimento realizadas em 2025, 64% dos incidentes com web shells foram classificados como de alta gravidade, 7% como de baixa gravidade (arquivos possivelmente legítimos, mas potencialmente comprometidos) e 29% como de gravidade média, exigindo erradicação.

Distribuição de incidentes de web shell por gravidade ( download )

Uma das formas pelas quais os web shells persistem é através de backups infectados. A distribuição dos incidentes descobertos nos projetos mostra que 60% dos web shells estavam localizados em sistemas ativos, enquanto 40% estavam armazenados em backups. Restaurar esses backups pode reintroduzir a ameaça muito tempo depois da infecção inicial.

Localização do shell web ( download )

Outro problema comum são as lacunas no inventário de ativos, observadas em 25% dos casos. Isso resultou em dispositivos não rastreados, principalmente servidores web Linux exclusivamente em nuvem que não estão integrados ao Active Directory, escapando das verificações de rotina.

Problemas com o inventário de ativos ( download )

Um atacante pode instalar um web shell em um servidor na nuvem, e esse servidor nunca aparece no inventário, embora ainda receba backups regulares. Como resultado, o web shell pode persistir no servidor na nuvem por um longo período. Se for excluído ocasionalmente, o servidor de backup restaura posteriormente os arquivos infectados, expondo o web shell a terceiros novamente. Isso demonstra que, sem um inventário de ativos completo e atualizado, as capacidades de detecção ficam significativamente comprometidas.

Foi observado um caso em que o web shell estava localizado em um servidor de arquivos interno (não um servidor web) dentro de um arquivo .rar no seguinte caminho: D:\backup\[redacted_for_privacy].rar/wwwroot/<…>/[redacted_for_privacy].aspx

Durante a investigação, os administradores do servidor indicaram que a pasta havia sido copiada de um servidor diferente que estava offline no momento da avaliação. Devido a um inventário de ativos deficiente, a equipe de segurança da empresa não detectou a infecção nesse servidor. Como resultado do procedimento de backup, o web shell foi copiado para o servidor de arquivos interno. A análise forense do servidor offline revelou que o invasor havia introduzido uma porta dos fundos na maioria dos servidores Windows do ambiente, configurando a conta de administrador local com uma senha idêntica.

A técnica consistia em usar o PsExec para executar um script .cmd em todos os servidores listados em um arquivo .txt ; o script alterava a senha do administrador local para um valor comum:

Legítimos, porém suspeitos: LoLBins e ferramentas de gerenciamento remoto

Em 2025, utilitários de gerenciamento remoto (RM) não padronizados foram observados em todas as avaliações de comprometimento. Binários “living-off-the-land” (LoLBins) também estavam presentes em todas as avaliações. Essas descobertas destacam o desafio constante para os centros de operações de segurança (SOCs), que precisam distinguir entre uso administrativo legítimo e abuso malicioso.

As ferramentas de gerenciamento remoto observadas abrangem tanto plataformas proprietárias, como TeamViewer e AnyDesk, quanto ferramentas gratuitas, incluindo PsExec, servidores VNC e frameworks de gerenciamento remoto de código aberto. Esses binários são usados ​​diariamente em muitos ambientes para solução de problemas, implantação de software ou suporte remoto. No entanto, as mesmas funcionalidades — criar uma nova conta de administrador local, copiar arquivos para um compartilhamento remoto ou executar uma varredura de portas de rede para diagnóstico — também são típicas de atividades de pós-exploração de ataques. Os analistas frequentemente encontram casos em que uma ação legítima de um administrador de sistemas se assemelha a uma movimentação lateral. Isso torna o simples fato de “uma ferramenta de gerenciamento remoto ter sido executada” insuficiente para classificá-la como um incidente. Em vez disso, o incidente deve ser avaliado em relação a uma linha de base específica da organização, considerando o uso esperado. Estabelecer essa linha de base requer uma compreensão profunda e contextual de quem está autorizado a executar a ferramenta, a partir de quais endpoints e em quais circunstâncias — um processo que demanda muitos recursos e é analisado caso a caso.

Os LoLBins, binários que fazem parte do sistema operacional ou de utilitários comumente instalados (como certutil , bitsadmin , regsvr32 e wmic ), também estavam presentes em todas as avaliações. Embora esses arquivos sejam componentes confiáveis ​​do sistema, a inteligência de ameaças confirma que eles são frequentemente reutilizados para movimentação lateral, exfiltração de dados e persistência. O gráfico abaixo mostra a distribuição de gravidade para incidentes envolvendo riskware ou um binário LoLBin. A proporção relativamente alta de descobertas de gravidade média (40%) e alta (31%) ressalta que o uso indevido de utilitários legítimos é frequentemente o vetor que permite que uma invasão progrida além do ponto de apoio inicial.

Distribuição da gravidade dos incidentes envolvendo riskware ou LoLBin (2025) ( download )

Para lidar com o potencial uso de LoLBins e ferramentas de gerenciamento remoto por atacantes, recomendamos uma abordagem em várias camadas que vai além das listas de bloqueio estáticas:

1. 1 Formalize uma política que enumere as ferramentas de gerenciamento remoto autorizadas para uso. A política deve ser acompanhada de um requisito para encaminhar os logs operacionais do software para uma plataforma central de gerenciamento de logs (SIEM ou coletor de logs dedicado). O monitoramento contínuo desses logs permite que um SOC detecte desvios dos padrões de uso autorizados.
2. 2 Realize periodicamente uma auditoria de inventário de software para identificar ferramentas de gerenciamento remoto não autorizadas. Considere coletar dados das seguintes chaves de registro em todos os hosts:
   • HKLM\Software\Microsoft\Windows\CurrentVersion\Desinstalar
   • HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Microsoft\Windows\CurrentVersion\Uninstall
   • HKEY_USERS\*\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
3. 3 Enriquecer os hashes (MD5/SHA-256) de cada binário executado com uma categoria funcional, como “Acesso Remoto”, “Imagem Padrão” ou “Software de Segurança”. Correlacionar a categoria com o caminho de execução permite identificar instâncias em que um binário de “Acesso Remoto” é executado a partir de um local não padrão, como %TEMP% ou a pasta de Downloads do usuário.
4. 4 Implemente regras de detecção que identifiquem padrões conhecidos de abuso do LoLBin, como  `certutil -decode` ,  `bitsadmin -transfer` ,  `regsvr32 -i <dll>` e  `wmic process call create` . Essas regras devem ser continuamente comparadas com a atividade normal da organização. A linha de base é derivada de um período de uso legítimo verificado e atualizada sempre que novos casos de uso legítimo surgirem. Os alertas são gerados somente quando o comportamento observado diverge da norma estabelecida, reduzindo assim o ruído e preservando a sensibilidade a abusos reais.

Impacto da ausência de monitoramento contínuo e busca proativa de ameaças

Análises de projetos recentes de avaliação de comprometimento revelam um ponto cego sistemático em organizações que seguem o modelo de segurança por compra para defender suas redes. Sem monitoramento humano contínuo ou um programa dedicado à busca de ameaças, o perfil de gravidade dos incidentes detectados torna-se fortemente enviesado para um impacto maior.

Muitas vezes, o problema não é a falta de ferramentas, mas sim a falta de uso operacional dessas ferramentas. Muitas empresas implementam soluções de segurança de última geração e as deixam funcionar no modo “configure e esqueça”, ou dependem exclusivamente de um fluxo de trabalho orientado por alertas. Os seguintes problemas são comuns nessas organizações:

• Fadiga de alertas: altas taxas de falsos positivos sobrecarregam os analistas com ruído, forçando-os a priorizar indicadores superficiais em vez de conduzir investigações contextuais aprofundadas.
• Atribuição fragmentada de análises: sem uma equipe de busca dedicada, o mesmo analista pode ser encarregado de dezenas de alertas não relacionados, limitando o tempo disponível para a exploração baseada em hipóteses necessária para descobrir pontos de apoio furtivos.

Na prática, isso resulta em um tempo de permanência prolongado do invasor, permitindo a movimentação lateral contínua e a exfiltração de dados antes que a organização tome conhecimento da violação. Esse padrão representa uma exposição a riscos mensurável que se traduz diretamente em impacto nos negócios. Como ilustra o exemplo a seguir, a simples aquisição de controles de segurança não garante a detecção; o monitoramento contínuo, a validação regular de alertas e a busca estruturada por ameaças são essenciais para reduzir o tempo de permanência e limitar o impacto nos negócios.

Estudo de caso: Segurança desde a concepção, sem monitoramento contínuo.

A empresa investiu em controles de segurança e presumiu que o ambiente era seguro por natureza. No entanto, os controles de segurança exigem configuração adequada, ajustes contínuos e monitoramento ativo para serem eficazes. As ferramentas haviam sido instaladas, mas ninguém garantia que os controles de segurança estivessem configurados corretamente, não havia nenhum analista revisando os alertas gerados e não existia um cronograma para revisar os registros coletados.

A organização optou pelo serviço de Avaliação de Comprometimento da Kaspersky. Registros de segurança históricos foram coletados e investigados como parte dos procedimentos de avaliação. O objetivo era simples: determinar o que realmente havia acontecido na rede nos últimos meses.

A análise de logs revelou evidências claras de atividade maliciosa. Foram descobertas atividades relacionadas ao comportamento do Impacket que levaram à implantação do Cobalt Strike e do Mimikatz em diversos servidores críticos, incluindo os controladores de domínio. Essas atividades tinham três meses de idade no momento da detecção, e a empresa não tinha conhecimento delas porque não havia um monitoramento eficaz 24 horas por dia, 7 dias por semana.

Impacket é uma coleção de scripts Python para protocolos de rede e manipulação de pacotes de rede de baixo nível. Atacantes podem explorá-lo para se movimentar lateralmente na rede. A seguir, exemplos de artefatos detectados na rede:

O atacante usou o Impacket para executar um comando do PowerShell que baixou um arquivo executável de um servidor de comando e controle. Constatou-se que esse servidor estava associado ao Cobalt Strike. O Cobalt Strike é uma ferramenta de pós-exploração que permite a execução remota de comandos e a movimentação lateral em uma rede comprometida. A execução foi configurada por meio de uma tarefa agendada que tentou se passar por uma tarefa legítima de atualização do Google Chrome.

A análise da linha do tempo confirmou a presença de um binário do Mimikatz e um despejo de memória associados ao mesmo incidente no sistema comprometido, confirmando que uma operação de roubo de credenciais de fato ocorreu.

A organização desconhecia completamente a violação. A atividade passou despercebida por três meses porque os controles implementados nunca foram monitorados. Ao tomar conhecimento das descobertas, uma resposta completa ao incidente foi iniciada para erradicar os pontos de acesso, rotacionar as credenciais e reforçar a segurança do ambiente.

Os controles de segurança não são autossuficientes. Implantar um firewall ou uma solução EDR não garante proteção automática. Sem a configuração adequada, o ajuste inicial e, principalmente, o monitoramento contínuo de logs e a busca por ameaças, esses controles tornam-se meramente decorativos. O monitoramento contínuo, seja realizado internamente ou delegado a um serviço de segurança gerenciado externo, pode transformar invasões ocorridas há semanas em alertas de minutos, correlacionando eventos, buscando usos anômalos de ferramentas de teste de penetração ou de hacking e escalando atividades suspeitas.

Estatísticas de ações de resposta a incidentes

Uma análise de projetos históricos de avaliação de comprometimento revela uma discrepância persistente entre as melhores práticas descritas em manuais de resposta a incidentes e as realidades operacionais de sua execução em ambientes despreparados e, muitas vezes, afetados por sistemas legados. A figura abaixo mostra a frequência com que cada ação de resposta foi necessária durante a fase inicial de resposta de uma avaliação de comprometimento.

Ações de resposta a incidentes necessárias após avaliação de comprometimento ( download )

A distribuição destaca três padrões observados com frequência:

• A análise forense é responsável pela maioria dos casos, com cerca de 59% exigindo pelo menos uma coleta e análise de amostras forenses.
• A erradicação remota, ou seja, a remoção de arquivos ou chaves de registro, foi relatada em 39% dos casos.
• Os planos evoluem à medida que a investigação avança; 39% das intervenções exigiram uma atualização do plano a meio da intervenção, o que reflete a natureza iterativa da resposta a incidentes.

Por que a coleta forense é o ponto de entrada padrão

A coleta e análise forense de pacotes foi a ação de resposta mais frequente, ocorrendo em 59% dos casos. A prevalência da coleta forense de pacotes pode ser explicada por dois fatores observáveis ​​em investigações de segurança cibernética: (1) a visibilidade histórica limitada da organização alvo e (2) o fato de que uma proporção substancial de incidentes tinha mais de 90 dias no início da avaliação. Em muitos casos, os logs nativos já haviam sido rotacionados ou apagados, forçando os investigadores a se basearem em artefatos residuais (por exemplo, entradas MFT, hives de registro, timestamps do sistema de arquivos) para reconstruir a cronologia dos eventos.

Nossas observações sugerem que a coleta remota de pacotes forenses é, na prática, um pré-requisito, e não uma mera conveniência opcional. O gráfico abaixo resume a capacidade relatada de coletar pacotes forenses, categorizada por nível de gravidade do incidente. Ele destaca que, em uma proporção significativa de casos de alta gravidade, a organização afetada não possuía essa capacidade.

A capacidade da organização de coletar dados forenses por gravidade do incidente ( download )

Contenção: O paradoxo da remoção de arquivos/chaves de registro

A execução de respostas e ações de erradicação, como a remoção de arquivos ou chaves de registro (relatada em 39% dos casos), também foram comuns. No entanto, elas evidenciaram uma lacuna notável nas práticas de execução. Embora muitas organizações tenham relatado possuir recursos de EDR para remoção remota, a execução era frequentemente delegada a equipes de TI ou MSPs por meio de sistemas de tickets. Isso pode introduzir atrasos e reduzir a precisão do processo de remoção. A remoção de malware é um processo cirúrgico, particularmente em cenários de múltiplas etapas, sem arquivos ou com alta persistência. A capacidade por si só é insuficiente sem expertise, sequenciamento e planejamento, especialmente quando artefatos podem existir em cópias de sombra, backups, caminhos ocultos ou cadeias de download.

Falhas de comunicação: um custo operacional adicional

Uma descoberta organizacional importante emergiu em relação à comunicação. Em 32% dos projetos, problemas de comunicação interna na organização avaliada impactaram materialmente a execução das respostas. Abaixo estão os principais obstáculos:

• Confirmação de ação pouco clara – os administradores de sistema não conseguiram confirmar rapidamente se um arquivo suspeito era legítimo.
• Validação do proprietário atrasada – escalonamentos de chamados paralisados ​​enquanto se aguarda resposta dos proprietários do sistema.
• Canais de comunicação comprometidos – contas de e-mail ou portais de emissão de bilhetes – podem já estar sob o controle do atacante em caso de suspeita de comprometimento de domínio.
• Rotatividade de pessoal – perda de conhecimento sobre as configurações históricas de referência.

Esses resultados sugerem que exercícios de simulação regulares são necessários para testar não apenas os manuais técnicos, mas também os fluxos de trabalho humanos e de comunicação, bem como os acordos operacionais que regem e facilitam a comunicação entre diferentes equipes e os procedimentos operacionais padrão para a documentação adequada.

A natureza iterativa das atualizações do plano de resposta

A natureza iterativa das atualizações do plano de resposta

A necessidade de atualizar os planos de resposta com base em novas análises surgiu em 39% dos casos, enfatizando a natureza inerentemente iterativa da resposta a incidentes. Os planos iniciais não conseguem, realisticamente, prever todas as variáveis. Exemplos das causas mais comuns para a atualização do plano de resposta estão listados abaixo:

• Resultados de engenharia reversa que revelam servidores ou comportamentos de comando e controle (C2) até então desconhecidos.
• Descobertas forenses, como tarefas agendadas ocultas, artefatos de cópia sombra ou DLLs inativas.
• Análises de tráfego revelam caminhos adicionais para movimentos laterais.
• Limitações humanas – indisponibilidade dos responsáveis ​​pelo sistema, mudanças nos processos de gestão ou aprovação da supervisão.

Com base em nossa experiência, as equipes que tratam o plano de resposta a incidentes como um documento vivo – incorporando cada novo artefato, repriorizando ações e republicando o manual antes da próxima etapa de contenção – reduzem o risco de falhas na erradicação. Por outro lado, a adesão estrita a um plano inicial, com evidências limitadas, pode aumentar o risco de negligenciar focos persistentes.

Diferenciar artefatos reais de atacantes de resquícios de testes de penetração.

Por fim, distinguir a atividade do atacante dos artefatos de testes de penetração continuou sendo um desafio recorrente (12% dos casos). As avaliações de comprometimento frequentemente revelam resquícios de ferramentas de teste legítimas, o que pode gerar incerteza sobre se um artefato detectado se originou de uma intrusão maliciosa ou de um teste de penetração legítimo. Fatores contribuintes:

• Relatório de teste de penetração e limpeza de artefatos mal documentados.
• Conjuntos de ferramentas sobrepostos (por exemplo, SharpHound) usados ​​tanto por operadores de equipes vermelhas quanto por adversários.
• Executar avaliações de comprometimento e projetos ativos de testes de penetração simultaneamente prejudica o foco do analista e aumenta as taxas de falsos positivos. Embora correlacionar as descobertas com os relatórios de testes de penetração seja essencial, as avaliações de comprometimento são processos investigativos conduzidos por humanos, e confundir os analistas com sinais de ataque “legítimos” sobrepostos leva a interpretações errôneas e resultados menos eficazes.

Maturidade da resposta a incidentes e seu efeito na gravidade.

Os dados mostram uma correlação entre a presença de capacidades internas de perícia digital ou engenharia reversa de malware e a distribuição das categorias de gravidade dos incidentes. Ao longo das avaliações de comprometimento de 2025, a distribuição de resultados de baixa, média e alta gravidade diferiu consideravelmente entre as organizações que possuíam essas capacidades e aquelas que não as possuíam. Os dados abaixo ilustram essa correlação e fornecem uma base para avaliar o valor comercial da expansão das habilidades internas de resposta a incidentes.

Classificação da gravidade dos incidentes para casos que exigem perícia digital, com base nas capacidades da organização ( download )

Organizações capazes de analisar artefatos forenses digitais de forma independente registraram metade dos incidentes de alta gravidade e uma proporção maior de casos de baixa e média gravidade.

Classificação da gravidade dos incidentes para casos que exigem análise de malware, com base nas capacidades da organização ( download )

A presença de um recurso dedicado à engenharia reversa está correlacionada com a ausência total de casos de alta gravidade em nosso conjunto de amostras; a maioria dos incidentes foi classificada como de gravidade média, com uma proporção significativa de resultados de baixa gravidade.

A análise dessa correlação indica, com um nível de confiança moderado, que as mudanças observadas provavelmente não são causadas apenas por efeitos do tamanho da amostra. Em vez disso, é mais provável que reflitam um fenômeno operacional genuíno: as capacidades internas de perícia digital e análise de malware contribuem não apenas para os processos do SOC, mas também para a ciber-resiliência em geral.

Estudo de caso: Infecção LionTail em memória em servidores Windows críticos

Durante uma avaliação de comprometimento, uma ameaça persistente na memória foi identificada em vários servidores críticos. A atividade foi atribuída ao framework LionTail, um conjunto sofisticado de carregadores personalizados e implantes de shellcode residentes na memória. O LionTail explora comportamentos não documentados do driver HTTP.sys do Windows para entregar e receber payloads de forma oculta por meio do tráfego HTTP de entrada, integrando efetivamente atividades maliciosas a fluxos de rede legítimos.

Diversas variantes observadas são atribuídas ao agente Scarred Manticore , que gera um implante exclusivo para cada hospedeiro comprometido e realiza a exfiltração de dados, mascarando cuidadosamente as comunicações de comando e controle em meio a um tráfego de aparência normal.

A detecção foi realizada por meio de assinaturas estáticas de memória descobertas no processo scrcons.exe. Embora o scrcons.exe seja um binário legítimo do host WMI localizado em C:\Windows\System32\wbem , ele é frequentemente usado indevidamente para hospedar payloads injetados, tornando-o um alvo atraente para operações furtivas na memória.

O plano de resposta compreendeu uma série de ações, sendo as mais críticas destacadas abaixo:

• Coleta de despejos de memória volátil para análise detalhada.
• Aquisição de imagens forenses completas dos discos dos sistemas afetados.
• Análise detalhada dos artefatos coletados e atualizações subsequentes ao plano de resposta a incidentes.

A execução dessas ações provou ser um desafio para a organização devido às suas limitadas capacidades de perícia digital e engenharia reversa. Em incidentes dominados por ameaças residentes em memória sem arquivo, essas capacidades não são opcionais – são essenciais. Sem elas, as organizações correm o risco de perder evidências críticas, avaliar erroneamente o alcance da invasão ou não conseguir erradicar completamente implantes avançados que deixam rastros mínimos no disco.

Embora os especialistas tenham conseguido concluir a investigação e conter a violação, o caso revelou uma lacuna de prontidão. Demonstrou o risco operacional de depender de assistência externa durante incidentes de alto impacto e reforçou a necessidade de maturidade interna em perícia forense e engenharia reversa para alcançar um gerenciamento de incidentes oportuno, confiável e abrangente.

Resolver os problemas que causam a raiz do problema

Após a conclusão de uma avaliação de riscos, o foco muda da resposta a incidentes para uma fase de consultoria. O workshop final concentra-se na prevenção da recorrência de incidentes, identificando as deficiências subjacentes que permitiram que passassem despercebidos. As recomendações são práticas e adaptadas ao contexto. Para efeitos deste relatório, foram agrupadas num conjunto limitado de categorias gerais.

Observações comuns sobre as causas principais

A verificação da integridade dos sensores foi a ação corretiva mais frequente. Em mais da metade dos casos em que os alertas estavam ausentes, recomendou-se uma simples verificação da integridade dos sensores e da relevância das regras para suprir a lacuna. Sem essa validação, não era possível atribuir imediatamente a falha à capacidade do produto.
A análise humana ainda é essencial para alertas de baixa confiabilidade. Os pipelines automatizados, por si só, não conseguem compensar regras propensas a falsos positivos (por exemplo, heurísticas genéricas de web shell). Recomendou-se a inclusão de uma etapa de triagem manual para reduzir o tempo de permanência dos incidentes.

A higiene de processos (gestão de vulnerabilidades, busca de ameaças, políticas de segurança) responde por uma parcela substancial das causas principais. Mesmo organizações maduras apresentaram lacunas em atividades rotineiras que poderiam ser mitigadas com fluxos de trabalho disciplinados. A ausência de políticas/processos documentados foi a causa principal em 23,9% dos casos.

Um exemplo moderno de lacuna nas políticas é o uso de ferramentas de desenvolvimento de IA generativa que operam sem regras claras de tratamento de dados. Durante um projeto, identificamos uma estação de trabalho macOS que executava o assistente de linha de comando Claude Code (Anthropic) como uma extensão do VS Code. A ferramenta capturava automaticamente instantâneos do sistema de arquivos para enriquecer as instruções do seu modelo de linguagem. Esses instantâneos incluíam listagens completas de diretórios e caminhos absolutos para diversas planilhas do Excel contendo dados confidenciais internos.

A organização foi aconselhada a realizar sessões de conscientização para os funcionários sobre o risco de expor dados internos confidenciais a ferramentas de IA generativa e a desenvolver uma política que regule o uso dessas ferramentas com informações confidenciais.

Falta de detecções: causas e impactos

As avaliações de comprometimento demonstram repetidamente que a fidelidade insuficiente na detecção é um fator que contribui significativamente para incidentes de alta gravidade. Nos casos em que a cobertura de detecção da organização-alvo foi classificada como baixa, 52% dos incidentes foram classificados como de alta gravidade e 15% como de baixa gravidade. Isso sugere uma correlação: a visibilidade limitada parece aumentar a proporção de incidentes que evoluem para comprometimentos de alta gravidade.

Distribuição da gravidade dos incidentes quando a cobertura de detecção foi insuficiente ( download )

Uma suposição comum é que a contratação de um provedor de serviços de segurança gerenciados (MSSP) melhora a maturidade da detecção. Os dados, no entanto, mostram um cenário mais complexo. Mesmo com a contratação de um MSSP, 26,5% dos incidentes relacionados à baixa cobertura de detecção permanecem sem identificação, e aproximadamente 50% dos projetos com suporte de MSSP apresentam lacunas básicas de auditoria do Windows (por exemplo, ausência de coleta de logs de eventos ou políticas de auditoria desativadas).
Essas descobertas sugerem que a terceirização por si só não garante uma detecção eficaz; governança ativa e validação contínua são necessárias. A detecção deve ser tratada como uma capacidade em constante evolução que requer testes, medições e aprimoramento contínuos, independentemente de ser gerenciada internamente ou por terceiros.

Estatísticas de incidentes não detectados devido à falta de capacidade de detecção com ou sem MSSP ( download )

A análise das causas principais das detecções perdidas revela vários temas recorrentes. Em muitos ambientes, a tecnologia está presente, mas mal operacionalizada. Os principais problemas são:

• Ausência de verificação de integridade da plataforma de proteção de endpoints (EPP) – quase 50% dos incidentes escalaram para alta gravidade em ambientes onde a verificação de integridade da EPP era deficiente ou inexistente. Isso reflete o risco clássico de “instalado, mas não aplicado”, onde os agentes estão presentes, mas não estão configurados, atualizados ou validados.
• Lacunas na inteligência de ameaças – quando não havia um feed ou plataforma funcional de inteligência de ameaças, cerca de metade dos incidentes atingia alta gravidade. Sem indicadores de comprometimento selecionados e enriquecimento contextual, os analistas dependem de alertas genéricos e podem ignorar comportamentos maliciosos conhecidos.

A questão subjacente é uma mentalidade de “configurar e esquecer”, orientada por alertas: as organizações presumem que as ferramentas implantadas as protegerão automaticamente, mesmo que essas ferramentas não sejam continuamente ajustadas, validadas ou enriquecidas com informações sobre ameaças.

As falhas de detecção raramente são causadas por um único controle ausente; elas surgem de configurações deficientes, telemetria insuficiente e ausência de verificações regulares de controles e processos para garantir seu funcionamento, especialmente em modelos terceirizados. Uma abordagem de monitoramento híbrida, que combina responsabilidade interna com suporte externo de MDR ou MSSP, demonstra consistentemente ser o modelo mais resiliente quando funções, expectativas e métricas de desempenho são claramente definidas. A detecção deve ser tratada como uma função viva, e não como um resultado de aquisição.

O exemplo a seguir ilustra as consequências reais das falhas de controle, analisando um incidente grave que permaneceu sem ser detectado por meses simplesmente porque a organização não possuía os recursos de detecção e as ferramentas de segurança necessárias.

Estudo de caso: Infecção por PurpleFox na memória evade a proteção convencional de endpoints

Durante uma avaliação de comprometimento, a memória dos hosts alvo foi analisada usando o conjunto de regras de busca de ameaças. Dois objetos ocultos foram identificados:

• O código do rootkit PurpleFox foi injetado em processos legítimos do svchost.exe em vários servidores críticos.
• Assinaturas do minerador de criptomoedas XMRig residindo nas mesmas instâncias comprometidas do svchost.exe .

O PurpleFox instala DLLs especialmente criadas e força o svchost.exe a carregá-las. A partir daí, ele instala um driver em modo kernel que concede ao atacante capacidades de execução persistente e furtiva, além da habilidade de extrair payloads adicionais. Isso resulta no carregamento do minerador XMRig.

A solução EPP implantada monitorava a criação de arquivos, modificações no registro e conexões de rede. No entanto, seu módulo de inspeção de memória estava desativado. Além disso, o conjunto de assinaturas aplicado no momento da avaliação não estava atualizado. Como resultado, nenhum alerta foi gerado para as DLLs injetadas ou para o shellcode do minerador. A equipe de avaliação de comprometimento identificou essa lacuna de detecção durante a fase de análise de memória e documentou a ausência da capacidade de inspeção em memória no relatório final.

As operações de segurança da organização foram terceirizadas para um MSSP (provedor de serviços de segurança gerenciados), que coletava os registros e os encaminhava para a solução SIEM (sistema de gerenciamento de informações de segurança). Como os registros nunca continham alertas de atividade em memória, a atividade do PurpleFox não foi identificada.

Gestão insuficiente de vulnerabilidades: um catalisador para comprometimentos de alta gravidade.

Nos projetos de avaliação de comprometimento de 2025, mais da metade das ameaças identificadas e relacionadas a práticas insuficientes de gerenciamento de vulnerabilidades ou à ausência de patches foram classificadas como de alta gravidade. As consequências mais frequentemente observadas foram a implantação de web shells que permitiam a execução remota e persistente de código e a exploração de instâncias do Active Directory mal configuradas.

Distribuição da gravidade dos incidentes devido à gestão inadequada de vulnerabilidades ( download )

As causas principais da ausência de patches são multifacetadas. Incluem gerenciamento inadequado de inventário de ativos (25% dos projetos) e a ausência de processos formais de gerenciamento de vulnerabilidades (41% dos projetos). Além disso, 86% das organizações que afirmaram ter um programa de gerenciamento de vulnerabilidades ainda apresentaram configurações incorretas exploradas durante avaliações de comprometimento. Essas descobertas sugerem que um gerenciamento robusto de patches, práticas abrangentes de inventário de ativos e processos estruturados de gerenciamento de vulnerabilidades são essenciais para a prevenção de incidentes de alta gravidade.

Estudo de caso: Como a distribuição de software baseada em GPOs excessivamente permissivas pode dar errado.

Durante diversas avaliações de vulnerabilidades, observou-se consistentemente uma configuração incorreta de alto impacto: um Objeto de Política de Grupo (GPO) era usado para apontar para um executável em uma pasta compartilhada e executá-lo em todas as estações de trabalho por meio de uma tarefa agendada. A lista de controle de acesso (ACL) no compartilhamento estava definida como “Todos – Controle Total”.

Dado que qualquer usuário autenticado do domínio pode gravar no compartilhamento, um invasor que comprometa uma única conta com privilégios baixos pode substituir o binário legítimo por uma carga maliciosa. A próxima execução da tarefa agendada propaga a carga automaticamente para todos os endpoints que recebem a GPO. Isso proporciona:

• Contexto de execução elevado: a tarefa agendada normalmente é executada na conta SYSTEM ou na conta de administrador local.
• Movimentação lateral automática: o binário malicioso se propaga sem exigir exploração adicional da rede.
• Escalada de privilégios: uma conta com privilégios baixos comprometida pode levar à execução de código de administrador de domínio.

Procedimentos de gerenciamento de vulnerabilidades que incluem auditorias sistemáticas de GPOs e permissões de compartilhamento teriam sinalizado a ACL gravável como uma vulnerabilidade de alta gravidade, permitindo a correção antes da exploração. A correção normalmente envolve restringir as permissões de compartilhamento a “Usuários Autenticados” com acesso somente leitura e limitar as modificações a determinadas contas privilegiadas. Incorporar essas verificações aos controles de segurança básicos reduz a superfície de ataque, demonstrando a redução tangível de riscos alcançável por meio de práticas disciplinadas de avaliação de vulnerabilidades e testes de penetração (VAPT).

Conclusão

Em 2025, a Avaliação de Comprometimento da Kaspersky ajudou as organizações a revelar uma lacuna persistente na detecção: 30,8% de todos os incidentes e 52% dos comprometimentos de alta gravidade apresentavam histórico de atividade superior a três meses. De todos os incidentes descobertos, 20% foram encontrados manualmente, enquanto 60% passaram despercebidos pelas empresas devido à ausência de alertas de alta confiabilidade nas ferramentas existentes. O incidente mais antigo não detectado identificado pela equipe da Avaliação de Comprometimento da Kaspersky em 2025 tinha quatro anos.

As verificações pós-incidente produziram a maior porcentagem de constatações de alta gravidade, enquanto auditorias proativas regulares, auditorias orientadas à conformidade e auditorias realizadas antes da fusão de duas redes tenderam a revelar problemas mais cedo. Isso indica que investigações puramente reativas frequentemente deixam passar problemas persistentes ocultos. As principais recomendações de alto nível para melhoria imediata em 2025 para todos os projetos foram:

• Execute uma verificação completa da integridade do mecanismo de detecção em até 30 dias após o encerramento do projeto, priorizando a integridade da telemetria e a relevância das regras.
• Implementar uma equipe de validação de alertas de Nível 1 que revise todos os eventos de baixa confiança em um cronograma definido.
• Garantir um monitoramento robusto 24 horas por dia, 7 dias por semana, complementado por recursos de busca ativa de ameaças, com foco em definição de linhas de base, alertas de baixa fidelidade e técnicas emergentes de adversários.
• Reavalie o pipeline de gerenciamento de vulnerabilidades para garantir a aplicação contínua de patches e a ativação dos logs de auditoria em todos os ativos críticos.
• Atualizar os currículos de conscientização sobre segurança para abordar o vazamento de credenciais de dispositivos pessoais e reforçar as práticas seguras de BYOD (Bring Your Own Device).
• Garantir a realização periódica de exercícios simulados para testar os manuais técnicos e aprimorar as habilidades da equipe e os fluxos de trabalho de comunicação.
• Estabelecer acordos de nível operacional para reger e facilitar a comunicação entre diferentes equipes, bem como procedimentos operacionais padrão para a devida documentação.

Abordar sistematicamente as categorias de causas raiz reduzirá a probabilidade de futuros pontos cegos e melhorará a postura geral de segurança das organizações envolvidas

Fonte: SecureList

Clique e fale com representante oficial Netwrix Endpoint Protector

Veja também:

• Segurança de aplicações na era da IA: estamos de olhos vendados
• Novo serviço de phishing da Bluekit burla a autenticação multifator
• Vulnerabilidade crítica no python.org permite requisições de API como Admin
• Ataques com ransomwares fizeram 791 vítimas em maio
• O Fantasma na Máquina: o desafio das alucinações de IA na segurança corporativa
• Sem usar vírus, golpe que engana funcionários se multiplica por 37
• Estratégia de cibersegurança vira pilar de sobrevivência para empresas
• IA leva à descoberta de nova técnica de ransomware
• Judiciário brasileiro combate ataques com tecnologia de alta performance 
• Altos riscos da segurança em data centers
• IA, ameaças nacionais e cenário global redefinem estratégias de defesa
• Ataques cibernéticos ampliam preocupação do mercado de resseguros