Detecção de anomalias de rede no KATA

Introdução

Após o invasor penetrar em uma rede corporativa, as etapas seguintes do ataque costumam envolver o uso de protocolos padrão da infraestrutura de domínio: interações com o Kerberos, consultas DNS, acesso a serviços internos e pastas de rede, entre outras ações rotineiras. Essa atividade não costuma ser diferente do tráfego de rede legítimo, o que dificulta consideravelmente sua identificação com métodos clássicos de detecção de ataques de rede.

O Kerberoasting e o tunelamento de DNS já deixaram de ser técnicas raras há muito tempo; hoje, consolidaram-se como métodos padrão em ataques modernos, pois permitem aos invasores executar etapas críticas do comprometimento mantendo-se pouco visíveis para os mecanismos de defesa tradicionais. Essa tendência tem sido confirmada com regularidade em campanhas recentes, nas quais observamos a aplicação prática tanto do Kerberoasting quanto do tunelamento de DNS.

As ferramentas clássicas de defesa de rede tem bom desempenho quando o ataque apresenta um indicador estável e reconhecível: uma string característica na solicitação, um padrão conhecido de tráfego malicioso ou o código-fonte de um exploit. Esse método de detecção de ameaças continua eficaz, mas nem sempre se aplica à busca de ataques de rede que se confundem com o tráfego legítimo da rede corporativa.

Em vez de buscar indicadores explícitos de ataque, a tecnologia NAD (Network Anomaly Detection) examina todo o tráfego em busca de sinais suspeitos que não correspondem à atividade de rede típica do host. Entre as soluções da Kaspersky, essa tecnologia é implementada, em particular, pela plataforma Kaspersky Anti Targeted Attack (KATA).

O sistema analisa os dados dos pacotes de tráfego de rede (por exemplo, DNS, DCE/RPC, Kerberos, entre outros) e extrai deles parâmetros relevantes, usados para identificar comportamentos anômalos. Esse método permite detectar ataques a controladores de domínio, sinais de tunelamento e exfiltração de tráfego, comunicação C2 e outros cenários que podem indicar comprometimento da infraestrutura de rede.

No entanto, a tecnologia de detecção de anomalias de rede não se baseia, por si só, em um conjunto universal de indicadores. Cada cenário de ataque utiliza modelos de detecção próprios, que levam em conta as particularidades do protocolo de rede correspondente, o comportamento típico dos hosts e os desvios característicos em relação a ele. Neste artigo, analisamos dois exemplos práticos (a detecção de Kerberoasting e a detecção de tunelamento de DNS) para mostrar como esses princípios são aplicados nas regras NAD do KATA e por que essa abordagem tem mais eficácia do que a análise clássica por assinaturas.

Detecção do ataque Kerberoasting no KATA

Por que o Kerberoasting é difícil de detectar com ferramentas padrão

O ataque Kerberoasting se baseia na lógica padrão de funcionamento do protocolo Kerberos. O invasor localiza contas de serviço com identificador Service Principal Name (SPN), solicita para elas um tíquete Ticket-Granting Service (TGS) e tenta descobrir a senha usando o tíquete obtido e um ataque de dicionário. Se a senha for fraca ou não tiver sido alterada há muito tempo, o invasor pode obtê-la em texto claro por meio de força bruta. Posteriormente, as credenciais comprometidas podem ser usadas para movimentação vertical e lateral na rede.

A essência do ataque Kerberoasting está no fato de que o invasor, dispondo de uma conta comprometida com privilégios baixos e de um tíquete Ticket-Granting Ticket (TGT) válido para essa conta, pode solicitar tíquetes TGS com criptografia enfraquecida para contas de serviço com SPN. Nesse caso, é irrelevante se a conta comprometida tem ou não permissão de acesso a esse serviço. Ao obter esses tíquetes, o invasor pode descriptografá-los localmente, sem atividade de rede, por meio de tentativa e erro de senhas. Dessa forma, ele obtém o hash da senha da conta de serviço.

