Nova detecção de injeção de processo usando anomalias de rede

Resumo executivo

• Os pesquisadores da Akamai criaram uma nova técnica para detectar a injeção de processos por meio da análise de anomalias de rede.

• Os mecanismos de detecção atuais dependem de fatores baseados em host que podem ser contornados por novas técnicas de ataque, o que exige uma nova maneira de identificar ameaças.

• À medida que essas técnicas de ataque evoluem, os mecanismos de defesa também devem evoluir, com o mínimo de falsos positivos possível.

• Um ataque bem-sucedido de injeção de processo pode levar a inúmeros resultados prejudiciais, incluindo caminhos deescalonamento de privilégio e instalação de backdoor.

• Nossa metodologia de detecção depende da observação do comportamento da rede de um processo, o que torna mais difícil para uma ameaça permanecer despercebida.

• Nós fornecemos um exemplo desta metodologia em ação a partir de um incidente real que foi descoberto ser associado com a campanha de cryptojacking WannaMine.

Introdução

A injeção de processo é usada em quase todas as operações de ataque. Os invasores continuam a encontrar maneiras de manipular soluções de segurança, por exemplo, ocultando e executando uma carga útil em um processo já ativo.

As técnicas de injeção estão entre as ameaças que evoluíram bastante ao longo dos anos. Essas técnicas altamente sofisticadas somente de memória estão substituindo rapidamente as técnicas tradicionais de injeção que são facilmente detectadas por soluções de segurança modernas, como a detecção e resposta de ponto de extremidade (EDR).

Independentemente do objetivo final do agente da ameaça, uma injeção bem-sucedida levará a tentativas de movimentação lateral, realização de uma varredura de rede ou instalação de um ouvinte para servir como backdoor. Isso dá início ao jogo de gato e rato: Um invasor encontra um novo vetor de ataque, os fornecedores de segurança atualizam sua detecção de acordo, e assim por diante.

Essas novas técnicas de detecção são introduzidas mensalmente, o que significa que a tecnologia EDR precisa atualizar suas detecções com uma quantidade mínima de falsos positivos. Considerando o nível de risco que uma injeção bem-sucedida representa, tivemos que nos perguntar: "O que podemos fazer de forma diferente?"

A maioria dos mecanismos de detecção envolve técnicas como rastreamento de chamadas de API, alterações de sinalizadores de proteção de memória, alocações e outros artefatos baseados em host. No entanto, sabemos que esses mecanismos podem ser manipulados por novas técnicas e ameaças. Essas novas técnicas de injeção, encadeadas com os métodos de desvio de EDR, não são consistentemente detectadas e bloqueadas. Isso implica que, como caçadores de ameaças, não podemos depender exclusivamente de uma solução de antivírus (AV) ou EDR para atenuar esses ataques baseados em host, e precisamos de uma maneira eficiente de detectar ataques bem-sucedidos.

Nesta publicação do blog, apresentaremos uma técnica de detecção de injeção de processo desenvolvida pela equipe do Akamai Hunt usando a detecção de anomalias de rede, em oposição aos artefatos baseados em host listados acima. Nossa técnica se concentra no comportamento da rede do processo, algo que é muito mais difícil de esconder do que artefatos de host, como chamadas de API ou alterações no sistema de arquivos. Usamos essa técnica e muitas outras para detectar malware, movimento lateral, exfiltração de dados e outros tipos de ataques nas redes de nossos clientes.

Nossa detecção funciona em três etapas principais:

1. Categorização da comunicação do processo em grupos de portas

2. Construção de uma linha de base de janela deslizante para a comunicação normal de processos

3. Comparação de novos dados de processo com a linha de base

Sinta-se à vontadepara fazer com que sua própria equipe de segurança implemente a lógica descrita nesta publicação. Mesmo sem a enorme quantidade de dados que temos, Akamai Huntvocê ainda pode esperar obter resultados interessantes com seus próprios dados.

Como funciona comunicação do processo?

