BladedFeline: campanha de ciberespionagem provavelmente vinculada ao OilRig

Em 2024, a equipe de pesquisa da ESET descobriu diversas ferramentas maliciosas nos sistemas utilizados por autoridades dos governos curdo e iraquiano. O grupo APT responsável pelos ataques é o BladedFeline, uma quadrilha iraniana que realiza atividades desde pelo menos 2017, quando comprometeu autoridades dentro do Governo Regional do Curdistão (KRG). Esse grupo desenvolve malwares para manter e expandir o acesso dentro de organizações no Iraque e no KRG. Embora este seja nosso primeiro post exclusivo sobre o BladedFeline, descobrimos o grupo em 2023, após ele ter mirado autoridades diplomáticas curdas com o backdoor Shahmaran, e já havíamos reportado suas atividades nos relatórios ESET APT Activity Q4 2023–Q1 2024 e Q2 2024–Q3 2024.

O conjunto de ferramentas utilizadas na recente campanha demonstra que, desde o lançamento do Shahmaran, o BladedFeline continuou expandindo seu arsenal. Identificamos dois túneis reversos, uma variedade de ferramentas auxiliares e, mais notavelmente, um backdoor que nomeamos Whisper e um módulo malicioso do IIS que chamamos de PrimeCache. Whisper é um backdoor que realiza login em uma conta de webmail comprometida em um servidor Microsoft Exchange e a utiliza para se comunicar com o grupo por meio de anexos de e-mail. PrimeCache também funciona como um backdoor: trata-se de um módulo malicioso do IIS relacionado ao que denominamos Grupo 2 em post (em inglês) que publicamos em 2021, Anatomy of native IIS malware. De forma relevante, o PrimeCache também apresenta semelhanças com o backdoor RDAT usado pelo grupo APT OilRig, alinhado ao Irã.

Com base nessas semelhanças de código, assim como em outras evidências apresentadas neste post, avaliamos com confiança média que o BladedFeline é um subgrupo do OilRig, um grupo APT alinhado ao Irã que mira governos e empresas no Oriente Médio. Já havíamos reportado anteriormente outras atividades relacionadas ao OilRig. Para evitar confusão, desde então refinamos nosso monitoramento do OilRig e agora acompanhamos ambas as operações sob um subgrupo separado, Lyceum, dentro do OilRig.

O BladedFeline tem atuado de forma consistente para manter acesso ilícito a autoridades diplomáticas curdas, enquanto simultaneamente explora um provedor regional de telecomunicações no Uzbequistão e desenvolve e mantém acesso a autoridades do governo do Iraque. Este post vai detalhar os aspectos técnicos dos implantes iniciais entregues aos alvos do BladedFeline, as conexões entre as vítimas e estabelece a base para associar esse subgrupo ao OilRig.

Pontos principais deste post:

• O BladedFeline comprometeu autoridades dentro do Governo Regional do Curdistão pelo menos desde 2017;
• Os implantes iniciais utilizados nessa operação podem ser vinculados ao OilRig;
• Descobrimos o BladedFeline após seus operadores comprometerem autoridades diplomáticas curdas com o backdoor característico Shahmaran, em 2023;
• Esse grupo APT também infiltrou autoridades de alto escalão no governo do Iraque;
• Avaliamos com confiança média que o BladedFeline é um subgrupo dentro do OilRig;
• Analisamos dois túneis reversos (Laret e Pinar), um backdoor (Whisper), um módulo malicioso do IIS (PrimeCache) e diversas ferramentas auxiliares.

Visão geral do BladedFeline

O BladedFeline é um grupo de ciberespionagem alinhado ao Irã, ativo desde pelo menos 2017, segundo a telemetria da ESET. Descobrimos o grupo em 2023, quando ele implantou seu backdoor Shahmaran contra autoridades diplomáticas curdas. Shahmaran, nomeado a partir de uma criatura mítica meio cobra, meio mulher do folclore iraniano, é um executável portátil 64 bits que encontramos no diretório Startup do alvo. Esse backdoor simples não utiliza qualquer compressão ou criptografia nas comunicações de rede. Após se conectar ao servidor C&C, o backdoor executa quaisquer comandos fornecidos pelo operador, que incluem o upload e download de arquivos adicionais, solicitação de atributos específicos de arquivos e fornecimento de APIs para manipulação de arquivos e diretórios.

Como evidenciado pelo conjunto de ferramentas da campanha que descrevemos neste post, desde o lançamento do Shahmaran, o BladedFeline continuou desenvolvendo seu malware para manter e até ampliar seu acesso ao Governo Regional do Curdistão (KRG) e a altos escalões do governo do Iraque (GOI). Descobrimos a campanha em 2024, após encontrar o backdoor Whisper do BladedFeline, o backdoor PrimeCache para IIS e um conjunto de ferramentas pós-comprometimento nas redes de autoridades diplomáticas curdas, autoridades do governo iraquiano e um provedor regional de telecomunicações no Uzbequistão.

Detectamos e coletamos uma versão do Whisper e encontramos outra no VirusTotal, enviada por um usuário no Iraque. Elas são praticamente idênticas, e conseguimos identificar a provável identidade do remetente do arquivo no VirusTotal, com base nos dados da amostra do Whisper e em outras amostras enviadas pelo mesmo ID de remetente. PrimeCache, Flog (um webshell) e Hawking Listener (um implante em estágio inicial que escuta em uma porta específica) também foram enviados ao VirusTotal pelo mesmo ID de remetente que enviou as amostras do Whisper. Com base no vínculo com o Whisper e no curto intervalo de tempo (ambos enviados em questão de minutos), acreditamos que foram implantados pelo BladedFeline em uma vítima do governo do Iraque. Algumas das ferramentas mencionadas a seguir na Linha do Tempo são discutidas posteriormente no relatório (por exemplo, Slippery Snakelet).

Linha do tempo

2017-09-21 ● VideoSRV reverse shell no sistema KRG | 2018-01-30 ● RDAT backdoor no sistema KRG | 2019-07-09 ● Custom Plink no sistema KRG | 2021-05-01 ● Sheep Tunneler no sistema KRG | 2023-01-23 ● LSASS despejado no sistema KRG | 2023-02-01 ● Shahmaran backdoor no sistema KRG | 2023-03-25 ● Primeira vítima direcionada a uma empresa de telecomunicações no Uzbequistão | 2023-06-12 ● Shahmaran versão 2 no sistema KRG para manutenção de acesso | 2023-12-14 ● Operadores BladedFeline executando comandos CLI no sistema KRG | 2023-12-16 ● Slippery Snakelet backdoor no sistema KRG | 2023-12-20 ● P.S. Olala (um executor do PowerShell) no sistema KRG | 2023-12-20 ● PsExec no sistema KRG | 2024-01-07 ● Whisper backdoor no sistema KRG | 2024-02-01 ● Laret reverse tunnel no sistema KRG | 2024-02-20 ● Pinar reverse tunnel no sistema KRG | 2024-02-29 ● PrimeCache malicious IIS module uploaded to VirusTotal | 2024-03-11 ● Whisper versão 2, Flog e Hawking Listener uploaded to VirusTotal

Atribuição

Nossa atribuição desta campanha ao BladedFeline baseia-se nos seguintes pontos:

• A campanha tem como alvo membros do Governo Regional do Curdistão (KRG), assim como em ataques anteriores conduzidos pelo BladedFeline;
• A atividade inicial de ataque direcionada ao KRG nos permitiu identificar malwares sucessivos, já que o BladedFeline tem buscado manter e expandir o acesso à organização;
• Análises adicionais dos ataques nos levaram a identificar a vítima do setor de telecomunicações no Uzbequistão;
• Simultaneamente, a investigação do backdoor Whisper ajudou a identificar a vítima no governo do Iraque (GOI).

Avaliamos que o BladedFeline está direcionando suas ações ao KRG e ao GOI para fins de ciberespionagem, visando manter acesso estratégico a autoridades de alto escalão em ambos órgãos governamentais. A relação diplomática do KRG com nações ocidentais, aliada às reservas de petróleo na região do Curdistão, torna esse alvo atrativo para grupos alinhados ao Irã, que buscam espioná-lo e potencialmente manipulá-lo. No Iraque, esses grupos provavelmente tentam conter a influência dos governos ocidentais após a invasão e ocupação do país pelos Estados Unidos.

Acreditamos, com confiança média, que o BladedFeline seja um subgrupo do OilRig:

• Assim como o OilRig, o BladedFeline direciona suas ações a organizações no Oriente Médio com o propósito de ciberespionagem;
• Encontramos ferramentas do OilRig (VideoSRV e RDAT) em um sistema comprometido do KRG;
• O módulo malicioso para IIS do BladedFeline, PrimeCache, compartilha similaridades de código com o RDAT do OilRig.

BladedFeline não é o único subgrupo do OilRig que monitoramos: já acompanhamos o Lyceum, também conhecido como HEXANE ou Storm-0133, outro subgrupo do OilRig. O Lyceum foca em alvos variados em Israel, incluindo órgãos governamentais, instituições e organizações na área da saúde. As principais ferramentas atribuídas ao Lyceum incluem os backdoors DanBot, Shark, Milan e Marlin, além de Solar and Mango, OilForceGTX e diversos downloaders que utilizam serviços legítimos de nuvem para comunicação C&C.

Continuaremos usando o nome OilRig para nos referir ao grupo principal, também conhecido como APT34 ou Hazel Sandstorm (anteriormente EUROPIUM). O OilRig é um grupo de ciberespionagem ativo desde pelo menos 2014, comumente acreditado estar baseado no Irã. O grupo tem como alvo governos do Oriente Médio e diversos setores empresariais, incluindo químico, energético, financeiro e de telecomunicações. Campanhas notáveis do OilRig incluem a campanha DNSpionage de 2018 e 2019, visando vítimas no Líbano e Emirados Árabes Unidos; a campanha HardPass de 2019–2020, que usou o LinkedIn para atacar vítimas do setor energético e governamental no Oriente Médio; o ataque de 2020 contra uma organização de telecomunicações na região, utilizando o backdoor RDAT; e os ataques de 2023 contra organizações no Oriente Médio com os backdoors PowerExchange e MrPerfectionManager.

Ferramentas OilRig usadas pelo BladedFeline

Encontramos duas ferramentas OilRig nas máquinas do KRG comprometidas pelo BladedFeline.

RDAT

Descobrimos uma versão não relatada anteriormente do backdoor RDAT da OilRig em dois sistemas de vítimas do KRG. Analisando o RDAT, descobrimos que o fluxo operacional (consulte o relatório da Unidade 42 para obter detalhes), o registro de data e hora da compilação (2017-12-26 10:49:35) e a hora de gravação do arquivo (2018-01-30) estão alinhados com a atividade e o direcionamento da OilRig, especialmente em relação à atividade do grupo em 2017. Observamos um arquivo com um SHA-1 de 562E1678EC8FDC1D83A3F73EB511A6DDA08F3B3D e um caminho de C:\Windows\System32\LogonUl.exe em ambos os sistemas. O caminho do PDB também corrobora que esse binário é RDAT: C:\Users\Void\Desktop\RDAT\client\x64\Release\client.pdb. Até o momento, só observamos o RDAT em uso pela OilRig. Além disso, não vimos nenhum compartilhamento de implante personalizado entre a OilRig e outros grupos do Oriente Médio, e isso raramente ocorre entre agentes de ameaças alinhados ao Irã.

Para reforçar ainda mais a hipótese de que o BladedFeline é um subgrupo da OilRig, assim como o Lyceum, está a análise que vincula o RDAT ao PrimeCache, um módulo malicioso do IIS que foi carregado no VirusTotal, presumivelmente pela vítima do GOI. Esse link é explorado com mais profundidade na seção Links com o OilRig do blogpost.

VideoSRV

Um ponto de dados adicional sobre a conexão entre a OilRig e a BladedFeline é um reverse shell implantado em uma das vítimas do KRG (21 de setembro de 2017) antes de o RDAT ser lançado no mesmo sistema (³⁰ de janeiro de 2018). VideoSRV (SHA-1: BE0AD25B7B48347984908175404996531CFD74B7), assim chamado por seu nome de arquivo videosrv.exe, tem a string PDB C:\Users\v0id\Desktop\reverseShell\clientProxy\x64\Release\ConsoleApplication1.pdb, que tem algumas semelhanças com a cadeia de caracteres PDB RDAT C:\Users\Void\Desktop\RDAT\client\x64\Release\client.pdb.

Análise técnica

Acesso inicial

Ainda não está claro como o BladedFeline está desenvolvendo o acesso às suas vítimas. O que sabemos é que, no caso das vítimas do KRG, os agentes da ameaça obtiveram acesso pelo menos desde 2017 e o mantiveram desde então. Quanto às vítimas do GOI, suspeitamos que o grupo explorou uma vulnerabilidade em um aplicativo em um servidor da Web voltado para a Internet, o que lhes permitiu implantar o Flog webshell.

Conjunto de ferramentas

PrimeCache - módulo IIS malicioso

O PrimeCache, cujo nome derivamos do RTTI AVRSAPrimeSelector e de seu nome de arquivo(cachehttp.dll), é um backdoor passivo implementado como um módulo nativo do IIS com um nome interno de HttpModule.dll. Ele foi carregado no VirusTotal pelo mesmo usuário que carregou uma das amostras do backdoor Whisper. É uma DLL C++ de 64 bits com um registro de data e hora de compilação de 2023-05-14 06:55:52 e tem uma string PDB minimizada de apenas HttpModule.pdb. Ela tem uma única exportação: RegisterModule.

O PrimeCache é o sucessor de uma coleção de backdoors não atribuídos do IIS que relatamos anteriormente como Grupo 2 (backdoors simples do IIS) em nosso blogpost de 2021, Anatomia do malware nativo do IIS. Obtivemos essas amostras originais do VirusTotal, onde foram carregadas por usuários de Bahrein, Israel e Paquistão, entre 2018 e 2020. Com base apenas na localização das supostas vítimas, é possível que esses casos também estejam relacionados às atividades do BladedFeline - ou, de forma mais ampla, do OilRig.

Funcionalidade principal

A principal funcionalidade do PrimeCache é implementada no manipulador CGlobalModule::OnGlobalPreBeginRequest. Essa é uma implementação exclusiva, diferente de seus antecessores, que usavam o manipulador CHttpModule::OnBeginRequest. O PrimeCache filtra as solicitações HTTP de entrada, processando apenas as dos operadores BladedFeline, que são reconhecidos por terem um cabeçalho de cookie com a estrutura:

F=<command_ID>,<param>;

Observe que esse valor pode ser autônomo ou incorporado a um cookie mais longo, cercado por caracteres de ponto e vírgula (;).

O backdoor funciona de uma forma incomum (nova nesta versão em comparação com nossa análise de 2021). Em vez de aceitar um comando de backdoor e todos os seus parâmetros em uma única solicitação HTTP, cada ação é dividida em várias solicitações. Primeiro, o operador do BladedFeline envia uma solicitação individual para cada parâmetro; esses parâmetros são armazenados em uma estrutura global. Em seguida, o operador envia outra solicitação para acionar o comando backdoor. Por fim, o PrimeCache usa os parâmetros recebidos anteriormente para executar a ação especificada e, em seguida, limpa os parâmetros armazenados em cache.

Comandos do operador

Há três tipos de solicitações que podem ser recebidas pelo backdoor, conforme mostrado na Tabela 1.

Tabela 1. Comandos do operador do PrimeCache

Depois que a ação é acionada (por meio de <command_ID>=0), o PrimeCache executa uma ação, com base nos parâmetros obtidos anteriormente, conforme mostrado na Tabela 2. Uma observação sobre o quadro abaixo:

A ação do PrimeCache é o comando do operador (OpCom) a, a chave da sessão é OpCom k, os dados binários são OpCom b e o nome do arquivo é OpCom f.

Tabela 2. Ações de comando pós-operador do PrimeCache

Criptografia

Semelhante a seus predecessores, a PrimeCache usa RSA e AES-CBC para sua comunicação C&C. Os parâmetros e os valores de retorno são sempre criptografados em AES-CBC usando a chave de sessão e, em seguida, codificados em base64. A chave de sessão é criptografada em RSA; o backdoor tem uma chave RSA privada e pública codificada (não um par) para lidar com ambas as direções da comunicação.

Uma biblioteca Crypto++ vinculada estaticamente é usada para lidar com as operações de criptografia e descriptografia.

Comunicações de C&C

Os comandos do operador são transmitidos no cabeçalho do cookie (outro desvio em relação às versões anteriores, que usavam o URL ou o corpo da solicitação HTTP). As respostas do PrimeCache são adicionadas ao corpo da resposta HTTP. Se um arquivo estiver sendo exfiltrado, o cabeçalho Content-Type será definido como anexo, correspondendo à funcionalidade das versões anteriores.

Os antecessores do PrimeCache também usavam o mesmo esquema de criptografia e nomes de parâmetros semelhantes(a, c, f, k), mas todos eram enviados para o backdoor em uma única solicitação. Os únicos comandos suportados eram r, u e d.

Links com o OilRig

Quando comparamos o PrimeCache com o RDAT, conforme descrito na subseção de atribuição do RDAT, vemos várias semelhanças que sustentam nossa suposição de que o BladedFeline é um subgrupo do OilRig.

• Tanto o RDAT quanto o PrimeCache usam a biblioteca Crypto++ e ambos analisam os comandos do backdoor usando a expressão regular [^,]+
  • A carga útil tenta analisar o texto claro descriptografado usando a expressão regular [^,]+ para obter o valor do comando e os argumentos do comando que são divididos com uma vírgula.
• Ambos compartilham uma função, mostrada na Figura 1, que executa um comando shell e lê a saída, que, em nosso corpus, é encontrada somente nesses dois malwares.

Backdoor Whisper

O Whisper é um binário do Windows de 32 bits escrito em C#/.NET, nomeado de acordo com suas cadeias de caracteres PDB G:\csharp\Whisper_Trojan_winform\Whisper_Trojan_winform\Whisper_Trojan_winform\obj\Release\Veaty.pdb e Z:\csharp\Whisper_Trojan_winform_for_release\Whisper_Trojan_winform\Whisper_Trojan_winform\obj\Release\Veaty.pdb. Ele usa um servidor Microsoft Exchange para se comunicar com os atacantes, enviando anexos de e-mail por meio de uma conta de webmail comprometida. Vimos duas versões do backdoor: detectamos e coletamos uma versão, que foi carregada no VirusTotal pelo Iraque. Essas amostras são praticamente idênticas, mas conseguimos determinar a provável identidade do remetente do VirusTotal com base nos dados da amostra do Whisper e em outras amostras enviadas por esse usuário.

Ambas as versões do Whisper têm carimbos de data e hora de compilação com registro de data e hora (2090-04-11 23:38:14 e 2080-12-11 03:50:47). Elas são compiladas usando o Costura, presumivelmente para garantir que o sistema da vítima use as DLLs empacotadas com o binário e não as DLLs no Global Assembly Cache.

A operação do Whisper não é a primeira vez que observamos um subgrupo da OilRig usando serviços de nuvem para seu protocolo C&C. Embora, diferentemente do Whisper, não houvesse e-mails sendo realmente enviados, o Lyceum usou rascunhos de e-mail para a comunicação entre seu malware e os operadores ao longo de 2022, conforme descrevemos em um post anterior.

Fluxo de trabalho operacional

O Whisper não exige nem aceita nenhum argumento. Em vez disso, seu dropper, que apelidamos de Whisper Protocol por causa de seu nome de arquivo, Protocol.pdf.exe, grava seu arquivo de configuração no disco junto com ele (consulte a seçãoWhisper Protocol ). O arquivo de configuração, mostrado na Figura 2, está no formato XML com suas cadeias de caracteres de chave e valor codificadas em base64. Ele é chamado pela classe Specs do Whisper, que usa uma função - DelockItems - para decodificar em base64 as variáveis de configuração.

A Figura 3 mostra o fluxo operacional do Whisper, que será detalhado nos parágrafos seguintes.

O fluxo operacional do Whisper pode ser dividido em sete etapas:

Na Etapa 1, o Whisper usa as credenciais do arquivo de configuração (linha 15 na Figura 2) e a classe ExchangeService do Microsoft Exchange Web Services para tentar fazer login em contas de webmail comprometidas. Quando o Whisper consegue fazer login em uma conta, ele salva as credenciais na memória e grava o seguinte no arquivo de registro c:\Windows\Temp\WindowsEventLogs.txt:

------------ ItemContext is set: username [<username>] , use_defaultCred: [credentials>]

Se nenhuma credencial no arquivo de configuração for válida, o Whisper registrará as seguintes mensagens de erro no arquivo de registro:

---------------------------------- não foi possível acessar nenhuma caixa de correio.

__________ A função de extração é chamada.

Se um erro inesperado for detectado, o Whisper grava o seguinte no arquivo de registro (observe a grafia incorreta da palavra happened, indicativa de um falante não nativo de inglês) e sai usando o método Environment.Exit(Int32). Estranhamente, o exitCode usado, 0, indica que o processo foi concluído com êxito.

----------------------------------__ an unknown Exception happend. program turned off

Em seguida, na Etapa 2, a Whisper usa as credenciais da etapa anterior para verificar as regras da caixa de entrada usando o método ExchangeService.GetInboxRules (que recupera uma coleção de regras da caixa de entrada associadas ao usuário especificado). Usando o valor na linha 13 do arquivo de configuração(key="receive_sign", value="PMO"), o Whisper itera sobre as regras da caixa de entrada procurando que esse valor seja especificado em um dos três locais: assunto, corpo ou assuntooucorpo e que os emails que correspondam a esse valor sejam enviados para um local especificado(itens excluídos ou caixa de entrada, dependendo da versão do Whisper). Se a caixa de entrada tiver essa regra, o Whisper passará para a próxima etapa; caso contrário, o Whisper criará uma regra com os parâmetros fornecidos:

• Nome da regra: MicosoftDefaultRules.
• Mover para a pasta: deleteditems ou caixa de entrada
  • Uma versão do Whisper especifica a pasta deleteditems; a outra aponta para a caixa de entrada. Ambas são codificadas nos binários separados.
• Marcar como lido: true.
• Condição: o assunto contém PMO
  • O local para procurar a cadeia de caracteres, subject, é codificado em ambas as versões do Whisper. A cadeia de caracteres a ser procurada, PMO, está no arquivo de configuração usado pelo Whisper; não foi possível coletar o outro arquivo de configuração.

Na Etapa 3, o Whisper inicia um loop interminável que envia uma mensagem de e-mail de check-in da conta de e-mail comprometida na Etapa 1 para um endereço de e-mail especificado no arquivo de configuração (linha 16, key="alive_mail"). A mensagem de check-in é enviada a cada 10 horas (linha 10 no arquivo de configuração, key="al_time"; em minutos), o assunto (linha 17, key="alive_msg_subj") é Content e o corpo da mensagem contém a string definida abaixo:

"Content ID: " + base64_encode("COMPUTERNAME:USERDNSDOMAIN:USERNAME")

Em seguida, na Etapa 4, o Whisper busca os comandos do operador. Ele faz isso pesquisando na caixa de entrada identificada na Etapa 1 os arquivos em uma determinada pasta(deleteditems ou caixa de entrada, dependendo da versão do Whisper) com anexos em que o assunto corresponde a uma cadeia de caracteres (fornecida no arquivo de configuração; PMO no único arquivo de configuração que coletamos). Para correspondência de e-mails com anexos, o Whisper coleta o corpo do anexo (que deve conter comandos criptografados) e armazena o endereço de e-mail do remetente para uso posterior como o servidor C&C para o qual os resultados dos comandos do operador são carregados.

Na Etapa 5, o Whisper descriptografa os comandos do operador. Ele faz isso primeiro decodificando em base64 a cadeia de caracteres que contém o comando e, em seguida, descriptografando o resultado usando a classe .NET AES com um vetor de inicialização de 16 bytes e a chave de criptografia encontrada no arquivo de configuração (linha 18, key="enc_key" value="cXdlcmFzZHp4Y3ZmZ2d0aGhsZGZvZ2g/bHZtZ2xrZyE="). Os comandos descriptografados estão na forma de <cmd_id>;<command_to_execute>. A ID do comando, os comandos e a saída do comando são salvos no seguinte formato:

base64-encoded(<command_id>: <cmd_id>\n<cmd_output>\n)

Em seguida, na Etapa 6, o Whisper executa os comandos do backdoor e registra os resultados. Os comandos possíveis incluem:

• Gravar um arquivo no disco

Os dados gravados no disco são:

este é o conteúdo do meu arquivo

<caminho do arquivo>

<nome do arquivo>

<nbytes-to-write>

Os bytes a serem gravados são codificados em base64 (e decodificados antes de serem gravados no disco). A execução bem-sucedida retorna:

arquivo recebido corretamente. escreveu em: <caminho do arquivo>\<nome do arquivo>

• Enviar um arquivo para o servidor C&C

Esse comando é prefixado com este é o meu caminho de arquivo necessário, seguido por \n<unknown_variable>\n<filepath>\<filename >. O Whisper lê o conteúdo do arquivo na memória, codifica-o em base64 e retorna:

este é o meu arquivo requerido <caminho>\n<variável_desconhecida>\n<filename>\n<conteúdo_do_arquivo_codificado_em_base64>

• Executar um script do PowerShell

Esse comando não tem um prefixo e, em vez disso, contém apenas um comando de texto simples que o PowerShell é capaz de executar, pós-fixado com um pipe após o qual o Whisper acrescenta Out-String. A saída é salva neste formato:

base64-encoded(<command_id>: <cmd_id>\n<cmd_output>\n)

Finalmente, na Etapa 7, a Whisper envia a saída do comando em uma mensagem de e-mail para a caixa de entrada do C&C encontrada na Etapa 4. O e-mail é formatado com estes detalhes:

• endereço de e-mail de envio: caixa de entrada da Etapa 1,
• destinatário: endereço de e-mail da Etapa 4,
• subject (assunto): E-mail (do arquivo de configuração, linha 14, key="send_sign"),
• corpo da mensagem: Hey There! encontre seus resultados no anexo (codificado no binário), e
• anexo: saída dos comandos da Etapa 6, criptografada com a mesma chave de criptografia da Etapa 5 (linha 18 do arquivo de configuração, key="enc_key" value="cXdlcmFzZHp4Y3ZmZ2d0aGhsZGZvZ2g/bHZtZ2xrZyE=").

As etapas 4 a 7 continuam em um loop usando o mesmo cronograma de check-in da etapa 3 até que as credenciais codificadas no arquivo de configuração sejam alteradas.

Backdoor Shahmaran

O backdoor Shahmaran, nomeado em homenagem a uma criatura mítica metade cobra, metade mulher do folclore iraniano, é um PE de 64 bits que foi encontrado na pasta de inicialização como:

%ROAMINGAPPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\adobeupdater.exe

Na inicialização do sistema, o Shahmaran cria um objeto de evento do Windows, o SysPrep. É possível que os desenvolvedores do Shahmaran tenham escolhido SysPrep como o nome do evento para se misturar ao ruído de fundo, pois o SysPrep faz parte do processo de criação de imagens do Windows. Os administradores do Windows o utilizam para criar uma imagem padrão do Windows (geralmente chamada de imagem Gold ou Golden) antes da implementação em sistemas corporativos. A Figura 4 mostra o objeto de evento SysPrep em um sistema comprometido, conforme visto pelo WinObj da Sysinternals.

O domínio do C&C é codificado, olinpa[.]com, assim como a porta, 80, e a string User-Agent, que são duas. A conexão inicial com o C&C usa uma string User-Agent incompleta (está faltando o parêntese de fechamento):

Mozilla/4.0 (compatível; MSIE 6.0; Windows NT 5.0

A comunicação subsequente com o C&C usa a string User-Agent corrigida:

Mozilla/4.0 (compatível; MSIE 6.0; Windows NT 5.0)

O Shahmaran não usa nenhuma compressão ou criptografia nas comunicações de rede. E, embora a porta seja codificada(80), há fragmentos de código que verificam a porta em uso e atualizam as variáveis de comunicação se a porta 443 for usada.

Depois de fazer o check-in com o servidor C&C, o Shahmaran executa todos os comandos de operador fornecidos, retorna qualquer saída desses comandos e, em seguida, dorme por 30 segundos antes de fazer o check-in com o servidor C&C novamente, ad infinitum. A Tabela 3 mostra os comandos de operador disponíveis e suas funções.

Tabela 3. Comandos do operador e suas descrições

Depois de executar um comando de operador, Shahmaran envia a saída para o servidor C&C usando o formato t=<operator_command>&<command_output>, como t=1&s=<file_timestamp>.

Backdoor do Slippery Snakelet

O Slippery Snakelet é um pequeno backdoor baseado em Python com recursos limitados:

1. executa um comando via cmd.exe,

2. baixa um arquivo de uma URL e

3. faz upload de um arquivo para o caminho /newfile/ URI.

O Slippery Snakelet tem um servidor de C&C codificado, zaincell[.]store, e se comunica com ele por meio de URLs no formato https://zaincell[.]store/request/<UID>, em que <UID> é o domínio de login da vítima e o nome do computador comprometido, separados por um ponto e depois codificados em base64 (por exemplo victim_domain.computer_name = dmljdGltX2RvbWFpbi5jb21wdXRlcl9uYW1l).

O Slippery Snakelet também tem este User-Agent hardcodeado:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, como Gecko) Chrome/88.0.4324.104 Safari/537.36

O servidor C&C foi disfarçado como um site de E-Learning do Golfo Árabe e a página de destino HTML padrão não contém nenhum comando. Quando o Slippery Snakelet fornece uma solicitação formatada corretamente (por exemplo, https://zaincell[.]store/request/<UID>), o servidor C&C insere tags <code> como <code>6wjTyB3Y20KSzU1VUlTagp3aG9hbWkKbnVsbApudWxs</code> na página, e o Slippery Snakelet as coleta e decodifica.

O Slippery Snakelet decodifica em base64 tudo, desde o oitavo caractere até o final da string (ou seja, Y20KSzU1VUlTagp3aG9hbWkKbnVsbApudWxs no exemplo acima). A saída decodificada é separada por nova linha e contém os cinco itens descritos na Tabela 4

Tabela 4. Argumentos e opções do Slippery Snakelet

Laret e Pinar - túneis reversos

Laret e Pinar, cujos nomes são derivados dos nomes internos em cada arquivo respectivo, são binários do Windows de 32 bits escritos em C#/.NET. Ambos têm carimbos de data e hora de compilação do PE - uma tática comum entre os grupos de ameaças do Oriente Médio (e particularmente ligados ao Irã) - de 2058-02-07 00:12:48 e 2072-07-10 18:26:15, respectivamente. Ambos foram encontrados em dois sistemas nos locais da Tabela 5.

Tabela 5. Localizações de Laret e Pinar no disco, juntamente com nomes de arquivos

No caso em que não temos um local no disco para o Laret, mas temos o nome do arquivo(wincapsrv.exe), podemos ver que o Laret foi baixado de http://178.209.51[.]61:8000/wincapsrv.exe via PowerShell. Infelizmente, não conseguimos descobrir onde ele foi gravado no disco. As tentativas de enumerar o IP e baixar o arquivo foram rejeitadas pelo servidor C&C, o que provavelmente indica que alguma forma de identificação de host comprometido é necessária na configuração da conexão (que não temos).

Com relação à gravação em disco, os operadores do BladedFeline provavelmente alteraram a data de criação do arquivo Pinar para 2017-09-14 14:56:00 em um dos dois sistemas comprometidos. Como a data de criação do arquivo foi alterada é uma questão em aberto, mas mostra que os invasores comprometeram esses dois sistemas a tal ponto que provavelmente têm direitos administrativos.

No tempo de execução, tanto a Laret quanto a Pinar dependem de um arquivo de configuração no mesmo diretório de seus binários para oito variáveis necessárias, que estão listadas na Tabela 6.

Tabela 6. Parâmetros de configuração do Laret e do Pinar com valores padrão codificados

Até o momento, não coletamos o arquivo de configuração, mas reconstruímos seu conteúdo provável, encontrado na Figura 5, com base na análise do código. A leitura do arquivo de configuração é feita pela decodificação base64 da cadeia codificada em bytes, o que resulta em cadeias de valores de caracteres delimitados por espaço e codificados em hexadecimal, que, por sua vez, são decodificados em cadeias ASCII.

Os desenvolvedores do BladedFeline se referem a isso como Delocking e o oposto (gravação no arquivo de configuração) como Enlocking. Isso provavelmente indica uma familiaridade passageira com o inglês, mas os desenvolvedores estavam longe de ser proficientes. Outros exemplos de habilidades de tradução fracas incluem:

• tempo decorrido e cliente não conectado
• aerpoo após
• Aguardando conexão ...
• erro no cliente ssh criado

É interessante notar que, em outro ponto dos túneis reversos, os desenvolvedores escreveram corretamente a palavra elapsed(tempo decorrido!), o que é um indicativo de codificação deficiente e revisão de código frouxa, se houver alguma (por exemplo, há muita saída de texto de resultado de comando para a linha de comando, como se os túneis reversos tivessem sido enviados imediatamente após a conclusão bem-sucedida do teste).

A função e o fluxo reais do Laret e do Pinar depois de coletar os parâmetros do arquivo de configuração são bastante banais, mas isso provavelmente é um esforço intencional para se misturar. Ambos procuram um nome de arquivo no parâmetro process_file e, se houver um arquivo que corresponda ao nome fornecido, executam-no e iniciam dois threads:

1. Estabelece uma conexão SSH com o IP do C&C no arquivo de configuração usando a DLL Core.Renci.SshNet incluída no binário. A porta 22 é codificada como a porta do C&C e o encaminhamento de porta também é ativado, usando a variável remote_port do arquivo de configuração.
2. Configura um ouvinte na porta especificada no parâmetro local_port do arquivo de configuração. Observe que todos os dados enviados ao ouvinte são feitos de forma clara (ou seja, nenhuma criptografia ou ofuscação é usada além dos caracteres \0 extras que são removidos no momento do recebimento por Laret e Pinar).

Se nenhum arquivo for especificado em process_file, tanto o Laret quanto o Pinar ignoram a configuração de uma porta de ouvinte.

O Laret e o Pinar diferem significativamente apenas no fato de que o Pinar configura um serviço, chamado Service1, para persistência antes de executar os dois threads. O Laret não tem meios de persistência além de seu processo ser executado indefinidamente.

Ferramentas complementares

Shell da Web Flog

O Flog é um webshell encontrado carregado no VirusTotal do Iraque pelo mesmo remetente que carregou uma das versões do Whisper. Com base nisso e no período de tempo próximo (ambos foram carregados em questão de minutos), acreditamos que ele foi implantado pelo BladedFeline na vítima do governo iraquiano.

O Flog, assim chamado por causa de seu nome de arquivo - flogon.aspx - procura entradas específicas dos operadores do BladedFeline no formato <password>=<(a|b|c|d)>#<path>

O Flog faz o hash da senha, que deve corresponder à soma de verificação MD5 4CC88CE123B0DA8D75C0FE66A39339F6.

As variáveis(a|b|c|d) são opções de comando:

• a retorna, para o caminho fornecido, uma listagem de diretórios e o comprimento em bytes de cada arquivo,
• b cria um arquivo no disco, usando o caminho fornecido,
• c divide a variável path em um pipe e grava um arquivo no disco, em que a primeira parte do path é o nome do arquivo e a segunda parte são os dados a serem gravados, e
• d exclui um arquivo especificado dado no caminho fornecido.

Hawking Listener

O Hawking Listener, assim chamado devido à sua string PDB - C:\Users\g18u04\source\repos\Hawking\Hawking\obj\Release\listner.pdb - é um binário .NET/C# Windows de 32 bits com tempo de compilação registrado em 2057-11-14 16:59:12. Ele também foi carregado no VirusTotal pelo mesmo usuário que carregou o Flog e provavelmente é uma ferramenta do BladedFeline. Ele implementa a classe .NET HTTPListener para configurar um ouvinte com um URL codificado (que não podemos divulgar neste caso sem revelar a identidade da vítima). Como alternativa, o Hawking pode ser fornecido em tempo de execução com URLs para o soquete do ouvinte monitorar.

O Hawking escuta uma QueryString fornecida (de um operador BladedFeline) com snmflwkejrhgsey como a chave no par chave-valor. Uma vez recebido, o Hawking executa o valor no cmd.exe e retorna a saída. Para interromper o Hawking, os operadores só precisam enviar stop como a chave na QueryString com uma variável não nula no valor.

O Hawking registra todas as interações, argumentos de tempo de execução e saída de comando no arquivo log.txt em seu diretório de trabalho.

P.S. Olala

P.S. Olala é um binário .NET de 32 bits nomeado de acordo com sua função pretendida (execução de scripts do PowerShell) e seu caminho PDB G:\csharp\psExecuterService\ewsService\obj\Release\Olala.pdb. Ele não aceita nenhum argumento de tempo de execução. Em vez disso, no tempo de execução, o P.S. Olala usa o método Run(ServiceBase[]) da classe ServiceBase do .NET para se registrar como um serviço no Service Control Manager (para persistência).

Quando o serviço do P.S. Olala é chamado, ele gera um thread e executa a função mainLoop, mostrada na Figura 6. Essencialmente, o P.S. Olala é um executor do script do PowerShell armazenado em %APPDATA%\Local\Microsoft\InputPersonalization\TrainedDataStore.ps1.

Infelizmente, não foi possível coletar nenhum dos scripts TrainedDataStore.ps1. No entanto, as informações contextuais indicam que ele provavelmente é um executor do backdoor do Whisper ou de um dos túneis reversos (Laret ou Pinar). O fluxo inteiro (P.S. Olala → TrainedDataStore → Whisper/Laret/Pinar) é provavelmente uma cadeia de persistência alongada com o objetivo de manter o acesso.

Tunelador de ovelhas

O Sheep Tunneler, um aplicativo de tunelamento personalizado que nomeamos com base na cadeia PDB C:\Users\sheep\source\repos\MP\MP\obj\Release\MP.pdb), foi observado nos dois locais a seguir:

• %APPDATA%\Local\Microsoft\Windows\Ringtones\RingService.exe
• %APPDATA%\Local\Microsoft\Windows\Shell\mspsrv.exe

O Sheep Tunneler pode ser executado em dois modos: tunelamento de rede (usando o argumento de tempo de execução middle) ou conexão de volta (usando os argumentos cb <ip>:<port>).

Protocolo Whisper

O Whisper Protocol, assim chamado devido ao seu nome de arquivo(Protocol.pdf.exe), é um binário do Windows de 64 bits compilado em Python com um registro de data e hora de compilação de 2024-03-11 09:01:20. Ele cria uma pasta em C:\ProgramData\VeeamUpdate e grava o Whisper e seu arquivo de configuração nessa pasta. O protocolo Whisper também copia a si mesmo para %APPDATA%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\VeeamUpdate.lnk para persistência. Por fim, ele executa o Whisper e sai de forma elegante.

Conclusão

O BladedFeline é um grupo de ameaças avançadas especializado em atingir vítimas iraquianas e curdas, especificamente funcionários e organizações governamentais. Avaliamos que o grupo é provavelmente um subgrupo do OilRig. Esperamos descobrir que o BladedFeline persistirá no desenvolvimento de implantes para manter e expandir o acesso em seu conjunto de vítimas comprometidas, provavelmente para ciberespionagem.

Para qualquer dúvida sobre nossa pesquisa publicada no WeLiveSecurity, entre em contato conosco pelo e-mail threatintel@eset.com.

A ESET Research oferece relatórios privados de inteligência sobre APTs e feeds de dados. Para qualquer dúvida sobre este serviço, visite a página ESET Threat Intelligence.

IoCs

Arquivos

Rede

Técnicas do MITRE ATT&CK

Esta tabela foi criada usando a versão 17 da estrutura MITRE ATT&CK.

#Linguagem do espaço reservado = '1' id='1555'#@#