Introdução

Em julho, o Google anunciou um novo mecanismo de proteção para cookies armazenados no Chrome no Windows, conhecido como Application-Bound Encryption. Não há dúvidas de que essa implementação de segurança elevou o nível e impactou diretamente o ecossistema de malware. Depois de meses com esse novo recurso, muitos infostealers escreveram novos códigos para contornar essa proteção (como a Equipe de Segurança do Chrome previu) para permanecerem competitivos no mercado e fornecer recursos que recuperam dados de cookies de navegadores Chrome de forma confiável.

O Elastic Security Labs vem monitorando um subconjunto dessa atividade, identificando diversas técnicas usadas por diferentes famílias de malware para contornar a criptografia vinculada ao aplicativo. Embora o ecossistema ainda esteja evoluindo devido a essa pressão, nosso objetivo é compartilhar detalhes técnicos que ajudem as organizações a entender e se defender contra essas técnicas. Neste artigo, abordaremos os diferentes métodos usados pelas seguintes famílias de infostealers:

• ROUBAR/VIDAR
• METASTEALER
• FEMEDRONA
• XENOSTEALER
• LUMMA

Principais conclusões

• As versões mais recentes de infostealers implementam desvios em torno do recurso de proteção de cookies recente do Google usando criptografia vinculada ao aplicativo
• As técnicas incluem a integração da ferramenta de segurança ofensiva ChromeKatz, aproveitando o COM para interagir com os serviços do Chrome e descriptografar a chave de criptografia vinculada ao aplicativo e usando o recurso de depuração remota no Chrome
• Os defensores devem monitorar ativamente as diferentes técnicas de desvio de cookies contra o Chrome no Windows em antecipação a futuras mitigações e desvios que provavelmente surgirão no curto e médio prazo.
• O Elastic Security fornece mitigações por meio de assinaturas de memória, regras comportamentais e oportunidades de caça para permitir identificação e resposta mais rápidas à atividade do infostealer

Histórico

Em termos gerais, os cookies são usados por aplicativos da web para armazenar informações do visitante no navegador que o visitante usa para acessar o aplicativo da web. Essas informações ajudam o aplicativo da web a rastrear o usuário, suas preferências e outras informações de um local para outro, até mesmo entre dispositivos.

O token de autenticação é um uso das estruturas de armazenamento de dados do lado do cliente que permite grande parte do funcionamento da interatividade da web moderna. Esses tokens são armazenados pelo navegador depois que o usuário se autentica com sucesso em um aplicativo da web. Após o nome de usuário e a senha, após a autenticação multifator (MFA) por meio de senhas de uso único ou biometria, o aplicativo da web “lembra” que seu navegador é você por meio da troca desse token a cada solicitação da web subsequente.

Um agente malicioso que obtém acesso a um token de autenticação válido pode reutilizá-lo para representar o usuário naquele serviço web, com a capacidade de assumir contas, roubar informações pessoais ou financeiras ou executar outras ações como aquele usuário, como transferir ativos financeiros.

Os criminosos cibernéticos usam infostealers para roubar e transformar esse tipo de informação em mercadoria para ganho financeiro.

Segurança de cookies do Google Chrome

Versões legadas do Google Chrome no Windows usavam a API de proteção de dados nativa do Windows (DPAPI) para criptografar cookies e protegê-los de outros contextos de usuários. Isso forneceu proteção adequada contra vários cenários de ataque, mas qualquer software malicioso em execução no contexto do usuário visado poderia descriptografar esses cookies usando os métodos DPAPI diretamente. Infelizmente, esse contexto é exatamente o nicho em que os infostealers geralmente se encontram após a engenharia social para acesso inicial. O esquema DPAPI agora é bem conhecido por invasores com vários vetores de ataque; desde a descriptografia local usando a API até o roubo da chave mestra e descriptografia remota, até o abuso da chave DPAPI de backup de todo o domínio em um ambiente corporativo.

Com o lançamento do Chrome 127 em julho de 2024, o Google implementou a criptografia vinculada ao aplicativo dos dados do navegador. Esse mecanismo abordou diretamente muitos ataques DPAPI comuns contra dados do navegador Windows Chrome, incluindo cookies. Ele faz isso armazenando os dados em arquivos de dados criptografados e usando um serviço executado como SYSTEM para verificar se quaisquer tentativas de descriptografia estão vindo do processo do Chrome antes de retornar a chave para esse processo para descriptografar os dados armazenados.

