Combinação de machine learning supervisionado e não supervisionado para detecção de DGA

É com grande entusiasmo que anunciamos nossa primeira integração de segurança e ML supervisionado! Hoje, estamos lançando um pacote de solução de machine learning (ML) supervisionado para detectar a atividade do algoritmo de geração de domínio (DGA) nos seus dados de rede.

Além de um modelo de detecção totalmente treinado, nosso lançamento contém configurações de pipeline de ingestão, trabalhos de detecção de anomalia e regras de detecção que tornarão sua jornada desde a configuração até a detecção de DGA mais fácil e tranquila. Navegue até o nosso repositório de regras de detecção e veja como você pode começar a usar machine learning supervisionado para detectar atividade de DGA na sua rede e iniciar a sua avaliação gratuita com o Elastic Security hoje mesmo. 

Sobre os DGAs

Os algoritmos de geração de domínio (DGA) são uma técnica empregada por muitos autores de malware para que a infecção de uma máquina cliente consiga evitar medidas defensivas. O objetivo dessa técnica é ocultar a comunicação entre uma máquina cliente infectada e o servidor de comando e controle (C & C ou C2) usando centenas ou milhares de nomes de domínio gerados aleatoriamente, que acabam por resolver para o endereço IP de um servidor de C & C.

Para visualizar mais facilmente o que está ocorrendo em um ataque de DGA, imagine por um momento que você seja um soldado em um campo de batalha. Como muitos soldados, você tem um equipamento de comunicação que usa frequências de rádio para comunicação. Seu inimigo pode tentar interromper suas comunicações interferindo nas suas frequências de rádio. Uma maneira de conceber uma contramedida para isso é por salto de frequência, usando um sistema de rádio que muda as frequências muito rapidamente durante o curso de uma transmissão. Para o inimigo, as mudanças de frequência parecem ser aleatórias e imprevisíveis, dificultando a interferência.

Os DGAs são como um canal de comunicação de salto de frequência para o malware. Eles mudam de domínio com tanta frequência que fica inviável bloquear o canal de comunicação com o C2 do malware por meio do bloqueio do nome de domínio do DNS. A quantidade de nomes de DNS gerados aleatoriamente é simplesmente grande demais, impossibilitando qualquer tentativa de identificação e bloqueio. 

Essa técnica surgiu no mundo do malware com força em 2009, quando o worm “Conficker” começou a usar um grande número de nomes de domínio gerados aleatoriamente para comunicação. Os autores do worm desenvolveram essa contramedida depois que um consórcio de buscadores de segurança interrompeu o canal de C2 do worm fechando os domínios de DNS que ele estava usando para comunicação. A mitigação de DNS também foi realizada no caso do surto global de ransomware WannaCry em 2017.

Misturando-se para passar despercebido

Se o melhor lugar para esconder uma árvore é em uma floresta, há muito tempo os operadores de malware perceberam que se misturar com o tráfego normal da Web é uma das melhores maneiras de passar despercebido. Uma solicitação HTTP com um nome de domínio gerado aleatoriamente é um grande problema no monitoramento e detecção de segurança da rede. A grande quantidade de tráfego HTTP nas redes modernas inviabiliza a análise manual. Alguns malwares e bots têm strings de agente do usuário incomuns que podem gerar alertas com regras de busca, mas os autores de malware podem aproveitar facilmente uma string de agente do usuário que não pareça diferente de um navegador da Web.

Com o surgimento dos dispositivos móveis e da IoT, as strings de agente do usuário se tornaram tão numerosas que a análise manual de atividades suspeitas também está se tornando inviável. Os proxies da Web há muito tempo usam a categorização para procurar URLs que sejam conhecidas por serem suspeitas, mas os domínios de DGA são tão volumosos e efêmeros que muitas vezes não são categorizados. Os feeds de inteligência de ameaças podem identificar endereços IP e solicitações de HTTP associados a famílias e campanhas de malware conhecidas, mas eles são alterados com tanta facilidade pelos operadores de malware que essas listas muitas vezes já estão desatualizadas no momento em que as colocamos em uso nas buscas.

