Tomando SHELLTER: uma estrutura de evasão comercial abusada na natureza 

Introdução

O Elastic Security Labs está observando diversas campanhas que parecem estar aproveitando a estrutura de evasão AV/EDR comercial, SHELLTER, para carregar malware. O SHELLTER é comercializado para o setor de segurança ofensiva para avaliações de segurança sancionadas, permitindo que os operadores da equipe vermelha implantem suas estruturas C2 de forma mais eficaz contra soluções antimalware contemporâneas.

Principais conclusões

• Estrutura de evasão comercial SHELLTER adquirida por grupos de ameaças
• SHELLTER foi usado em várias campanhas de infostealer desde abril de 2025, conforme registrado nos metadados da licença
• SHELLTER emprega capacidades únicas para evitar análise e detecção
• Elastic Security Labs lança descompactador dinâmico para binários protegidos por SHELLTER

Throughout this document we will refer to different terms with “shellter” in them. We will try to 
maintain the following style to aid readability:
  *  “Shellter Project” - the organization that develops and sells the Shellter evasion framework
  *  “Shellter Pro Plus/Elite” - the commercial names for the tools sold by the Shellter Project
  *  “SHELLTER” - the loader we have observed in malicious usage and are detailing in this report
  *  “SHELLTER-protected” - a descriptor of final payloads that the SHELLTER loader delivers

Visão geral do SHELLTER

SHELLTER é uma estrutura de evasão comercial que auxilia equipes vermelhas há mais de uma década. Ele ajuda provedores de serviços de segurança ofensivos a contornar ferramentas antivírus e, mais recentemente, EDR. Isso permite que as equipes vermelhas utilizem suas estruturas C2 sem o desenvolvimento constante normalmente necessário, já que os fornecedores de segurança escrevem assinaturas de detecção para elas.

While the Shellter Project does offer a free version of the software, it has a limited feature-set, 
only 32-bit .exe support, and is generally better understood and detected by anti-malware 
products. The free version is not described in this article.

SHELLTER, como muitas outras ferramentas de segurança ofensivas (OSTs), é um produto de uso duplo. Atores mal-intencionados, uma vez que obtêm acesso a ele, podem usar o SHELLTER para estender a vida útil de suas ferramentas. Fornecedores respeitáveis de segurança ofensiva, como o Shellter Project, implementam salvaguardas para reduzir o risco de seus produtos serem usados de forma maliciosa. Essas medidas incluem limites geográficos de vendas, due diligence organizacional e Contratos de Licença de Usuário Final (EULAs). Apesar desses esforços, agentes maliciosos altamente motivados continuam sendo um desafio.

Em meados de junho, nossa pesquisa identificou diversas campanhas de infostealers com motivação financeira que têm usado o SHELLTER para empacotar cargas úteis a partir do final de abril de 2025. As evidências sugerem que esta é a versão 11.0 do Shellter Elite, que foi lançada em abril 16, 2025.

SHELLTER é um projeto complexo que oferece uma ampla gama de configurações personalizadas para ambientes operacionais específicos, mecanismos de entrega de carga útil e paradigmas de criptografia. Este relatório se concentra exclusivamente em recursos observados em campanhas maliciosas identificadas. Embora alguns recursos pareçam comuns, uma revisão abrangente de todos os recursos disponíveis está além do escopo deste documento.

Carregador SHELLTER - Detalhes técnicos

As seções a seguir descrevem recursos que se assemelham a alguns dos Recursos Exclusivos Elite publicados pelo Projeto Shellter. Nossa avaliação indica que estamos observando Shellter Elite. Essa conclusão se baseia em uma revisão da documentação pública do desenvolvedor, na observação de vários exemplos de diferentes compilações com alto grau de similaridade de código e na prevalência de recursos de evasão raramente observados.

Código Lixo Polimórfico

Amostras protegidas por SHELLTER geralmente empregam shellcode automodificável com ofuscação polimórfica para se incorporarem em programas legítimos. Essa combinação de instruções legítimas e código polimórfico ajuda esses arquivos a escapar da detecção e assinaturas estáticas, permitindo que eles permaneçam indetectáveis.

