BLOG

Por que seu SIEM/EDR não alerta quando a invasão de sistema acontece

POR:

Haline Farias

Jovem hacker com um teclado e vário símbolos de cadeado. Ele está pronto para invadir um sistema tido como impenetrável

Quando equipes de segurança investem milhares de reais em ferramentas de SIEM e EDR, existe uma expectativa clara: que esses sistemas detectam e bloqueiam invasões. 

Contudo, a realidade é diferente. 

Pesquisadores da MDPI (2024) demonstraram que SOCs enfrentam lacunas críticas de cobertura ao mapear sua infraestrutura contra o framework MITRE ATT&CK. 

Além disso, ataques executados com o Kali Linux frequentemente passam despercebidos por soluções defensivas tradicionais.

O problema central não está na qualidade das ferramentas de defesa. O verdadeiro desafio reside na ausência de validação ofensiva contínua. 

Sem testes reais de invasão, as empresas operam sob uma falsa sensação de segurança, acreditando que seus dados estão protegidos quando, na realidade, atacantes já podem ter acesso ao ambiente.

Por que o Kali Linux é a ferramenta preferida dos atacantes

Desenvolvido pela Offensive Security, o Kali Linux é uma distribuição especializada em testes de penetração que reúne mais de 600 ferramentas pré-instaladas. 

Conforme documentado pela CISA (2024), red teams governamentais utilizam essas mesmas ferramentas para avaliar a segurança de organizações críticas.

Atualmente, o arsenal do Kali Linux permite executar técnicas avançadas de evasão de EDR. 

Um estudo publicado em janeiro de 2025 catalogou mais de 50 métodos diferentes de bypass documentados no repositório Awesome EDR Bypass. 

Portanto, atacantes não precisam desenvolver malware do zero – eles simplesmente adaptam ferramentas públicas que já funcionam contra as defesas modernas.

Como o SIEM/EDR funciona e onde falha

Um SIEM coleta e correlaciona logs de diversos sistemas, enquanto o EDR monitora endpoints em busca de comportamento suspeito.

De acordo com relatório da Eventus Security (2024), aproximadamente 45% dos alertas gerados por SIEM são falsos positivos, criando fadiga nos analistas do SOC.

Além disso, essas ferramentas dependem de assinaturas e regras predefinidas. 

Quando um atacante utiliza técnicas de syscall direto, unhooking de DLLs ou ofuscação de payload, o EDR simplesmente não consegue identificar a ameaça. 

Um artigo técnico de S3cur3Th1sSh1t demonstra que EDRs injetam DLLs em processos para monitorar chamadas à API do Windows – mas essa abordagem possui limitações fundamentais.

Com isso, surgem pontos cegos críticos. O SOC recebe alertas apenas sobre ameaças conhecidas, enquanto técnicas personalizadas e zero-day passam completamente invisíveis.

Técnicas de bypass que o seu EDR não detecta

Syscalls diretos e unhooking

Segundo pesquisa recente sobre técnicas Hell’s Gate e Tartar

usGate, atacantes podem fazer chamadas diretas ao kernel do Windows sem passar pelas APIs monitoradas pelo EDR. 

Essa técnica explora o fato de que soluções de segurança só conseguem observar atividades no modo usuário, não no modo kernel.

Execução antes da inicialização do sistema

Em dezembro de 2024, pesquisadores demonstraram a técnica BootExecute EDR Bypass, que executa código nativo antes que os sistemas de segurança sejam carregados. 

Portanto, o malware pode deletar arquivos críticos do EDR com privilégios SYSTEM antes mesmo que a proteção seja ativada.

Abuse de processos legítimos

Técnicas de DLL hijacking e process hollowing permitem que atacantes executem código malicioso dentro de processos confiáveis. 

Como o EDR confia em processos como svchost.exe ou explorer.exe, essas atividades maliciosas não geram alertas.

O que o SOC vê versus o que realmente acontece

Um red team experiente consegue estabelecer persistência em uma rede corporativa em menos de 48 horas. 

