Scarred Manticore usa implantes passivos em servidores Windows no Oriente Médio

Grupo alinhado ao Irã emprega o framework LIONTAIL para receber cargas por tráfego HTTP, pipes nomeados e web shells, com implantes adaptados a servidores comprometidos.

Componente	Framework LIONTAIL, backdoors passivos em C, loaders de shellcode, web shells, pipes nomeados e o encaminhador LIONHEAD em servidores Windows, incluindo instâncias expostas à internet e servidores Exchange.
Vetor	Uso de acesso prévio a servidores públicos para instalar executáveis ou DLLs carregadas por sequestro de ordem de busca, com listeners em prefixos HTTP, web shells ou pipes nomeados em hosts internos.
Impacto	Execução remota de shellcode em memória, execução de comandos, acesso encadeado a recursos internos e possível ocultação de tráfego para EWS; a exfiltração é descrita como objetivo observado em operações do ator.
Prioridade	Investigar servidores Windows e Exchange expostos, revisar DLLs anômalas em C:\windows\system32, serviços habilitados fora do padrão, listeners HTTP incomuns e criação permissiva de pipes nomeados.
Artefatos	DLLs wlanapi.dll e wlbsctrl.dll, prefixos HTTP com curinga forte +, uso direto de HTTP.sys, IOCTLs de recebimento e resposta HTTP, pipe \\.\pipe\test-pipe e obfuscação com XOR de um byte seguida de Base64.
Atribuição	A atividade é acompanhada como Scarred Manticore, ator iraniano próximo de DEV-0861, com sobreposições históricas a clusters ligados ao OilRig, mas sem base suficiente para afirmar equivalência direta.

Resumo técnico

Scarred Manticore aparece como um conjunto de operações de intrusão associado ao ecossistema iraniano e voltado principalmente a organizações governamentais e de telecomunicações no Oriente Médio. A atividade também é relacionada a incidentes envolvendo infraestrutura governamental da Albânia e a operações anteriores com web shells e implantes baseados em driver. O ponto técnico central é a evolução para uma arquitetura mais discreta, na qual o operador usa servidores Windows já comprometidos como pontos de recepção passiva, evitando padrões mais óbvios de conexão reversa e moldando o implante ao ambiente específico onde ele será instalado.

O framework LIONTAIL reúne loaders customizados e cargas residentes em memória. Em vez de depender apenas de uma web shell tradicional ou de um serviço de rede explícito, a família observada configura mecanismos para extrair comandos e shellcode de requisições HTTP recebidas, ou de pipes nomeados em servidores internos. Essa abordagem reduz ruído em tráfego de saída, aproveita serviços de servidor já esperados no ambiente e permite que a comunicação se confunda com rotas legítimas, especialmente quando os caminhos usados imitam pastas e serviços existentes.

Fluxo técnico

O backdoor LIONTAIL, escrito em C, é descrito como um implante passivo leve para Windows Server. Ele lê uma configuração cifrada por XOR de um byte, obtém uma lista de prefixos de URL e prepara listeners para requisições de entrada. Todas as amostras analisadas continham o prefixo hxxp://+/Temporary_Listen_Addresses/%60, enquanto outras variantes acrescentavam caminhos em portas 80, 443 e 444, inclusive rotas parecidas com serviços de Exchange, como endpoints de descoberta automática e EWS. O uso do caractere + como curinga forte faz o listener aceitar nomes de host variados, independentemente do valor enviado no cabeçalho Host`, desde que a URL relativa corresponda ao prefixo registrado.

A parte mais relevante da técnica é a interação direta com HTTP.sys, o driver de modo kernel responsável por receber requisições HTTP no Windows e encaminhá-las a processos de modo usuário. Aplicações legítimas normalmente interagem com esse subsistema por meio da HTTP Server API, do IIS ou de classes de alto nível. O LIONTAIL evita essas camadas e usa IOCTLs não documentados para registrar prefixos, receber requisições, ler o corpo da mensagem e enviar respostas. O efeito operacional é um canal de comando menos visível para controles que monitoram apenas IIS, logs de aplicação ou chamadas convencionais da API HTTP.

Depois de receber uma requisição do operador, o implante decodifica Base64, aplica XOR usando o primeiro byte como chave e interpreta o conteúdo como estrutura de execução. O shellcode é iniciado em uma nova thread e permanece em memória, sem depender de um binário gravado para cada ação. A resposta segue fluxo semelhante: os dados retornados são cifrados com uma chave aleatória de um byte, a chave é anexada ao início do blob e o conjunto é codificado em Base64 antes de ser devolvido pela resposta HTTP. Essa escolha não representa criptografia robusta, mas é suficiente para reduzir assinaturas triviais em inspeção textual e para manter a semântica de uma conversa HTTP aparentemente comum.

Além da versão HTTP, há uma variante baseada em web shell e outra voltada a pipes nomeados. Na versão de web shell, os parâmetros seguem o mesmo padrão de codificação e a estrutura de argumentos é compatível com o loader de LIONTAIL, indicando uma base comum de geração de cargas. Na variante de pipe, o implante cria um canal local ou interno com descritor de segurança permissivo, permitindo acesso amplo ao pipe. Diferentemente da versão HTTP, essa implementação usa APIs padrão de kernel32.dll, como criação e leitura de pipe, o que sugere uso em servidores internos onde a comunicação pela internet não é o caminho principal.

Superfície afetada

A superfície mais exposta envolve servidores Windows que já foram acessados pelo operador, especialmente máquinas públicas que podem receber tráfego HTTP ou HTTPS e servidores Exchange. O fluxo descrito não começa com uma vulnerabilidade específica identificada no contexto; ele pressupõe que o invasor já possui acesso suficiente para implantar executável, gravar DLL em diretório de sistema, habilitar serviço ou instalar web shell. Por isso, a defesa deve tratar o caso como atividade pós-comprometimento em servidores de alto valor, não como uma simples varredura externa por um único CVE.

Duas formas de instalação foram observadas. Em uma delas, o implante é executável autônomo, com amostras tentando se passar por Cyvera Console, componente associado ao Cortex XDR. Na outra, o código é entregue como DLL e carregado por sequestro de ordem de busca. Os nomes wlanapi.dll e wlbsctrl.dll foram colocados em C:\windows\system32, explorando a ausência padrão desses arquivos em instalações Windows Server. Dependendo da versão do sistema e do serviço habilitado, processos legítimos ou serviços como IKE and AuthIP IPsec Keying Modules e Extensible Authentication Protocol acabam carregando a DLL maliciosa.

O componente LIONHEAD amplia a superfície em servidores Exchange comprometidos. Ele é descrito como um pequeno encaminhador web, também instalado como serviço por técnica semelhante de DLL ausente. Seu papel é redirecionar tráfego para endpoints EWS, o que pode ajudar o operador a contornar restrições de conexão externa e mascarar quem realmente consome dados de Exchange. Esse ponto é importante para ambientes onde EWS permanece habilitado por compatibilidade, automação ou integrações legadas.

• Servidores Windows com DLLs wlanapi.dll ou wlbsctrl.dll inesperadas em C:\windows\system32.
• Exchange exposto com caminhos adicionais imitando autodiscover ou ews em portas 443 ou 444.
• Serviços desabilitados por padrão que aparecem habilitados sem mudança administrativa documentada.
• Hosts internos com pipes nomeados permissivos usados como canal de execução remota.
• Web shells .NET com ofuscação de classes, métodos e strings por XOR de um ou dois bytes.

Hunting e telemetria

A investigação deve começar por servidores públicos e Exchange, porque são os pontos onde o tráfego de entrada pode esconder comandos. Como o LIONTAIL tenta operar abaixo de camadas monitoradas do IIS, a ausência de registros claros no IIS não elimina a hipótese de uso do canal. A telemetria de endpoint deve ser correlacionada com alterações em arquivos de sistema, eventos de criação ou modificação de serviços, carregamento de DLL por processos que não costumam usar esses módulos e escuta de prefixos HTTP incomuns.

Em rede, o foco não deve ser apenas tráfego de saída para C2. O modelo passivo permite que o operador envie requisições para caminhos que parecem pertencer à aplicação local. Padrões de interesse incluem requisições a rotas HTTP pouco usadas, caminhos que combinam nomes legítimos com palavras aleatórias adicionais, tráfego para portas 80, 443 ou 444 em servidores que hospedam Exchange, e respostas com blobs Base64 sem semântica compatível com a aplicação esperada. Esse hunting exige comparação com inventário de rotas legítimas, porque o objetivo do implante é ficar próximo do tráfego normal do servidor.

No endpoint, o uso direto de HTTP.sys por um processo incomum é um sinal forte, especialmente quando combinado com alocação e execução de memória para shellcode. A variante por pipe nomeado deixa rastros diferentes: criação de pipe com descritor permitindo acesso amplo, comunicação por APIs padrão e execução de carga em memória após leitura do canal. Em ambos os casos, a defesa deve buscar encadeamento entre alteração persistente, recebimento de dados codificados, decodificação simples por XOR e execução de thread com região de memória recentemente escrita.

• Carregamento de wlanapi.dll ou wlbsctrl.dll a partir de servidores onde esses arquivos não deveriam existir.
• Habilitação recente de IKE and AuthIP IPsec Keying Modules ou Extensible Authentication Protocol sem justificativa operacional.
• Processos que registram prefixos HTTP com curinga forte + e caminhos não documentados no inventário da aplicação.
• Requisições a caminhos similares a EWS ou autodiscover, mas com segmentos adicionais fora do padrão.
• Respostas HTTP contendo dados Base64 recorrentes em endpoints que normalmente retornam XML, JSON ou HTML estruturado.
• Criação de pipe \\.\pipe\test-pipe ou de pipes com DACL ampla em servidores que não usam esse padrão.
• Web shells com strings cifradas por XOR simples e nomes de classes ou métodos fortemente ofuscados.

Mitigação

A mitigação deve combinar contenção do host, revisão de persistência e validação de identidade. Como o contexto descreve atividade pós-comprometimento, apenas bloquear uma URL ou remover um arquivo isolado não é suficiente. Servidores com sinais compatíveis devem ser isolados de forma controlada, preservando memória e artefatos de disco para análise. Em Exchange, a revisão precisa incluir web roots, serviços, módulos carregados, configurações EWS e qualquer mecanismo usado por aplicações internas para acessar caixas postais.

A erradicação exige remover DLLs e executáveis não autorizados, desfazer serviços habilitados para carregamento do implante, revisar permissões de diretórios de sistema e confirmar que não há web shells alternativas no mesmo host. Para a variante por pipe, a validação deve alcançar servidores internos que talvez não estejam expostos diretamente à internet, porque o ator usa servidores públicos como pivôs para recursos internos. Logs de autenticação, movimentação entre hosts e acessos administrativos devem ser preservados e correlacionados com a janela de implantação dos arquivos.

Depois da contenção, a organização deve revisar controles preventivos. Monitoramento de HTTP.sys, inventário de prefixos HTTP, alertas para DLLs ausentes em Windows Server que passam a existir em system32, auditoria de serviços habilitados e detecção de execução em memória são pontos diretamente ligados ao comportamento descrito. A rotação de credenciais deve priorizar contas usadas no servidor comprometido, contas de serviço relacionadas a Exchange e credenciais administrativas que possam ter sido acessadas durante a intrusão. Como a atribuição direta a OilRig não é confirmada, a resposta deve se orientar por TTPs e evidências locais, não por rótulo de ator.

• Isolar servidores com artefatos compatíveis antes de remover arquivos, para preservar memória, módulos carregados e conexões ativas.
• Comparar C:\windows\system32 com baseline confiável e investigar DLLs wlanapi.dll e wlbsctrl.dll inesperadas.
• Auditar serviços recentemente habilitados e desfazer mudanças sem registro administrativo aprovado.
• Revisar Exchange, EWS e web roots em busca de encaminhadores, web shells e rotas adicionais não documentadas.
• Criar detecções para prefixos HTTP incomuns, uso anômalo de HTTP.sys e respostas Base64 em endpoints sensíveis.
• Procurar pipes nomeados permissivos em servidores internos e correlacionar com execução de memória por processos incomuns.
• Rotacionar credenciais de contas de serviço e administrativas associadas aos hosts afetados após confirmar o escopo da intrusão.