Ao definir um ponto de interrupção VirtualAlloc em em uma amostra RHADAMANTHYS protegida por SHELLTER, podemos ver a pilha de chamadas desta amostra de malware.

Esse tipo de código polimórfico confunde os desmontadores estáticos e prejudica os esforços de emulação. Essas instruções aparecem durante o estágio de descompactação, chamando um desses pares de funções da API do Windows para alocar memória para um novo stub de shellcode:

• GetModuleHandleA / GetProcAddress
• CreateFileMappingW / MapViewOfFile

A funcionalidade SHELLTER está contida em uma nova função substancial. Ele é alcançado após instruções adicionais de descompactação e lixo no stub do shellcode. O IDA Pro ou o Binary Ninja podem descompilar o código com sucesso nesta fase.

Desconectando módulos do sistema por meio de mapeamentos de arquivos

Para ignorar técnicas de interceptação de API de fornecedores de AV/EDR, o SHELLTER mapeia uma nova cópia de ntdll.dll via NtCreateSection e NtMapViewOfSection.

Há também uma segunda opção para desengatar carregando um ntll.dll limpo do diretório KnownDLLs via NtOpenSection e NtMapViewOfSection.

Criptografia e compressão de carga útil

O SHELLTER criptografa suas cargas finais definidas pelo usuário usando o modo AES-128 CBC. Essa criptografia pode ocorrer de duas maneiras:

• Chave/IV incorporado: Um par de chave/IV gerado aleatoriamente é incorporado diretamente na carga útil do SHELLTER.
• Chave/IV obtida pelo servidor: o par chave/IV é obtido de um servidor controlado pelo adversário.

Para amostras que utilizaram a opção incorporada, recuperamos com sucesso a carga útil subjacente.

Os blobs criptografados estão localizados no final de cada carga útil do SHELLTER.

A chave AES e o IV podem ser encontrados como constantes sendo carregadas em variáveis de pilha em estágios muito iniciais do payload como parte de sua rotina de inicialização.

No Shellter Elite v11.0, por padrão, as cargas úteis são compactadas usando o algoritmo LZNT1 antes de serem criptografadas.

Pré-carregamento de DLL e evasão de pilha de chamadas

O recurso “Forçar pré-carregamento de módulos do sistema” permite o pré-carregamento de DLLs essenciais do subsistema Windows, como advapi32.dll, wininet.dll e crypt32.dll, para dar suporte às operações da carga útil subjacente. As três opções configuráveis incluem:

• --Force-PreloadModules-Basic (16 módulos de uso geral)
• --Force-PreloadModules-Networking (5 módulos específicos de rede)
• --Force-PreloadModules-Custom (até 16 módulos definidos pelo usuário)

Esses módulos estão sendo carregados por meio de LoadLibraryExW ou LdrLoadDll. Detalhes sobre proxy de API por meio de manipuladores de exceção vetorizados (VEH) personalizados serão discutidos em uma seção subsequente.

Abaixo está um exemplo de uma lista de módulos pré-carregados em uma carga útil protegida por SHELLTER que corresponde à opção --Force-PreloadModules-Basic , encontrada em um exemplo que implementa um cliente carregador C++ simples abusando do BITS (Background Intelligent Transfer Service) para C2 – uma abordagem incomum favorecida por algumas ameaças.

O exemplo a seguir é uma lista que corresponde à opção --Force-PreloadModules-Networking encontrada em um carregamento de amostra LUMMA.

Este recurso (lançado no Shellter Pro Plus v10.x) aproveita a capacidade de evasão da pilha de chamadas para ocultar a origem da chamada LoadLibraryExW ao carregar bibliotecas relacionadas à rede e criptografia.

Abaixo está um exemplo de um rastreamento procmon ao carregar wininet.dll, mostrando uma pilha de chamadas truncada:

No mesmo exemplo que tem o sinalizador --Force-PreloadModules-Basic habilitado, observamos que as dependências dos módulos pré-carregados também estavam sujeitas à corrupção da pilha de chamadas. Por exemplo, urlmon.dll também oculta a origem da chamada LoadLibraryExW para suas dependências iertutil.dll, srvcli.dll e netutils.dll.

