Introdução

Neste artigo, vou me aprofundar na detecção de contrabando de HTML, seguindo o processo de engenharia de detecção que descrevi nas duas últimas postagens. Este processo inclui pesquisa, teste e desenvolvimento de novos conceitos de detecção. No entanto, ao contrário de minhas postagens anteriores, desta vez observaremos, traçaremos perfis e detectaremos malware QakBot real no laboratório. Com esta peça, espero mostrar como os engenheiros de detecção atuais e aspirantes podem ir além dos desafios simulados no estilo CTF para estudar e detectar técnicas de invasores do mundo real, sinalizando-as para nosso SOC e permitindo que nossos colegas de resposta a incidentes neutralizem a ameaça.

Nosso Itinerário

Após algum histórico e definição do objetivo, demonstrarei como podemos executar o malware QakBot HTML Smuggling no laboratório, rastreando seu comportamento no Splunk. Em seguida, sequenciarei eventos observáveis ​​desse ataque e identificarei pontos de detecção úteis (que considero “blocos de construção” ou elos da cadeia de ataque). Também apresentarei a correlação (especificamente as regras da cadeia), uma ferramenta crucial em sua caixa de ferramentas de detecção de ameaças. Para ilustrar como isso se parece, discutirei e demonstrarei um recurso ainda não lançado do Sigma, chamado Sigma Correlations. Concluirei testando uma nova regra de cadeia contra 10 amostras adicionais do malware QakBot HTML Smuggling para ver como ele se comporta.

Vamos começar!

Fundo

No início de minha jornada de segurança cibernética, John Strand, da Black Hills Information Security, disse algo que ficou na minha cabeça: “Não há registro 'VOCÊ FOI HACKEADO'.” Os logs de eventos podem ser confusos e difíceis de ler, mesmo em um bom dia. Derivar insights úteis e acionáveis ​​de logs é complicado! O desafio às vezes requer análise profunda e técnicas especializadas para ser bem-sucedido.

Eu guardei essa lição em minha mente ao longo de minha carreira em segurança, e foi com isso em mente que, alguns meses atrás, comecei a ver toneladas de posts como este de @pr0xylife :

Gosto da maneira como pr0xylife e seus colegas resumem esses ataques de forma tão sucinta, e me vi repetindo a sequência de tipos de arquivo em voz alta - quase como uma estranha forma de poesia!

Eu queria aprender mais, mas não sabia como começar. Eu havia revisado algumas pesquisas excelentes sobre o QakBot pela equipe da Trellix, então sabia um pouco sobre suas técnicas. (Se você nunca ouviu falar do QakBot, leia o relatório do Trellix!) Quando comecei a acompanhar a atividade do QakBot e a me aprofundar, percebi que o pr0xylife e outros estavam descrevendo as combinações e variações sutis na maneira como o QakBot poderia enganar suas vítimas e escapar de nosso defesas. Alguns exemplos:

• Ele usa HTML Smuggling , onde um arquivo HTML malicioso contendo JavaScript codificado é executado pelo navegador da vítima, baixando o próximo estágio da carga útil.
• Ele usa arquivos zip protegidos por senha para bloquear a análise de sandbox.
• Ele usa um formato de imagem de disco chamado arquivo .iso para escapar da proteção Mark-of-the-Web, como o Red Canary explica muito bem .
• Arquivos LNK disfarçados para induzir os usuários a executar arquivos .CMD e .DLL ocultos.
• E assim por diante com truques cada vez mais enganosos!

O objetivo

Existem algumas detecções disponíveis para contrabando de HTML e outras técnicas conectadas ao QakBot. Eles se baseiam principalmente na correspondência de eventos de log suspeitos, como este da segurança da Elastic:

Eu queria ver se poderia criar minhas próprias detecções, utilizando a correlação (em oposição à correspondência simples) para torná-las resilientes a mudanças sutis no comportamento do ataque.

TBH, eu também estava cansado da trapaça idiota do QakBot e queria uma maneira confiável de colocá-lo diretamente em nossa mira.

Observação inicial e análise do QakBot Malware