O grande volume de tráfego de rede coletado em muitas organizações e a natureza aleatória dos domínios gerados pelo DGA tornam a detecção dessa atividade um desafio para as técnicas baseadas em regras — e um uso ideal para o nosso modelo de machine learning supervisionado! Usando a Inferência, o modelo de ML para detecção de DGA da Elastic examinará os dados de DNS do Packetbeat enquanto estiverem sendo ingeridos no cluster do Elasticsearch, determinando automaticamente quais domínios são potencialmente maliciosos. Siga as etapas da próxima seção para começar. 

Para começar

Para começar a detecção de DGA dentro do app de segurança, lançamos um conjunto de recursos em nosso repositório de regras publicamente disponível para auxiliar na importação de modelos de machine learning para o Elastic Stack. Esse repositório não apenas fornece à nossa comunidade um lugar para colaborar na detecção de ameaças, mas também atua como um lugar para compartilhamento das ferramentas necessárias para testar e validar regras.

Consulte nosso post do blog e nosso webinar anteriores para obter informações adicionais sobre a iniciativa. Se você ainda não tem uma assinatura do Elastic Cloud, pode experimentá-lo por meio da nossa avaliação gratuita de 14 dias na nuvem e começar a testar o pacote de solução de ML supervisionado para detectar atividade de DGA.

Parte deste kit de ferramentas de regras é uma CLI (interface de linha de comando) para não apenas testar regras, mas também interagir com a sua stack. Por exemplo, lançamos várias bibliotecas Python para interagir com a API do Kibana. Isso foi fundamental na facilitação do processo de importação das dependências do modelo para tornar suas regras operacionais. Para começar a enriquecer os dados de DNS e receber alertas de atividade de DGA, siga estas três etapas:

Etapa um: importar o modelo

Primeiro, você deve importar o modelo de DGA, scripts Painless e processadores de ingestão para a sua stack. Atualmente, os modelos de DGA e quaisquer modelos não supervisionados para detecção de anomalia (há mais por vir) estão disponíveis no repositório detection-rules usando versões do github. Para carregar, execute o seguinte comando da CLI:

python -m detection_rules es <args_or_config> experimental setup-dga-model -t <release-tag>

Após carregar, você precisará atualizar sua configuração do Packetbeat, pois o modelo enriquecerá os eventos de DNS do Packetbeat com uma pontuação de DGA. Isso pode ser feito facilmente incluindo a configuração adicional na configuração de saída do Elasticsearch:

output.elasticsearch:
  hosts: ["your-hostname:your-port"]
  pipeline: dns_enrich_pipeline

O modelo supervisionado analisará e enriquecerá os eventos de DNS do Packetbeat, que contêm estes campos do ECS:

dns.question.name
dns.question.registered_domain

Então, o modelo adicionará estes campos aos eventos de DNS processados:

Uma captura de tela de uma amostra de dados de DNS enriquecidos é mostrada abaixo:

Observação: para obter informações mais detalhadas, consulte o readme de detection-rules.

Sobre as regras de DGA

Agora vamos dar uma olhada em algumas regras de busca condicional que detectam e alertam sobre a atividade de DGA. Duas regras de busca fornecidas no pacote podem ser habilitadas e executadas no mecanismo de detecção do app Elastic Security:

1. Machine Learning Detected a DNS Request Predicted to be a DGA Domain (O machine learning detectou uma solicitação de DNS que se prevê ser um domínio de DGA)
2. Machine Learning Detected a DNS Request With a High DGA Probability Score (O machine learning detectou uma solicitação de DNS com uma alta pontuação de probabilidade de ser de DGA)

A primeira regra faz a correspondência de qualquer evento de DNS que tenha um valor “1” de previsão de DGA, indicando que o nome de domínio de DNS provavelmente foi o produto de um algoritmo de geração de domínio e, portanto, é suspeito. A regra, encontrada aqui, simplesmente procura a seguinte condição:

event.category:network and network.protocol:dns and ml_is_dga.malicious_prediction: 1

A segunda regra faz a correspondência de qualquer evento de DNS com probabilidade de DGA superior a 0,98, indicando que o nome de domínio de DNS provavelmente foi o produto de um algoritmo de geração de domínio e, portanto, é suspeito. A regra, encontrada aqui, simplesmente procura a seguinte condição:

event.category:network and network.protocol:dns and ml_is_dga.malicious_probability > 0.98

Como todas as regras no mecanismo de detecção da Elastic, elas podem ser bifurcadas e customizadas para se adequar às condições locais. A pontuação de probabilidade na segunda regra poderá ser ajustada para cima ou para baixo se você achar que uma pontuação de probabilidade diferente funciona melhor com seus eventos de DNS. Qualquer regra poderá ter sua pontuação de risco aumentada se você desejar elevar a prioridade das detecções de DGA na sua fila de alertas. É possível adicionar exceções às regras para ignorar falsos positivos, como domínios de rede de distribuição de conteúdo (CDN) que podem usar nomes de domínio pseudoaleatórios.

Outra possibilidade futura que planejamos explorar é usar EQL (Event Query Language) para procurar clusters de alertas baseados em busca ou anomalias usando correlação multivariada. Por exemplo, se virmos um cluster de alertas de um host envolvido em provável atividade de DGA, aumentará a confiança de que temos uma detecção de malware significativa que precisa de atenção.

Esse cluster pode consistir em alertas de DGA combinados com outros alertas de detecção de anomalia, como um processo raro, um processo de rede, um domínio ou uma URL. Essas detecções de anomalia adicionais são produzidas pela biblioteca de pacotes de machine learning incluída no app Elastic Security.

Etapa dois: importar as regras

As regras no pacote de DGA podem ser importadas usando o recurso upload-rule do Kibana na CLI de detection-rules (no formato .toml). Como as regras fornecidas em Releases (Versões) do repositório detection-rules estão no formato .toml, basta executar o seguinte comando para carregar uma regra do repositório:

python -m detection_rules kibana upload-rule -h
Kibana client:
Options:
  --space TEXT Kibana space
  -kp, --kibana-password TEXT
  -ku, --kibana-user TEXT
  --cloud-id TEXT
  -k, --kibana-url TEXT
Usage: detection_rules kibana upload-rule [OPTIONS] TOML_FILES...
  Upload a list of rule .toml files to Kibana.
Options:
  -h, --help  Show this message and exit.
  -h, --help  Show this message and exit.

Etapa três: habilitar a regra e aproveitar

Agora que o modelo treinado de ML supervisionado foi importado na stack, os eventos de DNS estão sendo enriquecidos e as regras estão à nossa disposição, só nos resta confirmar se a regra está habilitada e aguardar os alertas! 

Ao visualizar a regra no mecanismo de detecção, você pode confirmar que ela está ativada conforme visto abaixo:

E agora aguarde os alertas. Depois que um alerta é gerado, você pode usar o recurso de linha do tempo para verificar o evento de DNS e iniciar sua investigação.

No entanto, nenhum modelo de machine learning é perfeito! Alguns domínios benignos serão erroneamente rotulados, o que tende a gerar falsos positivos. Na próxima seção, investigaremos como utilizar os trabalhos pré-configurados de detecção de anomalia e as regras que os acompanham, incluídos nesta versão, para eliminar falsos positivos.

Falsos positivos? A detecção de anomalia vem para nos salvar!

Como acontece com toda técnica de detecção, sempre haverá alguns falsos positivos. Eles podem vir na forma de tráfego de CDN ou domínios customizados que parecem ser maliciosos, mas que, na verdade, são normais no ambiente. Para garantir que nossa detecção de DGA se adapte ao ambiente de cada usuário, criamos um trabalho pré-configurado de detecção de anomalia chamado experimental-high-sum-dga-probability. Quando habilitado, esse trabalho de ML examina as pontuações de DGA produzidas pelo modelo de DGA supervisionado (sim, é ML o tempo todo) e procura padrões anômalos de pontuações excepcionalmente altas para um determinado endereço IP de origem. Uma pontuação de anomalia é atribuída a tais eventos.

Para maximizar o benefício do trabalho de detecção de anomalia, estamos lançando-o junto com uma regra complementar: Potential DGA Activity (Atividade de DGA em potencial). Isso criará um alerta baseado em anomalia na página de detecção do app de segurança.

