Backdoor `Stealth Soldier` é usado em espionagem direcionada contra alvos no Norte da África

A operação usa downloaders com nomes em árabe, infraestrutura de phishing e módulos de vigilância para capturar teclas, telas, áudio e dados de navegadores em ambientes ligados principalmente à Líbia.

Componente	Backdoor modular para Windows chamado Stealth Soldier, com downloader, loader MSDataV5.16945.exe, watchdog MSCheck.exe, payload MShc.txt e plugins de vigilância.
Vetor	A entrega inicial do downloader não foi confirmada, mas os nomes de arquivos em árabe, como هام وعاجل.exe e برقية 401.exe, indicam provável engenharia social contra alvos líbios.
Impacto	O implante permite vigilância por registro de teclas, captura de tela, gravação de microfone, execução de módulos, coleta de dados do sistema e roubo de informações de navegadores.
Prioridade	Priorizar caça por execução dos artefatos MSDataV5.16945.exe, MSCheck.exe, persistência em tarefa agendada MSChk, chave Run do Windows e comunicação com domínios C2 defangados associados às versões 6, 8 e 9.
Versões	Foram observadas cadeias das versões 6, 8 e 9; a versão 6 foi compilada em outubro de 2022 e a versão 9 aparece como a mais recente no conjunto analisado, com compilação em janeiro de 2023 e provável entrega em fevereiro de 2023.
IoCs	Exemplos defangados incluem filestoragehub[.]live, customjvupdate[.]live, filecloud[.]store, msheartbeat[.]live e o IP 94.156.33[.]228; os domínios devem ser tratados como indicadores históricos e correlacionados com telemetria local.

Resumo técnico

A campanha envolve um backdoor modular chamado Stealth Soldier, usado em uma operação de espionagem contra alvos no Norte da África, com indícios mais fortes de direcionamento a organizações líbias. A atividade combina downloaders para Windows, infraestrutura de comando e controle, domínios com aparência compatível com phishing e componentes capazes de executar vigilância no endpoint comprometido. Os arquivos iniciais observados foram submetidos a repositórios de análise a partir da Líbia entre novembro de 2022 e janeiro de 2023 e usavam nomes em árabe que sugerem iscas de urgência ou comunicação oficial. A forma exata de entrega não foi confirmada, portanto a hipótese defensiva mais sólida é tratar a etapa inicial como provável engenharia social, sem assumir um canal específico como e-mail, mensageria ou download web.

O Stealth Soldier não aparece como uma ferramenta genérica de commodity no material analisado. A cadeia contém múltiplos estágios, troca de componentes pelo C2 e diferenças entre versões que indicam manutenção ativa ao longo do período observado. As versões 6, 8 e 9 mantêm lógica semelhante, mas alteram domínios de comando, nomes de arquivos, mutexes, chaves XOR, diretórios e mecanismos de atualização. Essa variação importa para a defesa porque uma detecção baseada apenas em um nome de arquivo ou em um domínio tende a perder amostras posteriores. A atividade deve ser modelada como uma família modular com comportamento persistente, coleta local, plugins baixados sob demanda e comunicação codificada, não como um único binário estático.

Fluxo técnico

A execução começa quando o downloader é iniciado no host Windows. Nas amostras descritas, o downloader abre um PDF vazio como isca e, em seguida, recupera um loader cifrado do servidor de comando. Na versão 9, esse loader é gravado em %APPDATA% com o nome MSDataV5.16945.exe após decodificação por XOR. O loader passa a organizar a continuidade da cadeia: baixa o módulo .NET pwls.dll, internamente chamado PowerPlus comando operacional omitido MSCheck.exe. Quando o watchdog não está presente, o loader o baixa e o executa. Essa separação entre downloader, loader, watchdog e payload permite atualizar partes da operação sem trocar toda a cadeia inicial.

A persistência é implementada por combinação de tarefa agendada e chave de execução automática no Registro do Windows. A tarefa agendada usa o nome MSChk e aciona periodicamente o watchdog, enquanto valores sob SOFTWARE\Microsoft\Windows\CurrentVersion\Run aparecem como outro ponto de retomada entre versões. O watchdog tem papel de recuperação e atualização: na versão 6 ele verifica a existência do segundo estágio MSCheck.exe; na versão 8 ele observa o loader MSUpdate.exe dentro de MSTemp e usa MSUVersion.txt para obter endereço de atualização; na versão 9 ele tenta baixar diretamente o arquivo completo quando o loader esperado não existe. A presença de MSUVersion.txt apontando para msheartbeat[.]live sugere reaproveitamento ou transição de infraestrutura em fases anteriores da operação.

O payload consulta a versão por meio de MV.txt e deriva nomes de payload no formato MShc.txt, o que mostra uma rotina de versionamento controlada pelo C2. Depois de ativo, o implante envia dados em pacotes codificados por XOR usando a chave textual Windows Cmd e se comunica com o IP 94.156.33[.]228 no material descrito. A rotina de tarefas usa uma mensagem de solicitação ao C2 para receber comandos. Parte das funções é interna ao malware, como MicRecord, que usa a API mciSendStringA para gravação de áudio; outras funções são plugins baixados, gravados com nomes próprios e executados conforme instruções do operador. Esse desenho reduz o tamanho do payload principal e permite acionar capacidades apenas quando a operação precisa delas.