Para atingir meu objetivo, tive que ir além dos relatórios de inteligência de ameaças de fornecedores de segurança e dos testes do Atomic Red Team; Eu precisava dos meus próprios dados criados a partir de amostras reais de malware. Recorri a um antigo favorito: malware-traffic-analysis.net de Brad Duncan (@malware_traffic). Este site está entre os recursos educacionais mais úteis que encontrei sobre segurança. Além dos tutoriais do Wireshark e exercícios práticos de tráfego de rede, o site oferece análise de qualidade de amostras de malware do mundo real, incluindo arquivos de contrabando QakBot HTML.

Depois de fazer instantâneos de minhas VMs de laboratório, iniciei meu laboratório de detecção virtual e visitei uma entrada recente. Cuidado, os arquivos hospedados neste site não são seguros!

Baixei o arquivo zip dos artefatos e o extraí para minha pasta de downloads usando o utilitário WinRAR integrado ao meu laboratório de detecção:

As notas do COI foram extremamente úteis para contextualizar os arquivos incluídos. Entre as notas estavam as seguintes, que me informaram que a cadeia de infecção começou com o arquivo HTML, chamado SCAN_DT6281.html.

2022-12-09 (FRIDAY) - HTML SMUGGLING FOR QAKBOT (QBOT) DISTRIBUTION TAG: AZD

DISTRIBUTION:

- Unknown source, possibly email --> HTML file --> password-protected zip archive --> extracted ISO image with .img file extension

…claro, vamos abrir o arquivo zip, por que não?

O arquivo zip foi protegido por senha, mas pode ser aberto usando a senha exibida na página HTML. O arquivo zip continha um único arquivo .img, que eu sei ser outro formato de arquivo de imagem de disco montável. Clicar duas vezes nisso montou o arquivo como a unidade D no meu sistema:

Também notei um diretório oculto chamado IncomingPay, que continha um arquivo .lnk, dois arquivos de texto que continham (não estou brincando) trechos da página da Wikipédia sobre psicologia, um arquivo .cmd e um arquivo .lc .

Como um profissional de segurança e observador zeloso do treinamento de conscientização de segurança corporativa, todos os meus estavam de pé e acenando com a brisa. Mas isso é para a ciência, então mordo a isca e clico duas vezes no arquivo LNK, exatamente como o invasor deseja que a vítima faça. Uma janela de linha de comando aparece por alguns segundos e depois desaparece:

A propriedade de destino do arquivo LNK é interessante:

C:\Windows\System32\cmd.exe /c IncomingPay\Issues.cmd A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9

Como sei quais pesquisas executar? Na verdade não, mas por meio de minha experiência como analista e pesquisador, sei que existem certos tipos de evidências que podem aparecer em meus logs - execuções de processos, criações de arquivos, conexões de rede e assim por diante. É aqui que a experiência prática como analista de segurança ou uma boa dose de treinamentos no estilo CTF (como os disponíveis em CyberDefenders ou LetsDefend ) são úteis.

Depois de atualizar minhas pesquisas algumas vezes e me perguntar se havia feito algo errado, notei um sinal claro e incontestável de intrusão: uma explosão de atividade de reconhecimento em meu host de vítima:

Enquanto olhava para esses comandos, observei o período de tempo em que eles ocorreram - tudo dentro de alguns segundos! Além disso, todos os processos foram gerados por um pai incomum - wermgr.exe (o Windows Error Reporting Manager). Uma boa oportunidade de detecção, talvez? Mesmo que o administrador mais confuso ou o software [legítimo] sobrecarregado não execute todos esses comandos de reconhecimento suspeitos em um período de tempo tão curto e nunca como filhos de um wermgr.exe. Passando para minhas conexões de rede, notei que wermgr.exe de repente se tornou extremamente tagarela com endereços IP externos:

Após esta avaliação inicial dos meus dados, determinei que:

• A amostra de malware continha um vetor de acesso inicial mal-intencionado (duh, a galeria maliciosa dos arquivos .html, .zip, .img, .lnk, .cmd e .lc).
• O malware baixava o arquivo zip depois de abrir a página HTML em um navegador, e o arquivo zip continha um arquivo .img montável.
• A unidade montada continha um atalho malicioso que resultaria na execução de comandos adicionais.
• Um processo wermgr.exe injetado gerou uma explosão automática de atividade de reconhecimento e, em seguida, conectou-se a endereços IP externos suspeitos, presumivelmente para enviar ao invasor informações sobre nosso sistema e rede.

