Conteúdo de detecção proativa: CVE-2019-0708 vs ATT&CK, Sigma, Elastic e ArcSight

Acredito que a maioria da comunidade de segurança concordou que a vulnerabilidade CVE-2019-0708 é de prioridade crítica para lidar. E embora dizer “corrija seus problemas!” pareça a primeira coisa que alguém deve pensar, as lembranças do WannaCry e NotPetya ainda estão frescas na minha mente. Sabemos que as correções não acontecerão na velocidade e na escala necessárias. E assim, estamos, novamente, construindo as regras de detecção!

Um detalhe pequeno, mas importante: a vulnerabilidade CVE-2019-0708 está relacionada aos Serviços de Área de Trabalho Remota (RDS), portanto, a implementação real da Microsoft do uso do Protocolo de Área de Trabalho Remota (RDP) no Windows. O protocolo RDP em si está bem. Sinto que esta afirmação precisa estar aqui para evitar todos os tipos de hype semelhante ao que vimos durante o surto do Wannacry.

A hashtag “BlueKeep” foi usada pela primeira vez por Kevin Beaumount. Eu a escolhi por 2 razões: referência a GoT e para encontrar postagens relevantes no Twitter, já que não se pode simplesmente hashtag um CVE (a menos que se removam os traços). BlueKeep está apenas facilitando o twiterops 😉

https://twitter.com/GossiTheDog/status/1128348383704485895

Virando a balança a favor dos defensores.
Para estabelecer uma teoria de detecção, devemos considerar dois modelos de ameaça:

1. Ameaça de worm, semelhante ao cenário WannaCry.
2. Atores APT, usando a vulnerabilidade como parte de uma campanha mais sofisticada, assim como EternalBlue e SMB foram apenas parte do desastre do NotPetya.

Para identificar ativos em risco, vamos nos referir à tabela a seguir, compartilhada por cortesia da Dragos:

fonte: https://dragos.com/blog/industry-news/ics-impact-from-microsoft-rdp-vulnerability/

O CVE-2019-0708 pode ser usado para Acesso Inicial em grande escala, semelhante ao Wannacry? Uma rápida olhada nos dados do Shodan revela muitas máquinas na internet com a porta 3389 exposta e executando as versões do Windows potencialmente vulneráveis:

https://www.shodan.io/search?query=port:3389+os:”Windows+7+or+8″

https://www.shodan.io/search?query=port:3389+2003

https://www.shodan.io/search?query=port:3389+2008

https://www.shodan.io/search?query=port:3389+os:”Windows+XP”E no total, estamos olhando para 2,375 milhões de hosts com RDP acessível da internet – mas não tire conclusões ainda!

https://www.shodan.io/search?query=Remote+Desktop+Protocol

Citando o tweet de Dan Tentler de 23 de abril de 2017 “nem todos esses hosts são Windows, e nem todas essas portas são SMB”. Adaptando isso para os dias de hoje “Nem todos esses 2,3 milhões de hosts são Windows e nem todas essas portas são serviços vulneráveis ao CVE-2019-0708”. Se compararmos isso com a linha do tempo do WannaCry, estamos na fase em que o MS-17010 já está fora, o EternalBlue ainda não foi lançado e, portanto, não podemos ir e escanear o próximo DoublePulsar. E até que tal PoC exista e alguém escanei para backdoor presente, assim como Dan fez há 2 anos, não podemos ter certeza absoluta de que as coisas estão indo para o sul. No entanto, eles estão “prestes a” chegar a esse estágio e talvez ainda tenhamos 30 dias para colocar defesas, talvez menos.

https://twitter.com/Viss/status/856227372785221632

Enquanto podemos debater se essas máquinas são usadas por organizações reais, seu status de correção, segmentação de rede etc., é de conhecimento comum que muitas empresas ainda operam versões vulneráveis do Windows e os ciclos de correção podem ser difíceis para esses sistemas. Além disso, em comparação com o WannaCry, vemos aproximadamente 24K+ hosts potencialmente exploráveis vs 140K+ hosts com DoublePulsar enfrentando a internet 3 semanas antes do incidente.

O maior perigo neste estágio é a exploração do CVE-2019-0708 uma vez dentro da organização para comprometer rapidamente os hosts e para Movimento Lateral. E, como Exploit PoC não está disponível até o momento da escrita deste artigo (no entanto, muitos falsos estão), usaremos todas as ferramentas ao nosso dispor para construir a detecção -antes- mesmo que o exploit esteja disponível.

Considerando tudo isso, as 3 principais coisas que você pode fazer como defensor são:

1. Implantar conteúdo de detecção proativa.
2. Advocar rigorosamente pela correção ou mitigação da vulnerabilidade.
3. Acompanhar o desenvolvimento da situação seguindo informações de pesquisadores em quem confia.

Para reforçar alguns dos pontos, gostaria de me referir a 2 tweets de Florian Roth sobre o problema:

Regras Sigma, primeiro ao resgate.