Tanto o trabalho pré-configurado de detecção de anomalia quanto a regra complementar estão disponíveis em Releases (Versões) do repositório detection-rules. 

Como escolher a configuração certa para o seu ambiente

Tudo começa com o modelo de DGA supervisionado. Cada solicitação de DNS ingerida por meio do Packetbeat é analisada pelo modelo, e atribui-se uma probabilidade que indica o quanto o domínio envolvido na solicitação é malicioso. Você pode usar as saídas do modelo supervisionado diretamente no app de segurança usando as regras de lógica condicional discutidas na seção “Para começar” ou pode importar e habilitar nosso trabalho e as regras de detecção de anomalia pré-configurados para customizar ainda mais as detecções de acordo com as sutilezas do seu ambiente. 

Como escolher a configuração certa para o seu ambiente? Comece de um jeito simples. Habilite as regras de busca condicional apresentadas na seção “Para começar”. Essas regras atuam diretamente nas saídas do modelo supervisionado e darão rapidamente uma ideia de quanto ruído de fundo proveniente de falsos positivos existe no seu ambiente. Se acha que as regras de busca condicional operando nas saídas diretas do modelo supervisionado produzem alertas demais, você pode importar e habilitar o trabalho de detecção de anomalia. 

Em particular, a regra de detecção de ML que opera nos resultados do trabalho de detecção de anomalia pode ser útil para encontrar fontes com grandes quantidades agregadas de atividade de DGA, em vez de alertar sobre pontuações de DGA individuais, uma por uma. Se você não tem o módulo de ML em execução, inicie uma avaliação gratuita ou experimente no Elastic Cloud.

Veja algumas capturas de tela de amostra do modelo de detecção de anomalia e das regras associadas fornecidas com a versão:

Estudo de caso: detecção de atividade de DGA no mundo real no ataque SUNBURST

Vamos tentar aplicar esse fluxo de trabalho experimental de DGA à campanha do SUNBURST que ocorreu recentemente. 

Para recapitular, em 13 de dezembro a SolarWinds lançou um comunicado de segurança sobre um ataque bem-sucedido à cadeia de suprimentos na plataforma de gerenciamento de rede Orion. No momento em que este post foi escrito, o ataque afetava as versões do Orion lançadas entre março e junho de 2020. Da mesma forma, em 13 de dezembro, a FireEye divulgou informações sobre uma campanha global envolvendo o comprometimento da cadeia de suprimentos da SolarWinds que afetou algumas versões do software Orion.

Lançamos anteriormente um post do blog falando sobre os usuários do Elastic e o caso da SolarWinds, comumente chamado de SUNBURST. Esse post destaca que a tecnologia de prevenção de malware do Elastic Security usada tanto pelo Elastic Endgame quanto pelo Elastic Endpoint Security foi atualizada com detecções para os ataques descritos na divulgação da SolarWinds.

O SUNBURST foi um sofisticado ataque à cadeia de suprimentos do software que supostamente inseriu um malware no produto Orion da SolarWinds e o distribuiu usando um mecanismo de atualização automática. O tamanho, o escopo e a extensão do incidente ainda estavam sendo avaliados no momento em que este post foi escrito. 

Detecções existentes do Elastic Security

Um conjunto de 1.722 nomes de domínio gerados por DGA e usados pelo malware SUNBURST foi compartilhado por um pesquisador de segurança. Uma das regras existentes de detecção baseada em machine learning do Elastic Security, DNS Tunneling (Tunelamento de DNS), produz dois alertas baseados em anomalia nos nomes de DNS nesta amostra. De forma semelhante ao tunelamento de DNS, a proporção de domínios filho para pai na amostra de nomes do SUNBURST é muito alta. Este trabalho de ML associado a essa regra é codificado para analisar dados do Packetbeat, mas ele pode ser clonado e modificado para ingerir outros eventos de DNS no formato do Elastic Common Schema (ECS). Este é o trabalho de ML de tunelamento de DNS:

Este trabalho de ML tem uma regra de detecção associada chamada DNS Tunneling (Tunelamento de DNS):