Dividindo o ataque em blocos de construção de detecção

Tendo realizado uma execução inicial da técnica de contrabando QakBot HTML no laboratório e revertido para meus instantâneos de VM, era hora de aprofundar os logs para ver o que estava acontecendo.

Ao revisar os vários tipos de eventos gerados pelo ataque, comecei a desenvolver uma compreensão narrativa em linguagem simples do que estava acontecendo:

“Um invasor envia à vítima um arquivo HTML que pretende conter um relatório, fatura ou outro documento de seu interesse. Basicamente, uma isca de phishing. Quando a vítima abre o arquivo em seu navegador, o código JavaScript incorporado é executado, baixando ou criando um arquivo zip protegido por senha no sistema da vítima. Quando a vítima descompacta o arquivo , a extração cria um arquivo de imagem de disco montável. Depois de montar a unidade , o usuário vê um atalho que acredita que o levará ao recurso que está tentando encontrar. Mas o atalho na verdade chama um comando ou interpretador de script que executa outros arquivos maliciososque estão ocultos na unidade de disco, levando ao comprometimento do acesso inicial.”

Isso é um pedaço de prosa prolixo, mas faz sentido na minha cabeça. Se eu vou detectar algo, preciso entender primeiro! Observe o texto em negrito: usei minha narrativa para destacar eventos que eu poderia usar para detectar a cadeia de ataque. Com base nessa revisão, analisei os logs do ataque, tentando isolar os seguintes eventos:

1. E-mail de phishing enviado à vítima contendo um anexo em HTML.
2. Criação de um arquivo HTML em locais suspeitos.
3. Abertura de um arquivo HTML autônomo em um aplicativo de navegador.
4. Download/criação de um arquivo zip pelo aplicativo do navegador.
5. Abertura/extração de um arquivo zip protegido por senha.
6. Criação de um formato de arquivo de unidade de disco montável (.iso, .img, etc).
7. Montando uma unidade.
8. Execução do processo em uma unidade externa (a partir de um executável nessa unidade ou executável do sistema tocando em arquivos nessa unidade).

As boas notícias

A boa notícia é que existem maneiras de detectar quase todos os eventos listados acima! Isso significa que tive várias ideias de como consultar e filtrar logs disponíveis para extrair os eventos significativos (blocos de construção) para futuras detecções.

As más notícias

A má notícia é que nenhum desses muitos eventos é, por si só, malicioso. Novamente, não há registro de VOCÊ FOI HACKEADO: cada um desses eventos pode ocorrer no curso normal dos negócios e ser completamente seguro e benigno. A solução seria correlacionar esses eventos, em uma sequência ordenada ou não, agrupando-os por um atributo comum como hostname, e disparando um alerta quando todos eles ocorrerem dentro de uma janela de tempo, como uma hora. O problema é, a partir de minha análise e teste (mais sobre isso em um momento), encadear ou correlacionar muitos eventos resultaria em uma detecção frágil.

Frágil vs. Resiliente

“Fragilidade” descreve o grau em que uma ideia de detecção desmorona diante de mudanças sutis nas técnicas do invasor, variações nas ações executadas pela vítima, problemas com registro ou outros fatores fora de nosso controle. As detecções frágeis contrastam com as detecções “resilientes”, que são flexíveis e podem suportar essas mudanças sutis.

Não é tão simples quanto dizer “Frágil = ruim e resiliente = bom”. Uma detecção frágil pode ser altamente direcionada, com uma "abertura" estreita. A vantagem pode ser que, se uma regra de detecção frágil for acionada, há uma probabilidade muito alta de que seja um verdadeiro positivo. As detecções resilientes podem ter uma abertura mais ampla e podem corresponder a mais atividades maliciosas em potencial. No entanto, isso pode levar a falsos positivos e a um SOC frustrado se não for desenvolvido com cuidado.

Com isso em mente, voltei à minha lista de eventos acima.

Determinando os blocos de construção para testar