O objetivo do invasor é encontrar uma conta de serviço com senha simples. Muito provavelmente, será uma conta criada manualmente pelos administradores da infraestrutura ou de um serviço específico. Por isso, os invasores não têm interesse nas contas de serviço do sistema com SPN (por exemplo, CIFS/fileserver.company.local), visto que elas são geradas automaticamente e têm senhas muito complexas, inviáveis de descobrir por força bruta.

Vale destacar que as solicitações de tíquetes TGS feitas pelos invasores não são diferentes das solicitações legítimas. Em qualquer domínio, sempre haverá bastante tráfego Kerberos. Nisso reside a dificuldade de detectar o Kerberoasting: as solicitações legítimas de tíquetes de serviço (TGS-REQ) são indistinguíveis das solicitações dos invasores. Por isso, o principal método de detecção é a correlação de indícios indiretos, e não a busca por assinaturas. Os principais indicadores incluem: origem anômala da solicitação (host ou conta atípicos), aumento brusco no número de SPNs solicitados em um curto período, tentativas de obtenção de tíquetes de serviço para contas de serviço sensíveis ou privilegiadas, além de horário e quantidade de solicitações em desacordo com o padrão histórico do usuário e do host de destino.

A tecnologia NAD permite detectar a maioria desses indícios, ajudando o analista a passar de um grande volume de tráfego Kerberos para uma hipótese concreta de quem pode ter originado o ataque Kerberoasting, quais contas de serviço foram comprometidas e por que essa atividade é diferente da atividade comum.

Neste ataque, a anomalia de rede caracteriza-se pela obtenção, em um curto período, por parte de um único host (provavelmente usando uma única conta, cname), de tíquetes TGS ("msg_type": "KRB_TGS_REP") para diversos serviços exclusivos com SPN (sname). Essas contas de serviço não são de sistema.

Exemplo de par de eventos de solicitação TGS-REQ e resposta TGS-REP nos atributos da sessão de rede

Para detectar essa anomalia, a regra da tecnologia NAD “Indícios de ataque Kerberoasting” aplica a seguinte lógica:

1. Dentre as sessões de rede pelo protocolo Kerberos, no período correspondente à profundidade de busca da regra, são selecionadas apenas aquelas em que foi obtida uma resposta Kerberos TGS-REP bem-sucedida. Nesse caso, é necessário atender às seguintes condições:
   • o endereço IP a partir do qual a sessão foi iniciada não deve estar excluído na variável excl_sip;
   • o nome do cliente que enviou a solicitação (cname) não deve constar na lista de usuários excluídos (variável excl_users);
   • o SPN (sname) não deve estar excluído na própria regra. Os SPNs de sistema são excluídos da lógica, pois estão presentes na maioria das infraestruturas e não despertam interesse dos invasores nesse tipo de ataque. Caso fossem contabilizados no total de SPNs exclusivos, poderiam gerar um falso positivo na regra por ultrapassar o limite definido.
2. Dessas sessões são extraídos o cname (nome do cliente que enviou o TGS-REQ) e o sname (o próprio SPN).
3. As sessões são agrupadas pelo endereço IP de origem da solicitação e pelo nome da conta do cliente (cname), agregando sessões com SPNs exclusivos.
4. Se, para um mesmo endereço IP com uma mesma conta de cliente, dentro do período igual à profundidade de busca, forem obtidas respostas TGS-REP para N nomes de SPN exclusivos (em que N é maior ou igual ao valor da variável de limite count_spns), um alerta é gerado.
5. Durante o período igual ao tempo de resolução de repetição do evento, todos os alertas subsequentes relacionados ao mesmo endereço IP do cliente serão agregados ao primeiro alerta. Isso evita a criação de novos eventos, aumentando em vez disso o contador de agregação de alertas (indicador “Total de ocorrências”).

