Este post também está disponível em: 日本語 (Japonês)
agentes Maliciosos têm utilizado o Comando & Controle (C2) canais de comunicação sobre o Serviço de Nome de Domínio (DNS) e, em alguns casos, até mesmo ter usado o protocolo para a evasão de dados. Isto está além do que uma conexão C2 de “batimento cardíaco” comunicaria., Atores maliciosos também infiltraram dados maliciosos/cargas úteis para o sistema de vítimas ao longo do DNS e, por alguns anos, a unidade 42 pesquisa descreveu diferentes tipos de abuso descoberto.
DNS é um protocolo fundamental e fundamental da internet-muitas vezes descrito como a” agenda da internet ” – mapeando nomes de domínio para endereços IP, e muito mais, como descrito no núcleo RFCs para o protocolo. A ubiquidade da DNS (e frequente falta de escrutínio) pode permitir métodos muito elegantes e sutis para comunicar e compartilhar dados, além das intenções originais do protocolo.,
em cima dos exemplos de uso de DNS já mencionados, uma série de ferramentas existem que podem permitir, entre outras coisas, seus atacantes para criar canais encobertos sobre DNS com a finalidade de esconder a comunicação ou contornar Políticas colocadas em prática pelos administradores de rede. Um caso de uso popular é para contornar o hotel, café etc Wi-Fi registro de conexão, usando o muitas vezes aberto e disponível DNS. Mais notavelmente, estas ferramentas estão disponíveis online gratuitamente em lugares como o GitHub e podem ser fáceis de usar. Mais informações sobre estas ferramentas podem ser encontradas na seção Apêndice no final deste relatório.,
neste relatório introduzimos os tipos, métodos e uso de infiltração e exfiltração de dados baseados no DNS e fornecemos alguns indicadores para mecanismos de defesa.
DNS
DNS usa a porta 53 que está quase sempre aberta em sistemas, firewalls e clientes para transmitir consultas DNS. Ao invés do mais familiar Transmission Control Protocol (TCP), estas consultas usam User Datagram Protocol (UDP) por causa de sua baixa latência, largura de banda e uso de recursos comparados TCP-equivalent queries., UDP não tem nenhuma capacidade de erro ou controle de fluxo, nem tem qualquer verificação de integridade para garantir que os dados chegaram intactos.como é que o uso da internet (navegação, aplicações, chat, etc) é tão fiável? Se a consulta UDP DNS falhar (é um protocolo de melhor esforço afinal) em primeira instância, a maioria dos sistemas irá repetir um número de vezes e somente após várias falhas, potencialmente mudar para TCP antes de tentar novamente; TCP também é usado se a consulta DNS exceder as limitações do tamanho do datagrama UDP – tipicamente 512 bytes para DNS, mas pode depender de Configurações do sistema.,
Figura 1 abaixo ilustra o processo básico de como o DNS opera: o cliente envia uma string de consulta (por exemplo, mail.googlecom neste caso) com um certo tipo-tipicamente A para um endereço de host. Eu saltei a parte em que os sistemas DNS intermediários podem ter que estabelecer onde ‘.com’ existe, antes de descobrir onde ‘googlecom’ pode ser encontrado, e assim por diante.
Figura 1., Operação DNS simplificada
Uma vez que um nome é resolvido para um cache IP também ajuda: o nome resolvido para IP é tipicamente cache no sistema local (e possivelmente em servidores DNS intermediários) por um período de tempo. Consultas subsequentes para o mesmo nome do mesmo cliente, em seguida, não deixe o sistema local até que o cache expire. É claro que, uma vez que o endereço IP do serviço remoto é conhecido, As aplicações podem usar essa informação para permitir que outros protocolos baseados em TCP, como o HTTP, para fazer o seu trabalho real, por exemplo, garantindo que GIFs internet cat pode ser fiavelmente compartilhado com seus colegas.,
assim, ao todo, algumas dezenas de consultas DNS adicionais UDP de uma rede de uma organização seria bastante discreto e poderia permitir que uma carga maliciosa para beacon out para um adversário; comandos também poderiam ser recebidos para o pedido de processamento com pouca dificuldade.
Se quiser aprofundar a forma como o DNS funciona – desde que você digite as chaves para soletrar o nome de domínio que deseja navegar – então por favor leia este artigo.,
trilho de dados
assim como quando você navega na internet, se girando a partir de um resultado do motor de busca ou acessando diretamente um URL do site, suas consultas DNS também deixam um traço. Quanto de um traço depende dos sistemas e processos envolvidos ao longo do caminho, desde a consulta que sai do sistema operacional, até receber o endereço IP resultante.,
com Foco no lado do servidor e, usando alguns exemplos básicos, é possível para os servidores de DNS – especialmente aqueles com a extensão ou o log de depuração activada – para reunir toda uma série (sem trocadilhos) de informações sobre o pedido, e o cliente o solicite.,
Este artigo fornece alguma ideia do tipo de informação que poderia ser obtida a partir de logs do servidor DNS; um adversário que opere tal servidor obtém o IP remoto a enviar o pedido – embora este possa ser o último IP do servidor hop ou DNS, não o IP exacto do cliente que solicita–, bem como o texto de consulta em si, e qualquer que seja a resposta do servidor.
tunelamento DNS
Agora que temos uma compreensão comum de DNS, como ele opera em uma rede, e as capacidades de rastreamento do servidor, vamos cavar um pouco mais fundo nas capacidades de tunelamento., Nesta secção descreveremos como os faróis de comando e controlo (C2) podem operar sobre DNS, e como a exfiltração e infiltração de dados é possível.
C2
um canal C2 muitas vezes serve dois propósitos para o adversário. Em primeiro lugar, ele pode agir como um farol ou batimento cardíaco indicando que sua carga remota ainda está operando – ainda tem um batimento cardíaco – como ele está beaconing-out (comunicando) para o seu servidor.
pode considerar a operação DNS básica, como mostrado na Figura 1 acima, como um exemplo de batimento cardíaco., Se o implante malicioso no sistema cliente envia repetidamente uma consulta ao servidor do ator através da infra-estrutura DNS, o ator pode dizer pelos registros que um implante está em execução. O que se torna difícil é distinguir entre múltiplas vítimas infectadas com o implante.
considere outro exemplo descrito pela Figura 2 abaixo, onde o sistema cliente está comprometido com malware que está construindo strange-looking query strings para enviar DNS., Consultas como estas ainda atuam como um batimento cardíaco indicando ao adversário que sua carga útil ainda está ativa, no entanto, eles também fornecem alguns meta-dados básicos sobre a vítima e, o que é importante, maneiras de identificar uma vítima de outra.
Figura 2., Exemplo C2 Operação de pesquisa DNS
Usernames e hostnames podem nem sempre ser únicos, e alguns IPs podem ser duplicados através de várias redes usando a tradução de endereço de rede (NAT), no entanto os sistemas têm identificadores únicos universais (UUIDs) ou outras propriedades, que quando combinados podem criar um identificador único para um determinado host ou vítima.
alguns dos meta-dados da máquina comprometida podem ser enviados como texto simples, mas podem parecer mais suspeitos à primeira vista para qualquer um que veja tais strings em uma consulta DNS., Em muitos casos, os dados conterão caracteres não suportados pelo DNS, caso em que será necessária codificação. Na Figura 2 você pode ver o equivalente codificado base64 para os meta-dados, que é construído usando uma notação delimitada ‘-‘ para simples processamento e decodificação no lado do servidor, como mostrado na Figura 3 abaixo.
Figura 3., O dns do lado do servidor regista a comunicação C2
A Figura 3 mostra um exemplo do que um registo de DNS raw de uma aplicação de servidor de DNS pode parecer, com entradas de linha para a consulta do malware e a resposta do servidor de DNS, NXDOMAIN (ou domínio inexistente), neste caso.
de alguma forma, um log como este, ou talvez um pequeno banco de dados contendo os registros descodificados deles, poderia ser comparado com os painéis de controle botnet mais snazzy-look que permitem que o pastor de botnet para controlar seus sistemas de vítimas zumbis.
exfiltração
então, o que mais poderia ser enviado em consultas DNS?, Bem, qualquer coisa em teoria, desde que esteja codificado correctamente e não abuse dos limites de tamanho UDP. Uma maneira de contornar a última restrição pode ser enviar várias mensagens de um registro e fazer com que elas sejam costuradas de alguma forma no lado do servidor. No entanto, surgiriam complicações em datagramas abandonados ou em falta.
Ao contrário do TCP que assegura a retransmissão de pacotes falhados, o UDP não tem esse mecanismo., Um algoritmo seria necessário para entender quantas mensagens serão enviadas, e verificar o número correto chega, mas mais complicado do que isso, de alguma forma, pedir ao cliente para retransmitir determinados segmentos de dados novamente até 100% chega. Dependendo da quantidade de dados a transmitir – cada PDF no sistema, por exemplo – pode levar uma idade, e parecer extremamente suspeito para os administradores de rede.,
infiltração
Em contraste, infiltração de dados seja Código, comandos, ou um arquivo binário para cair em disco e executar poderia ser muito mais fácil, especialmente usando o tipo DNS de TXT (em oposição ao tipo de registro host a). Os tipos TXT foram projetados para fornecer texto descritivo, tais como detalhes de Serviço, nomes de contato, números de telefone, etc em resposta às consultas TXT DNS para nomes de domínio.Adivinha O que parece gostar de texto? Base64-dados não-texto codificados!, A figura 4 abaixo mostra a consulta idêntica que está sendo enviada para o site malicioso como Na Figura 2, no entanto, o tipo agora é TXT tanto na solicitação quanto na resposta, e os dados de resposta contêm os primeiros 300 caracteres de um arquivo executável binário codificado que poderia ser executado pelo malware cliente. Mais uma vez, usando os logs, o adversário seria capaz de saber qual cliente pediu a carga útil, e que a carga foi enviada (quem sabe se realmente chegou…).
Figura 4., Example C2 DNS query with TXT type response
But how does the malicious implant know to change the type to TXT or when to request whatever lies inside the “text” data? Ele pode ser incorporado à carga útil para consulta em um certo ponto em sua execução ou após uma certa quantidade de tempo, mas na realidade, ele vai ser impulsionado pelo ator usando o segundo propósito de um controle de canal C2.
In my earlier examples of C2 DNS communication the response from the DNS server was NXDOMAIN., Esta mensagem obviamente alcança o sistema cliente (e o malware) e pode ser usada uma mensagem ou instrução para a carga útil, mas é limitada sem parâmetros e detalhes. Entre NOERROR.
NOERROR, como o termo sugere significa que tudo funcionou bem-seu pedido foi processado e uma resposta espera por você. Com um NOERROR vem uma resposta que pode ser processada. Normalmente este é o IPv4 (para pedidos de tipo) ou IPv6 (para pedidos de tipo AAAA) ou pode ser TXT, como mostrado na Figura 4 acima., Focando em um exemplo simples-a resposta de endereço IPv4-o malware não precisa de um IP real para se comunicar, ao contrário do seu navegador que perguntou ” Onde está o googlecom?”. O malware já está em comunicação ao seu destino usando o C2 sobre DNS.
o malware pode usar a resposta IP para qualquer um dos 4 294,967,296 comandos ou instruções possíveis. Mais uma vez, mantendo isso muito simples, é possível que um valor particular no quarto octeto do IP, digamos, 100, indicaria ao malware para enviar uma consulta TXT DNS para o domínio do ator para coletar e executar uma carga útil., Value 10 in the first octet could mean to desinstall and wipe traces of the malicious payload from the operating system and event logs. Literalmente, as opções são infinitas, assim como os níveis de possível sofisticação.
dado que o adversário tem o controle sobre o servidor DNS, e que certas aplicações do servidor DNS ou daemons são altamente configuráveis, é possível enviar respostas condicionais de volta para o malware nos sistemas da vítima com base em pedidos enviados a partir deles.,
Por exemplo, se a consulta de entrada contém uma certa bandeira – um caractere-como o primeiro subdomínio para o nome de domínio, ele pode ser lido por um programa rodando dentro do serviço DNS no servidor e fornecer uma resposta personalizada de volta para o cliente. Isto pode ser usado para que o malware funcione através de um conjunto de tarefas automaticamente, e relatar de volta de acordo com os atores para receber sua próxima tarefa.
conclusão
DNS é uma ferramenta muito poderosa utilizada em quase todos os lugares, permitindo aplicações e sistemas para procurar recursos e serviços com os quais interagir., DNS fornece uma fundação de comunicação que permite protocolos de nível superior e mais poderosos para funcionar, mas pode significar que ele é ignorado de um ponto de vista de segurança, especialmente quando você considera a quantidade de malware é entregue através de protocolos de E-mail ou baixado a partir da web usando HTTP.
Por estas razões, o DNS é a escolha perfeita para adversários que procuram um protocolo sempre aberto, muitas vezes negligenciado e provavelmente subestimado para alavancar as comunicações de e para hosts comprometidos., A unidade 42 viu múltiplos exemplos de malware, e os atores por trás deles, abusando do DNS para ter sucesso em seus objetivos, como discutido neste relatório.
organizações podem se defender contra tunelamento DNS de muitas maneiras diferentes, seja usando plataforma operacional de segurança das redes Palo Alto, ou tecnologia de código aberto.,seguintes:
- Bloqueio de domínio-os nomes (ou IPs ou localização geográfica regiões) com base na reputação ou a percepção de perigo;
- Regras de “aparência estranha” consulta de DNS cadeias de caracteres;
- Regras em todo o comprimento, o tipo ou o tamanho do tanto de saída como de entrada ou de consultas de DNS;
- Geral endurecimento dos sistemas operacionais de cliente e a compreensão do nome de capacidades de resolução bem como a sua específicos ordem de pesquisa;
- Usuário e/ou o comportamento do sistema do google analytics que automaticamente anomalias, tais como novos domínios que estão sendo acessados, especialmente quando o método de acesso e de frequência são anormais.,
- redes Palo Alto recentemente introduziu um novo serviço de segurança DNS focado em Bloquear o acesso a nomes de domínio maliciosos.
outras informações também podem ser encontradas no ATT &CK framework documentation on Mitre’s website. Concretamente, as seguintes técnicas referem-se a conceitos discutidos neste relatório.,>
Thanks to Yanhui Jia, Rongbo Shao, Yi Ren, Matt Tennis, Xin Ouyang, John Harrison and Jens Egger for their input on this report.,
Appendix: Toolkit List
| Tool Name | Description |
| dns2tcp | dns2tcp was written by Olivier Dembour and Nicolas Collignon. It is written in C and runs on Linux. The client can run on Windows. It supports KEY and TXT request types. |
| tcp-over-dns | tcp-over-dns (TCP-over-DNS) was released in 2008., Ele tem um servidor baseado em Java e um cliente baseado em Java. Ele funciona em Windows, Linux e Solaris. Suporta compressão LZMA e tunelamento de tráfego TCP e UDP. |
| OzymanDNS | OzymanDNS é escrito em Perl por Dan Kaminsky, em 2004. É usado para configurar um túnel SSH sobre DNS ou para transferência de arquivos. Os pedidos são codificados base32 e as respostas são codificadas base64 registros TXT codificados., |
| iodo | iodo é um DNS túnel programa lançado pela primeira vez em 2006, com atualizações recentemente, em 2010. Foi desenvolvido por Bjorn Andersson e Erik Ekman. O iodo é escrito em C e é executado em Linux, Mac OS X, Windows e outros. O iodo foi portado para Android. Ele usa uma interface TUN ou TAP no endpoint. |
| SplitBrain | SplitBrain é uma variante do OzymanDNS., |
| DNScat-P / dnscat2 | DNScat (DNScat-P) foi lançado originalmente em 2004 e a versão mais recente foi lançado em 2005. Foi escrito por Tadeusz Pietraszek. A DNScat é apresentada como uma ferramenta de” faca do exército suíço”, com muitos usos envolvendo comunicação bidirecional através do DNS. DNScat é baseado em Java e funciona em sistemas Unix. DNScat suporta um registro e pedidos de registro CNAME (Pietraszek, 2004)., Uma vez que existem dois utilitários chamados DNScat, este será referido como DNScat-P neste papel para distingui-lo do outro. |
| DNScapy | DNScapy foi desenvolvido por Pierre Bienaime. Usa escápula para a geração de pacotes. DNScapy suporta tunelamento SSH sobre DNS, incluindo um proxy Socks. Ele pode ser configurado para usar registros CNAME ou TXT ou ambos aleatoriamente. |
| TUNS | TUNS, um IP através do DNS do túnel, foi desenvolvido por Lucas Nussbaum e escrito em Ruby., Ele não usa nenhum tipo de registro experimental ou raramente usado. Usa apenas os registos do CNAME. Ele ajusta o MTU usado a 140 caracteres para combinar os dados em um pedido DNS. TUNS podem ser mais difíceis de detectar, mas vem a um custo de desempenho. |
| PSUDP | PSUDP foi desenvolvido por Kenton Nascido. Injecta dados em pedidos de DNS existentes, modificando os comprimentos IP / UDP., Ele requer que todos os hosts que participam da rede secreta para enviar seus pedidos de DNS para um serviço de corretagem que pode manter mensagens para um host específico até que um pedido de DNS vem desse host. A mensagem pode então ser enviada na resposta. |
| Liberdade | HTTPS:/UDP/FTP/DNS/ECHO VPN & encapsulamento solução para Windows, Mac OSX, Linux e Android., Bypass proxies and access the Internet anonymously |
| Hexify | a tool is developed by Infoblox to do The penetrating test for DNS tunneling., |
Appendix: Malware List
| Malware Name | Description |
| DNS_TXT_Pwnage | A backdoor capable of receiving commands and PowerShell scripts from DNS TXT queries., |
| DNSMessenger | DNSMessenger é de Tróia de Acesso Remoto (RAT) que abre um backdoor para que os hackers podem controlar a máquina comprometida remotamente |
| plataforma de petróleo – BONDUPDATER | Trojan contra o Oriente Médio do governo pode usar Uma registros e registros TXT dentro do seu DNS, protocolo de encapsulamento para a sua C2 comunicações |