No contexto, percebi que os itens de um a três na lista acima podem não ser bons componentes da minha detecção de contrabando de HTML. A falta de visibilidade e um grande volume de comportamento inocente prejudicariam o item 1. Atingi o item dois porque tinha capacidade limitada de testar esse evento, e o item três provou não ser confiável dependendo de qual navegador eu usei. Além disso, embora não seja tecnicamente contrabando de HTML, muitas atividades do QakBot usam URLs, em vez de arquivos HTML independentes, para fornecer a carga útil inicial.

O item cinco (extração de um arquivo zip protegido por senha) tem muito potencial e pode ser detectado usando esta regra escrita por Florian Roth e inspirada na pesquisa de @SBousseaden . No entanto, deixei isso fora do meu escopo porque 1) esse evento não estava sendo registrado em meu laboratório e 2) alguma documentação indica que é aplicável apenas a determinados sistemas operacionais.

Depois de explorar meus dados, enumerar possíveis blocos de construção de detecção para minha correlação e filtrar essa lista com base em análises adicionais, eu tinha os seguintes blocos de construção:

1. O navegador da Web cria (faz o download) um arquivo compactado (representa a abertura do arquivo HTML malicioso em um navegador).
2. Arquivo ISO, VHD, LNK ou IMG extraído do Zip (extraindo o arquivo de imagem de disco malicioso).
3. Disk Image Mount (montagem da imagem — essa eu tirei direto da Sigma).
4. Execução suspeita de processo iniciado pelo usuário na unidade externa (clicando no arquivo .lnk que executa ou faz referência a arquivos na unidade externa).

Correlações Sigma

A correlação nos permite rastrear eventos de log ao longo do tempo. Em vez de disparar um alerta para cada um dos quatro eventos listados acima, uma correlação de regra em cadeia nos permite alertar apenas quando todos os quatro eventos ocorrem em ordem no mesmo host pelo mesmo usuário, o que é muito mais suspeito. Muitos produtos SIEM e suas linguagens de consulta correspondentes oferecem suporte a esse tipo de encadeamento (embora alguns não).

Para oferecer suporte a essa funcionalidade, a Sigma tem um padrão de correlações em andamento que nos permitirá escrever regras de correlação personalizadas em um formato comum e, em seguida, convertê-las em qualquer produto SIEM compatível com essa lógica. O projeto de norma pode ser revisto aqui:

O que isso pode parecer? É um padrão de rascunho e está sujeito a alterações , mas um exemplo simples de uma regra de cadeia de força bruta pode ser assim:

action: correlation
type: temporal
rule:
    - many_failed_logins
    - successful_login
group-by:
    - User
timespan: 1h
ordered: true

Minha regra de correlações de rascunho se parece com isto:

title: HTML Smuggling Activity - Chain Rule
id: 0952f2fa-e29b-4eb5-831c-ce21520c56e3
status: experimental
description: Detects HTML smuggling-style compromise (such as HTML > ZIP > ISO/IMG/VHD > CMD/BAT/VBS > DLL). Includes rules to detect zipfile dropped by browser, ISO/IMG/VHD/LNK file extraction, disk image mount, followed by user-initiated process creation on an external drive.
references:
    - https://blog.talosintelligence.com/html-smugglers-turn-to-svg-images/#:~:text=HTML%20smuggling%20is%20a%20technique,directly%20on%20the%20victim's%20device.
    - https://www.malwarebytes.com/blog/news/2021/11/evasive-maneuvers-html-smuggling-explained
    - Original research and analysis performed off of QakBot intelligence gathered at https://github.com/pr0xylife/Qakbot, https://www.malware-traffic-analysis.net/, and https://github.com/executemalware/Malware-IOCs
author: Micah Babinski
date: 2022/12/27
tags:
    - attack.s0650
    - attack.s0483
    - attack.initial_access
    - attack.defense_evasion
    - attack.execution
    - attack.t1564
    - attack.t1566.001
    - attack.t1566
    - attack.t1027
    - attack.t1027.006
    - attack.t1059
    - attack.t1204
    - attack.t1204.002
action: correlation
type: temporal
rule:
    - 1_win_zipfile_drop.yml
    - 2_win_susp_file_extraction.yml
    - 3_win_security_iso_mount.yml
    - 4_win_process_creation_ext_drive.yml