Embora acreditemos que esse esquema de criptografia não seja uma panaceia para proteger todos os dados do navegador (como a Equipe de Segurança do Chrome reconhece em seu comunicado), acreditamos que ele teve sucesso em levar os autores de malware a TTPs mais abertamente maliciosos e mais fáceis para os defensores identificarem e responderem.

Técnicas de desvio de ladrão, resumidas

As seções a seguir descreverão técnicas específicas de infostealer usadas para ignorar o recurso App-Bound Encryption do Google, conforme observado pelo Elastic. Embora esta não seja uma compilação exaustiva de desvios, e o desenvolvimento dessas famílias esteja em andamento, elas representam uma dinâmica interessante dentro do espaço dos infostealers, mostrando como os desenvolvedores de malware responderam ao controle de segurança atualizado recentemente pelo Google. As técnicas observadas pela nossa equipe incluem:

• Depuração remota via Protocolo DevTools do Chrome
• Leitura de memória do processo de serviço de rede do Chrome (ChromeKatz e ReadProcessMemory (RPM))
• Elevando para SYSTEM e então descriptografando app_bound_encryption_key com o método DecryptData de GoogleChromeElevationService através de COM

ROUBAR/VIDAR

Nossa equipe observou um novo código introduzido no STEALC/VIDAR relacionado à técnica de desvio de cookie por volta de 20 de setembro. Essas eram amostras atípicas que se destacavam das versões anteriores e foram implementadas como arquivos PE de 64 bits incorporados, juntamente com verificações condicionais. Os valores criptografados nos bancos de dados SQLite onde o Chrome armazena seus dados agora são prefixados com v20, indicando que os valores agora são criptografados usando criptografia vinculada ao aplicativo.

O STEALC foi introduzido em 2023 e foi desenvolvido com “forte inspiração” de outros ladrões mais estabelecidos, como RACOON e VIDAR. STEALC e VIDAR continuaram o desenvolvimento simultâneo e, no caso de desvios de criptografia vinculados a aplicativos, foram estabelecidos na mesma implementação.

Durante a extração de dados criptografados dos bancos de dados, o malware verifica esse prefixo. Se começar com v20, um processo filho será gerado usando o arquivo PE incorporado na seção .data do binário. Este programa é responsável por extrair valores de cookies não criptografados que residem em um dos processos filhos do Chrome.

Este binário incorporado cria uma área de trabalho oculta via OpenDesktopA / CreateDesktopA e então usa CreateToolhelp32Snapshot para escanear e encerrar todos os processos chrome.exe . Um novo processo chrome.exe é então iniciado com o novo objeto de área de trabalho. Com base na versão instalada do Chrome, o malware seleciona um padrão de assinatura para o recurso CookieMonster do Chromium, um componente interno usado para gerenciar cookies.

Usamos os padrões de assinatura para migrar para o código existente desenvolvido para uma ferramenta de segurança ofensiva chamada ChromeKatz. Neste momento, os padrões foram removidos do repositório ChromeKatz e substituídos por uma nova técnica. Com base em nossa análise, o autor do malware parece ter reimplementado o ChromeKatz dentro do STEALC para ignorar o recurso de proteção de criptografia vinculado ao aplicativo.

Depois que o malware identifica uma assinatura correspondente, ele enumera os processos filhos do Chrome para verificar a presença do sinalizador de linha de comando --utility-sub-type=network.mojom.NetworkService . Este sinalizador indica que o processo é o serviço de rede responsável por manipular toda a comunicação da Internet. Ele se torna um alvo principal, pois contém os dados confidenciais que o invasor procura, conforme descrito na postagem do MDSec. Em seguida, ele retorna um identificador para esse processo filho específico.

Em seguida, ele enumera cada módulo no processo filho do serviço de rede para encontrar e recuperar o endereço base e o tamanho de chrome.dll carregado na memória. STEALC usa CredentialKatz::FindDllPattern e CookieKatz::FindPattern para localizar as instâncias do CookieMonster. Há 2 chamadas para CredentialKatz::FindDllPattern.

