Introdução
Proteções baseadas em reputação, como o serviço de reputação da Elastic, podem melhorar significativamente os recursos de detecção, mantendo baixas taxas de falsos positivos. Entretanto, como qualquer capacidade de proteção, existem fraquezas e desvios são possíveis. Entender essas fraquezas permite que os defensores concentrem sua engenharia de detecção nas principais lacunas de cobertura. Este artigo explorará o Windows Smart App Control e o SmartScreen como um estudo de caso para pesquisar desvios para sistemas baseados em reputação e, em seguida, demonstrará detecções para cobrir essas fraquezas.
Principais conclusões:
- O Windows Smart App Control e o SmartScreen têm várias falhas de design que permitem que invasores obtenham acesso inicial sem avisos de segurança ou pop-ups.
- Um bug no tratamento de arquivos LNK também pode ignorar esses controles de segurança
- Os defensores devem entender as limitações desses recursos do sistema operacional e implementar detecções em sua pilha de segurança para compensar
SmartScreen/Fundo SAC
O Microsoft SmartScreen é um recurso integrado do sistema operacional desde o Windows 8. Ele opera em arquivos que possuem a “Marca da Web” (MotW) e são clicados pelos usuários. A Microsoft introduziu o Smart App Control (SAC) com o lançamento do Windows 11. O SAC é, de certa forma, uma evolução do SmartScreen. A Microsoft diz que “adiciona proteção significativa contra ameaças novas e emergentes ao bloquear aplicativos maliciosos ou não confiáveis”. Ele funciona consultando um serviço de nuvem da Microsoft quando os aplicativos são executados. Se forem conhecidos como seguros, eles poderão ser executados; no entanto, se forem desconhecidos, eles só serão executados se tiverem uma assinatura de código válida. Quando o SAC está ativado, ele substitui e desativa o Defender SmartScreen.
A Microsoft expõe APIs não documentadas para consultar o nível de confiança de arquivos para SmartScreen e Smart App Control. Para ajudar nesta pesquisa, desenvolvemos um utilitário que exibirá a confiança de um arquivo. O código fonte deste utilitário está disponível aqui.
Malware assinado
Uma maneira de contornar o Smart App Control é simplesmente assinar malware com um certificado de assinatura de código. Mesmo antes do SAC, havia uma tendência de invasores assinarem seus malwares para evitar a detecção. Mais recentemente, os invasores têm obtido rotineiramente certificados de assinatura Extend Validation (EV). Os certificados EV exigem comprovação de identidade para obter acesso e só podem existir em tokens de hardware especialmente projetados, o que os torna difíceis de roubar. No entanto, os invasores encontraram maneiras de se passar por empresas e comprar esses certificados. O grupo de ameaças por trás do SolarMarker utilizou mais de 100 certificados de assinatura exclusivos em suas campanhas. As Autoridades Certificadoras (ACs) devem fazer mais para reprimir o abuso e minimizar os certificados adquiridos de forma fraudulenta. Mais pesquisas públicas podem ser necessárias para pressionar as CAs que mais frequentemente vendem certificados fraudulentos.
Sequestro de reputação
O sequestro de reputação é um paradigma de ataque genérico em sistemas de proteção contra malware baseados em reputação. É análogo à pesquisa sobre confiança equivocada de Casey Smith e outros contra sistemas de controle de aplicativos, bem como à pesquisa sobre drivers vulneráveis de Gabriel Landau e eu. Infelizmente, a superfície de ataque neste caso é ainda maior. O sequestro de reputação envolve encontrar e redirecionar aplicativos com boa reputação para contornar o sistema. Para funcionar como um vetor de acesso inicial, uma restrição é que o aplicativo deve ser controlado sem nenhum parâmetro de linha de comando — por exemplo, um host de script que carrega e executa um script em um caminho de arquivo previsível.
Os hosts de script são um alvo ideal para um ataque de sequestro de reputação. Isto é especialmente verdadeiro se eles incluírem uma capacidade de interface de função estrangeira (FFI). Com o FFI, os invasores podem facilmente carregar e executar códigos arbitrários e malware na memória. Por meio de pesquisas no VirusTotal e no GitHub, identificamos muitos hosts de script que têm uma boa reputação e podem ser cooptados para execução completa de código. Isso inclui intérpretes Lua, Node.js e AutoHotkey. Um exemplo para demonstrar essa técnica está disponível aqui.
O vídeo a seguir demonstra o sequestro com o utilitário de compilação JamPlus para ignorar o Smart App Control sem avisos de segurança:
Em outro exemplo, os avisos de segurança do SmartScreen foram ignorados usando um interpretador AutoHotkey conhecido:
Outra maneira de sequestrar a reputação de um aplicativo conhecido é explorá-lo. Isso pode ser simples, como um estouro de buffer clássico ao ler um arquivo INI em um caminho previsível. Pode ser algo mais complexo que encadeie outros primitivos (como execução de comando/gravação no registro/etc.). Além disso, vários aplicativos conhecidos podem ser encadeados para obter execução completa do código. Por exemplo, um aplicativo que lê um arquivo de configuração e executa um parâmetro de linha de comando pode ser usado para iniciar outro aplicativo conhecido que requer um conjunto de parâmetros para obter execução de código arbitrário.
Semeadura de reputação
Outro ataque às proteções de reputação é semear binários controlados pelo invasor no sistema. Se elaborados com cuidado, esses binários podem parecer benignos e ganhar uma boa reputação, mas ainda assim serem úteis para invasores mais tarde. Pode ser simplesmente um novo binário de host de script, um aplicativo com uma vulnerabilidade conhecida ou um aplicativo que tenha um primitivo útil. Por outro lado, pode ser um binário que contém código malicioso incorporado, mas só é ativado após uma determinada data ou gatilho ambiental.
O Smart App Control parece vulnerável à propagação. Após executar uma amostra em uma máquina, ela recebeu um rótulo bom após aproximadamente 2 horas. Notamos que técnicas básicas antiemulação pareciam ser um fator para receber um veredito ou reputação benigna. Felizmente, o SmartScreen parece ter uma barra de prevalência global mais alta antes de confiar em um aplicativo. Um exemplo que demonstra essa técnica está disponível aqui e é demonstrado abaixo:
Violação de reputação
Uma terceira classe de ataque contra sistemas de reputação é a adulteração de reputação. Normalmente, os sistemas de reputação usam sistemas de hash criptograficamente seguros para inviabilizar a adulteração. Entretanto, notamos que certas modificações em um arquivo não pareciam alterar a reputação do SAC. O SAC pode usar hash fuzzy ou comparações de similaridade baseadas em recursos em vez ou além do hash de arquivo padrão. Ele também pode aproveitar um modelo de ML na nuvem para permitir arquivos que tenham uma pontuação altamente benigna (como ser muito semelhante a arquivos conhecidos como bons). Surpreendentemente, algumas seções de código puderam ser modificadas sem perder sua reputação associada. Por meio de tentativa e erro, conseguimos identificar segmentos que poderiam ser adulterados com segurança e manter a mesma reputação. Criamos um binário adulterado com um hash exclusivo que nunca havia sido visto pela Microsoft ou pelo SAC. Isso incorporou um shellcode “execute calc” e pode ser executado com SAC no modo de execução:
LNK pisando forte
Quando um usuário baixa um arquivo, o navegador cria um arquivo “Zone.Identifier” associado em um fluxo de dados alternativo conhecido como Mark of the Web (MotW). Isso permite que outros softwares (incluindo AV e EDR) no sistema saibam que o arquivo é mais arriscado. O SmartScreen verifica apenas arquivos com a Marca da Web. O SAC bloqueia completamente certos tipos de arquivos, caso existam. Isso faz com que os desvios de MotW sejam um alvo de pesquisa interessante, pois geralmente podem levar à violação desses sistemas de segurança. Grupos de ameaças com motivação financeira descobriram e aproveitaram diversas vulnerabilidades para contornar as verificações do MotW. Essas técnicas envolviam anexar assinaturas de código inválidas e criadas em arquivos JavaScript ou MSI.
Durante nossa pesquisa, nos deparamos com outro bypass do MotW que é fácil de explorar. Envolve a criação de arquivos LNK que têm caminhos de destino ou estruturas internas não padrão. Quando clicados, esses arquivos LNK são modificados pelo explorer.exe com a formatação canônica. Essa modificação leva à remoção do rótulo MotW antes que as verificações de segurança sejam realizadas. A função que substitui os arquivos LNK é _SaveAsLink(), conforme mostrado na pilha de chamadas a seguir:
A função que executa a verificação de segurança é CheckSmartScreen(), conforme mostrado na pilha de chamadas a seguir:
A demonstração mais fácil desse problema é acrescentar um ponto ou espaço ao caminho executável de destino (por exemplo, powershell.exe.). Como alternativa, é possível criar um arquivo LNK que contenha um caminho relativo, como .\target.exe. Após clicar no link, explorer.exe procurará e encontrará o nome .exe correspondente, corrigirá automaticamente o caminho completo, atualizará o arquivo no disco (removendo o MotW) e, finalmente, iniciará o destino. Outra variante envolve a criação de um caminho multinível em uma única entrada da matriz de caminhos de destino do LNK. A matriz do caminho de destino normalmente deve ter 1 entradas por diretório. O utilitário pylnk3 mostra a estrutura de um exploit LNK (formato não canônico) antes e depois da execução (formato canônico):
Um script Python que demonstra essas técnicas está disponível aqui.
O seguinte mostra um arquivo LNK ignorando as restrições do MotW no Smart App Control para iniciar o Powershell e o pop calc:
Em outro exemplo, mostramos essa técnica encadeada com o depurador de linha de comando cdb da Microsoft para obter execução de código arbitrário e executar shellcode para pop calc:
Identificamos diversas amostras no VirusTotal que apresentam o bug, demonstrando seu uso na natureza. A amostra mais antiga identificada foi enviada há mais de 6 anos. Também divulgamos detalhes do bug ao MSRC. Pode ser corrigido em uma atualização futura do Windows. Estamos divulgando essas informações, juntamente com a lógica de detecção e contramedidas, para ajudar os defensores a identificar essa atividade até que um patch esteja disponível.
Detecções
O sequestro de reputação, por natureza, pode ser difícil de detectar. Inúmeras aplicações podem ser cooptadas para executar a técnica. Catalogar e bloquear aplicativos que são sabidamente abusados é uma etapa inicial (e contínua).
process where process.parent.name == "explorer.exe" and process.hash.sha256 in (
"ba35b8b4346b79b8bb4f97360025cb6befaf501b03149a3b5fef8f07bdf265c7", // AutoHotKey
"4e213bd0a127f1bb24c4c0d971c2727097b04eed9c6e62a57110d168ccc3ba10" // JamPlus
)No entanto, essa abordagem sempre ficará atrás dos invasores. Uma abordagem um pouco mais robusta é desenvolver assinaturas comportamentais para identificar categorias gerais de software abusado. Por exemplo, podemos procurar nomes de funções ou módulos comuns do Lua ou Node.js em pilhas de chamadas suspeitas:
sequence by process.entity_id with maxspan=1m
[library where
(dll.Ext.relative_file_creation_time <= 3600 or
dll.Ext.relative_file_name_modify_time <= 3600 or
(dll.Ext.device.product_id : ("Virtual DVD-ROM", "Virtual Disk","USB *") and not dll.path : "C:\\*")) and
_arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: "*!luaopen_*")] by dll.hash.sha256
[api where
process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
process.thread.Ext.call_stack_final_user_module.hash.sha256 : "?*"] by process.thread.Ext.call_stack_final_user_module.hash.sha256api where process.Ext.api.name : ("VirtualProtect*", "WriteProcessMemory", "VirtualAlloc*", "MapViewOfFile*") and
process.Ext.api.behaviors : ("shellcode", "allocate_shellcode", "execute_shellcode", "unbacked_rwx", "rwx", "hook_api") and
process.thread.Ext.call_stack_final_user_module.name : "ffi_bindings.node"As equipes de segurança devem prestar atenção especial aos arquivos baixados. Eles podem usar a reputação local para identificar valores discrepantes em seu ambiente para uma inspeção mais detalhada.
from logs-* |
where host.os.type == "windows"
and event.category == "process" and event.action == "start"
and process.parent.name == "explorer.exe"
and (process.executable like "*Downloads*" or process.executable like "*Temp*")
and process.hash.sha256 is not null
| eval process.name = replace(process.name, " \\(1\\).", ".")
| stats hosts = count_distinct(agent.id) by process.name, process.hash.sha256
| where hosts == 1O stomping LNK pode ter muitas variantes, dificultando a detecção baseada em assinaturas em arquivos LNK. No entanto, todos eles devem acionar um sinal comportamental semelhante: explorer.exe sobrescrevendo um arquivo LNK. Isso é especialmente anômalo na pasta de downloads ou quando o LNK tem a Marca da Web.
file where event.action == "overwrite" and file.extension : "lnk" and
process.name : "explorer.exe" and process.thread.Ext.call_stack_summary : "ntdll.dll|*|windows.storage.dll|shell32.dll|*" and
(
file.path : ("?:\\Users\\*\\Downloads\\*.lnk", "?:\\Users\\*\\AppData\\Local\\Temp\\*.lnk") or
file.Ext.windows.zone_identifier == 3
)Por fim, uma cobertura comportamental robusta em torno de técnicas comuns de invasores, como evasão na memória, persistência, acesso a credenciais, enumeração e movimento lateral, ajuda a detectar intrusões realistas, inclusive de sequestro de reputação.
Conclusão
Sistemas de proteção baseados em reputação são uma camada poderosa para bloquear malware comum. No entanto, como qualquer técnica de proteção, elas têm pontos fracos que podem ser contornados com algum cuidado. O Smart App Control e o SmartScreen têm uma série de deficiências fundamentais de design que podem permitir acesso inicial sem avisos de segurança e com interação mínima do usuário. As equipes de segurança devem examinar cuidadosamente os downloads em sua pilha de detecção e não depender apenas dos recursos de segurança nativos do sistema operacional para proteção nessa área.