DNS Sinkholing a partir de uma perspectiva activa I

Em busca de uma definição

Do ponto de vista de um atacante, a nossa infra-estrutura é o espaço onde o seu pedaço de malware será executado, provavelmente com objectivos diferentes (desde a incorporação dos nossos dispositivos a uma Botnet, o desvio dos nossos dados, a recolha de informações de interesse, até aos casos mais engenhosos). Esse pequeno pedaço de código precisa de utilizar alguns dos nossos recursos para atingir os seus objectivos.

DNS Sinkhole é uma técnica bem conhecida onde são fornecidos resultados manipulados para consultas a partir de domínios considerados maliciosos. Isto permite então que o atacante seja redireccionado para um sistema alvo diferente (controlado por nós).

Tradicionalmente, os vários serviços que integram a protecção da conectividade ofereciam (e oferecem) a possibilidade de bloqueio preventivo destas consultas. Com esta técnica podemos ir um passo mais longe e levar esse simples pedido DNS feito pelo nosso dispositivo infectado e utilizá-lo em nosso benefício.

Apenas uma técnica para a nossa Defesa Activa

Como já explorámos em posts anteriores, esta é apenas uma de várias técnicas centradas na Defesa Activa (HoneyPots, Beaconing). Especificamente, podemos colocar o DNS Sinkholing no contexto do MITRE Engage Framework e ATT&CK como uma técnica onde manipulamos a nossa rede, claramente com o objectivo de evitar que o atacante avance com as suas operações, mas também prejudicando operações em curso, tais como fugas de dados.

Malware e NATeo

Chega um ponto no ciclo de execução de qualquer peça de malware onde faz contacto com o mundo exterior, seja para reportar um estado de activação, para fazer um push de dados, ou para procurar novos comandos (claro que cada cenário é diverso, se pudermos generalizar). É neste ponto que o malware é exposto na nossa rede

Por outro lado, as consultas DNS são normalmente realizadas através de uma rede complexa, pelo que detectar o IP a partir do qual a consulta de domínio malicioso foi realizada não é fácil do ponto de vista das nossas NGFWs. A técnica DNS Sinkholing provoca a máquina infectada a comunicar directamente com o nosso IP de detecção ou IP Sinkholing, e é aí que capturamos o endereço do nosso dispositivo comprometido para iniciar tarefas de remediação.

Antes de prosseguir, é importante notar que esta tarefa nem sempre é eficaz porque só funciona nos casos em que os domínios utilizados pelos adversários já são detectados pelos fornecedores da lista de blocos. Além disso, existem muitas alternativas tão simples como a utilização de um IP fixo (que anularia completamente a nossa medida). Outras técnicas engenhosas são também utilizadas, tais como a utilização de domínios respeitáveis para comunicação externa ou a geração aleatória de novos domínios, embora "sorte a nossa", uma única acção registada pela nossa técnica é suficiente para detectar um computador infectado no nosso ambiente e para iniciar tarefas de mitigação.

Algumas implementações

Existem muitos produtos de código aberto e comerciais que nos permitem bloquear as consultas DNS feitas a nomes de sítios infectados. Alguns dos serviços que podemos utilizar para esta protecção são: Cloudfare ,OpenDNS, AmazonRoute53, Checkpoint, y Fortinet. No entanto, isto é apenas metade dos benefícios que podemos obter com esta técnica. Alguns fornecedores deram nativamente a opção de oferecer uma resposta a essa consulta maliciosa com um resultado alterado (como no caso de Palo Alto). Neste caso, partilharemos umapequena implementação na Amazon AWS.

A sua configuração é bastante simples através de uma série de "Regras de Grupo" dentro dos VPCs. Desta forma, todas as consultas DNS são processadas de acordo com as regras definidas:

Esta implementação pode ser destacada pela sua facilidade de configuração e integração com a infra-estrutura já implantada na nuvem. Com estas regras, todas as consultas DNS que são detectadas no VPC atribuído e correspondem a domínios maliciosos serão sobrescritas com o nosso IP Sinkhole.

Para os amantes de Open Source encontramos Pi-Hole, um micro SO que podemos integrar com os nossos servidores DNS já implantados (desde o Microsoft DNS no local até ao Google Cloud DNS) e oferecer uma extensão das

O Pi-Hole pode ser utilizado como um reencaminhador DNS para interceptar consultas externas e responder com base em configurações. Ao contrário da implementação anterior, onde só tínhamos listas de malware AWS, neste caso podemos integrar com vários fornecedores de DNS que já temos:

Após algumas configurações simples do modo de bloqueio do dispositivo, estamos prontos para redireccionar pedidos de domínios maliciosos:

Uma vez que a Pi-Hole esteja em funcionamento, permite-nos visualizar cada consulta para obter alguns detalhes. Neste caso, tomámos alguns dos domínios listados como maliciosos para realizar uma série de testes:

É claro que este cenário mostra apenas metade da história. Para o completar devemos utilizar algum serviço que permita uma monitorização constante, por exemplo para pedidos HTTP e HTTPS, que são tipicamente utilizados para comunicação com C2s.

Pode encontrar referências para a implementação de um HoneyPot aqui .

Algumas conclusões

• É importante compreender quais os cenários que nos ajudam a proteger e quais os que estão fora do âmbito desta técnica. Isto permitir-nos-á desenvolver uma estratégia abrangente para este tipo de ameaça.


• Cada infra-estrutura tem a sua própria arquitectura. Para a aplicação desta técnica, é necessário considerar o cenário em que ela entra em jogo, por exemplo, Home Office, Zero Trust, múltiplos prestadores de serviços, etc.


• A implementação minimalista do Pi-Hole traz-nos uma ferramenta extremamente útil para redes domésticas, e pode ser implementada em dispositivos de poucos recursos ou em pequeno hardware como o Raspberry Pi.