Vale destacar que essa lógica não pode ser implementada por meio de assinaturas de IDS. Suponhamos, por exemplo, que criamos uma regra Suricata para detectar pacotes Kerberos do tipo TGS-REP. Para evitar falsos positivos, excluímos da assinatura a lista de SPNs de sistema com senhas complexas e definimos um limite para a quantidade dessas respostas recebidas por um mesmo cliente. No entanto, uma regra desse tipo não consegue levar em conta a exclusividade dos nomes de SPN; restaria basear-se apenas no número de pacotes. Por isso, a quantidade de falsos positivos para essa assinatura será muito alta, já que em qualquer domínio haverá muitas mensagens TGS-REP legítimas totalmente idênticas.

Além disso, adicionar exceções e alterar valores de limite, adaptando a lógica à própria infraestrutura, é muito mais prático por meio de variáveis personalizadas na interface do que por meio da edição da estrutura da própria regra de IDS.

Criação de regra de detecção de anomalias de rede

As regras da tecnologia NAD são representadas como consultas SQL ao banco de dados do KATA baseado em ClickHouse. A seguir, mostramos como adicionar e colocar em funcionamento uma regra desse tipo.

Para começar a trabalhar com as regras da tecnologia NAD, é preciso acessar a seção “Regras personalizadas” da interface, e o subitem “Detecção de intrusões”. Na guia “Detecção de anomalias de rede”, é possível adicionar uma nova regra.

Interface da página “Detecção de anomalias de rede”

Ao adicionar uma nova regra, é possível selecionar o modelo de regra desejado entre os modelos prontos, fornecidos junto ao produto por meio das atualizações. Além disso, o analista pode modificar manualmente a regra adicionada a partir do modelo (nesse caso, ela passa a ser considerada personalizada, enquanto o modelo permanece inalterado) ou criar a sua própria do zero, seguindo as instruções.

Ao selecionar um modelo, o analista pode consultar a descrição da regra, além de alterar ou manter os valores padrão para:

• profundidade de busca (intervalo de tempo a partir do momento atual dentro do qual a consulta SQL será executada);
• cronograma (periodicidade de execução da consulta conforme a profundidade de busca indicada anteriormente);
• tempo de resolução de repetição do evento (período dentro do qual alertas semelhantes são agregados em um único alerta, em vez de serem exibidos como novos).

Interface de criação de uma nova regra NAD

Para o funcionamento correto da regra, recomendamos que, antes de ativá-la, você acesse a guia “Consulta SQL” e revise as variáveis usadas na regra (a descrição de cada variável fica disponível ao passar o cursor sobre o ponto de interrogação).

As variáveis correspondem a diversas listas, compostas por endereços IP, datas, strings e valores numéricos, que descrevem a infraestrutura de rede: controladores de domínio, servidores DNS, intervalos de tempo, segmentos críticos e outras entidades. Esse recurso permite adaptar cada regra a diferentes ambientes de rede, considerando as particularidades da infraestrutura sem alterar a lógica subjacente.

Em nosso exemplo, por meio de variáveis, a regra “Indícios de ataque Kerberoasting” pode ser configurada da seguinte forma, sem alterar a consulta SQL propriamente dita:

• excluir do escopo de verificação o endereço IP de origem das solicitações TGS-REQ (aqui é possível indicar um único valor, uma máscara de sub-rede ou um catálogo com lista de endereços e máscaras), bem como a conta do cliente que envia a solicitação (admite-se um único valor ou um catálogo com vários valores);
• alterar o valor de limite para geração de alerta com base na quantidade de SPNs exclusivos nas mensagens TGS-REQ.

Conteúdo da consulta e variáveis utilizadas na nova regra

Nessa mesma página, é possível verificar o funcionamento da regra antes de salvá-la.

Resultado da verificação de funcionamento da regra

Quando essa regra é acionada, é gerado um alerta do tipo NDR:NAD. No cartão do alerta, o analista visualiza informações básicas: endereços IP, portas e os participantes da interação de rede.

Cartão de alerta da regra da tecnologia NAD

Em seguida, é possível acessar o evento vinculado ao alerta, onde são apresentados uma descrição detalhada da anomalia e links para os hosts afetados.

Evento de acionamento da regra da tecnologia NAD

