Estudos de caso para o uso de ferramentas de análise de anomalias de rede: descoberta de campanhas de DNSpionage

Continuamos analisando casos para sistemas de análise de tráfego de rede (NTA) para objetivos de segurança cibernética. Hoje veremos como essas soluções podem ser usadas para detectar campanhas muito complexas, direcionadas e muito eficazes, chamadas DNSpionage e Sea Turtle.

Mas antes disso, lembrarei brevemente como o DNS (Sistema de Nomes de Domínio), subjacente à interação na Internet, funciona. O cérebro humano é tão organizado que é incapaz de memorizar muitos números e números que uma pessoa não associa a nada familiar. E o número de combinações memoráveis ​​de números e números é, de qualquer forma, pequeno. Portanto, para não memorizar e armazenar no notebook centenas e milhares de endereços IP dos sites em que estamos interessados, foi inventado o sistema DNS, que traduz os endereços simbólicos dos sites que são mais compreensíveis aos seres humanos em seus endereços IP. Se eu precisar acessar qualquer site, envie uma consulta DNS com o nome do site para o servidor DNS, que retornará seu endereço IP, para o qual vou.



Se você se aprofundar um pouco mais nos detalhes, o esquema parecerá mais complicado. Se o servidor DNS mais próximo de mim não souber o endereço IP do site que me interessa, ele me direciona para o servidor raiz, que me direciona para o servidor DNS da zona na qual o site de interesse para mim está localizado (por exemplo, “.ru”) e mais ao longo da cadeia até chegar a um servidor DNS que saiba o endereço IP necessário.



Acontece que confiamos nos servidores DNS que nos enviam os endereços IP dos sites que queremos visitar. E se alguém invadir um servidor DNS e falsificar um registro por corresponder um nome simbólico e endereço IP? E se formos direcionados para um site falso que pareça real e que possa roubar nossos logins e senhas, além de outras informações confidenciais sobre nós? Essa falsificação é chamada de redirecionamento de DNS e é usada por criminosos cibernéticos em ataques especialmente perigosos.



Em 2009, o "Exército Cibernético Iraniano" substituiu o twitter.com. Em 2011, 186 domínios foram substituídos por hackers turcos, incluindo HSBC, Vodafone, Acer e outros.Em 2013-2014, o Exército Eletrônico da Síria substituiu os sites NYT, Twitter, Huffingtin Post (a tentativa falhou contra o Facebook). No mesmo ano, ações semelhantes foram realizadas contra o WhatsApp, AVG e Avira. Um ano depois, os sites vietnamitas e malaios do Google foram substituídos, bem como o domínio do Federal Reserve Bank de St. Louis. Em 2016, uma certa quantidade de criptomoeda foi roubada do blockchain.info dessa maneira.

De fato, existem mais vetores de ataque de DNS, mas hoje veremos apenas os relacionados às campanhas de DNSpionage e Sea Turtle .



Agora que examinamos rapidamente como o DNS funciona e como você pode usá-lo em detrimento, podemos recorrer diretamente às campanhas de DNSpionage e tartarugas marinhas, começando pela primeira. Em 2018, a divisão Cisco Talos a encontrou em vários países do Oriente Médio. Consistia em duas partes - infecção de usuários e redirecionamento de DNS, que nem sempre estavam relacionadas, mas, por vários sinais, concluímos que o mesmo grupo provavelmente está por trás de ambas as partes.



No primeiro caso, os usuários vítimas receberam ofertas de emprego pelo LinkedIn e outros sites de busca de emprego. Todas as vagas levaram a sites falsos nos quais foram postadas vagas tentadoras. Dois sites foram registrados - hr-wipro [.] Com e hr-suncor [.] Com, que redirecionou os usuários para o legal wipro.com e suncor.com. Os links colocaram os arquivos no formato MS Word com macros incorporadas, cada uma das quais funcionou quando o documento foi aberto e fechado, respectivamente.



A primeira macro decodificou o arquivo PE e o salvou no endereço "% UserProfile% \. OracleServices \ svshost_serv.doc". A segunda macro renomeou "svshost_serv.doc" para "svshost_serv.exe". Em seguida, a macro criou a tarefa “chromium updater v 37.5.0”, que executou o arquivo executável e o repetiu a cada minuto. Esse malware executava as funções do RAT (ferramenta de administração remota), denominada DNSpionage. Ele interagiu com um domínio especialmente criado, solicitando / recebendo comandos que ele executou. Entre esses comandos estão a solicitação de conteúdo do diretório, a varredura da rede, a cópia de arquivos, o uso de utilitários remotos (WinSSHD, Putty, mimikatz), etc. Os comandos do servidor de comandos, bem como os resultados do trabalho, foram enviados em um dos dois modos - HTTP ou DNS. A segunda opção é geralmente mais simples, pois existe uma alta probabilidadeque você não possui uma inspeção completa do tráfego DNS e simplesmente não percebe o código malicioso da página DNS se comunicando com o servidor de comando.

O mais interessante começa no momento em que as partes do cliente e do servidor do malware se comunicam. O cliente envia a seguinte consulta DNS ofuscada para 0ffice36o [.] Com (o primeiro caractere é zero e a última letra é "o"): RoyNGBDVIAA0 [.] 0ffice36o [.] Com, onde os primeiros 4 bytes são gerados aleatoriamente e o restante (GBDVIAA0 ) são uma solicitação codificada em base32 (para cada vítima, seu próprio alfabeto base64 / dase32 foi selecionado). Decifrá-lo nos dá "0GT \ x00", onde GT é o identificador da vítima e \ x00 é o número da solicitação. O servidor de comando nos responde na forma de um endereço IP, que nem sempre é correto, por exemplo, 0.1.0.3 (o protocolo DNS permite isso). A segunda consulta DNS é assim: t0qIGBDVIAI0 [.] 0ffice36o [.] Com. O servidor de comando retorna o endereço IP: 100.105.114.0, com 4 caracteres na codificação ASCII comum,que neste caso significa o comando executável "dir \ x00". Em resposta, o lado do cliente da DNSpionage envia:

GLtAGJDVIAJAKZXWY000 0ffice36o com [.] [.] -> GJDVIAJAKZXWY000 -> "2gt \ x01 Vol»
TwGHGJDVIATVNVSSA000 0ffice36o com [.] [.] -> GJDVIATVNVSSA000 -> «2gt \ x02 ume»
1QMUGJDVIA3JNYQGI000 0ffice36o com [.] [.] - > GJDVIA3JNYQGI000 -> "2GT \ x03 in d"
iucCGJDVIBDSNF3GK000 [.] 0ffice36o [.] Com -> GJDVIBDSNF3GK000 -> "2GT \ x04 rive"
viLxGJDVIB] [Q] h "

Como parte da segunda parte da campanha de DNSpionage, o administrador do servidor DNS foi roubado, os registros DNS correspondentes foram alterados e os certificados criados com o LetsEncrypt, que será usado posteriormente no ataque "site no meio". É nesse site que o ataque de redirecionamento de DNS descrito anteriormente enviará vítimas selecionadas (em apenas 2 anos desta campanha, conseguimos identificar 25 redirecionamentos, o que indica não um ataque maciço, mas direcionado). Observe que tanto o seu próprio servidor DNS (se você tiver um) quanto os servidores DNS de terceiros que você já não controla podem ser atacados.

Como parte de suas atividades, os atacantes foram capazes de interceptar todo o tráfego direcionado aos domínios indicados pelos órgãos governamentais do Líbano e dos Emirados Árabes Unidos (Ministério das Finanças, polícia, Ministério das Comunicações e Telecomunicações, companhia aérea etc.), incluindo e-mail e VPN, que poderiam permita-lhes reunir informações adicionais sobre suas vítimas.

A campanha Cisco Talos Sea Turtle foi ainda mais complicada do que a DNSPionage, pois os atacantes atacaram não apenas servidores DNS, mas também servidores TLD (incluindo ccTLDs e gTLDs),



que permitiram que hackers desconhecidos atacassem organizações estatais e militares no Oriente Médio e no Norte. África, bem como serviços especiais e empresas de petróleo e gás.



Agora, volte à tarefa original e veja como os sistemas de análise de tráfego de rede podem ajudar a identificar as campanhas mencionadas. Deve-se notar imediatamente que, dada a sua complexidade e o fato de poderem ser direcionados a servidores DNS externos, os sistemas de classe NTA nem sempre nos ajudam. Mas nesses casos, quando se trata do modo DNS de operação da DNSpionage ou de um ataque a servidores DNS locais na estrutura da DNSpionage ou da Sea Turtle, podemos usar o Netflow para ver todos os sinais de um ataque necessário e bloqueá-los em tempo hábil.

Primeiro de tudo, precisamos definir nossos servidores DNS internos e adicioná-los a um grupo. É aqui que começa a introdução de praticamente qualquer sistema de monitoramento de anomalias. Para entender se encontramos anomalias no tráfego da rede ou não, primeiro precisamos decidir o que é normal e legítimo. E somente depois disso o sistema começa a funcionar com força total.



Isso pode ser feito manualmente, mas é melhor usar a função de classificar nós por tipo de tráfego, o que permite identificar todos os nós, mesmo aqueles que não conhecemos, mas que funcionam como servidores DNS.



No nosso caso, encontramos 5 servidores:



Depois de decidirmos sobre os servidores DNS legais, só podemos monitorar todo o tráfego DNS, o que é anômalo, ou seja, além do permitido. Por exemplo, é assim que podemos descrever uma regra para identificar servidores DNS internos que funcionam ilegalmente:



E essa regra se parecerá com esta, mostrando que, por alguma razão, temos 2 servidores DNS em nossa rede, um dos quais está localizado no segmento de servidores confidenciais e o segundo no segmento de dispositivos do usuário.



A regra a seguir permite identificar servidores DNS suspeitos externos que interagem diretamente com hosts internos, o que pode indicar que o servidor de comando DNSpionage funciona com dispositivos corporativos infectados:



E encontramos exemplos dessa interação:



De maneira semelhante, podemos configurar o sistema de detecção de anomalias de rede (e este artigo usa o Cisco Stealthwatch como exemplo) para detectar tentativas não autorizadas de acessar nós internos ao servidor DNS local (isso pode indicar que uma DNSpionage ou Sea Turtle está funcionando), bem como interação ativa hosts internos com hosts externos usando o protocolo DNS (isso registrará a operação da pionagem DNS no modo DNS).

Após corrigir as anomalias correspondentes e violações da política de segurança, devemos desenvolver regras que permitam sinalizar quaisquer tentativas futuras de conectar nós internos, excluindo servidores DNS locais, a servidores DNS externos (e vice-versa).



A segunda regra nos permite registrar quaisquer tentativas de interação usando o tráfego DNS na rede corporativa, excluindo os servidores DNS locais.



É assim que o monitoramento do Netflow (bem como de outros protocolos de fluxo) nos permite identificar estágios individuais de ataques bastante complexos que podem prejudicar empresas modernas e agências governamentais.

Source: https://habr.com/ru/post/undefined/