Desvinculação de módulos AV/EDR

O SHELLTER inclui funcionalidade para desvincular módulos DLL de chamariz que são colocados dentro do Process Environment Block (PEB). Esses módulos de isca são usados por alguns fornecedores de segurança como canários para monitorar quando o shellcode tenta enumerar a lista PEB LDR manualmente. PEB LDR é uma estrutura no Windows que contém informações sobre os módulos carregados de um processo.

Observamos apenas um nome de módulo exclusivo com base em seu hash (diferente por amostra), que acaba resolvendo para kern3l32.dll [sic].

Ofuscação de hash de API

Amostras observadas empregam semeadura baseada em tempo para ofuscar endereços de API. O malware primeiro lê o valor SystemTime da estrutura KUSER_SHARED_DATA no endereço 0x7FFE0014 para derivar uma chave XOR dinâmica.

Em seguida, ele usa um algoritmo de hash ROR13 semeado em nomes de API para resolver os endereços de função em tempo de execução.

Uma vez resolvidos, opcionalmente, esses ponteiros são ofuscados por meio de XOR com a chave baseada em tempo e aplicação de uma rotação bit a bit antes de serem armazenados em uma tabela de consulta. Essa tática é aplicada em todo o binário para ocultar uma variedade de dados, como outros ponteiros de função, stubs de chamadas de sistema e identificadores de módulos carregados.

Verificação de licença e autodesarmamento

Para cada carga útil SHELLTER, há três estruturas FILETIME incorporadas. Em um exemplo de amostra, descobriu-se que estes eram:

• Data e hora de expiração da licença (2026-04-17 19:17:24.055000)
• Data e hora de autodesarme (2026-05-21 19:44:43.724952)
• Data e hora de início da infecção (2025-05-21 19:44:43.724952)

A verificação de expiração da licença compara a hora atual com a data e hora de expiração da licença, definindo o sinalizador license_valid na estrutura de contexto. Existem 28 locais de chamada exclusivos (provavelmente 28 recursos licenciados) para a verificação de validade da licença, onde o sinalizador license_valid determina se a lógica do código principal é ignorada, confirmando que a data e hora de expiração da licença atua como um kill switch.

Por padrão, a data de autodesarmamento é definida exatamente um ano após a data de início da infecção inicial. Quando o sinalizador de autodesarmamento é acionado, várias rotinas de limpeza são executadas. Uma dessas rotinas envolve o desmapeamento do módulo ntdll carregado manualmente (se presente) e a limpeza da tabela de consulta NTAPI, que faz referência ao módulo ntdll mapeado manualmente ou ao carregado durante a inicialização do processo.

Embora as datas e horas de início do autodesarme e da infecção sejam diferentes de amostra para amostra, observamos que a data e hora de expiração da licença (2026-04-17 19:17:24.055000) permanece constante.

É possível que esse tempo seja gerado exclusivamente para cada licença emitida pelo The Shellter Project. Se for assim, isso apoiaria a hipótese de que apenas uma única cópia do Shellter Elite foi adquirida para uso malicioso. Este valor não aparece na análise estática, mas aparece no primeiro estágio descompactado.

Abaixo está uma regra YARA que pode ser usada para identificar esse valor de expiração de licença codificado nas amostras ilícitas de SHELLTER que examinamos:

rule SHELLTER_ILLICIT_LICENSE {  
    meta:  
        author = "Elastic Security"  
        last_modified = "2025-07-01"  
        os = "Windows"  
        family = "SHELLTER"  
        threat_name = "SHELLTER_ILLICIT_LICENSE"

    strings:

        // 2026-04-17 19:17:24.055000  
        $license_server = { c7 84 24 70 07 00 00 70 5e 2c d2 c7 84 24 74 07 00 00 9e ce dc 01}

    condition:  
        any of them  
}

Evasão de varredura de memória

