conteúdo
- Introdução
- Principais Alvos
- Setores Afetados
- Foco geográfico
- Cadeia de infecção
- Descobertas iniciais
- Analisando o documento de isca
- Análise Técnica
- Etapa 1 – Entrega Inicial
- Caminho A: Execução baseada em LNK
- Caminho B: Entrega baseada em executáveis
- Etapa 2 – Cadeia de ejetores baseada em script
- Etapa 3 – RUSTCLOAK (Carregador de ferrugem)
- Etapa 4 – AZUREVEIL (Agente C2 da Adaptix)
- Etapa 1 – Entrega Inicial
- Infraestrutura e Atribuição
- Conclusão
- SEQRITE pós-colheita
- Indicadores de Compromisso (IOCs)
- Mapeamento MITRE ATT&CK
- autores
Introdução
O Seqrite A equipe da APT tem monitorado ativamente ameaças em todo o mundo. Durante nossa análise recente, identificamos uma campanha de spearphishing direcionada a autoridades e cidadãos da República Tcheca e de Taiwan. Observamos um único documento de isca, juntamente com vários artefatos de apoio, que sugerem fortemente que a campanha está visando especificamente essas regiões, já que os arquivos imitam de perto as comunicações oficiais.
O ataque começa com um anexo ZIP. Ao ser extraído, o arquivo contém vários arquivos que parecem legítimos, mas na verdade fazem parte de uma cadeia de infecção estruturada, projetada para executar payloads maliciosos em segundo plano.
Este blog fornece uma descrição detalhada de todo o processo de infecção e explica como o atacante usa dois caminhos de entrega diferentes para executar o payload. Também examina como serviços confiáveis, como o Armazenamento de Blobs do Microsoft Azure, são explorados para comunicação de comando e controle, e como o agente Adaptix é usado para exfiltração de dados e controle remoto.
Além disso, analisamos a criptografia multicamadas usada para proteger a carga útil e como ela ajuda o atacante a evitar a detecção. O blog também apresenta indicadores-chave de comprometimento (IOCs), destaca descobertas importantes de nossa análise e mapeia o comportamento observado para as técnicas do MITRE ATT&CK, a fim de fundamentar a atribuição desta campanha a um agente de ameaças ligado à China.
Principais Alvos
Setores Afetados
- Governo e Setor Público
- Pesquisa e Academia
- Tecnologia e Software
- Serviços Financeiros
Foco geográfico
- República Checa
- Taiwan
Cadeia de infecção
Descobertas iniciais
Como parte de nossos esforços contínuos de monitoramento de ameaças, o SEQRITE A equipe do laboratório identificou um arquivo ZIP suspeito no threat intelplataforma de liderança VirusTotal.
Com base na telemetria disponível, o arquivo foi submetido inicialmente de Taiwan em 26 de março de 2026. Essa submissão inicial fornece uma pista importante, pois pode indicar a região onde a campanha foi observada pela primeira vez ou onde estava sendo ativamente visada.
Após analisar o conteúdo do arquivo ZIP extraído, identificamos diversos arquivos suspeitos, incluindo uma pasta chamada " data" , um atalho para o arquivo 計畫申請審查結果通知單.pdf.lnk disfarçado de documento PDF e um executável _計畫申請審查結果通知單.exe disfarçado de arquivo legítimo. O nome do arquivo se traduz como "Notificação de Resultado da Análise da Candidatura ao Projeto", sugerindo uma tentativa de se passar por um documento oficial. Os nomes dos arquivos estão escritos em chinês tradicional, idioma comumente usado em Taiwan, o que reforça a suspeita de que a campanha esteja direcionada a usuários dessa região.
Após analisar o conteúdo da pasta de dados, encontramos vários arquivos envolvidos em diferentes estágios da cadeia de infecção, incluindo contêineres de carga útil criptografados (1.dat e Com.dat), arquivos de script (Profile.ps1 e empty.vbs), uma DLL maliciosa usada para instalação por fora da pasta (UnityPlayer.dll) e um arquivo PDF falso usado para distrair a vítima.
Após analisar o arquivo executável, observamos que ele gera um documento adicional de isca, projetado para se assemelhar a um documento oficial da República Tcheca. Este documento será analisado em detalhes posteriormente neste blog, e sua presença indica ainda mais que a campanha também está visando autoridades tchecas.
Analisando o documento de isca
Após examinarmos o conteúdo do arquivo ZIP, descobrimos um documento de isca dentro da pasta data/ chamado 000b67d70f3876965bb09fd37164b7.pdf. Além disso, ao analisarmos o executável principal _計畫申請審查結果通知單.exe, encontramos outro documento de isca incorporado no próprio binário. À primeira vista, ambos os documentos parecem semelhantes devido aos seus nomes, mas seus conteúdos são diferentes.
Documento 1: Isca encontrada dentro da pasta data/
O arquivo 000b67d70f3876965bb09fd37164b7.pdf foi identificado na pasta data/ e está criptografado usando um XOR de um único byte com a chave 0xBE. Após a descriptografia, descobrimos que o documento está escrito em chinês e contém conteúdo relacionado a um anúncio do software WPS PDF. Apesar de apresentar um padrão de nomenclatura semelhante ao do documento isca incorporado no executável, este arquivo não é referenciado nem utilizado em nenhuma etapa da cadeia de infecção.
Isso sugere que o documento pode ter sido incluído involuntariamente pelo agente da ameaça, possivelmente como um resquício de uma campanha diferente, onde tal documento poderia ter servido como isca.
Documento 2: Chamariz incorporado dentro _計畫申請審查結果通知單.exe
O arquivo de isca está incorporado no executável _計畫申請審查結果通知單.exe e é o documento exibido à vítima durante a execução. O nome do documento é 000b67d70f3876965bb09fd37164b7ccrezervaci.pdf, que combina uma sequência semelhante a um hash com uma palavra em tcheco (“rezervaci”). O documento está escrito em tcheco e aparenta ser um aviso de agendamento da Administração de Seguridade Social Tcheca (ČSSZ), provavelmente obtido do site oficial cssz.cz. Ele inclui detalhes como um agendamento para uma pessoa chamada Zuzana Košková em 16 de março de 2026, fazendo-o parecer um documento genuíno emitido pelo governo.
A seção final do documento fornece instruções adicionais ao destinatário, orientando-o sobre o que fazer ao chegar ao escritório. Explica como obter uma senha usando o código de identificação fornecido e instrui o usuário a aguardar sua vez, de forma semelhante aos procedimentos de agendamento padrão.
O documento também inclui um link para o site oficial da Administração de Segurança Social Checa (ČSSZ) para gerir ou cancelar a marcação. Parece ter sido criado a partir do ficheiro original do site, em formato PDF.
Na próxima seção, analisaremos os aspectos técnicos desta campanha.
Análise Técnica
Ao analisarmos o conteúdo do arquivo ZIP, notamos algo interessante: havia, na verdade, duas maneiras pelas quais a cadeia de infecção poderia, em última instância, instalar o arquivo DLL malicioso que contém o payload, dependendo de com qual arquivo a vítima interagisse primeiro.
No Caminho A , a infecção começa quando a vítima clica no arquivo LNK malicioso 計畫申請審查結果通知單.pdf.lnk. Essa ação aciona silenciosamente um script VBScript (empty.vbs), que então executa um script PowerShell (Profile.ps1). O script PowerShell é responsável por descriptografar o arquivo 1.dat , gravar o conteúdo descriptografado como RuntimeBroker_update.exe e executá-lo.
No Caminho B , a vítima executa diretamente o arquivo _計畫申請審查結果通知單.exe. Este executável atua como um dropper independente baseado em Rust, que extrai todos os componentes necessários por conta própria e, em seguida, executa o mesmo arquivo RuntimeBroker_update.exe.
Embora as etapas iniciais sejam diferentes, ambos os caminhos terminam no mesmo estágio. O arquivo RuntimeBroker_update.exe carrega uma DLL maliciosa, UnityPlayer.dll, usando o método de carregamento lateral de DLL (DLL sideloading), o que leva à execução de um carregador baseado em Rust que chamamos de RUSTCLOAK . Esse carregador, então, descriptografa e executa a carga útil final, AZUREVEIL , um agente C2 da Adaptix.
Etapa 1 – Entrega Inicial
Caminho A: Execução baseada em LNK
O primeiro método de distribuição começa com um atalho malicioso do Windows chamado 計畫申請審查結果通知單.pdf.lnk, que se traduz como “Aviso de Resultado da Análise da Candidatura ao Projeto.pdf”. O uso de uma extensão dupla ( .pdf.lnk ) é intencional, fazendo com que o arquivo pareça um documento PDF normal.
O arquivo LNK está configurado para executar o wscript.exe a partir do diretório do sistema Windows, passando .\data\empty.vbs como argumento. Em vez de abrir um PDF, o atalho executa silenciosamente este arquivo VBScript em segundo plano. Ao mesmo tempo, ele usa o ícone do Microsoft Edge para parecer um documento normal.
Caminho B: Entrega baseada em executáveis
O segundo método de entrega utiliza um executável compilado em Rust chamado _計畫申請審查結果通知單.exe. Este arquivo funciona como um dropper completo, com todos os componentes necessários incorporados, portanto, não depende de nenhum arquivo externo do arquivo ZIP.
Durante a análise dinâmica, descobrimos que o binário executa várias ações por conta própria. Primeiro, ele cria um diretório em %LOCALAPPDATA%\WebViewFixUtility para armazenar seus arquivos. Em seguida, ele instala vários componentes, incluindo BrowserViewUtility.exe (um executável legítimo usado para sideloading), um UnityPlayer.dll malicioso (RUSTCLOAK), um arquivo de configuração criptografado, um documento falso (000b67d70f3876965bb09fd37164b7ccrezervaci.pdf) e RuntimeBroker_update.exe.
Etapa 2 – Cadeia de ejetores baseada em script
O Caminho B lida com tudo internamente, então, a partir daqui, nos concentramos apenas no Caminho A , a cadeia baseada em script que percorre três componentes adicionais: empty.vbs, Profile.ps1 e 1.dat. Cada um deles desempenha um papel na preparação e execução do binário final, RuntimeBroker_update.exe, que é usado posteriormente para o carregamento lateral de DLLs.
Assim que a vítima clica no arquivo LNK, o arquivo empty.vbs é executado e a cadeia de scripts é iniciada. Esse fluxo funciona silenciosamente em segundo plano, passando o controle de um componente para o outro sem revelar nada suspeito ao usuário.
Após analisar o script VBScript, descobrimos que se trata de um script muito pequeno com um único propósito: executar o Profile.ps1 usando o PowerShell. Ele executa o PowerShell com a política de execução ignorada habilitada e em uma janela oculta, de forma que nada seja visível para o usuário. O script em si não contém nenhuma lógica real e serve apenas como uma ponte para a próxima etapa.
A lógica principal da cadeia de infecção é gerenciada pelo Profile.ps1. Este script lê o arquivo 1.dat da pasta data/ e o descriptografa usando uma simples operação XOR com a chave embutida P@ssw0rd_am_2026. Após a descriptografia, o arquivo se torna RuntimeBroker_update.exe , que é então gravado no disco.
O script também move os arquivos UnityPlayer.dll e Com.dat para o diretório %TEMP%, garantindo que todos os componentes necessários estejam reunidos. Assim que tudo estiver pronto, ele executa o arquivo RuntimeBroker_update.exe em segundo plano e abre o documento falso para distrair o usuário.
O arquivo 1.dat não é um executável comum. Trata-se de um contêiner criptografado com XOR que contém o arquivo RuntimeBroker_update.exe. A criptografia é simples e utiliza uma chave curta, provavelmente para evitar detecção básica. Após a descriptografia realizada pelo Profile.ps1, o executável RuntimeBroker_update.exe é extraído e executado.
Conforme descrito anteriormente, a campanha utiliza dois pontos de entrada diferentes, dependendo de como a vítima interage com o arquivo. Ambos os caminhos eventualmente entregam a mesma carga útil, RuntimeBroker_update.exe, mas a forma como o fazem é diferente. O Caminho A segue uma cadeia de scripts com várias etapas que se inicia quando a vítima clica no arquivo LNK, enquanto o Caminho B é autossuficiente e requer apenas que a vítima execute o arquivo executável.
Etapa 3 – RUSTCLOAK (Carregador de ferrugem)
Os dois caminhos convergem aqui e o RuntimeBroker_update.exe agora está em execução. A primeira coisa que o Windows faz é procurar o arquivo UnityPlayer.dll na mesma pasta. O atacante se aproveita disso, colocando um arquivo UnityPlayer.dll malicioso na mesma pasta. Por causa disso, o Windows carrega a DLL do atacante em vez da legítima.
Essa DLL, que chamamos de RUSTCLOAK, é um carregador baseado em Rust responsável por continuar a cadeia de execução e preparar a carga útil final.
Artefatos de desenvolvimento
Uma das principais descobertas durante nossa análise do RUSTCLOAK foi um erro de segurança operacional cometido pelo agente da ameaça. O caminho de compilação do Rust, C:\Users\dell2\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\src\decrypt_SM4.rs, foi deixado dentro do binário como texto simples, expondo detalhes do sistema do desenvolvedor:
Isso expõe o nome de usuário do Windows do desenvolvedor como dell2 e as versões específicas da biblioteca usadas, como libsm-0.5.1 para criptografia SM4 e base64-0.21.7 para operações Base64.
Anti-análise: Detecção em Sandbox
Antes de executar qualquer atividade maliciosa, o RUSTCLOAK verifica se está sendo executado em um ambiente de sandbox ou de análise. Ele recupera o nome do computador do sistema e o compara com uma lista fixa de mais de 100 nomes de máquinas conhecidos de sandbox e de análise.
Se uma correspondência for encontrada, o carregador é encerrado imediatamente sem executar o payload. A lista inclui nomes comuns como DESKTOP-NAKFFMT , JULIA-PC e ARCHIBALD-PC , que são frequentemente encontrados em configurações de análise automatizada. Essa verificação ajuda o malware a evitar a detecção durante a análise.
Cadeia de decriptografia de tripla camada
Após ser carregado, o RUSTCLOAK lê o conteúdo criptografado (Com.dat) do disco e o processa através de múltiplas camadas de descriptografia antes de poder ser executado.
Camada 1: Decriptação RC4 personalizada – A primeira etapa utiliza um algoritmo RC4 modificado. A chave usada nesta etapa é: F8 83 40 17 1D 66 AA C2 B0 25 A8 6C A0 DD C4 5A
Camada 2: Decodificação Base64 – Após a etapa RC4, a saída ainda não é diretamente utilizável. Ela está codificada em formato Base64, então o carregador a decodifica para obter os dados binários reais para a próxima etapa.
Camada 3: Decriptação SM4-CBC – Na etapa final, os dados são decriptados usando SM4 no modo CBC. A chave e o vetor de inicialização utilizados são:
Chave: CD CE 4F DB 3E 6A F2 44 AC 62 8C F4 96 1F 6B FB
IV: FA 70 B1 81 A0 BA 5D 46 7A 5D 40 DD 99 B6 9B 42
Execução em memória via fibras do Windows
Após a conclusão do processo de descriptografia, o RUSTCLOAK aloca memória usando VirtualAlloc e copia o shellcode descriptografado para essa memória. Em seguida, ele altera as permissões de memória para executável usando VirtualProtect antes de executar o payload.
Em vez de criar uma nova thread, que geralmente é monitorada por ferramentas de segurança, ele usa fibras do Windows para execução. O carregador chama CreateFiberEx e, em seguida, SwitchToFiber para passar o controle para o shellcode.
Durante a depuração do carregador, observamos que ele aloca uma grande região de memória e copia o payload descriptografado para ela. Ao inspecionar mais detalhadamente a região de memória, identificamos um cabeçalho PE válido (MZ), confirmando que o shellcode contém, de fato, um executável completo incorporado. O tamanho desse payload na memória foi estimado em aproximadamente 103 KB.
Extraímos este arquivo PE da memória durante a depuração, que se revelou ser a carga útil final, AZUREVEIL . Isso demonstra que o RUSTCLOAK não está simplesmente executando o shellcode diretamente, mas sim descriptografando e carregando um executável completo na memória e, em seguida, transferindo a execução para ele.
Etapa 4 – AZUREVEIL (Agente C2 da Adaptix)
AZUREVEIL é a carga útil final e a parte tecnicamente mais interessante desta campanha.
Após analisar o arquivo usando o DIE, descobrimos que o AZUREVEIL é um agente Adaptix C2 completo, compilado como uma DLL de 64 bits usando MinGW C++.
Durante a análise no VirusTotal, a amostra foi sinalizada como maliciosa por vários fornecedores, com a detecção apontando para uma configuração incorporada ligada à família de malware Adaptix.
Observamos que o AZUREVEIL resolve cerca de 87 APIs do Windows em tempo de execução usando um método de hash baseado em djb2. Ele carrega essas APIs de bibliotecas principais como wininet.dll , Ws2_32.dll , Advapi32.dll , Iphlpapi.dll e msvcrt.dll.
Comunicação C2 do Armazenamento de Blobs do Azure
Durante nossa análise, observamos que o AZUREVEIL utiliza o Armazenamento de Blobs do Microsoft Azure para comunicação de comando e controle. O aspecto interessante reside no mecanismo de C2, visto que não há nenhum servidor C2 tradicional. O malware simplesmente se comunica com o Armazenamento de Blobs do Azure, o mesmo serviço utilizado por milhares de empresas legítimas em todo o mundo.
Ponto de extremidade C2: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net
Em vez de usar um modelo C2 tradicional baseado em pull, o AZUREVEIL segue uma abordagem de dead-drop. O atacante e o sistema infectado nunca se comunicam diretamente. Em vez disso, ambos os lados usam o mesmo contêiner de armazenamento do Azure para trocar dados.
O agente carrega periodicamente um pequeno beacon criptografado (cerca de 124 bytes) para sinalizar que está ativo. O atacante então coloca comandos no mesmo contêiner. O AZUREVEIL recupera esses comandos, os descriptografa, os executa e carrega os resultados de volta como blobs criptografados.
Capacidades de comando do AZUREVEIL
Durante nossa análise estática e dinâmica, identificamos 36 comandos suportados pelo AZUREVEIL , que abrangem uma ampla gama de atividades pós-exploração. Essas capacidades permitem que o atacante controle totalmente o sistema infectado, realize roubo de dados e se movimente lateralmente pela rede.
Operações do sistema de arquivos
- Liste o conteúdo do diretório e as unidades lógicas.
- Ler, mover, renomear e excluir arquivos
- Exfiltrar arquivos para o Armazenamento de Blobs do Azure
- Transfira arquivos do C2 para o sistema da vítima.
- Baixar arquivos em fila
Controle de Processo e Casca
- Executar comandos shell
- Liste os processos em execução e os pipes nomeados.
- Configurar e encerrar processos
- Interrompa processos ou feche tubulações
Rede e pivô
- Encaminhamento de portas e controle de proxy SOCKS
- Conexões de pivô TCP e UDP
- Comunicação por canal nomeado
- Enumeração de adaptadores de rede (MAC, IP, tipo)
Gestão C2
- Reconfigurar as definições do C2 em tempo de execução
- Estado de transferência de arquivos de controle
- Recuperar tempo de atividade do sistema
Execução de código na memória
- Executar arquivos de objeto Beacon (BOF) integralmente
na memória sem gravar em disco
Motor de Execução BOF
O comando 0x32 chamou nossa atenção durante a análise estática. A princípio, parecia uma rotina genérica de injeção, mas após analisar o código de realocação, descobrimos que era algo mais complexo.
A função lia dados no deslocamento +2 para contagem de seções e no deslocamento +12 para contagem de símbolos, exatamente os mesmos deslocamentos definidos no formato de arquivo COFF padrão. Para confirmar isso, compilamos um arquivo objeto COFF AMD64 real em nossa máquina de análise e comparamos sua estrutura com a do analisador sintático.
Ao receber um BOF (Object Object File), o AZUREVEIL primeiro aloca memória e carrega as diferentes seções do arquivo objeto nela. Em seguida, processa as realocações necessárias e resolve as referências de função usando sua busca interna baseada em hash. Após configurar tudo, o carregador executa o ponto de entrada do BOF diretamente no processo do agente.
Qualquer saída gerada durante a execução é capturada usando um pipe nomeado e, em seguida, enviada de volta ao atacante por meio do Armazenamento de Blobs do Azure. Isso permite que o atacante execute funções adicionais no sistema e obtenha os resultados de volta, tudo isso permanecendo completamente na memória.
Infraestrutura e Atribuição
Durante nossa análise, observamos que o AZUREVEIL se comunica inteiramente por meio do Armazenamento de Blobs do Microsoft Azure, abusando da infraestrutura legítima de nuvem para comando e controle. Em vez de usar um servidor C2 tradicional, o atacante utiliza uma conta de armazenamento do Azure dedicada: note1ggbbhggdwa1[.]blob[.]core[.]windows[.]net
Uma análise mais aprofundada revelou os seguintes detalhes sobre a configuração de armazenamento:
Contêiner: /note/ats/
Formato Blob: {agent_id}/{timestamp1}_{timestamp2}.bin
ID do agente: 345831bc
Porta: 443 (HTTPS)
Toda a comunicação ocorre via HTTPS na porta 443, o que faz com que o tráfego se misture com a atividade normal do Azure. Como o blob.core.windows.net é amplamente utilizado por aplicativos legítimos, essa abordagem ajuda o invasor a evitar a detecção em nível de rede.
Identificamos também um token de Assinatura de Acesso Compartilhado (SAS) embutido no arquivo encrypted_blob, que é gerado pelo executável _計畫申請審查結果通知單.exe, usado para autenticar todas as operações na conta de armazenamento:
sv=2024-11-04&ss=b&srt=sco&sp=rwdlaciytfx&st=2026-03-19T09:20:44Z&se=2027-03-19T17:35:44Z&spr=https&sig=ECJjJIIE9Ou75dwiHhliC4fWccdBpLX9u580AX9TGwY=
O token é válido por um ano, de 19 de março de 2026 a 19 de março de 2027. Esse longo período de validade sugere que o atacante pretendia manter o acesso persistente por um período prolongado. As permissões associadas ao token permitem interação completa com o contêiner de armazenamento, incluindo operações de leitura, gravação, exclusão e upload.
Com base nas TTPs (Táticas, Técnicas e Procedimentos), ferramentas e alvos observados ao longo desta campanha, avaliamos com moderada confiança que ela está ligada a um agente de ameaças baseado na China. No entanto, não a atribuímos a nenhum grupo específico conhecido, visto que a campanha inclui técnicas que não foram previamente documentadas em atividades de APT chinesas publicamente conhecidas.
Conclusão
A Operação Dragon Weave é uma campanha de espionagem direcionada. Um dos aspectos únicos dessa campanha é o uso do Armazenamento de Blobs do Microsoft Azure como um canal de comando e controle (C2) oculto. Em vez de se comunicar com um servidor C2 normal, o malware mistura seu tráfego com a atividade regular da nuvem, o que torna sua detecção muito mais difícil. A carga útil final, AZUREVEIL, é um agente C2 Adaptix completo com 36 comandos de pós-exploração. Juntamente com a capacidade de execução de BOF (Blob Object File) em memória, ele oferece ao atacante muita flexibilidade para executar código adicional e controlar o sistema sem deixar muitos rastros no disco.
Observamos também que a campanha tem como alvo tanto a República Tcheca quanto Taiwan, utilizando documentos-isca específicos para cada região. Isso indica que a operação é planejada e direcionada, e não aleatória. Com base no uso de ferramentas e técnicas distintas, avaliamos que esta campanha está ligada a um agente de ameaças baseado na China.
SEQRITE pós-colheita
Lnk.Trojan.50646.GC
Trojan.Agent.S38943638
Script.Trojan.50655.SL
Script.Trojan.50650.SL
Indicadores de Compromisso (IOCs)
Nome do arquivo SHA-256
| 096372d19b4787e989f44e04c5ecc29885aa927c34ae8666628d6c0eb20bb447 | 計畫申請審查結果通知單.pdf.lnk |
| 1c56228cbd1bdebb9e5ea55c2749150fee06c865ede4a3754e8bd6843e51d2d4 | 計畫申請審查結果通知單.exe |
| 080ab9bc2893ba7bad354551604a667af40ed2ae2d042d2323c2bd9ad3122192 | UnityPlayer.dll |
| 5ed14c2b7f7433a1a72dd6b668413f935a217ba10b69d89b774a82990fa12fe1 | BrowserViewUtility.exe |
| 61f7d9cd2d8ce7df950639b23ce90085b300b0c6dd0d8d934bba8fdecb670f15 | RuntimeBroker_update.exe |
| 24aa4e780ccd66cef13da9ef98c32954105cf2a32ec643efab0ba1aa2d6352f4 | Com.dat |
| 02542a49b3bd6bd2795afb67840acb4557b17e017f7503dd03ebe3aeeb28720e | 000b67d70f3876965bb09fd37164b7ccrezervaci.pdf |
| 8ae7c82a3e4f742777e590b25a1c563d19bd9bcba2a387d004aae72c4b2828f9 | 000b67d70f3876965bb09fd37164b7.pdf |
| 047687548605734348792e2a9d771b6cba42facd0d0d7d44d778290a25848574 | 1.dat |
| a4e9f9919d62589b57cfa08c9ccb89e386b09f683271373413cd8e8c8c7d1c5a | vazio.vbs |
| 823d5969db3f3b72ebbdce1b78752717ea849884a0fb40d86146416c38e128de | Perfil.ps1 |
| 783661d0f7edb338d2d50be087764d82dbbc9ee7989ddc57db1801e4ec9045b0 | azureveil.exe |
Indicador de rede
Descrição do indicador
| nota1ggbbhggdwa1[.]blob[.]core[.]windows[.]net | Armazenamento de Blobs do Azure C2 |
Mapeamento MITRE ATT&CK
| Tática | ID da técnica | Nome da técnica |
| Acesso Inicial | T1566.001 | anexo de spearphishing |
| Execução | T1204.002 | Arquivo malicioso – execução pelo usuário |
| T1059.001 | PowerShell | |
| T1059.005 | Visual Basic | |
| Evasão de Defesa | T1574.002 | Carregamento lateral de DLL |
| T1027 | Arquivos ou informações ocultadas | |
| T1055 | Injeção de processo | |
| T1497.001 | Evasão de virtualização/sandbox | |
| T1620 | Carregamento de código reflexivo | |
| Discovery | T1083 | Descoberta de arquivos e diretórios |
| T1057 | Descoberta de processo | |
| T1016 | Descoberta de configuração de rede do sistema | |
| T1082 | Descoberta de informações do sistema | |
| Comando e Controle | T1102.001 | Serviço web – resolvedor de entrega direta |
| T1573 | Canal criptografado | |
| T1090 | procuração | |
| T1105 | Transferência de ferramenta de entrada | |
| exfiltration | T1041 | Exfiltração pelo canal C2 |
autores
Priya Patel
Kartikkumar Jivani
