APT31 usa serviços de nuvem em ataques furtivos contra o setor de TI russo

Campanha atribuída ao grupo associado à China abusou de Yandex Cloud, OneDrive, spear phishing, tarefas agendadas e ferramentas como CloudyLoader, COFFProxy e LocalPlugX para manter acesso prolongado e exfiltrar informações.

ComponenteEmpresas russas de tecnologia da informação, principalmente contratadas e integradoras de soluções para órgãos governamentais.
VetorSpear phishing com arquivos compactados, uso de atalho Windows LNK, carregamento lateral de DLL e abuso de serviços legítimos de nuvem e perfis de mídia social para comando, controle e entrega de estágios.
ImpactoAcesso persistente por longos períodos, coleta de arquivos e informações confidenciais, incluindo senhas de caixas de e-mail e serviços internos das vítimas.
PrioridadeRevisar telemetria de nuvem, tarefas agendadas, execução de LNK em anexos, carregamento lateral de DLL e conexões incomuns com Yandex, Microsoft OneDrive e canais externos usados como C2.
ArtefatosCloudyLoader, Cobalt Strike loader, StickyNotesExtract.exe, Tailscale VPN, AufTime, COFFProxy, VtChatter e LocalPlugX.
PersistênciaTarefas agendadas com nomes semelhantes a aplicações legítimas, incluindo Yandex Disk e Google Chrome.
Resumo técnico

A campanha atribuída ao APT31 mirou o setor russo de tecnologia da informação entre 2024 e 2025, com ênfase em empresas que atuam como contratadas e integradoras de soluções para órgãos governamentais. O padrão observado combina espionagem, permanência silenciosa e uso de infraestrutura legítima para reduzir a chance de detecção por controles baseados apenas em reputação de domínio ou bloqueio de tráfego desconhecido. Em pelo menos uma intrusão contra uma empresa de TI, o acesso teria começado no fim de 2022 e ganhado intensidade durante o feriado de Ano Novo de 2023, o que indica planejamento para operar em janelas de menor vigilância operacional.

O elemento central da atividade é o abuso de serviços de nuvem conhecidos no ambiente russo, especialmente Yandex Cloud, além de Microsoft OneDrive e armazenamento em nuvem da Yandex. Esses serviços foram usados para comando e controle, entrega de conteúdo e exfiltração de dados, permitindo que o tráfego malicioso se misturasse a comunicações corporativas aparentemente normais. A campanha também usou perfis de mídia social, domésticos e estrangeiros, para armazenar comandos e cargas criptografadas, criando uma camada adicional de indireção entre o operador e os sistemas comprometidos.

A operação não se limita a uma única ferramenta. O conjunto técnico inclui carregadores, backdoors, túneis criptografados, ferramentas de extração local, mecanismos de comunicação assíncrona e variantes voltadas para movimentação dentro da rede. Essa diversidade aumenta a dificuldade de resposta, porque a remoção de um binário ou a interrupção de um canal de C2 não elimina necessariamente todos os caminhos de controle preservados pelo operador.

Fluxo técnico

Um dos fluxos descritos começa com spear phishing enviado em dezembro de 2024. A mensagem continha um arquivo RAR com um atalho Windows LNK, que acionava a execução de um carregador chamado CloudyLoader por meio de carregamento lateral de DLL. A finalidade do estágio era iniciar um loader associado ao Cobalt Strike, sem exigir que a vítima executasse um binário claramente suspeito. Em outra isca, um arquivo ZIP se passava por um relatório do Ministério das Relações Exteriores do Peru e também resultava na implantação do CloudyLoader.

Depois do acesso inicial, a campanha usou tarefas agendadas para persistência. Os nomes dessas tarefas imitavam aplicações legítimas, como Yandex Disk e Google Chrome, uma técnica que tenta reduzir suspeita durante revisões superficiais de endpoint. Esse detalhe é relevante para defesa porque o indicador não é apenas a existência de uma tarefa agendada, mas a combinação entre nome plausível, caminho de execução incomum, binário fora de diretórios esperados e horário de criação compatível com eventos de phishing, feriados ou períodos de baixa atividade administrativa.

O APT31 também manteve ferramentas configuradas para operar em modo servidor, aguardando conexão do operador ao host infectado. Esse desenho muda o modelo de detecção: em vez de procurar apenas beacons periódicos saindo da rede, as equipes precisam observar portas locais abertas, processos escutando conexões, túneis criptografados, uso não autorizado de VPN e conexões P2P fora do perfil normal de estáções e servidores. O uso de Tailscale VPN para criar túnel criptografado e rede ponto a ponto entre host comprometido e infraestrutura externa reforça essa necessidade.

Entre as ferramentas citadas, StickyNotesExtract.exe foi usada para extrair dados da base do Windows Sticky Notes, o que pode expor anotações de usuários com informações sensíveis. AufTime aparece como backdoor Linux que usa a biblioteca wolfSSL para comunicação com C2. COFFProxy, escrito em Golang, suporta tunelamento de tráfego, execução de comandos, gerenciamento de arquivos e entrega de cargas adicionais. VtChatter usa comentários codificados em Base64 em um arquivo hospedado no VirusTotal como canal bidirecional de C2 em intervalos de duas horas. LocalPlugX é uma variante de PlugX voltada para propagação na rede local, não para comunicação direta com C2 externo.

Superfície afetada

A superfície prioritária envolve empresas de TI russas que prestam serviços a órgãos governamentais, porque esses ambientes podem funcionar como ponto de acesso indireto a clientes sensíveis, integrações internas, credenciais administrativas e documentação operacional. O contexto não confirma comprometimento de todos os clientes dessas empresas, mas o perfil dos alvos mostra interesse em cadeias de confiança, contratos técnicos e ambientes nos quais integradores mantêm conhecimento privilegiado sobre sistemas governamentais.

Os sistemas expostos incluem estáções Windows capazes de abrir anexos compactados e atalhos LNK, endpoints nos quais DLLs podem ser carregadas a partir de diretórios controlados pelo invasor, servidores Linux suscetíveis à instalação de backdoors e hosts com permissão para acessar serviços de nuvem usados na organização. Também entram no escopo contas de e-mail, serviços internos e repositórios de arquivos, já que a campanha coletou informações confidenciais e senhas associadas a caixas postais e serviços internos.

O uso de plataformas legítimas torna a superfície mais ampla do que uma lista de domínios maliciosos. Controles que permitem Yandex Cloud, Yandex Disk, armazenamento da Yandex, Microsoft OneDrive, VirusTotal ou redes VPN autorizadas sem inspeção contextual podem não distinguir tráfego corporativo regular de abuso operacional. A defesa deve correlacionar identidade, processo de origem, volume, horário, destino e histórico do ativo antes de classificar essas conexões como benignas.

  • Empresas russas de TI contratadas ou integradoras de soluções para órgãos governamentais.
  • Endpoints Windows expostos a anexos RAR ou ZIP contendo atalhos LNK e carregamento lateral de DLL.
  • Hosts com tarefas agendadas que imitam Yandex Disk ou Google Chrome, mas executam caminhos ou binários incompatíveis com instalações legítimas.
  • Ambientes Linux onde AufTime possa estabelecer comunicação criptografada com C2 usando wolfSSL.
  • Redes que permitem túneis Tailscale VPN, tráfego para serviços de nuvem e acesso a conteúdo externo sem correlação com processo e usuário.
Hunting e telemetria

O hunting deve começar pela linha do tempo de acesso inicial e persistência. Eventos de abertura de arquivos compactados vindos de e-mail, criação de atalhos LNK, execução de processos filhos inesperados e carregamento de DLL a partir de diretórios temporários ou perfis de usuário formam uma cadeia de sinal forte. A telemetria de EDR deve ser comparada com logs de gateway de e-mail, proxy e autenticação para identificar máquinas que receberam iscas e logo depois passaram a criar tarefas agendadas ou iniciar conexões incomuns de nuvem.

A análise de tráfego deve tratar serviços legítimos como destinos que exigem contexto, não como exceções automáticas. Conexões recorrentes com Yandex Cloud, Microsoft OneDrive, armazenamento Yandex e conteúdo externo em intervalos regulares podem indicar C2 ou exfiltração quando partem de processos sem relação com sincronizadores oficiais, navegadores em uso interativo ou ferramentas corporativas aprovadas. No caso de VtChatter, o comportamento relevante é a consulta periódica a conteúdo hospedado no VirusTotal e o uso de comentários codificados como meio de comunicação, sem publicar URLs ativos ou indicadores operacionais.

Também é importante procurar ferramentas que operam em modo servidor. Processos escutando conexões em estáções de trabalho, binários Go com funcionalidade de proxy, túneis P2P recém-criados, autenticações incomuns em VPN e conexões laterais entre hosts que não costumam se comunicar devem ser priorizados. Em redes onde integradores administram múltiplos ambientes, a correlação entre credenciais usadas, horários de acesso e origem do processo é essencial para diferenciar manutenção legítima de controle remoto indevido.

  • Criação de tarefas agendadas com nomes parecidos com aplicações legítimas, especialmente quando o caminho de execução não corresponde ao software instalado.
  • Execução de LNK a partir de anexos RAR ou ZIP recebidos por e-mail e seguida de carregamento lateral de DLL.
  • Conexões de processos incomuns para Yandex Cloud, armazenamento Yandex, Microsoft OneDrive ou conteúdo hospedado em plataformas externas.
  • Uso não autorizado de Tailscale VPN, túneis criptografados ou comunicação P2P entre host comprometido e infraestrutura externa.
  • Processos locais com comportamento de servidor, portas abertas sem justificativa operacional e ferramentas com capacidade de tunelamento, execução de comandos e gerenciamento de arquivos.
  • Acesso a bases locais do Windows Sticky Notes ou coleta incomum de arquivos contendo senhas, dados de e-mail e referências a serviços internos.
Mitigação

A resposta deve combinar contenção de endpoint, revisão de identidade e análise de nuvem. Máquinas com sinais de CloudyLoader, tarefas agendadas suspeitas, DLL side-loading ou ferramentas de túnel não autorizadas devem ser isoladas para preservar evidências e impedir exfiltração adicional. A remoção manual de um único artefato é insuficiente, porque a campanha usa múltiplos canais, incluindo nuvem, perfis externos, ferramentas em modo servidor e mecanismos de propagação local.

As equipes devem revisar políticas de execução de anexos, bloquear ou restringir atalhos LNK vindos de e-mail, reforçar inspeção de arquivos compactados e mapear processos autorizados a acessar serviços de nuvem. Para Yandex, OneDrive e plataformas similares, a mitigação mais eficaz não é apenas bloquear o domínio, mas aplicar controle por identidade, aplicação, localização, volume de dados e finalidade de negócio. Em organizações que dependem desses serviços, exceções devem ser documentadas e monitoradas com alertas para novos processos, novos usuários e horários fora do padrão.

Como a campanha coletou senhas de caixas postais e serviços internos, a rotação de credenciais deve ser orientada por escopo forense. Contas usadas em hosts comprometidos, credenciais administrativas, tokens de sincronização, acessos a e-mail e segredos presentes em arquivos locais precisam ser revisados. A validação final deve confirmar ausência de tarefas agendadas maliciosas, túneis não autorizados, processos em modo servidor, conexões de C2 por nuvem e ferramentas de propagação local como LocalPlugX.

  • Isolar hosts com sinais de CloudyLoader, LNK suspeito, carregamento lateral de DLL, tarefas agendadas falsas ou túneis VPN não autorizados.
  • Correlacionar EDR, e-mail, proxy, DNS, autenticação, logs de nuvem e telemetria de rede para reconstruir o fluxo de acesso inicial e persistência.
  • Restringir execução de atalhos LNK recebidos por e-mail e aumentar inspeção de anexos RAR e ZIP usados como isca.
  • Aplicar controles contextuais sobre Yandex Cloud, armazenamento Yandex, Microsoft OneDrive e plataformas externas usadas como canal de comando ou exfiltração.
  • Rotacionar credenciais associadas a hosts afetados, caixas de e-mail e serviços internos após delimitação forense.
  • Revisar tarefas agendadas, processos escutando conexões, ferramentas P2P, backdoors Linux e comunicação periódica com plataformas externas antes de encerrar o incidente.