Os plugins observados cobrem capacidades de vigilância e coleta. O módulo de captura de tela aparece como sc.exe e deriva de um projeto aberto de captura de desktop, com suporte a tela inteira e janela específica. O módulo BrCr.txt inicia uma cadeia de loaders que recupera dados de caminhos como /BRCRLa_enc.txt e /BRCRShc.txt, grava BRCRLa.exe em C:\Users\Public e executa o payload final em memória após descriptografia. O componente real associado a essa cadeia é baseado no projeto aberto HackBrowserData, usado para obter dados de navegadores populares. Para defesa, a combinação de gravação em diretórios públicos, execução em memória, decodificação por XOR e acesso a repositórios de credenciais de navegador deve ser tratada como sinal de comprometimento, mesmo quando os nomes individuais variem.

Superfície afetada

A superfície principal são estáções Windows de usuários visados por engenharia social e com permissão suficiente para executar o downloader. O material não sustenta uma vulnerabilidade de execução remota nem exploração ativa de falha específica; o risco depende de execução do artefato inicial pelo usuário ou por algum mecanismo de entrega não identificado. Ambientes de governo, diplomacia, organizações civis e entidades com relacionamento regional com a Líbia e o Egito merecem atenção maior porque a infraestrutura associada inclui domínios que tentam se passar por serviços de autenticação, webmail, notificações e órgãos ligados a relações exteriores. A atividade é estreita o bastante para não ser tratada como infecção massiva, mas técnica o bastante para exigir telemetria detalhada de endpoint, identidade e rede.

A infraestrutura das versões mapeadas aponta para domínios C2 diferentes: a versão 6 se comunica com filestoragehub[.]live, a versão 8 com customjvupdate[.]live e a versão 9 com filecloud[.]store. Há ainda histórico de resolução de customjvupdate[.]live e filestoragehub[.]live para endereços na faixa 185[.]125[.]230[.]0/24, além de sobreposição com domínios ligados à campanha Eye on the Nile, como weblogin[.]live, mailsecure[.]live e verifymail[.]live. A semelhança nos padrões de nomes, especialmente combinações de mail, notify, verify, web, log e live, reforça a hipótese de infraestrutura usada para phishing e espionagem regional, mas não prova por si só que todos os domínios tenham sido usados no mesmo momento operacional.

• Hosts Windows que executaram arquivos com nomes em árabe associados a urgência, telegrama ou comunicações oficiais devem ser revisados em conjunto com eventos de rede e criação de processos.
• Perfis de usuário contendo %APPDATA%, C:\Users\Public, diretórios TempDataDr, TempDataLa ou MSTemp com binários compatíveis com MSDataV5.16945.exe, MSCheck.exe, MSUpdate.exe, BRCRLa.exe, pwls.dll, MV.txt ou MShc.txt são prioritários para triagem forense.
• Contas de usuários que tiveram navegadores acessados pelo host comprometido devem entrar em processo de revisão de sessão, expiração de tokens e rotação de senhas quando houver evidência de execução do módulo baseado em HackBrowserData.

Hunting e telemetria

A caça deve começar pela linha de execução no endpoint, porque a cadeia deixa múltiplos pontos observáveis antes da comunicação C2. Eventos de criação de processo devem ser correlacionados para identificar um executável inicial abrindo um PDF sem conteúdo útil e, em seguida, gravando binários em %APPDATA% ou C:\Users\Public. A presença de pwls.dll comando operacional omitido [.]NET sem contexto administrativo legítimo e criação de tarefa agendada com nome MSChk formam uma sequência forte. Também é relevante revisar alterações em SOFTWARE\Microsoft\Windows\CurrentVersion\Run, especialmente valores que apontem para caminhos de usuário ou diretórios temporários com nomes parecidos com componentes Microsoft, mas fora dos diretórios esperados do sistema.

Na rede, a defesa deve procurar resolução DNS e conexões para os domínios C2 defangados associados às versões conhecidas, além de padrões de subdomínios que imitam mail.yahoo, livemail, telegram[.]org e login.outlook. A análise não deve bloquear apenas a lista curta de domínios, porque foram identificados mais de 50 nomes com características semelhantes e muitos estavam indisponíveis no momento da análise. O caminho mais robusto é combinar domínio recém-registrado, padrão lexical compatível com autenticação ou webmail, hospedagem compartilhada com histórico suspeito e acesso a partir de usuários com perfil de alvo regional. Em proxies e EDR, eventos de download de arquivos .txt que se comportam como payload cifrado ou loader devem ser tratados como anomalia quando vierem desses domínios.