Usando essas regras do Elastic Security, as detecções de anomalia, mostradas abaixo, podem ser transformadas em alertas de detecção e notificações opcionais, a fim de colocá-las na triagem de incidentes e nas filas de trabalho de resposta apropriadas. Esta é a aparência dessas detecções de anomalia do SUNBURST no app Elastic Machine Learning:

Trata-se de uma detecção útil, mas esse trabalho pode não detectar atividade de DGA o tempo todo. Para fortalecer a detecção de DGA, estamos incluindo o fluxo de trabalho experimental de detecção de DGA.

Uso do fluxo de trabalho experimental de DGA

Descobrimos que o fluxo de trabalho experimental de detecção de DGA com ML detecta a maior parte dessa atividade. Executamos esses domínios de DGA do SUNBURST por meio do modelo de detecção de DGA supervisionado discutido aqui (leia acima para saber os detalhes de como baixar e executar esse modelo e suas regras). Descobrimos que o modelo marcou 82% dos nomes na amostra como DGA, o que teria produzido 1.420 alertas no conjunto de amostra. Aqui está uma captura de tela dos nomes de DNS do SUNBURST que foram marcados como atividade de DGA pelo modelo supervisionado:

Esses eventos podem ser transformados em alertas usando a regra de detecção Machine Learning Detected a DNS Request Predicted to be a DGA Domain (O machine learning detectou uma solicitação de DNS que se prevê ser um domínio de DGA). Também podemos fazer uma cópia dessa regra e modificá-la para corresponder ao domínio pai observado usado por uma instância de malware específica, como o SUNBURST. Podemos fazer a correspondência com esse conjunto de eventos de DGA do SUNBURST adicionando um teste à consulta de regra como este:

network.protocol:dns and ml_is_dga.malicious_prediction: 1 and dns.question.registered_domain: "avsvmcloud.com"

Então, podemos atribuir à regra um nível de gravidade crítico e uma pontuação de alto risco de 99 para movê-la para o início da fila de trabalho de alerta e análise. Aqui está uma captura de tela dos alertas gerados por essa regra modificada para chamar a atenção para a detecção de atividade de DGA do SUNBURST:

Incluímos a regra Machine Learning Detected DGA activity using a known SUNBURST DNS domain (O machine learning detectou atividade de DGA usando um domínio de DNS do SUNBURST conhecido) no pacote. Em condições de infecção do mundo real, uma população de instâncias de malware usando DGA de alta frequência pode produzir alertas suficientes para desarmar o circuit breaker max_signals, que é definido como 100 por padrão. Nesse caso, podemos ter alertas para algumas instâncias de malware e não outras, dependendo de quais eventos tiveram correspondência primeiro na busca. 

Para garantir a identificação de um maior número de hosts infectados envolvidos na atividade de DGA, aumentamos o valor de max_signals nas regras de busca de DGA para 10.000. Observação: essa configuração não pode ser modificada no editor de regras; ela deve ser modificada em um arquivo de regras externo e, em seguida, importada. A configuração pode ser observada com a visualização de um arquivo de regras em um editor.

Nos casos em que a atividade de DGA é intensa e os alertas são numerosos, também podemos agregar e filtrar alertas ou eventos de DGA para contá-los por nome de host ou IP de origem em uma tabela de dados como esta:

Também estamos incluindo um dashboard de amostra para eventos de DGA do Packetbeat com visualizações e agregações, incluindo esta visualização da tabela de dados, que é agregada por source.ip. Como alternativa, você poderá agregar por host.name se seus eventos de DNS contiverem esse campo. Este arquivo chama-se dga-dashboard.ndjson e pode ser importado para o Kibana selecionando Import (Importar) na página Saved Objects (Objetos salvos), encontrada após selecionar Stack Management (Gerenciamento da stack).

Aqui está uma captura de tela desse dashboard mostrando eventos de DGA em um índice packetbeat-*:

Estamos aqui para ajudar

Você não está só! Se tiver problemas nesse processo ou simplesmente quiser saber mais sobre nossas filosofias quanto a detecção de ameaças e machine learning, fale conosco no nosso canal da comunidade no Slack ou em nossos fóruns de discussão, ou arregace as mangas e trabalhe conosco em nosso repositório de detecção aberto. Obrigado e aproveite!