Na primeira chamada para CredentialKatz::FindDllPattern, ele tenta localizar um dos padrões de assinatura (dependendo da versão do Chrome da vítima) em chrome.dll. Uma vez encontrado, STEALC agora tem um ponteiro de referência para o local de memória onde a sequência de bytes começa, que é a função net::CookieMonster::~CookieMonster, destruidora da classe CookieMonster .

A segunda chamada para CredentialKatz::FindDllPattern passa o endereço da função para net::CookieMonster::~CookieMonster(void) como um argumento para a pesquisa de sequência de bytes, resultando em STEALC tendo um ponteiro para a estrutura Virtual Function Pointer de CookieMonster .

O método a seguir usado pelo STEALC é, novamente, idêntico ao ChromeKatz, onde ele localiza instâncias CookieMonster escaneando blocos de memória no módulo chrome.dll em busca de ponteiros que referenciam a vtable CookieMonster . Como a vtable é uma constante em todos os objetos de uma determinada classe, qualquer objeto CookieMonster terá o mesmo ponteiro vtable. Quando uma correspondência é identificada, o STEALC trata o local da memória como uma instância CookieMonster e armazena seu endereço em uma matriz.

Para cada instância CookieMonster identificada, STEALC acessa a estrutura interna CookieMap localizada em um deslocamento de +0x30 e que é uma árvore binária. Cada nó dentro desta árvore contém ponteiros para estruturas CanonicalCookieChrome . As estruturas CanonicalCookieChrome contêm dados de cookies não criptografados, tornando-os acessíveis para extração. O STEALC então inicia uma travessia de árvore passando o primeiro nó para uma função de travessia dedicada.

Para cada nó, ele chama ReadProcessMemory para acessar a estrutura CanonicalCookieChrome da memória do processo de destino e, em seguida, processá-la em jy::GenerateExfilString.

O STEALC formata os dados do cookie extraídos convertendo a data de expiração para o formato UNIX e verificando a presença dos sinalizadores HttpOnly e Secure . Em seguida, ele acrescenta detalhes como o nome do cookie, valor, domínio, caminho e HttpOnly e Secure em uma string final para exfiltração. Estruturas OptimizedString são usadas no lugar de strings, então valores de string podem ser a própria string ou, se o comprimento da string for maior que 23, ele apontará para o endereço que armazena a string.

METASTEALER

O METASTEALER, observado pela primeira vez em 2022, atualizou recentemente sua capacidade de roubar dados do Chrome, ignorando os esforços de mitigação mais recentes do Google. Em 30 de setembro, os autores do malware anunciaram esta atualização por meio de seu canal no Telegram, destacando sua capacidade aprimorada de extrair informações confidenciais, incluindo cookies, apesar das mudanças de segurança na versão 129+ do Chrome.

O primeiro exemplar observado na natureza por nossa equipe foi descoberto em 30 de setembro, mesmo dia em que os autores promoveram a atualização. Apesar das alegações de que o malware opera sem precisar de privilégios Administrator , nossos testes revelaram que ele requer acesso elevado, pois tenta representar o token SYSTEM durante a execução.

Conforme mostrado nas capturas de tela acima, o método get_decryption agora inclui um novo parâmetro booleano. Este valor é definido como TRUE se os dados criptografados (cookie) começarem com o prefixo v20 , indicando que o cookie é criptografado usando o método de criptografia mais recente do Chrome. A função atualizada mantém a compatibilidade com versões anteriores, ainda suportando a descriptografia de cookies de versões mais antigas do Chrome, se presentes na máquina infectada.

O malware então tenta acessar os arquivos Local State ou LocalPrefs.json localizados no diretório de perfil do Chrome. Ambos os arquivos são formatados em JSON e armazenam chaves de criptografia (encrypted_key) para versões mais antigas do Chrome e app_bound_encrypted_key para versões mais recentes. Se o sinalizador estiver definido como TRUE, o malware usará especificamente o app_bound_encrypted_key para descriptografar cookies de acordo com o método de criptografia atualizado do Chrome.

Nesse caso, o malware primeiro personifica o token SYSTEM usando uma classe recém-introduzida chamada ContextSwitcher.

