Se o DNS nunca houvesse existido, a internet como conhecemos cairia no esquecimento. O DNS serve como uma ferramenta de tradução de nomes de domínio para endereços IP. E não há dúvida de que o DNS de qualquer organização está borbulhando com tráfego, muitas vezes despercebido por muitos analistas de segurança. Isso o torna um vetor atraente para um hacker que espera que seu tráfego DNS não seja monitorado. Embora o DNS tenha sido projetado para traduzir nomes de domínio, há uma quantidade mínima de dados que podem ser transferidos por meio dele que os hackers podem explorar para lançar um ataque de encapsulamento de DNS.
O que é um ataque de túnel DNS?
Vamos primeiro começar com o básico. O tráfego DNS pode permear e fluir através de soluções de proteção de perímetro, como firewalls, e escapar das defesas da organização. Ele fornece o canal perfeito para hackers estabelecerem um túnel virtual, que é basicamente uma conexão que contém uma carga maliciosa na forma de comandos ou pequenos bits de dados. O DNS não é realmente um protocolo de transmissão de dados, mas hackers sofisticados podem aproveitá-lo para transmitir dados destrutivos entre o sistema da vítima e o servidor do invasor.
Como o ataque túnel é configurado?
Um ataque de túnel DNS depende do modelo cliente-servidor de acesso aos recursos.
-
O hacker começa criando um domínio malicioso com o nome de domínio direcionando o tráfego para o servidor do hacker.
-
O hacker compromete um sistema na rede da organização alvo. Como as consultas de DNS podem atravessar o firewall sem parecer suspeitas, o resolvedor de DNS, um servidor que auxilia no processo de conversão de nome de domínio para IP, pode ser facilmente contatado.
-
O resolvedor de DNS direciona a consulta para o servidor do invasor onde existe o programa de encapsulamento, e agora é criado um canal entre o sistema da vítima e o servidor do hacker, conhecido como servidores de Comando e Controle (servidores C&C). É assim que ocorre a comunicação de Comando e Controle. Como essas comunicações estão sendo roteadas pelo resolvedor de DNS, é difícil rastrear comandos e pequenos pacotes de dados sendo transferidos pelo túnel.
O tunelamento DNS não é o ataque mais fácil de detectar. Infelizmente, você não pode somente aplicar a lógica de detecção e esperar resultados infalíveis ao detectar sua ocorrência.
Contudo, existem algumas maneiras quase infalíveis de se manter alerta quanto a um ataque de túnel DNS.
-
Solicitações de nomes de domínio incomuns: Os nomes de domínio para os servidores C&C geralmente são aleatórios, como “asdggj.com” ou “12.345.672.hujist.com”. Se tais nomes de domínio forem encontrados nos logs, eles devem ser imediatamente colocados na lista negra. Além disso, nomes de domínio de nível superior, como .tk e .ru, são suspeitos e devem ser verificados quanto a atividades maliciosas.
-
Volume anormal de DNS: quando um grande número de consultas de DNS é enviado em um curto espaço de tempo para domínios com nomes incomuns, é um sinal claro de atividade maliciosa. Se essas consultas ocorrerem em horários estranhos, é possível que os sistemas de consulta estejam infectados. Se você utilizar um sistema UEBA em sua estratégia de segurança, poderá estabelecer uma linha de base para determinar o tráfego DNS durante um dia típico. Depois disso, qualquer pico nos volumes DNS e acima de um determinado limite (como o dobro do volume normal) pode ser uma ótima maneira de detectar túneis DNS em sua rede. Isso ocorre porque os túneis DNS só podem transmitir pequenas quantidades de dados por vez por meio da consulta. Um hacker teria que usar várias consultas para executar comandos ou para exfiltrar dados, levando a um aumento nos volumes de consultas.
O encapsulamento de DNS não é um ataque em que você pode identificar a presença confiando em mecanismos de detecção ou regras de correlação. Em vez disso, sua equipe terá que usar métodos manuais de caça a ameaças com base nos indicadores de comprometimento que discutimos acima.
Quer saber mais sobre cibersegurança e SIEM? Não deixe de conferir os outros posts do nosso blog!
Esse post foi traduzido da nossa página em inglês SIEM Expert Talks, e sua autoria original é de Tanya Austin.