Amostras protegidas por SHELLTER implementaram várias técnicas, incluindo evasões de tempo de execução, para evitar a detecção. Esses tipos de técnicas incluem:

• Instruções de decodificação e recodificação em tempo de execução
• Remoção de permissões de execução em páginas de memória inativas
• Reduzindo o footprint, impactando assinaturas na memória usando YARA
• Usando estruturas internas do Windows, como PEB, como locais temporários de armazenamento de dados

SHELLTER gera um stub estilo trampolim com base na versão do sistema operacional. Há uma página de 4 KB que contém este stub, onde as permissões de memória flutuam usando NtQueryVirtualMemory e NtProtectVirtualMemory.

Quando a página estiver ativa, os bytes codificados podem ser observados neste endereço, 0x7FF5FFCE0000.

SHELLTER decodifica esta página quando ativa por meio de um loop XOR usando a chave SystemTime derivada da estrutura KUSER_SHARED_DATA .

Abaixo está a mesma página de memória (0x7FF5FFCE0000), mostrando o stub de trampolim decodificado para a chamada de sistema (ntdll_NtOpenFile).

Quando a funcionalidade é necessária, as permissões da página de memória são definidas com permissões de Leitura/Execução (RX). Após a execução, as páginas são definidas como inativas.

A proteção contínua da funcionalidade principal durante o tempo de execução complica os esforços de análise e detecção. Esse nível de proteção é incomum em amostras gerais de malware.

Syscalls indiretos / Corrupção da pilha de chamadas

Conforme mostrado na seção anterior, o SHELLTER ignora os ganchos do modo de usuário usando chamadas de sistema indiretas baseadas em trampolim. Em vez de invocar syscall diretamente, ele prepara a pilha com o endereço de uma instrução syscall limpa de ntdll.dll. Uma instrução ret então insere esse endereço no registrador RIP , desviando a execução para a instrução syscall furtivamente.

Abaixo está um exemplo de eventos do Elastic Defend VirtualProtect , mostrando a combinação das duas evasões (chamada de sistema indireta e truncamento de pilha de chamadas). Essa técnica pode ignorar ou interromper vários mecanismos de detecção de segurança.

Detecção avançada de VM/Sandbox

A documentação do SHELLTER faz referência a um recurso de detecção de hipervisor. Uma capacidade semelhante é observada em nossas amostras maliciosas após uma chamada para ZwQuerySystemInformationEx usando instruções CPUID e _bittest . Esta funcionalidade retorna várias informações da CPU junto com o sinalizador da Tecnologia Hyper-Threading (HTT).

Detecção do depurador (UM/KM)

O SHELLTER emprega detecção de depuração em modo de usuário e modo kernel usando sinalizadores de heap de processo e verificando o sinalizador KdDebuggerEnabled por meio da estrutura _KUSER_SHARED_DATA .

Desvio AMSI

Existem dois métodos de bypass de AMSI. O primeiro método envolve a aplicação de patches na memória de funções AMSI. Essa técnica pesquisa padrões de bytes específicos nas funções e os modifica para alterar a lógica da função. Por exemplo, ele substitui uma string de 4 bytes "AMSI" por bytes nulos e corrige saltos condicionais para seu oposto.

O segundo método é um pouco mais sofisticado. Primeiro, ele tenta sabotar opcionalmente a consulta da interface do Component Object Model (COM) encontrando a constante GUID CLSID_Antimalware {fdb00e52-a214-4aa1-8fba-4357bb0072ec} dentro de amsi.dll, localizando um ponteiro para ela em uma seção de dados graváveis e corrompendo esse ponteiro para fazê-lo apontar 8 bytes antes do GUID real.

O ponteiro de destino é o ponteiro CLSID na entrada do mapa de objetos da Biblioteca de Modelos Ativos (ATL) do módulo AMSI, uma estrutura usada pela função DllGetClassObject para localizar e criar classes COM registradas. Ao corromper o ponteiro neste mapa, a pesquisa pelo provedor antimalware falhará, impedindo sua criação, causando falha em AmsiInitialize com uma exceção CLASS_E_CLASSNOTAVAILABLE .