Em seguida, ele descriptografa a chave criando uma instância por meio do COM do serviço do Chrome responsável pela descriptografia, chamado GoogleChromeElevationService, usando o CLSID 708860E0-F641-4611-8895-7D867DD3675B. Uma vez inicializado, ele invoca o método DecryptData para descriptografar a chave app_bound_encrypted_key que será usada para descriptografar os cookies criptografados.

O METASTEALER emprega uma técnica semelhante à demonstrada em um resumo compartilhado no X em 27 de setembro, que pode ter servido de inspiração para os autores do malware. Ambas as abordagens utilizam métodos semelhantes para contornar os mecanismos de criptografia do Chrome e extrair dados confidenciais.

FEMEDRONA

Esse ladrão de código aberto chamou a atenção do mundo no início do ano por meio do uso de uma vulnerabilidade do Windows SmartScreen (CVE-2023-36025). Embora seu desenvolvimento ainda esteja ocorrendo no Telegram, nossa equipe encontrou uma versão recente (2.3.2) enviada no final de setembro, incluindo uma nova funcionalidade de captura de cookies para o Chrome.

O malware primeiro enumera os diferentes perfis no Chrome e, em seguida, executa uma verificação do navegador usando a função (BrowserHelpers.NewEncryption) que verifica o navegador Chrome com uma versão maior ou igual a 127.

Se a condição corresponder, o PHEMEDRONE usa uma combinação de funções auxiliares para extrair os cookies.

Ao visualizar a classe ChromeDevToolsWrapper e suas diferentes funções, podemos ver que o PHEMEDRONE configura uma sessão de depuração remota no Chrome para acessar os cookies. A porta padrão (9222) é usada junto com a posição da janela definida como -2400,-2400 que é definida fora da tela, impedindo que qualquer janela visível alerte a vítima.

Em seguida, o malware estabelece uma conexão WebSocket com a interface de depuração do Chrome, fazendo uma solicitação usando o método obsoleto do Chrome DevTools Protocol (Network.getAllCookies).

Os cookies são então retornados da solicitação anterior em texto simples. Abaixo está uma captura de rede mostrando esse comportamento:

XENOSTEALER

XENOSTEALER é um infostealer de código aberto hospedado no GitHub. Ele apareceu em julho 2024 e está em desenvolvimento ativo no momento desta publicação. Notavelmente, o recurso de bypass do Chrome foi confirmado em setembro 26, 2024.

A abordagem adotada pelo XENOSTEALER é semelhante à do METASTEALER. Primeiro, ele analisa o arquivo JSON em um determinado perfil do Chrome para extrair o app_bound_encrypted_key. No entanto, o processo de descriptografia ocorre dentro de um processo do Chrome. Para conseguir isso, o XENOSTEALER inicia uma instância de Chrome.exe e então injeta código usando uma classe auxiliar chamada SharpInjector, passando a chave criptografada como um parâmetro.

O código injetado posteriormente chama o método DecryptData do GoogleChromeElevationService para obter a chave descriptografada.

LUMMA

Em meados de outubro, a versão mais recente do LUMMA implementou um novo método para ignorar a proteção de cookies do Chrome, conforme relatado por @g0njxa.

Analisamos uma versão recente do LUMMA, confirmando que ele conseguiu recuperar com sucesso os dados do cookie da versão mais recente do Google Chrome (130.0.6723.70). O LUMMA primeiro cria um processo visível do Chrome via Kernel32!CreateProcessW.

Essa atividade foi acompanhada no depurador com várias chamadas para NtReadVirtualMemory , onde identificamos a pesquisa LUMMA dentro do processo do Chrome para chrome.dll.

Uma vez encontrado, o malware copia a imagem chrome.dll para sua própria memória de processo usando NtReadVirtualMemory. De forma semelhante à técnica ChromeKatz, o Lumma utiliza a varredura de padrões para atingir o componente CookieMonster do Chrome.

Lumma usa um padrão de assinatura ofuscado para identificar a funcionalidade CookieMonster :

3Rf5Zn7oFA2a????k4fAsdxx????l8xX5vJnm47AUJ8uXUv2bA0s34S6AfFA????kdamAY3?PdE????6G????L8v6D8MJ4uq????k70a?oAj7a3????????K3smA????maSd?3l4

Abaixo está a regra YARA após a desofuscação:

rule lumma_stealer
{
  meta:
    author = "Elastic Security Labs"
  strings:
    $lumma_pattern = { 56 57 48 83 EC 28 89 D7 48 89 CE E8 ?? ?? ?? ?? 85 FF 74 08 48 89 F1 E8 ?? ?? ?? ?? 48 89 F0 48 83 C4 28 5F 5E C3 CC CC CC CC CC CC CC CC CC CC 56 57 48 83 EC 38 48 89 CE 48 8B 05 ?? ?? ?? ?? 48 31 E0 48 89 44 24 ?? 48 8D 79 ?? ?? ?? ?? 28 E8 ?? ?? ?? ?? 48 8B 46 20 48 8B 4E 28 48 8B 96 ?? ?? ?? ?? 4C 8D 44 24 ?? 49 89 10 48 C7 86 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 FA FF 15 ?? ?? ?? ?? 48 8B 4C 24 ?? 48 31 E1}
  condition:
    all of them
}

Após decodificar e procurar o padrão em chrome.dll, isso leva ao destruidor CookieMonster (net::CookieMonster::~CookieMonster).

Os cookies são então identificados na memória e despejados em texto simples pelo processo do Chrome.

Após a conclusão, o LUMMA envia os cookies junto com os outros dados solicitados como vários arquivos zip (criptografados em xor e codificados em base64) para o servidor C2.

Detecção

Abaixo estão as seguintes detecções comportamentais que podem ser usadas para identificar técnicas usadas por ladrões de informações:

• Acesso de credencial do navegador da Web por meio de processo incomum
• Acesso de credencial do navegador da Web por meio de processo não assinado
• Acesso a credenciais do navegador de memória suspeita
• Falha na tentativa de acesso aos arquivos do navegador da Web
• Depuração do navegador de um pai incomum
• Descoberta potencial de informações do navegador

Além disso, as seguintes consultas podem ser usadas para procurar diversos comportamentos anormais relacionados:

Acesso aos cookies por um processo incomum

Esta consulta usa eventos de abertura de arquivo e acessos agregados por processo e, em seguida, procura aqueles que são observados em hosts exclusivos e com uma contagem total de acesso baixa:

FROM logs-endpoint.events.file-default*
| where event.category == "file" and event.action == "open" and file.name == "Cookies" and file.path like "*Chrome*"
| keep file.path, process.executable, agent.id
| eval process_path = replace(to_lower(process.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by process_path
| where agents_count <= 2 and access_count <=2

Abaixo, um exemplo de correspondências de diversos ladrões de informações, incluindo os atualizados com novos recursos de roubo de cookies do Chrome:

O comportamento do METASTEALER tende a primeiro encerrar todas as instâncias do Chrome em execução e, em seguida, chama CoCreateInstance para instanciar o serviço de elevação do Google Chrome. Essa série de eventos pode ser expressa com a seguinte consulta EQL:

sequence by host.id with maxspan=1s
[process where event.action == "end" and process.name == "chrome.exe"] with runs=5
[process where event.action == "start" and process.name == "elevation_service.exe"]

A busca anterior indica agentes suspeitos, mas não identifica o processo de origem. Ao habilitar a auditoria de acesso a objetos de registro por meio do evento 4663 na chave de registro CLSID do serviço Chrome Elevation {708860E0-F641-4611-8895-7D867DD3675B}, podemos detectar processos incomuns tentando acessar essa chave:

FROM logs-system.security-default* | where event.code == "4663" and winlog.event_data.ObjectName == "\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{708860E0-F641-4611-8895-7D867DD3675B}" and not winlog.event_data.ProcessName in ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe", "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe") and not winlog.event_data.ProcessName like "C:\\\\Program Files\\\\Google\\\\Chrome\\\\Application\\\\*\\\\elevation_service.exe" | stats agents_count = COUNT_DISTINCT(agent.id), access_count= count(*) by winlog.event_data.ProcessName | where agents_count <= 2 and access_count <=2

Abaixo está um exemplo de correspondências no malware METASTEALER ao chamar CoCreateInstance (CLSID_Elevator):

O ladrão PHEMEDRONE usa o método conhecido de depuração do navegador para coletar cookies via API do Chromium. Isso pode ser observado na captura de tela a seguir, onde podemos ver uma instância do NodeJs se comunicando com uma instância do navegador com depuração habilitada pela porta 9222:

A seguinte consulta EQL pode ser usada para procurar processos incomuns executando comportamento semelhante:

sequence by host.id, destination.port with maxspan=5s
[network where event.action == "disconnect_received" and
 network.direction == "ingress" and
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and
 source.address like "127.*" and destination.address like "127.*"]
[network where event.action == "disconnect_received" and network.direction == "egress" and not
 process.executable in~ ("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe",
"C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe") and source.address like "127.*" and destination.address like "127.*"]

Navegador Chrome gerado por um pai incomum

O exemplo STEALC que usa a implementação do ChromeKatz gera uma instância do Google Chrome para carregar o perfil padrão do usuário, enquanto procura por executáveis pais normais, verifica-se que ele está limitado aos pais assinados pelo Chrome e ao Explorer.exe. a seguinte consulta ES|QL pode ser usada para encontrar pais incomuns:

FROM logs-endpoint.events.process-*
| where event.category == "process" and event.type == "start" and to_lower(process.name) == "chrome.exe" and process.command_line like  "*--profile-directory=Default*"
| eval process_parent_path = replace(to_lower(process.parent.executable), """c:\\users\\[a-zA-Z0-9\.\-\_\$]+\\""", "c:\\\\users\\\\user\\\\")
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process_parent_path
| where agents_count == 1 and total_executions <= 10

Binários não confiáveis da pasta do aplicativo Chrome

Como o serviço de elevação do Chrome confia em binários executados na pasta program files do Chrome, as seguintes consultas podem ser usadas para procurar binários não assinados ou não confiáveis executados ou carregados de lá:

DLLs não assinadas carregadas da pasta do aplicativo Google Chrome

FROM logs-endpoint.events.library*
| where event.category == "library" and event.action == "load" and to_lower(dll.path) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" and not (dll.code_signature.trusted == true)
| keep process.executable, dll.path, dll.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, dll.path, dll.hash.sha256
| where agents_count == 1 and total_executions <= 10

Executável não assinado iniciado a partir da pasta do aplicativo Google Chrome

FROM logs-endpoint.events.process*
| where event.category == "library" and event.type == "start" and (to_lower(process.executable) like "c:\\\\program files\\\\google\\\\chrome\\\\application\\\\*" or to_lower(process.executable) like "c:\\\\scoped_dir\\\\program files\\\\google\\\\chrome\\\\application\\\\*")
and not (process.code_signature.trusted == true and process.code_signature.subject_name == "Goole LLC")
| keep process.executable,process.hash.sha256, agent.id
| stats agents_count = COUNT_DISTINCT(agent.id), total_executions = count(*) by process.executable, process.hash.sha256
| where agents_count == 1 and total_executions <= 10

Conclusão

O Google elevou o nível implementando novos controles de segurança para proteger dados de cookies no Chrome. Como esperado, isso fez com que os desenvolvedores de malware desenvolvessem ou integrassem seus próprios desvios. Esperamos que o Google continue inovando para fornecer proteção mais forte aos dados dos usuários.

Organizações e defensores devem monitorar consistentemente atividades incomuns em endpoints. Embora essas novas técnicas possam ser bem-sucedidas, elas também são ruidosas e detectáveis com a instrumentação, os processos e o pessoal de segurança corretos.

Desvios de Stealer e MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que as ameaças usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Acesso a credenciais
• Defense Evasion
• Descoberta
• Execução

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Roubar cookies de sessão Web
• Injeção de processo
• Credenciais de armazenamentos de senhas
• Descoberta de informações do sistema
• Descoberta de Processos
• Comunicação entre processos: Modelo de objeto componente

YARA

O Elastic Security criou regras YARA para identificar essa atividade.

• Windows.Trojan.Stealc
• Windows.Infostealer.PhemedroneStealer
• Windows.Trojan.MetaStealer
• Windows.Trojan.Xeno
• Windows.Trojan.Lumma
• Windows.Infostealer.Generic

Observações

Todos os observáveis também estão disponíveis para download nos formatos ECS e STIX.

Os seguintes observáveis foram discutidos nesta pesquisa.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://developer.chrome.com/release-notes/127
• https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html