A investigação de credenciais precisa ser conduzida com cuidado. O módulo de navegador sugere risco de acesso a senhas, cookies e outros dados locais, mas a existência do módulo no ecossistema não significa que todos os hosts tenham sido exfiltrados. A confirmação exige evidência de download e execução do plugin, acesso aos bancos de dados de navegador no perfil do usuário, criação de arquivos intermediários ou tráfego subsequente compatível com envio ao C2. Para microfone e tela, sinais incluem carregamento da API usada para gravação, criação de artefatos temporários de imagem ou áudio e execução de sc.exe fora de contexto administrativo legítimo. Se a organização coleta telemetria de janela ativa, captura de tela ou acesso a dispositivos de áudio, esses eventos devem ser correlacionados com a janela temporal da persistência.

• Criação ou execução de MSDataV5.16945.exe, MSCheck.exe, MSUpdate.exe, pwls.dll, BRCRLa.exe, MShc.txt, MV.txt, MSUVersion.txt e DRSch em diretórios de usuário ou C:\Users\Public.
• Tarefa agendada MSChk, alterações na chave Run do Windows e execução recorrente do watchdog em intervalos compatíveis com atualização ou recuperação do loader.
• Consultas DNS ou conexões para filestoragehub[.]live, customjvupdate[.]live, filecloud[.]store, msheartbeat[.]live, weblogin[.]live, mailsecure[.]live, verifymail[.]live e endereços relacionados à faixa 185[.]125[.]230[.]0/24 quando houver contexto de risco.
• Uso anômalo de PowerShell acionado por processo desconhecido, download de arquivos .txt cifrados, decodificação por XOR em memória e execução de payload com cabeçalho MZ carregado fora do fluxo normal de instalação de software.

Mitigação

A resposta deve começar com contenção dos hosts que executaram o downloader ou apresentaram qualquer estágio posterior da cadeia. O isolamento é importante porque o watchdog pode recuperar o loader e a arquitetura modular permite novas tarefas pelo C2. Em seguida, a equipe deve coletar imagem de memória, artefatos de disco, tarefas agendadas, chaves de execução automática, histórico de navegador, cache DNS, logs de proxy, telemetria EDR e eventos de criação de processo. A remoção manual de apenas um binário pode deixar a persistência funcional ou apagar evidência. A ordem correta é preservar evidência suficiente, interromper comunicação, desabilitar persistência, remover componentes e validar que não há reexecução após reinício.

A mitigação de identidade deve acompanhar a contenção do endpoint. Quando houver indício de execução do módulo de navegador, sessões ativas de contas usadas no host devem ser revogadas, senhas devem ser rotacionadas e fatores de autenticação devem ser revisados. Essa ação deve priorizar contas governamentais, contas de webmail, painéis administrativos, VPNs, sistemas diplomáticos e qualquer aplicação acessada a partir do navegador do usuário comprometido. A rotação sem revogação de sessão pode não encerrar tokens já coletados, e a revogação sem limpeza do host pode permitir nova coleta. A resposta precisa tratar endpoint e identidade como a mesma cadeia de risco.

No nível preventivo, controles de aplicação devem bloquear execução de binários em caminhos de usuário quando não houver necessidade operacional, e regras de EDR devem alertar para criação de tarefa agendada por processos recém-baixados, carregamento incomum de .NET para acionar PowerShell e acesso programático a dados de navegadores. Filtros DNS e proxy devem aplicar bloqueio aos indicadores conhecidos, mas também classificar domínios com padrões de autenticação falsa, infraestrutura recém-observada e hospedagem relacionada. Usuários de organizações com exposição regional devem receber orientação específica sobre anexos e executáveis com nomes de documentos oficiais, sem depender apenas de campanhas genéricas de conscientização.

A atribuição deve permanecer limitada. Existem sobreposições de infraestrutura e padrões com Eye on the Nile, além de direcionamento regional semelhante e uso de domínios compatíveis com phishing. Esses elementos sustentam relação operacional possível ou reaproveitamento de recursos, mas não bastam para afirmar identidade completa do operador em todos os casos. Para relatórios internos, é mais útil registrar a atividade como campanha Stealth Soldier, associar os indicadores ao cluster de infraestrutura observado e manter uma hipótese separada de relação com Eye on the Nile. Essa separação evita que bloqueios, regras de detecção e comunicação executiva extrapolem o que a telemetria realmente demonstra.

• Isolar hosts com execução dos estágios conhecidos, coletar evidências voláteis e preservar os arquivos antes de remover persistência.
• Desabilitar a tarefa MSChk, revisar valores em SOFTWARE\Microsoft\Windows\CurrentVersion\Run e validar que MSDataV5.16945.exe, MSCheck.exe e loaders relacionados não reaparecem após reinício.
• Bloquear e monitorar os domínios C2 defangados conhecidos, a faixa histórica associada e padrões de domínios que imitam autenticação, webmail, notificações e serviços governamentais.
• Revogar sessões, rotacionar credenciais e revisar MFA para contas usadas no host quando houver evidência de execução do módulo de navegador ou acesso suspeito aos bancos de dados do perfil do usuário.
• Adicionar detecções comportamentais para download de payload .txt cifrado, execução de componente .NET que aciona PowerShell, captura de tela por processo não autorizado e gravação de microfone fora de aplicações esperadas.