Se necessário, o analista pode visualizar e exportar as sessões de rede relacionadas ao acionamento da regra, que podem ser abertas a partir do alerta ou do próprio evento, pelo menu suspenso “Mostrar relações”.

Sessões de rede que provocaram o acionamento da regra

Em uma sessão específica, é possível obter informações padrão sobre as partes da interação, o volume de dados enviados e recebidos etc. Na guia “Atributos”, o analista pode visualizar os eventos registrados na sessão.

Atributos da sessão de rede

Detecção de tunelamento de DNS no KATA

Como funciona um túnel de DNS

O tunelamento de DNS é uma técnica de transmissão de dados ou de controle de malware por meio de firewalls, baseada na codificação de informações nas solicitações e respostas do protocolo DNS. Em vez da resolução de nomes convencional, o host infectado envia dados em subdomínios e recebe as respostas por meio de registros DNS. Esse channel pode ser usado para comunicação C2, evasão de restrições de rede ou exfiltração de dados.

Uma das formas de implementar o tunelamento de DNS é o uso de registros TXT, por exemplo. Nesse caso, o cliente gera solicitações DNS de registros TXT para nomes de domínio em que a parte direita do nome de domínio (os domínios de primeiro e segundo níveis) é estática, e a parte esquerda (o domínio de nível inferior) é usada para transmitir dados codificados ou criptografados do cliente para o servidor. A estrutura do nome de domínio, nesse caso, apresenta-se como o exemplo: ZFcABQAIBA[.]testlab[.]local, em que testlab[.]local é a parte direita estática do domínio, e ZFcABQAIBA é a parte esquerda variável, na qual são transmitidos os dados do cliente.

Em resposta a essas solicitações, o servidor envia comandos ou mensagens no campo de dados da resposta TXT. Devido à estabilidade da parte direita do nome de domínio, todas as solicitações do cliente chegam consistentemente ao mesmo servidor C2, mesmo que os servidores DNS para os quais o cliente envia as solicitações sejam alterados.

Solicitação DNS (à esquerda) e a respectiva resposta (à direita) no tunelamento de DNS por registros TXT

Identificar esse tipo de atividade maliciosa no tráfego DNS sem falsos positivos é bastante difícil. O DNS é permitido em quase todas as redes corporativas, nomes de domínio longos podem ser encontrados tanto na rede interna quanto na externa, e os registros TXT podem ser usados para fins técnicos legítimos.

A suspeita se forma a partir de um conjunto de indícios: muitos subdomínios longos e de aparência aleatória de um mesmo domínio de nível superior, alta frequência de solicitações, grande número de nomes exclusivos, tipos de registro incomuns e grande volume de dados na sessão DNS.

Após uma análise do tráfego DNS no contexto da tarefa de detecção, identificamos três campos de interesse:

• nome DNS solicitado;
• tipo de registro DNS;
• campo de dados TXT da resposta.

Na figura acima, é possível observar que todos os dados mencionados estão presentes na resposta DNS. Em condições reais, esse tipo de túnel transmite um volume de dados anormalmente grande para o tráfego DNS comum.

Troca de dados em um túnel de DNS

Assim, no caso do uso de tunelamento de DNS, a anomalia de rede caracteriza-se pelo seguinte cenário: o host de origem das solicitações envia dados na parte esquerda variável dos nomes de domínio, mantendo estática a parte direita (rrname), e recebe, nas respostas do servidor DNS, registros TXT (rtype) com dados variados (rdata). Nesse caso, o volume total de dados transmitidos tanto na parte esquerda do nome de domínio solicitado quanto nos dados TXT da resposta (rdata + rrname) deve exceder o limite definido.

Eventos de solicitação e resposta nos atributos da sessão DNS

Ao detectar o tunelamento de DNS, é importante considerar as seguintes particularidades:

• o túnel não fica limitado a uma única sessão DNS: os dados podem ser transmitidos em várias sessões com o servidor DNS, ou cada solicitação pode ser transmitida em uma sessão separada;
• uma solicitação DNS do cliente pode conter mais de um nome solicitado;
• uma resposta DNS pode conter vários registros TXT, além de um grande número de outros tipos de registro, não apenas TXT;
• é necessário excluir o tráfego entre servidores DNS, pois ele duplica as solicitações dos clientes e pode causar falsos positivos;
• apesar dos fatores descritos acima (parte esquerda do domínio anormalmente grande ou que muda com frequência, com a parte direita estática; string grande no registro TXT) serem alguns dos indícios de tunelamento de DNS, eles também podem ocorrer em tráfego legítimo.

Essas dificuldades abrem margem para falsos positivos na detecção do tunelamento de DNS, especialmente por meio de IDS. É praticamente impossível redigir uma regra de IDS precisa para esse tipo de atividade. Com raras exceções, as ferramentas de tunelamento de DNS apresentam marcadores estáticos que podem ser usados no método de detecção por assinatura. No entanto, na ausência desses marcadores, esse método não consegue garantir alta precisão de detecção sem gerar um volume elevado de falsos positivos. Nesses casos, é necessário aplicar uma abordagem abrangente, que combine diferentes indícios para melhorar a qualidade da detecção.

Lógica de detecção do tunelamento de DNS

Para adicionar uma regra de detecção da anomalia descrita, é possível usar o modelo pronto “Tunelamento de DNS por registros TXT” na interface de criação de nova regra. Na guia “Consulta SQL”, será exibida a lista de variáveis utilizadas:

• user_DNS_servers: lista de endereços dos servidores DNS internos da infraestrutura, para o funcionamento correto da regra e a redução do número de possíveis falsos positivos;
• excl_sip: endereços IP excluídos da aplicação da regra (é possível indicar um único endereço, uma máscara de sub-rede ou uma lista de endereços e máscaras);
• traffic_size: valor de limite para o volume de dados (em bytes) transmitidos no túnel.

Variáveis utilizadas na regra “Tunelamento de dados de DNS por registros TXT”

A regra de identificação dessa anomalia de rede é formada segundo o seguinte princípio:

1. Entre as sessões de rede pelo protocolo DNS, no intervalo de tempo correspondente à profundidade de busca da regra, são selecionadas as sessões em que foi registrada pelo menos uma resposta TXT.
   Nesse caso:
   • o endereço IP a partir do qual a sessão foi iniciada não deve estar excluído na variável excl_sip;
   • o endereço IP a partir do qual a sessão foi iniciada não corresponde aos servidores DNS internos listados na variável user_DNS_servers;
   • os nomes DNS solicitados pelo cliente não estão entre os excluídos dentro da regra.
2. As sessões DNS correspondentes são divididas em registros individuais, cada um referente a uma solicitação ou resposta específica. Desses registros, são selecionadas apenas as respostas DNS que contêm dados TXT.
3. Das respostas DNS são extraídos os nomes DNS, bem como os dados TXT correspondentes a esses nomes. São mantidos apenas os valores exclusivos.
4. Todos os registros são agrupados pelo endereço IP de origem das sessões. Todos os nomes DNS e dados TXT exclusivos são agregados.
5. Se, para um mesmo endereço IP, dentro da janela de profundidade de busca, o volume de bytes coletados em nomes DNS e dados TXT exclusivos exceder o limite definido (parâmetro traffic_size), um alerta é gerado).
6. Durante o período igual ao tempo de resolução de repetição do evento, todos os alertas subsequentes relacionados ao mesmo endereço IP do cliente serão agregados ao primeiro alerta. Isso evita a criação de novos eventos, aumentando em vez disso o contador de agregação do alerta (indicador “Total de ocorrências”).

Evento de acionamento da regra “Tunelamento de dados de DNS por registros TXT”

O principal diferencial da tecnologia NAD nesse cenário é a redução de ruído por meio da diminuição de falsos positivos e a aceleração da investigação. Um túnel de DNS raramente se apresenta como uma única solicitação maliciosa evidente. Ele deixa um rastro comportamental: repetição, comprimento, estrutura dos nomes, tipos de registro incomuns, muitos subdomínios com uma “base” fixa e desvio em relação ao padrão do host específico. O KATA reúne esses indícios em um único alerta e apresenta ao analista uma hipótese de ataque verificável, em vez de um conjunto de eventos DNS isolados.

