Por Threat Intelligence Team
Essa pesquisa tem o objetivo de apresentar discussões sobre o DNS over HTTPS (DoH) e de como ferramentas que oferecem este recurso podem expor redes corporativas a riscos e ameaças que abusam do protocolo para realização de ataques.
1. Introdução
- Trata-se de um protocolo que visa proporcionar maior privacidade aos usuários que navegam pela Internet. A equipe de Threat Intelligence da Tempest vem observando ao longo dos anos o crescimento da oferta de provedores DoH, assim como no seu uso.
- Desde sua proposta, o padrão sugerido e documentado na RFC8484 vem recebendo diversas críticas de administradores de rede e entidades de segurança e infraestrutura.
- Atualmente, os navegadores web mais populares, como o Google Chrome e Mozilla Firefox, suportam o uso do protocolo.
- A Microsoft inseriu em versões de teste do Windows 10 recursos para habilitar o uso do DoH.
- Especialistas de cibersegurança apresentaram ao longo dos últimos anos experimentos que salientam as preocupações e riscos para quem utiliza do protocolo.
- No último ano ocorreram incidentes que levantaram a “bandeira vermelha”, mostrando que atacantes podem abusar da infraestrutura de provedores DoH públicos legítimos para distribuir malwares e disfarçar domínios maliciosos.
2. Definição e função
Diversos profissionais da área de redes discutem as explorações do protocolo DNS como um problema de transparência. Através de todo o caminho da comunicação, do requerente até o servidor DNS que vai indicar o destino do acesso, qualquer intermediador tem conhecimento das informações em ambos os lados da negociação.
Isso quer dizer que cada nó no processo de comunicação consegue visualizar o conteúdo da consulta e pode identificar qual website está sendo procurado pelo usuário além de conseguir recuperar parcial ou completamente o endereço IP do solicitante. Um agente mal intencionado poderia tomar posse inapropriadamente destas informações e compartilhá-las, ou até mesmo mudar dados do tráfego DNS.
O DoH, defendido fortemente pela Mozilla[1], sugere uma alteração no processo de requisições para resolução de nomes. Padrão proposto pela IETF (Internet Engineering Task Force) em 2018, o DoH (DNS over HTTPS, RFC8484[2]) aplica uma nova forma de enviar consultas e obter respostas DNS (RFC1035) sobre HTTP (RFC7540) usando conexões HTTPS (RFC2818).
Através deste trabalho, ainda em andamento, o padrão normatiza como formatar e manter um serviço com maior privacidade além dos mecanismos comuns de negociação de nomes. O encadeamento dos protocolos deve ser capaz de receber solicitações de recursos (URIs) de clientes web utilizando o DoH e traduzir a solicitação para o endereço do recurso solicitado (URL). Ou seja, um resolvedor DoH usa URIs disponibilizadas por servidor DoH para realizar uma solicitação DNS.
Através de um navegador web, qualquer solicitação DNS seria resolvida primeiro internamente (Figura 1), caso exista um resolver de confiança já utilizado. Esta troca de mensagens seria feita sem encriptação TLS. A partir do momento que o navegador recebe uma resposta e passa a solicitar dados de uma rede pública, as consultas DNS em sequência são trocadas através da porta 443. O tráfego de mensagens encriptadas seria realizado por uma conexão HTTPS até um resolvedor DoH, que mediria a comunicação com o usuário até o conteúdo de destino. Este processo pode ser considerado homônimo ao padrão HTTP seguro, onde só o cliente e o servidor são capazes de decriptar o conteúdo das mensagens.
2.1. Objetivo da RFP
O objetivo da proposta existente na RFP é atrelar mecanismos que sejam capazes de criptografar requisições DNS com intuito de fornecer maior privacidade e prevenir os usuários de ataques man-in-the-middle, que são o cerne de diversos problemas atuais sobre abusos do protocolo DNS.
2.2. Quem utiliza
Em fevereiro de 2020[3], a Mozilla adotou o uso do DoH como padrão para usuários do Firefox nos EUA. Esta ação foi tomada dentro de um projeto voltado para melhorar a privacidade do DNS no navegador já em 2018, quando a RFC foi proposta. Desde a versão 62[4] já é possível usar este recurso.
A partir de setembro de 2020[5], o Google anunciou que o Chrome versão 85 passaria a usar o DoH como padrão em computadores pessoais e dispositivos Android. Atualmente, caso o provedor de origem do conteúdo acessado por qualquer usuário suporte o protocolo, será feita a mudança automática para o DoH. Este mecanismo é aplicado também caso exista suporte ao DNS sobre TSL (DoT).
A Microsoft adicionou[6] o suporte para o DoH na versão de Insider do Windows 10, em maio de 2020. Segundo a publicação, o recurso pode ser habilitado através do editor de registros do Windows. Essas e outras empresas consideradas Big Techs, estão cada vez mais próximas de utilizar e oferecer suporte ao protocolo de maneira mais ampla. Cada empresa vem defendendo a implementação à sua maneira, mas todas enfatizam que sua oferta é justificada pelo aumento da privacidade de navegação para qualquer usuário através da Internet.
3. Panorama
Nesta seção, alguns dos problemas já existentes sobre monitoramento e segurança do DNS serão discutidos e relacionados com pontos da proposta do DoH. Algumas provas de conceito (PoC) são citadas, assim como ameaças que abusaram do protocolo para realização de ataques.
3.1. DNS Tunneling
Técnicas de vazamento através de protocolos alternativos não são recentes no que concerne às ameaças cibernéticas. Atores maliciosos abusam do DNS de maneira abrangente a bastante tempo como canal de comunicação de comando e controle (C2) voltados para extração de dados. Ataques conhecidos como DNS Tunneling[7] são um dos meios que os adversários utilizam para encapsular dados de um protocolo e enviar consultas e respostas através do DNS para seus servidores. O tráfego malicioso capturado nestes ataques geralmente inclui payloads que podem ser adicionados ao que é executado dentro de um servidor DNS para controlá-lo de maneira remota[8].
Um dos problemas discutidos sobre o uso do DoH é que ele permite aos agentes maliciosos veicular técnicas de encapsulamento e resolução dinâmica[9] para abusar de terminais HTTPS e se passarem por tráfego benigno. Acima disto, os dados cifrados trazem uma dificuldade a mais para mecanismos de segurança comuns que já monitoram o DNS.
3.2. DoHC2
Em 2018, na MITRE ATT&CKcon, David Middlehurst, representante da equipe de segurança da Trustwave, apresentou uma pesquisa sobre técnicas que podem ser utilizadas para fins maliciosos na entrega de payloads e comunicação com servidor C2. Em sua estrutura (Figura 2), o pesquisador demonstrou como utilizar de assinaturas de endpoints para um ataque se passar por tráfego comum através do abuso do DoH.
A PoC[10], apelidada de DoHC2, se baseia no uso da ferramenta Cobalt Strike[11], comumente usada por equipes de red team e cibercriminosos. Através da criação de um C2 externo[12], um Beacon foi instanciado para simular a operação de adversários e se comunicar com o servidor DoH.
O diagrama apresentado demonstra o caminho implementado no ataque. Este modelo permitiu que o código inserido nos comandos do C2 e o tráfego de comunicação com a vítima fossem observados somente como tráfego comum (Figura 3) pelo provedor.
A pesquisa destacou também que, ao realizar as requisições, pelo menos um provedor DoH executou uma chamada para um resolvedor que compartilhou o endereço IPv4 do host inicial com outros serviços. Isso significa que abusos sobre o DoH podem também ser atrelados a outra técnica conhecida como domain fronting.
3.2.1. O ressurgimento do Domain Fronting
Trata-se de técnica utilizada[13] por adversários que exploram esquemas de roteamento gerenciados por uma rede de distribuição de conteúdo (CDN). Através da adoção de nomes de domínios diferentes para cada camada da comunicação HTTPS é possível ofuscar o destino pretendido do tráfego, ocultando as informações do site malicioso. Isso é realizado através do uso de diferentes nomes de domínio em cabeçalhos de dados TLS e também HTTP. Caso os domínios sejam providos pelo mesmo CDN (Figura 4), ao desempacotar os dados do cabeçalho da requisição um usuário é redirecionado ao domínio malicioso.
As controvérsias de alguns incidentes de segurança fizeram com que o Google e a Amazon removessem os recursos que viabilizavam o domain fronting em seus serviços. Em 2018[14], o Google anunciou que o Google App Engine não suportaria mais o domain fronting e a AWS fez alterações muito semelhantes sobre o CloudFront, tornando a aplicação da técnica, a princípio, impraticável.
3.3. goDoH
Leon Jacobs, da SensePost, publicou em outubro de 2018[15] uma PoC que implementa um mecanismo de vazamento de dados através do DoH, exemplificando como funciona o processo de sobreposição do DNS sobre HTTPS. O pesquisador faz uma analogia ao uso de uma API JSON capaz de realizar solicitações HTTP simples, por meio de um provedor como o Google, para realizar pesquisas DNS. Segundo Jacobs, domínios legítimos poderiam encaminhar tráfego para um C2 e evitar o bloqueio e rastreio de mecanismos de segurança. Para ele, essa seria uma nova forma de contornar o controle de uma CDN e realizar o domain fronting.
Isso é demonstrado através de uma ferramenta intitulada goDoH. Em seu experimento, foi utilizada uma estrutura que foca no monitoramento do tráfego DNS (Figura 5) com um resolvedor interno e um firewall de aplicação. Neste modelo, a configuração de segurança do DNS interno e do firewall conseguem filtrar e atuar com base no fluxo de solicitações DNS, seguindo a estrutura tradicional, existente em muitas organizações.
A partir deste diagrama, a pesquisa transfere a resolução de solicitações DNS para um provedor DoH (Figura 6).
A estrutura apresentada já traz um ponto de discussão, sobre como essa alteração impacta o monitoramento do fluxo de tráfego DNS. Pelo que é apresentado, o fator confiança do DNS fica indefinido, já que não é mais tratado como um protocolo específico. Filtros internos, como proxies e resolvedores DNS não conseguem interpretar as solicitações para o novo provedor. As requisições HTTPS encapsulando a consulta DNS contém uma URL para um domínio geralmente confiável. Um servidor DoH Google, por exemplo, pode ser utilizado para evitar estruturas tradicionais de monitoramento.
Uma vez que os componentes do goDoH são iniciados (Figura 7) é feita uma pesquisa de registro TXT DNS para o domínio de destino, que no arquivo texto tem o formato agentidentifier.targetdomain. Assim que o servidor recebe a consulta, se for a primeira vez que o agente a está realizando, o C2 registra a existência desse novo identificador como um fluxo de interação. Se não houver comandos a serem executados, apenas uma resposta padrão é enviada, sem comandos. Este loop é repetido infinitamente, através de intervalos definidos no código para manter a comunicação.
Se existem comandos a serem executados, codificados, comprimidos ou encriptados eles são enviados dentro do TXT de lookup da resposta .
O agente DoH então analisa a resposta do registro e interpreta a ação para executar o comando.
Com o resultado, a saída passa por um processo de encriptação e finalmente é traduzida, com seus dados particionados em pedaços para serem enviados como registro central de pesquisa do DNS. Com base no endereço IP dos dados de resposta é possível indicar se esse processo foi bem sucedido.
Do lado do servidor, um sinalizador é lido para entender se uma solicitação de entrada inicia um novo fluxo, se faz parte de um fluxo pendente ou se é o final de um fluxo e decide com base nisso qual deve ser a próxima etapa.
Depois que um fluxo de pesquisa de DNS é concluído, o tipo de protocolo é verificado e a ação é executada (Figura 8). Isso pode ser uma saída de comando exibido na tela ou um download de arquivo em que o conteúdo deve ser salvo.
No Início da proposta da RFP existiam poucos provedores. Atualmente uma consulta via cURL consegue listar mais de 40 organizações[16] que mantêm múltiplos servidores públicos DoH. Na página Wiki da biblioteca é disponibilizado um scrape[17] para varredura dos principais provedores, públicos e privados (Tabela 1).
3.4. Ameaças
Em 2019, equipe da Netlab360[18] reportou a descoberta de uma variante de malware abusando o protocolo DoH. Apelidado de Godlua por ter seu código fonte baseado na linguagem Lua, o backdoor atua sobre servidores Linux, nos quais os invasores estavam explorando uma falha do Confluence (CVE-2019-3396[19] – CVSS 9.8) que permitia realizar solicitações falsas do lado do servidor (SSRF) através do plugin WebDAV[20]. A pesquisa mostrou que o malware funciona como um bot DDoS e uma das características existente nas amostras é que o Godlua realiza solicitações DoH para recuperar registros TXT de um domínio contendo a URL que armazena informações sobre o servidor utilizado para armazenar dados e receber comandos do C2.
Mais uma vez, é destacado o uso do protocolo para criptografar os dados do domínio e oferecer o serviço através de uma URL com as informações do C2 invisíveis para mecanismos que monitoram o DNS, evitando seu bloqueio.
John Hammond, pesquisador da HuntressLabs, reportou em agosto de 2020[21], adversários abusando de provedores DoH do Google para carregar malwares. Segundo a BleepingComputer[22], criminosos estavam utilizando falsos logs de erro do Windows para esconder payloads maliciosos que eram carregados em tarefas agendadas de forma não autorizada em servidores Windows (Figura 9).
A análise de Hammond encontrou uma URL suspeita no código do payload. Uma vez que todas as tarefas são executadas, é possível recuperar a URL suspeita dentro do código do PowerShell malicioso. Ou seja, o DoH do Google está sendo utilizado para resolver uma requisição para um domínio suspeito que, ao ser consultado responde com um novo payload malicioso.
O retorno da comunicação contém no espaço de dados do pacote uma assinatura semelhante a uma autenticação de e-mail DKIM[23]. Trata-se de um cabeçalho adicionado à mensagem com conteúdo criptografado que é utilizado para verificar perfis de usuário e e-mail de um destinatário a um proprietário de domínio. Ao decifrar o conteúdo deste cabeçalho são encontradas representações decimais de endereços IPs maliciosos, que são utilizadas em novas consultas ao C2 (Figura 10) como forma de descentralizar a infraestrutura da infecção. Esta técnica foi utilizada para ofuscar informações que podem decifrar dados em pacotes de rede para analisar o conteúdo de requisições HTTP.
Os atacantes conseguiram injetar, nos registros TXT do DoH da Google, URLs maliciosas que, uma vez cifradas, parecem inofensivas ao monitoramento de segurança e, mesmo ao decifrá-las, o conteúdo malicioso em texto plano pode passar despercebido. Agregar isso ao método de entrega do malware sobre erros do Windows adicionou camadas de complexidade que ajudaram os atacantes a evitar sua detecção, e o pesquisador ressalta que isso passaria despercebido por diversos antivírus modernos.
4. Opiniões e rejeição
Existem diversas críticas[24] da comunidade de segurança e infraestrutura de rede sobre o DoH e o que realmente o projeto entrega aos usuários. Diversos especialistas já afirmaram que o fator privacidade não é o suficiente para garantir uma navegação segura. Através de dados sobre qual URL está sendo acessada e outras informações carregadas em solicitações HTTP ou HTTPS (como campos SNI) os ISPs conseguem rastrear usuários, mesmo que somente consigam distinguir a origem e o destino da comunicação.
Parte da crítica aborda como o DoH ignora as políticas empresariais, impactando de maneira negativa administradores que usam servidores DNS locais. O método de subscrição do protocolo DNS pode ser utilizado para contornar filtragens e mecanismos de segurança baseados em tráfego DNS. Desta mesma forma, adversários podem encapsular dados ao utilizar o protocolo DNS para evitar detecção e filtragem de rede. Isso também dificulta aos administradores aplicar meios para evitar ataques de sequestro de seus servidores, já que ferramentas de análise estática sobre as informações trocadas através do DNS não conseguiram interpretar os dados necessários para sua filtragem de conteúdo.
A APNIC (Centro de Informações de rede da Ásia-Pacífico) publicou[25] texto de opinião sobre como o DoH foge de um acordo de privacidade já aplicado sobre os ISPs. A proposta do DoH vem com a implementação de novos resolvedores, e assim não usa o próprio ecossistema de servidores DNS já existentes para o controle do tráfego de rede. Este ponto foi apresentado como crítica, com origem no fato de que a criptografia seria mantida por novos servidores e, portanto, fugiria da infraestrutura atual da camada DNS, permitindo a um invasor provisionar um servidor DoH para monitoramento do que é trafegado sem o conhecimento da CDN, por exemplo.
Por fim, a discussão aborda que os responsáveis por propor o DoH também concordam que o protocolo não corrige todos os vazamentos de privacidade e metadados do usuário. Os proponentes do DoH ainda declararam, segundo a APNIC, que o objetivo do projeto é dar ao usuário a capacidade de navegar por qualquer rede, segura ou não, com total privacidade.
5. Mitigação e monitoramento
Tanto o DoHC2 quanto o goDoH foram utilizados para analisar o comportamento do uso do protocolo nas organizações. A SensePost utilizou um proxy HTTP (Figura 11) para observar como é traduzida a comunicação cliente-servidor com o goDoH e encoraja equipes de segurança a utilizarem a ferramenta em seus ambientes de teste.
A análise da Trustwave termina com algumas recomendações para o monitoramento:
- Bloquear ou monitorar o tráfego de endpoint sobre serviços DoH. Caso seja de interesse da organização é recomendado estudar a implementação de resolvedores internos;
- Criar rotinas para inspeção de requisições HTTP subjacentes em busca de indicadores sobre a comunicação de servidores DoH, como conteúdo decifrado do TLS em campos ‘application/dns-json’ ou ‘application/dns-message’;
- Criar rotinas para potencializar o reconhecimento de domain fronting, onde o nome do host da conexão TLS de saída não corresponde ao host do cabeçalho HTTP subjacente;
- Aplicar detecções baseadas em heurísticas (análise de múltiplos critérios/alertas no tráfego de rede) ou tamanhos de pacotes, frequência e volume, tempo de conexão ou solicitações entre domínio e destino.
Uma pesquisa do SANS Institute[26], publicada em abril de 2020, implementou o goDoH como mecanismo de entrega de um malware de teste em três cenários distintos, com o intuito de analisar artefatos gerados que possam ser utilizados na detecção de comportamentos maliciosos através do DoH.
Nesta pesquisa foram utilizados ambientes virtuais baseados em hosts VMWare ESXi, contendo um firewall pfSense (integrado com o Suricata, IDS/IPS open source) como gateway para rede local. Em cada cenário o Firefox foi configurado para utilizar o provedor DoH da CloudFlare e tudo isso foi observado de maneira centralizada no Security Onion, distribuição Linux open source para threat hunting, monitoramento de segurança e gerenciamento de logs.
No primeiro cenário, nenhum registro adicional para enriquecimento do monitoramento foi habilitado na VM. O tráfego capturado permitiu a identificação de consultas DNS através do Firefox. A natureza do tráfego encriptado não pôde ser totalmente traduzida, mas o Suricata gerou diversos alertas baseado no monitoramento de tráfego do provedor DoH da CloudFlare, através de política que observa o SNI (Server Name Indication) para identificar tráfego DoH.
No segundo cenário, o objetivo do experimento era identificar mais indicadores que garantam visibilidade. Isso foi feito habilitando o registro de tráfego HTTP do Firefox[27]. Consultas DoH foram capturadas e coletadas do ElasticSearch. Assim, o Security Onion foi utilizado para decifrar dados de tráfego de consultas e respostas DoH reconhecidas no ambiente (Figura 12).
Já no terceiro cenário, foi utilizado um novo método para análise de dados encriptados que fosse além do que era trafegado no navegador web. Caso o host fosse comprometido por outros agentes maliciosos utilizando a porta 443 para comunicação, isso seria transparente para a detecção do cenário 2. Por isso, foi utilizada uma ferramenta para analisar todo tráfego de rede através da porta, o PolarProxy. O pfSense[28] foi configurado para redirecionar todo tráfego TLS para o PolarProxy, que decifrava o conteúdo destinado à porta 443 e enviava uma cópia dos dados para o ElasticSearch.
Foi possível identificar desvios no tamanho dos pacotes negociados entre o goDoH C2 e o host infectado, classificar o intervalo de comunicação com o Beacon e o C2 e ainda identificar o nome do domínio malicioso utilizado no experimento (Figura 13).
6. Comentário do analista
A aplicação do DoH passou, de 2018 a até a data atual, de um ambiente experimental para ser oferecido em ferramentas web e sistemas de grandes empresas através de produtos difundidos no mercado. As questões apresentadas neste documento assinalam riscos e a inevitabilidade do debate sobre o uso e monitoramento do DoH.
Em uma série de atualizações publicadas em março deste ano, o Cobalt Strike 4.3[29] adicionou suporte a novos grupos de Beacons DNS maleáveis e opções para alterações de indicadores de hosts DNS. A característica que mais chama a atenção é que agora o Cobalt Strike permite que Beacons DNS[30] especifiquem quais resolvedores devem ser utilizados em vez dos padrões que um navegador define Este recurso dá a um adversário permissão para configurar a comunicação através de resolvedores públicos, ou seja, possibilitar o uso de provedores DoH ou até mesmo provedores maliciosos.
A pesquisa publicada pela SANS Institute apontou exemplos de como monitorar o tráfego DoH presente em redes corporativas e é bastante recomendado que cada entidade aplique análise uma própria, respondendo como o DoH está sendo utilizado em sua rede interna e assim viabilizar a criação de políticas de segurança de redes que correspondam às necessidades de operação e trabalho da organização.
Ferramentas que permitem a exploração prática do protocolo DoH e as críticas já existentes enfatizam que este pode vir a se tornar um um vetor para realização de ataques mais sofisticados, principalmente se navegadores comuns passarem a oferecer o suporte total ao DoH de maneira padrão.
REFERÊNCIAS
[1] A cartoon intro to DNS over HTTPS. Mozilla. 31 maio 2018. Disponível em https://blog.nightly.mozilla.org/2018.
[2] DNS Queries over HTTPS (DoH). P. Hoffman e P. McManus. Outubro 2018. Disponível em https://tools.ietf.org/html/rfc8484.
[3] Firefox continues push to bring DNS over HTTPS by default for US users. Mozilla. 25 fevereiro 2020. Disponível em https://blog.mozilla.org/blog.
[4] Improving DNS Privacy in Firefox. Mozilla. 01 junho 2018. Disponível em https://blog.nightly.mozilla.org/2018.
[5] A safer and more private browsing experience on Android with Secure DNS. Google. 2 setembro 2020. Disponível em https://blog.chromium.org/2020/.
[6] Windows Insiders can now test DNS over HTTPS. Microsoft. 13 maio 2020. Disponível em https://techcommunity.microsoft.com/.
[7] Protocol Tunneling. MITRE. 27 Março 2020. Disponível em: https://attack.mitre.org/techniques/T1572/.
[8] Application Layer Protocol: DNS. MITRE. 21 Outubro 2020. Disponível em: https://attack.mitre.org/techniques/T1071/004/.
[9] Dynamic Resolution. MITRE. 2 Outubro 2020. Disponível em: https://attack.mitre.org/techniques/T1568/.
[10] Playing with DNS over HTTPS (DoH). dtmsecurity Blog. 21 Novembro 2018. Disponível em: https://dtm.uk.
[11] Cobalt Strike. MITRE. 24 Abril 2021. Disponível em: https://attack.mitre.org/.
[12] ExternalC2. Ryhanson Github. 23 Novembro 2017. Disponível em: https://github.com/ryhanson/ExternalC2.
[13] Proxy: Domain Fronting. MITRE. 16 Setembro 2020. Disponível em: https://attack.mitre.org/techniques/T1090/004/.
[14] As Google and AWS kill domain fronting, users must find a new way to fight censorship. TechRepublic. 2 Maio 2018. Disponível em: https://www.techrepublic.com/.
[15] Waiting for goDoH. SensePost. 28 Outubro 2018. Disponível em: https://sensepost.com/blog/2018/waiting-for-godoh/.
[16] Publicly available servers. cURL GitHub. 23 Abril 2021. Disponível em: https://github.com/curl/curl/wiki.
[17] Scrape DoH provider URLs from cURL’s wiki page. Kimbo GitHub. 13 Abril 2021. Disponível em: https://gist.github.com/kimbo.
[18] An Analysis of Godlua Backdoor. Netlab 360. 1 Julho 2019. Disponível em: https://blog.netlab.360.com/.
[19] CVE-2019-3396 Detail. NIST. 9 Fevereiro 2021. Disponível em: https://nvd.nist.gov/vuln/detail/CVE-2019-3396.
[20] Web-based Distributed Authoring and Versioning. Wikipedia. Disponível em: https://pt.wikipedia.org/wiki/WebDAV.
[21] Hiding in Plain Sight || Part 2. HuntressLabs. 20 Agosto 2020. Disponível: https://blog.huntresslabs.com/.
[22] Attackers abuse Google DNS over HTTPS to download malware. BleepingComputer. 2 Setembro 2020. Disponível em: https://www.bleepingcomputer.com/news/.
[23] Domain Keys Identified Mail. Antimspam.br. Disponível em: https://antispam.br/admin/dkim/.
[24] DNS-over-HTTPS causes more problems than it solves, experts say. ZDNet. 6 Outubro 2019. Disponível em: https://www.zdnet.com/.
[25] Opinion: Centralized DoH is bad for privacy, in 2019 and beyond. APNIC. 3 Outubro 2019. Disponível em: https://blog.apnic.net/2019/10/03.
[26] Dealing with DoH: Methods to Increase DNS Visibility as DoH Gains Traction. SANS Institute. 16 Abril 2021. Disponível em: https://www.sans.org/.
[27] HTTP logging. Mozilla. Disponível em: https://developer.mozilla.org/.
[28] PfSense. PfSense Org. Disponível em: https://www.pfsense.org/.
[29] Cobalt Strike Release Notes. HelpSystems LLC. Disponível em: https://www.cobaltstrike.com/.
[30] Cobalt Strike DNS Direct Egress Not That Far Away. DTMSecurity. 3 Março 2021. Disponível em: https://dtm.uk/.