group-by:
    - ComputerName
    - User
timespan: 1h
ordered: true
falsepositives:
    - Unknown
level: high

Novamente, a especificação Sigma Correlations está em desenvolvimento e está sujeita a alterações. Ainda assim, esta será uma expansão muito útil dos recursos da Sigma, então eu queria uma prévia para você agora!

Testando a correlação

Com esse conceito de detecção tomando forma e uma hipótese desenvolvida na forma de minha regra de correlação, era hora de testar a detecção com um tamanho de amostra maior. Confiei no repositório MalwareBazaar da Abuse.ch, que fornece uma biblioteca útil de amostras de malware marcadas. Baixei 10 amostras QakBot HTML, a maioria relatada por pr0xylife, variando na data vista pela primeira vez de 11 de julho a 22 de dezembro de 2022. Preparei as amostras em minha VM de laboratório e nomeei cada uma de acordo com a data da primeira vez e seu “humanhash” propriedade (uma sequência aleatória e única de palavras legíveis por humanos, como (“dakota-earth-mockingbird-march”):

Para acompanhar meus resultados, fiz uma tabela simples no Planilhas Google:

Fiz um instantâneo limpo e pré-teste do host da VM da minha vítima para reverter após cada teste e comecei o teste. Depois de testar sete das dez amostras, minha sequência de quatro blocos de construção teve uma cobertura perfeita! Quando acertei a oitava amostra, no entanto, a quarta regra da cadeia não foi acionada, porque o arquivo .lnk chamou RunDLL32.exe diretamente, em vez de cmd.exe ou wscript.exe. Tudo bem - simplesmente fiz um ajuste nas condições da minha regra Sigma, testei novamente e obtive correspondências perfeitas! Fiquei encantado com os resultados e animado para compartilhar o caso de uso de detecção com a comunidade.

Rodada de Bônus!

Muitos ataques de phishing do QakBot não usam anexos .html, mas sim arquivos .pdf maliciosos com links incorporados ou apenas os bons links de phishing antiquados que apontam para arquivos compactados hospedados em um site comprometido. Para testar se minha detecção era flexível o suficiente para capturar essas instâncias também, testei-as em alguns exemplos recentes do repositório IOC mantido por @ExecuteMalware e descobri que esses ataques driveby baseados em URL também foram detectados. O documentado aqui incluía até mesmo um .wsf (arquivo de script do Windows) — um tipo de arquivo com o qual eu não estava familiarizado, mas mesmo assim foi detectado por mim.

Viva a resiliência!

Conclusão

Parabéns! Você chegou ao fim de uma longa postagem sobre alguns tópicos densos e complicados. Você pode encontrar todas as regras referenciadas aqui . Obrigado por ler e espero que tenha gostado de minhas divagações sobre QakBot, HTML Smuggling, Sigma e correlações. Estou realmente empolgado com o lançamento do Sigma Correlations. Será uma grande vitória para a comunidade de engenharia de detecção e nos permitirá compartilhar casos de uso de detecção mais sofisticados.

Fiquei muito satisfeito com o andamento dos meus testes, principalmente quando mostrou que um dos blocos de construção da minha regra da cadeia havia falhado e precisava de ajustes! Afinal, pra que testar se você acha que seu trabalho já está perfeito? Por fim, essa experiência me mostrou o que eu já havia começado a acreditar - que não podemos detectar o que não entendemos. Não há substituto para a experiência em primeira mão com malware real ao vivo se você estiver tentando ver o que ele faz.

Graças ao projeto Detection Lab, sobre o qual me entusiasmei em postagens anteriores, essa experiência da vida real está ao alcance de mais pessoas do que nunca. Por fim, agradecemos a pr0xylife, Brad (malware_traffic) e executemalware por fornecer repositórios originais de amostras de malware QakBot bem documentadas para acessarmos, analisarmos e entendermos. Estes são verdadeiramente um tesouro educacional!

Sinta-se à vontade para me enviar ideias, comentários ou sugestões sobre como posso melhorar. Ainda sou novo nisso e agradeço comentários e críticas respeitosas de qualquer forma.

Como sempre, feliz análise!