É fácil presumir que as comunicações de processos são, em sua maioria, consistentes, ou seja, que os mesmos processos em redes diferentes têm os mesmos padrões de comunicação. Embora isso seja verdadeiro para alguns processos, é completamente falso para outros. Esperamos que os processos nativos do sistema operacional se comportem de forma semelhante, comunicando-se com domínios semelhantes e usando os mesmos protocolos de rede, mas há muitas variáveis que afetam essa suposição: Os builds, regiões, servidores proxy e outras configurações específicas da rede podem afetar seus destinos de comunicação e o protocolo de rede usado (Figura 1).

Nestes dados coletados da Akamai Guardicore Segmentationpodemos ver a inconsistência do uso de portas em ação. Isso pode tornar a detecção bastante difícil por si só, então o próximo passo foi encontrar uma maneira de analisar os dados em um formato que podemos analisar. Inserir os grupos de portas.

Classificação da comunicação do processo usando grupos de portas

Em nossa pesquisa, descobrimos que, ao agrupar portas semelhantes e associá-las a aplicativos específicos, podemos fornecer contexto ao algoritmo de detecção e encontrar padrões de comunicação mais facilmente. Isso nos ajuda a detectar anomalias nos padrões de comunicação.

Por exemplo, digamos que observaremos um processo específico que se comunica usando a porta 636 e a porta 389 em uma rede, mas a porta 3268 e a porta 3269 em outra. Como tudo isso faz parte do Protocolo de Acesso a Diretório Leve (LDAP, Lightweight Directory Access Protocol), podemos classificar todos eles como um grupo de portas: comunicação com o LDAP.

Isso funciona bem para a maioria dos aplicativos, mas tentar classificar todo o intervalo de portas válido é complicado. Muitas portas são usadas por mais de um aplicativo, o que pode fazer com que os processos sejam classificados incorretamente quando usam portas compartilhadas com outro software. Isso nos levou a restringir as classificações de portas a apenas portas que são usadas principalmente para um tipo de aplicativo e deixar o intervalo de portas altas como um grupo de portas.

O mapeamento completo das portas pode ser encontrado em Apêndice A.

Quantos dados são suficientes para tirar conclusões?

Vamos imaginar que você veja um processo específico em execução em sete máquinas, fazendo todas as conexões usando HTTPS para um servidor Web específico. Você será capaz de concluir que o mesmo processo nunca deve usar qualquer outra forma de comunicação? Provavelmente não.

Para decidir quanto dados por processo são suficientes para confiar, consideramos cada par de grupo de processo e porta, e contamos o número de redes em que o observamos.

Como ponto de partida, consideramos apenas os processos vistos em três ou mais redes de clientes. Se um processo aparecesse em menos de três redes (das centenas de redes que temos em nosso conjunto de dados), seria difícil tomar decisões confiantes sobre seu perfil de rede.

Em seguida, determinamos o nível de estabilidade de um processo de acordo com as diferenças no comportamento da rede entre os diferentes clientes. Se um processo se comunicar usando os mesmos grupos de portas em todos os clientes em que foi visto, ele será considerado estável. Se um processo se comunicar de forma completamente diferente em cada rede de clientes, ele será considerado instável.

Também adicionamos níveis de estabilidade para os 12, 25 e 100 principais, considerando apenas as portas dos 12, 25 e 100 portas mais populares, respectivamente. Incluímos também um nível semiestável, que ignora o intervalo de portas altas (números de porta acima de 49151).

Suporte e confiança

Se você estiver trabalhando em dados extraídos de uma única rede, poderá obter suporte e confiança do mundo da mineração de dados, o que ajuda a avaliar a força e a relevância dos dados em um conjunto de dados.

Suporte mede a frequência de um conjunto de itens no conjunto de dados; confiança mede a confiabilidade da relação entre dois conjuntos de itens em uma regra de associação. Em nosso caso:

Suporte (processo) = (número de pontos de dados que contêm o processo)/(número total de pontos de dados)

Suporte (processo –> grupo de portas) = (número de pontos de dados em que um processo é comunicado em um grupo de portas específico)/(número total de pontos de dados que contêm o processo)

Um ponto de dados seria um conjunto distinto de: [Host, Processo, Grupo de portas]

Definimos um valor limite para o suporte mínimo que um processo deve ter, juntamente com uma confiança mínima que um grupo de portas deve ter para ser considerado parte da linha de base. Essa também é a etapa 1 do algoritmo Apriori,que é um algoritmo popular usado para encontrar padrões em grandes conjuntos de dados. Após a avaliação, decidimos por valores que proporcionam descobertas interessantes junto com uma baixa relação sinal-ruído.

Criação de uma linha de base de janela deslizante

Nossa técnica de detecção funciona comparando cada comunicação de processo com sua linha de base de comportamento anterior.

Fazemos isso comparando todas as comunicações do processo que aconteceram em um dia específico com uma linha de base fundamentada no mês anterior de dados (Figura 2).

Isso nos ajuda a nos adaptarmos às tendências das redes dos clientes, pois as mudanças na rede, as implantações de sistemas e as ferramentas vistas pela primeira vez são levadas em conta no dia seguinte.

Como lidar com falsos positivos comuns

Algumas configurações de aplicativo podem alterar o perfil de rede de um processo. Se uma determinada configuração de aplicativo for modificada do uso de um endereço IP para um nome de host, ela começará a gerar tráfego DNS. O mesmo se aplica ao uso de servidores proxy internos, onde em cada rede uma porta diferente pode ser empregada para o mesmo propósito. Outras portas de destino tendem a gerar menos falsos positivos e podem ser permitidas por cliente para manter a lógica original intacta.

Para reduzir o número desses falsos positivos, cada alerta gerado será examinado usando a seguinte lógica:

Se a porta anômala de um processo for a porta DNS/proxy:

1. Extraia o IP de destino

2. Verifique quantos ativos entraram em contato com o mesmo IP de destino na mesma porta durante o mês anterior

3. Se esse número for maior que 20% do número de hosts da rede, marque o alerta como falso positivo
   

Essa lógica ajuda a lidar com configurações específicas de rede para os dois tipos de comunicação mais ruidosos: comunicação de DNS e proxy.

Detecção de ameaças reais: Um exemplo de ataque de um cliente Hunt

Usando nosso novo método para um cliente Hunt, detectamos cinco processos que desviaram de sua respectiva linha de base de comunicação. Esses cinco executáveis nativos do sistema, que usam um padrão de comunicação muito específico de portas relacionadas à Web, começaram a se comunicar com outros ativos na rede usando o protocolo Bloco de Mensagens do Servidor (SMB, Server Message Block) (Figura 3).

Ao analisar as linhas de base dos processos, podemos ver que nenhum deles deve iniciar qualquer comunicação SMB (Figura 4).

Durante a investigação do alerta, encontramos o arquivo C:\Windows\NetworkDistribution\svchost.exe em execução em dois hosts e um deles também encontrou um arquivo chamado

C:\Windows\System32\dllhostex.exe.

Em outra máquina, encontramos um script malicioso interessante (Figura 5).

Fig. 6: Uma comparação desse ataque com ataques anteriores

Todas as nossas descobertas foram comunicadas ao cliente assim que foram encontradas, juntamente com as etapas de correção e as recomendações de políticas de rede.

Conclusão

No cenário de ameaças e técnicas de ataque, há uma grande necessidade de metodologias precisas de detecção. Cada rede é um ecossistema diferente com desafios únicos, o que dificulta a "padronização" da detecção. Muitas organizações tentaram e não conseguiram detectar ataques, seja porque um invasor usou uma nova técnica ou porque  as próprias ferramentas de detecção eram muito complexas.

Ao nos concentrarmos nos padrões de comunicação de um processo, podemos melhorar as técnicas de detecção tradicionais a partir de um ângulo totalmente diferente. Ao combinar esta análise de padrões com o nosso conjunto de dados maciço, conseguimos criar e utilizar esta metodologia para detectar de forma eficiente anomalias na rede de processos e, assim, encontrar agentes de ameaças nas redes dos clientes.

Akamai Guardicore Segmentation e O serviço Akamai Hunt pode bloquear a disseminação de ransomware e tentativas de movimentação lateral, complementadas por um serviço de detecção que alerta você sempre que um ataque ocorrer.