Em seguida, ele chama AmsiInitialize - Se o patch anterior não ocorreu e a chamada da API for bem-sucedida, ele executa um patch vtable como um mecanismo de fallback. O HAMSICONTEXT obtido de AmsiInitialize contém um ponteiro para um objeto COM IAntimalware , que por sua vez contém um ponteiro para sua tabela de funções virtuais. O bypass tem como alvo a função IAntimalware::Scan nesta tabela. Para neutralizá-lo, o código pesquisa na página de memória que contém a função IAntimalware::Scan por uma instrução ret .

Após encontrar um gadget adequado, ele substitui o ponteiro de função Scan pelo endereço do gadget ret . O resultado é que qualquer chamada subsequente para AmsiScanBuffer ou AmsiScanString invocará a vtable corrigida, pulará diretamente para uma instrução ret e retornará imediatamente.

Proxy de API do manipulador de exceções vetorizado

Há um sofisticado mecanismo de proxy de API que é obtido redirecionando chamadas para APIs resolvidas e stubs de chamadas de sistema criados por meio de um manipulador de exceções personalizado, que atua como um proxy de fluxo de controle. Ele pode ser dividido em duas fases: configuração e execução.

A fase 1 envolve a alocação de duas páginas de memória especiais que servirão como “gatilhos” para o manipulador de exceções. A proteção para essas páginas está definida como PAGE_READONLY e tentar executar código ali causará uma exceção STATUS_ACCESS_VIOLATION , o que é intencional. Os endereços dessas páginas de gatilho são armazenados na estrutura de contexto:

• api_call_trigger_page - A página que será chamada para iniciar o proxy.
• api_return_trigger_page - A página para a qual a API real retornará.

Um modelo de manipulador de exceção do binário é copiado para uma região alocada e registrado como o manipulador primário para o processo usando RtlAddVectoredExceptionHandler. Um valor de espaço reservado mágico codificado (0xe1e2e3e4e5e6e7e8) no manipulador é então substituído por um ponteiro para a própria estrutura de contexto.

Observando um exemplo de callsite, se o proxy VEH for usado, o endereço de GetCurrentDirectoryA será armazenado em ctx_struct->target_API_function e o ponteiro de função da API será substituído pelo endereço da página de gatilho de chamada. Esta página de gatilho é então chamada, disparando uma exceção STATUS_ACCESS_VIOLATION .

O fluxo de controle é redirecionado para o manipulador de exceções. O endereço com falha do contexto de exceção é verificado e, se corresponder à página de gatilho de chamada, ele sabe que é uma chamada de proxy de API de entrada e executa o seguinte:

• Salve o endereço de retorno original
• Sobrescreva o endereço de retorno na pilha com o endereço da página do gatilho de retorno
• Define o registro RIP para o endereço de API real salvo anteriormente em ctx_struct->target_API_function.

A chamada GetCurrentDirectoryA é então executada. Quando termina, ele salta para a página do gatilho de retorno, causando uma segunda exceção STATUS_ACCESS_VIOLATION e redirecionando o fluxo de controle de volta para o manipulador de exceções. O endereço com falha é verificado para ver se corresponde à página de gatilho de retorno; se for o caso, RIP é definido como o endereço de retorno original e o fluxo de controle retorna ao site da chamada original.

Campanhas

Em junho, o Elastic Security Labs identificou diversas campanhas implantando vários ladrões de informações protegidos pelo Shellter Elite, conforme registrado pelas informações de licença presentes em cada binário. Aproveitando as ferramentas acima, observamos que agentes de ameaças em diferentes campanhas integraram rapidamente esse carregador altamente evasivo em seus próprios fluxos de trabalho.

LUMMA

O infostealer LUMMA estava sendo distribuído com o SHELLTER a partir do final de abril, como evidenciado pelos metadados dentro dos binários. Embora o vetor de infecção inicial não esteja claro, conseguimos verificar (usando ANY.RUN) que os arquivos relacionados estavam sendo hospedados na plataforma de hospedagem de arquivos MediaFire .

Quero vender

Em 16 de maio, o usuário do Twitter/X @darkwebinformer postou uma captura de tela com a legenda:

🚨Shellter Elite v11.0 à venda em um fórum popular

“Exploit Garant” neste caso se refere a um terceiro, semelhante a uma custódia, que media a transação.

ARECHCLIENT2

A partir de maio, observamos campanhas direcionadas a criadores de conteúdo com atrativos centrados em oportunidades de patrocínio. Esses parecem ser e-mails de phishing enviados a indivíduos com um canal do YouTube que se passa por marcas como Udemy, Skillshare, Pinnacle Studio e Duolingo. Os e-mails incluem links para download de arquivos compactados (.rar), que contêm conteúdo promocional legítimo empacotado com um executável protegido por SHELLTER.

Este executável subjacente compartilha características e comportamentos com nossa análise SHELLTER anterior. No momento em que este artigo foi escrito, ainda podemos ver amostras com taxas de detecção muito baixas no VirusTotal. Isso se deve a vários fatores associados a recursos personalizados para evitar análise estática, incluindo código polimórfico, backdooring de código em aplicativos legítimos e aplicação de certificados de assinatura de código.

A carga útil incorporada observada neste arquivo implanta o infostealer ARECHCLIENT2, também conhecido como SECTOP RAT. O C2 para este ladrão aponta para 185.156.72[.]80:15847, , que foi identificado anteriormente por nossa equipe em 17 de junho, quando discutimos essa ameaça em associação com o carregador GHOSTPULSE.

RHADAMANTHYS

Essas infecções começam com vídeos do YouTube direcionados a tópicos como hacking e mods de jogos, com comentários em vídeo vinculados a arquivos maliciosos hospedados no MediaFire.

Um dos arquivos que foi distribuído anteriormente usando esse método foi enviado 126 vezes únicas até esta publicação por diferentes indivíduos.

Este arquivo compartilha as mesmas características comportamentais do mesmo código subjacente das seções anteriores de análise do SHELLTER. A carga útil incorporada com este exemplo implanta o RHADAMANTHYS infostealer.

Desempacotador SHELLTER

O Elastic Security Labs está lançando um descompactador dinâmico para binários protegidos pelo SHELLTER. Esta ferramenta utiliza uma combinação de técnicas de análise dinâmica e estática para extrair automaticamente vários estágios de carga útil de um binário protegido por SHELLTER.

Como o SHELLTER oferece uma ampla gama de recursos opcionais, este desempacotador não é totalmente abrangente, embora processe com sucesso uma grande maioria das amostras testadas. Mesmo com binários não suportados, normalmente é possível extrair pelo menos um estágio de carga útil.

Por razões de segurança, esta ferramenta só deve ser executada em uma máquina virtual isolada. Durante o processo de descompactação, código executável potencialmente malicioso é mapeado na memória. Embora algumas salvaguardas básicas tenham sido implementadas, elas não são infalíveis.

Conclusão

Apesar dos melhores esforços da comunidade OST comercial para manter suas ferramentas para propósitos legítimos, os métodos de mitigação são imperfeitos. Eles, assim como muitos de nossos clientes, enfrentam invasores persistentes e motivados. Embora o Projeto Shellter seja uma vítima neste caso devido à perda de propriedade intelectual e ao tempo de desenvolvimento futuro, outros participantes no espaço de segurança agora devem lidar com ameaças reais utilizando ferramentas mais capazes.

Esperamos:

• Essa versão ilícita do SHELLTER continuará a circular pela comunidade criminosa e potencialmente fará a transição para atores alinhados aos Estados-nação.
• O Projeto Shellter atualizará e lançará uma versão que atenua as oportunidades de detecção identificadas nesta análise.
  • Qualquer nova ferramenta continuará sendo alvo de agentes mal-intencionados.
• Ameaças mais avançadas analisarão essas amostras e incorporarão recursos em seus conjuntos de ferramentas.

Nosso objetivo é que essa análise ajude os defensores na detecção precoce dessas campanhas de infostealers identificadas e os prepare para uma possível expansão dessas técnicas para outras áreas do cenário ofensivo.

Malware 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.

• Command and Control (Comando e controle)
• Coleta
• Defense Evasion
• Execução
• Acesso inicial
• Desenvolvimento de recursos

Técnicas

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

• Protocolo da Camada de Aplicação
• Dados do Sistema Local
• Injeção de Processo: Sequestro de Execução de Thread
• Arquivos ou informações ofuscados: inserção de código indesejado
• Injeção de conteúdo
• Obter Capacidades

Mitigando SHELLTER

Prevenção

• Shellcode do Módulo Assinado Incomum da Microsoft
• Shellcode sem suporte do módulo não assinado
• Execução de Shellcode do Módulo de Baixa Reputação
• Evasão potencial por meio de assinatura de código inválida
• Suspensão de thread de memória sem backup
• Mapeamento de memória executável suspeito

YARA

O Elastic Security criou regras YARA para identificar essa atividade.

rule Windows_Trojan_Shellter {  
    meta:  
        author = "Elastic Security"  
        creation_date = "2025-06-30"  
        last_modified = "2025-06-30"  
        os = "Windows"  
        arch = "x86"  
        category_type = "Trojan"  
        family = "Shellter"  
        threat_name = "Windows.Trojan.Shellter"  
        reference_sample = "c865f24e4b9b0855b8b559fc3769239b0aa6e8d680406616a13d9a36fbbc2d30"

    strings:  
        $seq_api_hashing = { 48 8B 44 24 ?? 0F BE 00 85 C0 74 ?? 48 8B 44 24 ?? 0F BE 00 89 44 24 ?? 48 8B 44 24 ?? 48 FF C0 48 89 44 24 ?? 8B 04 24 C1 E8 ?? 8B 0C 24 C1 E1 ?? 0B C1 }  
        $seq_debug = { 48 8B 49 30 8B 49 70 8B 40 74 0B C1 25 70 00 00 40 85 C0 75 22 B8 D4 02 00 00 48 05 00 00 FE 7F }  
        $seq_mem_marker = { 44 89 44 24 ?? 89 54 24 ?? 48 89 4C 24 ?? 33 C0 83 F8 ?? 74 ?? 48 8B 44 24 ?? 8B 4C 24 ?? 39 08 75 ?? EB ?? 48 63 44 24 ?? 48 8B 4C 24 }  
        $seq_check_jmp_rcx = { 48 89 4C 24 ?? B8 01 00 00 00 48 6B C0 00 48 8B 4C 24 ?? 0F B6 04 01 3D FF 00 00 00 75 ?? B8 01 00 00 00 48 6B C0 01 48 8B 4C 24 ?? 0F B6 04 01 3D E1 00 00 00 75 ?? B8 01 00 00 00 }  
        $seq_syscall_stub = { C6 84 24 98 00 00 00 4C C6 84 24 99 00 00 00 8B C6 84 24 9A 00 00 00 D1 C6 84 24 9B 00 00 00 B8 C6 84 24 9C 00 00 00 00 C6 84 24 9D 00 00 00 00 C6 84 24 9E 00 00 00 00 }  
        $seq_mem_xor = { 48 8B 4C 24 ?? 0F B6 04 01 0F B6 4C 24 ?? 3B C1 74 ?? 8B 44 24 ?? 0F B6 4C 24 ?? 48 8B 54 24 ?? 0F B6 04 02 33 C1 8B 4C 24 ?? 48 8B 54 24 ?? 88 04 0A }  
        $seq_excep_handler = { 48 89 4C 24 08 48 83 EC 18 48 B8 E8 E7 E6 E5 E4 E3 E2 E1 48 89 04 24 48 8B 44 24 20 48 8B 00 81 38 05 00 00 C0 }  
    condition:  
        3 of them  
}

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://x.com/DarkWebInformer/status/1923472392157790700
• https://www.shellterproject.com/shellter-editions-feature-comparison-table/
• https://www.shellterproject.com/Downloads/ShellterElite/Shellter_Elite_Exclusive_Features.pdf
• https://github.com/elastic/labs-releases/tree/main/tools/shellter