Regras prontas de detecção de anomalias de rede no KATA

Os usuários do KATA devem levar em conta que, por padrão, as regras de detecção de anomalias de rede (NAD) não vêm ativadas no produto. As regras precisam ser adicionadas manualmente, conforme descrito nas seções anteriores, uma vez que a maioria das regras exige configuração manual por parte do analista por meio de variáveis. Isso permite adaptar a regra de forma mais flexível à infraestrutura de rede específica.

O analista pode criar novas regras de três formas.

1. Adicionar uma regra a partir de um modelo pronto e alterar as variáveis personalizadas. Nesse caso, a regra será considerada do sistema.
2. Adicionar uma regra a partir de um modelo pronto e alterar sua consulta SQL (para isso, será necessário ativar a opção “Desbloquear todos os valores do modelo”), implementando sua própria regra com base no modelo. Nesse caso, a regra deixa de ser do sistema e passa a ser personalizada.
3. Criar uma regra personalizada do zero. Nesse caso, é necessário conhecer os fundamentos da linguagem de consultas do SGBD ClickHouse e consultar as instruções.

No momento da publicação deste artigo, o produto dispõe de 59 modelos prontos de regras de detecção de anomalias de rede, sendo que novos modelos podem ser fornecidos com as atualizações. O produto pode ter até 200 regras ativas simultaneamente.

As regras prontas são divididas em 6 categorias:

• Large Data Transfers: monitoramento de sessões de rede de tamanho anômalo em diferentes protocolos, seja em horário comum, noturno ou em fins de semana;
• Suspicious Connections: identificação de conexões suspeitas que podem indicar atividade perigosa, Shadow IT, tentativas de ocultação frente a ferramentas de detecção de ataques, entre outros;
• Domain Attacks: detecção de ataques clássicos à infraestrutura de rede de domínio com uso de ferramentas de hacking;
• Reconnaissance Activity: atividade suspeita em sessões de rede por protocolos de domínio (Kerberos, DCE/RPC, LDAP, DNS), semelhante a reconhecimento dentro do domínio;
• Connections to Suspicious Resources: detecção de ações que violam as políticas de segurança da informação, potencial exfiltração de dados para além do perímetro e acesso ilegítimo à internet a partir de segmentos protegidos da rede;
• C2 Communication: detecção de sessões de rede características de um possível canal de comunicação ou túnel com um servidor C2.

A tabela abaixo apresenta a lista de modelos de regras de identificação de anomalias de rede no KATA.

Conclusão

Os exemplos dos ataques Kerberoasting e de tunelamento de DNS evidenciam, de forma clara, que a defesa moderna não pode se limitar somente à busca por assinaturas conhecidas e indicadores de comprometimento. Ambos os ataques utilizam protocolos que operam diariamente na rede corporativa. No plano dos eventos isolados, eles podem parecer atividade legítima, mas, no contexto comportamental, tornam-se indícios de comprometimento.

É exatamente essa lacuna que a tecnologia NAD preenche. Ela possibilita identificar não apenas acionamentos por assinatura em tráfego Kerberos ou DNS, mas também o desvio em relação ao modelo habitual: quem iniciou a atividade, com que frequência ela se repetiu, quais serviços ou domínios foram afetados e por que isso é relevante para a infraestrutura específica.

Dessa forma, o analista obtém um ponto de entrada claro para a investigação. Isso é particularmente valioso na detecção de indícios da atuação de grupos APT, que agem de forma discreta e tentam se camuflar de atividade legítima. A importância dessa capacidade só tende a crescer com o tempo: quanto mais rápido um ataque se desenvolve, mais importante se torna a capacidade de identificar uma atividade suspeita nos estágios iniciais, antes que ela evolua para o comprometimento de serviços essenciais ou vazamento de dados.