A primeira regra, referida posteriormente como Sigma #1, foi compartilhada por cortesia de Markus Neis no repositório do github Sigma abordando a técnica de Movimento Lateral T12010 / Exploração de Serviços Remotos https://attack.mitre.org/techniques/T1210/ :

Dentro de uma hora, uma regra semelhante (Sigma #2) foi publicada no SOC Prime TDM por Roman Ranskyi como uma comunidade / livre para usar com algumas distinções na lógica de detecção se estendendo para T1036 / Disfarce https://attack.mitre.org/techniques/T1036/ e T1046 / Varredura de Serviços de Rede https://attack.mitre.org/techniques/T1046/ .

Basicamente, temos detecções TLP:WHITE e TLP:GREEN lá fora, antes do exploit! Mas isso é suficiente para detectar um ataque em escala total?

Aprendizado de Máquina, dando um passo adiante.

Vamos explorar como as capacidades de Aprendizado de Máquina podem nos dar uma vantagem sobre o problema e começar com a criação de uma receita para o Elastic stack.

Receita de ML: Detectar Movimento Lateral sobre RDP potencialmente relacionado ao CVE-2019-0708

Teoria

Um número excessivo de endereços IP de destino únicos em conexões RDP iniciadas de um host durante uma janela de tempo limitada pode ser uma indicação de Movimento Lateral e disseminação do worm que usa o protocolo RDP como método de propagação (usando o exploit do RDS relacionado à vulnerabilidade CVE-2019-0708).

Descrição

Esta receita de caso de uso identifica endereços IP de origem que potencialmente podem ser pontos de propagação de worm RDP ou Movimento Lateral via RDP / T1076 entre segmentos de rede.

Efetividade

Esta receita de caso de uso é fornecida como parte de uma Detecção Proativa Automatizada para Vulnerabilidade de Execução Remota de Código dos Serviços de Área de Trabalho Remota (CVE-2019-0708) ainda inexistente worm RDP, que se espera que explore a vulnerabilidade e use RDP para o Movimento Lateral através de segmentos LAN internos. Informações adicionais a respeito do comportamento do worm RDP após observá-lo no ambiente selvagem podem ser usadas para ajustar a receita para produzir resultados de detecção mais eficazes.

Tipo de Caso de Uso

Comportamento de Ataque Elementar (EAB) – Este caso de uso detecta anomalias associadas a comportamentos de ataque elementares. Cada anomalia detectada é atribuída a uma Pontuação de Anomalia normalizada e é anotada com os valores de outros campos nos dados que têm influência estatística na anomalia. Comportamentos de ataque elementares que compartilham Influenciadores estatísticos comuns estão frequentemente relacionados a um progresso de ataque comum.

Fonte de Dados do Caso de Uso

Eventos de Netflow, logs de fluxo VPC ou dados similares no formato ECS, que contenham logs de conexões RDP entre hosts Windows dentro de segmentos LAN internos.

Receita de Caso de Uso

Campo requerido

Exemplo de Consulta do Elasticsearch:Exemplo de Consulta do Elasticsearch:Análise de Aprendizado de Máquina / Configuração do Detector:Análise de Aprendizado de Máquina / Configuração do Detector:

Detector(es): high_distinct_count(destination.ip) over source.ip
Bucketspan: 15m
Influencer(s): source.ip

Explorando os resultados do ML no Elastic stack.

A visão de métrica única nos encontra os drones que estávamos procurando. Assim, quanto melhor o conjunto de dados que temos em mãos, mais precisa será a detecção de outliers.

O Anomaly Explorer ajuda a explicar a história das conexões RDP usuais vs um comportamento tipo worm ou um administrador super dedicado que pode ou não estar trabalhando para o ator da ameaça APT 😉

O som quente do motor de correlação ArcSight.

Neste estágio, temos a lógica de detecção claramente definida, vamos ver se podemos aplicá-la na tecnologia que muitas empresas ainda usam como ferramenta principal de SIEM. Há várias tarefas que tentaremos resolver em relação à ameaça iminente:

Identificar os ativos em risco de forma automatizada.

1. Rastrear atividade RDP anômala nos ativos acima.
2. Tentar detectar Movimento Lateral aproveitando regras Sigma e regras baseadas em comportamento.
3. Tarefa #1: é onde podemos contar com várias funções no ArcSight.

Fazer uma lista de ativos vulneráveis ao CVE-2019-0708 ao acessar o modelo de Ativos & Rede que (deve ser) populado por qualquer scanner de vulnerabilidade que forneça saída CEF (Qualys, Nessus ou mesmo nmap fará o truque).

E se não tivermos um scanner? Podemos rastrear hosts potencialmente vulneráveis ao fazer um filtro em ativos Windows XP, 7, 2003 e 2008, seja em base no modelo de Ativos & Rede ou com base em IDs de Eventos do Windows gerados por essas versões que são distintos de versões mais recentes do Windows.

Tarefa #2: para substituir o Aprendizado de Máquina, faremos uma regra que coleta eventos de Firewall e Netflow com base em Categorizações e armazena IPs de origem / destino RDP na Lista Ativa. Desta forma, podemos encontrar a primeira conexão para/de ativos potencialmente/confirmados vulneráveis. Além disso, construiremos Tendências para perfilar conexões RDP e detectar picos de tráfego pelo contador de conexões.

Tarefa #3: portar a regra Sigma #1 de consulta para correlação em tempo real abrangerá a detecção de Movimento Lateral T1210. Para isso, copiei a origem do Sigma #1 para o Uncoder.io para produzir a consulta ArcSight. Uma coisa boa sobre as consultas ArcSight é que, tendo algum conhecimento da linguagem, pode-se facilmente transformar o código no filtro para a regra de correlação em tempo real.

Coloque tudo junto e conecte no seu SOC!

Para o ArcSight, as peças de conteúdo acima estão vinculadas em um único painel que deve permanecer vazio durante as operações normais. Para fazer os eventos chegarem ao canal principal do SOC, adicione uma regra leve para consumir alertas correlacionados do canal ativo “Detalhes do Evento de Correlação”.

Para o SOC baseado em Elastic, adicionamos um painel Kibana simples. Ele exibe picos de RDP e visualização de Aprendizado de Máquina para encontrar outliers com base no tráfego de netflow, bem como detalhes sobre disparos de regras Sigma, hosts impactados etc.

Se você já usa o painel SOC Prime para gerenciamento de Watcher, pode explorar os dados através do prisma do MITRE ATT&CK e pivotar entre as Táticas, Técnicas, Usuários afetados, Computadores, observar a Linha do Tempo do ataque, gerenciar Watchers, pivotar para regras Sigma e casos via app SOC Workflow. Tudo isso sem sair da interface Kibana.

Elastic, ArcSight ou Sigma?

Se usarmos apenas o ATT&CK como referência, o Elastic é o vencedor por estar 1 técnica à frente.

A principal vantagem do Elastic stack é sua capacidade de combinar tanto Aprendizado de Máquina quanto consultas modernas de Threat Hunting baseadas em Sigma. Lembre-se de que a re-fatorização das regras Sigma para consultas de correlação em tempo real não encontra Masquerading / T1036 no ArcSight.

No entanto, vale a pena notar que é realmente mais fácil configurar o ArcSight para aproveitar dados de scanners de vulnerabilidade para correlação cruzada de dispositivos. Combinado com todas as outras fontes de log no pacote de regras de detecção, pode ser mais eficaz para muitas organizações.

Se olharmos para a tarefa do ponto de vista da velocidade e custo de desenvolvimento de detecção, o Sigma claramente lidera o caminho. Contanto que seu SIEM ou EDR suporte Sigma ou você tenha logs Sysmon de todas as suas máquinas, incluindo XP, 7, 2003 e 2008, esta será uma solução ideal para você. Mais uma vez, a vantagem de um pacote de detecção maior em relação a uma única regra baseia-se principalmente em nossa suposição de que um ataque real usará RDP para movimento lateral. Não há um tamanho único que serve para todos quando se trata de detecção de ameaças. O placar final será definido quando o exploit realmente funcional for lançado e pudermos construir a detecção, muito provavelmente usando regras Sigma. No final do dia, construímos um conteúdo de Detecção Proativa com base em Regras e Aprendizado de Máquina para o “Desconhecido Conhecido”, exatamente como o Dr. Anton Chuvakin afirmou recentemente em seu post:

Não se esqueça da Prevenção e Corrija seus Problemas Não se esqueça da Prevenção e Corrija seus Problemas .

 Aprenda com os erros dos outros, corrigir isso antecipadamente será tão benéfico quanto se você tivesse todos os SMB corrigidos durante o surto do Wannacry. Se você receber um não da equipe de correção, implante detecções, teste os backups e delegue o risco.

Links para conteúdo de detecção gratuito e mapeamentos para MITRE ATT&CK Links para conteúdo de detecção gratuito e mapeamentos para MITRE ATT&CK

Sigma #1 de Markus Neis

1. Movimento Lateral; T1210; fontes de log: microsoft sysmon. Movimento Lateral; T1210; fontes de log: microsoft sysmon.Sigma #2 de Roman Ranskyi
2. Movimento Lateral, Evasão de Defesa, Descoberta; T1210, T1036, T1046; fontes de log: microsoft sysmon. Movimento Lateral, Evasão de Defesa, Descoberta; T1210, T1036, T1046; fontes de log: microsoft sysmon.Pacote de regras ArcSight .ARB
3. https://tdm.socprime.com/tdm/info/2160/ https://tdm.socprime.com/tdm/info/2160/ Movimentação Lateral, Descoberta; T1210, T1046, T1076; fontes de logs: firewall, netflow, scanner de vulnerabilidade, logs do MS Active Directory, Sysmon.
4. Pacote de regras Elastic stack https://tdm.socprime.com/tdm/info/2160/ Movimentação Lateral, Evasão de Defesa, Descoberta; T1210, T1036, T1046, T1076; fontes de logs: netflow, logs do MS Active Directory, Microsoft Sysmon.

Edição comunitária do aplicativo SOC Workflow: https://github.com/socprime/soc_workflow_app_ce

/Se mantenha seguro