Durante esse período, o SOC geralmente não detecta nenhuma atividade suspeita. 

De acordo com dados da CrowdStrike (2024), o tempo médio entre o comprometimento inicial e a detecção pode ultrapassar vários dias.

No entanto, a ausência de alertas não significa ausência de invasão. 

Significa apenas que o atacante compreende melhor as capacidades de detecção do que a própria equipe defensiva. 

Diante disso, empresas precisam questionar: quantos acessos não autorizados existem neste momento sem que o SOC saiba?

A importância da validação ofensiva contínua

A metodologia de red team continuo da RESH preenche essa lacuna crítica. 

Enquanto ferramentas defensivas protegem contra ameaças conhecidas, o red team valida se essas proteções realmente funcionam contra técnicas modernas.

Além disso, esse processo identifica gaps de visibilidade antes que atacantes reais os explorem. 

Por exemplo, se um red team consegue exfiltrar dados sem gerar alertas, isso demonstra uma falha crítica que precisa ser corrigida imediatamente.

Assim sendo, empresas que implementam validação ofensiva contínua transformam descobertas em melhorias concretas. 

Cada teste revela não apenas vulnerabilidades técnicas, mas também deficiências em processos, resposta a incidentes e priorização de riscos.

Implicações para proteção de dados e LGPD

Quando invasores conseguem acessar sistemas sem detecção, os dados pessoais da organização ficam expostos. 

A ANPD estabeleceu em sua Resolução CD/ANPD 15/2024 que empresas devem notificar incidentes de segurança em até 3 dias úteis após a confirmação da violação.

Contudo, como notificar algo que o SOC não detectou? 

Organizações que sofreram vazamento de dados frequentemente descobrem o incidente através de fontes externas, não de seus próprios sistemas de monitoramento. 

Em 2024, a ANPD aplicou sanções contra entidades públicas e privadas por falhas na notificação de incidentes, incluindo casos onde a falta de detecção adequada contribuiu para o problema.

Portanto, investir em validação ofensiva não é apenas uma questão técnica – é um requisito para conformidade real com a LGPD. 

A lei exige medidas de segurança adequadas, e isso inclui a capacidade de detectar e responder a invasões avançadas.

Como corrigir a lacuna de detecção

Primeiro, empresas precisam mapear suas capacidades de detecção contra o framework MITRE ATT&CK. 

Segundo recomendação da SANS (2024), isso revela quais táticas e técnicas o SOC consegue identificar versus quais passam invisíveis.

Em seguida, é fundamental implementar testes de penetração que simulam ataques reais. O pentest especializado da RESH utiliza as mesmas ferramentas e técnicas que atacantes empregam, revelando exatamente onde as defesas falham.

Por fim, criar um ciclo de melhoria contínua onde cada teste gera aprimoramentos mensuráveis. 

Isso inclui ajustar regras de SIEM, melhorar políticas de EDR e treinar analistas para reconhecer indicadores sutis de comprometimento.

Conclusão

A combinação de Kali Linux, técnicas avançadas de evasão e a natureza reativa dos sistemas SIEM/EDR cria um cenário onde invasões podem permanecer indetectáveis por semanas ou meses. 

Enquanto o SOC monitora alertas que nunca chegam, atacantes movem-se livremente pela rede, exfiltrando dados e estabelecendo persistência.

A solução não está em substituir ferramentas defensivas, mas em complementá-las com validação ofensiva contínua. 

Somente através de testes reais de invasão, executados por especialistas que pensam como atacantes, as organizações podem ter certeza de que suas defesas realmente funcionam.

Empresas que esperam sofrer um incidente real para descobrir suas lacunas de detecção pagam um preço muito mais alto – em multas da LGPD, perda de dados críticos e danos irreparáveis à reputação.

Fontes e referências

Check Point – The Role of SIEM Solutions in SOCs – https://www.checkpoint.com/cyber-hub/threat-prevention/what-is-soc/the-role-of-siem-solutions-in-socs/ – 2024

Categorias

RESH

Compartilhe: