Detecção de DLL hijacking com machine learning: casos do mundo real

Introdução

Nossos colegas do Centro de especialização de IA desenvolveram recentemente um modelo de machine learning que detecta ataques de DLL hijacking. Em seguida, integramos esse modelo ao sistema SIEM da Kaspersky Unified Monitoring and Analysis Platform. Em um outro artigo, nossos colegas compartilharam como o modelo foi criado e se eles obtiveram sucesso em ambientes de laboratório. Aqui, nos concentramos em como o modelo opera dentro do Kaspersky SIEM, nas etapas de preparação executadas antes do seu lançamento e em alguns incidentes do mundo real que ele já nos ajudou a detectar.

Como o modelo funciona no Kaspersky SIEM

A operação do modelo geralmente se resume a uma verificação passo a passo de todas as bibliotecas DLL carregadas por processos no sistema, seguida pela validação na nuvem da Kaspersky Security Network (KSN). Essa abordagem permite que atributos locais (caminho, nome do processo e hashes de arquivo) sejam combinados com uma base de conhecimento global e indicadores comportamentais, o que gera uma melhora significativa da qualidade da detecção e reduz a probabilidade de falsos positivos.

O modelo pode ser executado em um dos dois modos: em um correlacionador ou em um coletor. Um correlacionador é um componente de SIEM que executa a análise e a correlação de eventos com base em regras ou algoritmos predefinidos. Se a detecção estiver configurada em um correlacionador, o modelo verificará os eventos que já acionaram uma regra. Isso reduz o volume de consultas à KSN e o tempo de resposta do modelo.

O fluxo de trabalho do modelo em um correlacionador ocorre da seguinte forma:

Um coletor é um componente de software ou hardware de uma plataforma de SIEM que coleta e normaliza eventos de várias fontes e, em seguida, entrega esses eventos ao núcleo da plataforma. Se a detecção estiver configurada em um coletor, o modelo processará todos os eventos associados a vários processos que carregam bibliotecas, desde que esses eventos atendam às seguintes condições:

• O caminho para o arquivo de processo é conhecido.
• O caminho para a biblioteca é conhecido.
• Os hashes do arquivo e da biblioteca estão disponíveis.

Esse método consome mais recursos e a resposta do modelo leva mais tempo do que em um correlacionador. No entanto, isso pode ser útil para a busca de ameaças retrospectiva, pois permite verificar todos os eventos registrados pelo Kaspersky SIEM. O fluxo de trabalho do modelo em um coletor ocorre da seguinte forma:

É importante observar que o modelo não está limitado a uma avaliação binária “maliciosa/não maliciosa”. Ele classifica suas respostas por nível de confiança. Isso permite que ele seja usado como uma ferramenta flexível na prática do SOC. Exemplos de veredictos possíveis:

• 0: os dados estão sendo processados.
• 1: não confirmada como maliciosa. Isso significa que, no momento, o modelo não considera a biblioteca maliciosa.
• 2: biblioteca suspeita.
• 3: confirmada como maliciosa.

Uma regra do Kaspersky SIEM para detectar DLL hijacking seria assim:

A incorporação do modelo ao correlacionador do Kaspersky SIEM automatiza o processo de identificação de ataques de DLL hijacking, tornando possível detectá-los em escala sem precisar analisar manualmente centenas ou milhares de bibliotecas carregadas. Além disso, quando combinado com regras de correlação e fontes de telemetria, o modelo pode ser usado não apenas como um módulo independente, mas como parte de uma defesa abrangente contra ataques de infraestrutura.

Incidentes detectados durante o teste piloto do modelo no serviço MDR

Antes de ser lançado, o modelo (como parte da plataforma Kaspersky SIEM) foi testado no serviço MDR, onde foi treinado para identificar ataques em grandes conjuntos de dados fornecidos pela nossa telemetria. Essa etapa foi necessária para garantir que a detecção funcionasse não apenas em configurações de laboratório, mas também em infraestruturas reais de clientes.

Durante o teste piloto, verificamos a resiliência do modelo a falsos positivos e sua capacidade de classificar corretamente o comportamento até mesmo em cenários atípicos de carregamento de DLL. Como resultado, vários incidentes do mundo real foram detectados com sucesso, onde atacantes usaram um tipo de DLL hijacking (a técnica de DLL sideloading) para obter persistência e executar seu código no sistema.

Vamos analisar em detalhes os três mais interessantes.

Incidente 1. O malware ToddyCat, disfarçado como uma biblioteca do sistema, tentou executar a ferramenta Cobalt Strike

Em um incidente, os atacantes aproveitaram com sucesso a vulnerabilidade CVE-2021-27076 para explorar um serviço SharePoint que usava o IIS como servidor web. Eles executaram o seguinte comando:

Após isso, o processo IIS criou arquivos que foram posteriormente usados para executar um código malicioso por meio da técnica de DLL sideloading (T1574.001 Hijack Execution Flow: DLL):

SystemSettings.dll é o nome de uma biblioteca associada ao aplicativo Configurações do Windows (SystemSettings.exe). A biblioteca original continha código e dados que o aplicativo Configurações usou para gerenciar e configurar vários parâmetros do sistema. No entanto, a biblioteca criada pelos atacantes tinha funcionalidade maliciosa e estava apenas fingindo ser uma biblioteca do sistema.
Mais tarde, para estabelecer persistência no sistema e lançar um ataque de DLL sideloading, uma tarefa agendada foi criada, disfarçada como uma atualização do navegador Microsoft Edge. Ela executou um arquivo SystemSettings.exe, que estava localizado no mesmo diretório que a biblioteca maliciosa:

A tarefa foi configurada para ser executada diariamente.

Quando o processo SystemSettings.exe foi iniciado, ele carregou a DLL maliciosa. Quando isso aconteceu, os dados do processo e da biblioteca foram enviados ao nosso modelo para análise e detecção de um possível ataque.

Os dados resultantes ajudaram nossos analistas a destacar uma DLL suspeita e analisá-la em detalhes. Descobriu-se que a biblioteca era um implante da ferramenta Cobalt Strike. Após carregá-la, o processo SystemSettings.exe tentou se conectar ao servidor de comando e controle dos atacantes.

Após estabelecer uma conexão, os atacantes iniciaram o reconhecimento do host para coletar vários dados e desenvolver o ataque.

Com base nas TTPs dos atacantes, como carregar a Cobalt Strike como uma DLL, usar a técnica de DLL sideloading (1, 2) e explorar o SharePoint, podemos dizer com bastante confiança que o grupo APT ToddyCat estava por trás do ataque. Graças à resposta rápida do nosso modelo, conseguimos responder a tempo e bloquear essa atividade, impedindo que os atacantes causassem danos à organização.

Incidente 2. Um infostealer se passou por um gerenciador de políticas

Outro exemplo de ataque foi descoberto pelo modelo depois que um cliente foi conectado ao monitoramento de MDR: um arquivo de sistema legítimo localizado em uma pasta do aplicativo tentou carregar uma biblioteca suspeita que estava armazenada ao lado dele.

O arquivo SettingSyncHost.exe é um processo do host do sistema para sincronizar configurações entre os diferentes dispositivos de um usuário. Suas versões de 32 bits e de 64 bits geralmente estão localizadas em C:\Windows\System32\ e em C:\Windows\SysWOW64\, respectivamente. Nesse incidente, o local do arquivo era diferente do normal.

A análise do arquivo de biblioteca carregado por esse processo mostrou que se tratava de um malware projetado para roubar informações dos navegadores.

O arquivo acessa diretamente os arquivos do navegador que contêm dados do usuário.

O arquivo da biblioteca está na lista de arquivos usados em DLL hijacking, conforme publicado no projeto HijackLibs. O projeto contém uma lista de processos e bibliotecas comuns empregadas em ataques de DLL hijacking, que podem ser usadas para detectar esses ataques.

Incidente 3. Um loader malicioso se passou por uma solução de segurança

Outro incidente descoberto pelo nosso modelo ocorreu quando um usuário conectou uma unidade USB removível:

O diretório da unidade conectada continha pastas ocultas com um atalho de nome idêntico para cada uma delas. Os atalhos tinham ícones que eram normalmente usados para pastas. Como as extensões de arquivo não eram exibidas por padrão na unidade, o usuário pode ter confundido o atalho com uma pasta e o iniciado. Por sua vez, o atalho abriu a pasta oculta correspondente e executou um arquivo executável usando o seguinte comando:

O CEFHelper.exe é um arquivo executável legítimo do Avast Antivírus que, por meio de DLL sideloading, carregou a biblioteca wsc.dll, que é um loader malicioso.

O loader abre um arquivo chamado AvastAuth.dat, que contém uma backdoor criptografada. A biblioteca lê os dados do arquivo na memória, os descriptografa e os executa. Depois disso, a backdoor tenta se conectar a um servidor de comando e controle remoto.

O arquivo da biblioteca, que contém o loader malicioso, está na lista de bibliotecas conhecidas usadas para DLL sideloading, conforme apresentado no site do projeto HijackLibs.

Conclusão

A integração do modelo ao produto proporcionou meios para fazer a detecção precoce e precisa de tentativas de DLL hijacking que anteriormente poderiam ter passado despercebidas. Mesmo durante o teste piloto, o modelo provou sua eficácia ao identificar vários incidentes usando essa técnica. No futuro, sua precisão só aumentará à medida que os dados se acumularem e os algoritmos forem atualizados na KSN, o que tornará esse mecanismo um elemento confiável de proteção proativa para sistemas corporativos.

IoC

Arquivos legítimos usados em DLL hijacking
E0E092D4EFC15F25FD9C0923C52C33D6 carrega SystemSettings.dll
09CD396C8F4B4989A83ED7A1F33F5503 carrega policymanager.dll
A72036F635CECF0DCB1E9C6F49A8FA5B carrega wsc.dll

Arquivos maliciosos
EA2882B05F8C11A285426F90859F23C6   SystemSettings.dll
E83F331BD1EC115524EBFF7043795BBE   policymanager.dll
831252E7FA9BD6FA174715647EBCE516   wsc.dll

Caminhos
C:\ProgramData\SystemSettings.exe
C:\ProgramData\SystemSettings.dll
C:\Program Files\Chiniks\SettingSyncHost.exe
C:\Program Files\Chiniks\policymanager.dll
D:\RECYCLER.BIN\1\CEFHelper.exe
D:\RECYCLER.BIN\1\wsc.dll