Project CAV3RN usa Outlook Calendar para C2 e DNS na espionagem

Em um cenário de ameaças persistentes avançadas (APTs), a evolução das táticas de comando e controle (C2) desafia constantemente as defesas corporativas. Recentemente, pesquisadores da Kaspersky GReAT revelaram um novo módulo do framework de ciberespionagem Project CAV3RN, detalhado em artigo publicado na Securelist. A novidade reside no abuso de eventos do Outlook Calendar, acessados via Microsoft Graph, como canal de C2, com um mecanismo de recuperação de configuração via registros DNS AAAA. Esta abordagem furtiva eleva o risco de vazamento de dados ao ocultar o tráfego malicioso em serviços legítimos de nuvem, tornando a detecção extremamente difícil.

Arquitetura do Projeto CAV3RN: Uma Engenharia de Persistência

O Project CAV3RN não é um malware comum; trata-se de um framework modular meticulosamente projetado para operações de espionagem de longo prazo. Desde seu rastreamento inicial em dezembro de 2025, o Kaspersky GReAT observou uma mudança arquitetural significativa em abril de 2026: a transição de uma estrutura de três componentes (downloader, executor, uploader) para uma arquitetura baseada em controlador, com um componente de comunicação dedicado via WebSocket. O novo módulo, AzureCommunication.dll, compilado com .NET Native AOT, representa mais um salto em sofisticação. Ele substitui o componente HTTP/WebSocket anterior, explorando a confiança inerente aos serviços Microsoft 365 para camuflar a exfiltração de dados e o recebimento de comandos.

A engenharia por trás desse módulo é notável. A compilação Native AOT (Ahead-of-Time) converte o código gerenciado em código de máquina nativo, eliminando metadados e a Intermediate Language (IL) que facilitam a engenharia reversa. O módulo expõe uma única exportação, QueryInterface, que aceita strings formatadas de forma similar ao controlador anterior, garantindo compatibilidade retroativa. Essa interface aceita comandos get e send, utilizando um Agent ID de sete caracteres gerado pelo controlador, mas ignorando a URL legada, pois as configurações de destino e credenciais são obtidas de uma configuração interna ou de um arquivo logAzure.txt.

Abuso do Outlook Calendar: O C2 Oculto em Eventos de 2050

O cerne da ameaça está no uso do calendário padrão de uma caixa de correio Microsoft 365 comprometida como um canal de comunicação morto-vivo (dead-drop). Utilizando credenciais de aplicação (Client ID, Client Secret) e um Tenant ID do Microsoft Entra ID, o módulo autentica-se via OAuth 2.0 (client credentials grant) e interage com a Microsoft Graph API. Em vez de empregar um servidor C2 tradicional, os operadores do CAV3RN criam, leem e excluem eventos em uma janela de tempo fixa: 13 de maio de 2050, das 22:00 às 23:00 UTC. Essa data distante no futuro minimiza a probabilidade de os eventos aparecerem em visualizações comuns do calendário, reduzindo a detecção por administradores ou usuários.

O formato dos assuntos dos eventos define sua função:

• Comando do operador: Assunto "Event ID: <agent-id>". O módulo busca o evento, baixa seus anexos (que contêm comandos criptografados) e, após o processamento, exclui o evento para apagar rastros.
• Heartbeat do agente: Assunto "Boss update ID: <agent-id>1500". O sufixo "1500" não faz parte do Agent ID, mas sinaliza que é uma atualização de status, garantindo que o operador saiba que o implante está ativo.
• Envio de resultados: Segue o mesmo padrão de heartbeat, mas com o conteúdo criptografado da saída de comandos no corpo ou anexos do evento.

Essa técnica é particularmente perigosa porque o tráfego para graph.microsoft.com é onipresente em ambientes corporativos que usam Office 365. Firewalls e sistemas de detecção de intrusão (IDS) configurados para inspecionar tráfego SSL/TLS podem não sinalizar essas conexões, já que são TLS 1.2/1.3 padrão com certificados confiáveis da Microsoft. A criptografia assimétrica (RSA) aplicada aos comandos e resultados adiciona uma camada extra de ofuscação, com chaves públicas e privadas embutidas no binário.

DNS AAAA como Mecanismo de Recuperação de Configuração

Um aspecto igualmente engenhoso é o plano de contingência. Se a autenticação no Microsoft Graph falhar ou a validação do tenant não for bem-sucedida, o módulo não tenta se comunicar com um domínio alternativo via HTTP. Em vez disso, ele recorre a consultas DNS do tipo AAAA (registros IPv6) para um host de bootstrap, no caso observado, cloudlanecdn[.]com. O processo de recuperação é dividido em duas fases:

1. Determinação do comprimento do campo: O módulo realiza consultas do tipo .p.<subdomínio>.cloudlanecdn[.]com. A resposta AAAA contém um endereço IPv6 cujos primeiros bytes, interpretados como um inteiro, indicam o tamanho do dado de configuração a ser recuperado.
2. Recuperação dos dados: Em seguida, consultas .q.<índice>.<subdomínio>.cloudlanecdn[.]com são feitas. Cada resposta AAAA carrega um fragmento da configuração (como Tenant ID, Client Secret, etc.) codificado nos 128 bits do endereço IPv6. Os fragmentos são concatenados até que o comprimento total seja atingido.

Se, após um número predefinido de tentativas, a recuperação falhar, o módulo aguarda por uma resposta AAAA sentinela (um valor específico) antes de reiniciar o processo. Esse uso de DNS é extremamente furtivo: consultas DNS são raramente bloqueadas, e o tráfego para resolvedores externos é comum. A codificação de dados em registros AAAA é uma técnica de tunelamento DNS avançada, que pode contornar controles de segurança focados apenas em inspeção de payload HTTP.

Indicadores de Comprometimento (IoCs) e Tabela de Riscos

Abaixo, uma lista de IoCs relevantes identificados na análise, seguida de uma tabela que avalia os riscos associados a essa ameaça:

• Hash do arquivo: AzureCommunication.dll (SHA256 indisponível publicamente, mas recomenda-se monitorar por comportamentos de acesso à Microsoft Graph com User-Agent não padrão).
• Domínio de bootstrap DNS: cloudlanecdn[.]com
• Padrão de consulta DNS: Consultas para subdomínios iniciando com .p. e .q. no domínio acima.
• URLs de API Microsoft Graph: https://graph.microsoft.com/v1.0/organization (validação de tenant), https://graph.microsoft.com/v1.0/users/<UserEmail>/calendar/events (acesso ao calendário).
• Endpoint de autenticação OAuth: https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token
• Arquivo de configuração: logAzure.txt no diretório de trabalho do processo.
• Janela de tempo dos eventos: 2050-05-13T22:00:00Z a 2050-05-13T23:00:00Z.

Conexão com Vazamento de Dados por Aplicativos Maliciosos

O modus operandi do Project CAV3RN ecoa um risco crescente no ecossistema corporativo: o vazamento de dados por meio de aplicativos maliciosos que abusam de permissões legítimas. Assim como esse módulo se passa por um aplicativo Microsoft Entra ID autorizado a acessar calendários, muitos ataques modernos começam com a concessão ingênua de permissões OAuth a aplicativos falsos. Um funcionário pode, por exemplo, instalar um aplicativo de produtividade ou de terceiros que solicita acesso ao Office 365, incluindo leitura e gravação em calendários. Uma vez consentido, o aplicativo pode operar como um canal de exfiltração idêntico ao do CAV3RN, sem necessidade de malware no endpoint.

Para mitigar esse risco, as organizações devem adotar uma política de Zero Trust para aplicativos integrados:

• Revisão rigorosa de permissões: Auditar regularmente as permissões concedidas a aplicativos no portal portal.azure.com (Enterprise applications) e remover aquelas não utilizadas ou excessivas.
• Políticas de consentimento do usuário: Restringir a capacidade de usuários finais consentirem com aplicativos. Permitir apenas consentimento administrador para aplicativos verificados pelo publisher.
• Monitoramento contínuo de atividades suspeitas: Utilizar ferramentas como Microsoft Sentinel ou Defender for Cloud Apps para detectar anomalias, como criação de eventos em calendários em horários incomuns ou por aplicativos recém-autorizados.
• Educação do usuário: Treinar funcionários para reconhecer solicitações de permissão suspeitas e nunca aprovar acesso a dados corporativos para aplicativos não verificados.
• Verificação de vazamentos: Utilizar serviços especializados como a Kzarka para monitorar se credenciais ou dados corporativos já foram expostos em violações anteriores, fechando a porta para ataques baseados em identidade.

Resposta a Incidentes e Proteção Corporativa

Diante de uma ameaça tão evasiva, a resposta a incidentes deve ir além da remoção do binário. As seguintes ações são críticas:

1. Análise de tráfego DNS: Inspecionar logs de DNS em busca de consultas para domínios suspeitos, especialmente aquelas com padrões de subdomínios codificados (.p., .q.). Implementar listas de bloqueio de domínios conhecidos e usar serviços de inteligência de ameaças para identificar domínios recém-registrados com propósitos similares.
2. Revisão de logs do Microsoft Entra ID e Office 365: Procurar por logins de aplicativos com ClientId desconhecidos, especialmente aqueles que acessam https://graph.microsoft.com/v1.0/organization e endpoints de calendário. Alertar sobre a criação de eventos em datas futuras distantes.
3. Isolamento de endpoints: Em caso de confirmação de comprometimento, isolar imediatamente o host afetado. Coletar artefatos como o arquivo logAzure.txt e realizar análise forense de memória e disco.
4. Rotação de credenciais: Revogar imediatamente o segredo do aplicativo Microsoft Entra ID comprometido e forçar a reautenticação de todos os usuários. Resetar senhas de contas potencialmente afetadas.
5. Monitoramento proativo de identidade: Após um incidente, é vital monitorar a superfície de exposição digital. A Kzarka oferece monitoramento contínuo de vazamentos de dados, alertando sobre credenciais expostas que poderiam ser usadas em ataques futuros, como o abuso de aplicativos OAuth.

Conclusão

O novo módulo do Project CAV3RN é um lembrete contundente de que atacantes avançados continuam a inovar, transformando serviços confiáveis em armas. O abuso do Outlook Calendar e do DNS AAAA demonstra um profundo conhecimento das infraestruturas de nuvem e dos pontos cegos de monitoramento. Para as organizações, a defesa deve evoluir na mesma velocidade: controles rigorosos de permissões de aplicativos, monitoramento comportamental e uma postura proativa de segurança de dados são essenciais. Não subestime o poder de um evento de calendário aparentemente inócuo; ele pode ser o vetor silencioso de um vazamento de dados catastrófico.

Perguntas Frequentes (FAQ)

Como o Project CAV3RN usa o Outlook Calendar para C2?

O módulo AzureCommunication.dll autentica-se via OAuth 2.0 com credenciais de aplicação Microsoft Entra ID e interage com a Microsoft Graph API. Ele cria, lê e exclui eventos em uma data futura (2050) no calendário de uma caixa de correio comprometida. Comandos do operador são baixados como anexos desses eventos, e resultados são enviados de volta por meio de novos eventos, tudo criptografado com RSA.

Qual é a função dos registros DNS AAAA nesse ataque?

Se a comunicação via Microsoft Graph falhar, o módulo usa consultas DNS AAAA para um domínio de bootstrap (cloudlanecdn[.]com) para recuperar uma nova configuração. As respostas AAAA codificam o comprimento e os fragmentos dos dados de configuração (como Tenant ID, Client Secret), permitindo que o implante se reconfigure sem depender de HTTP.

Como posso detectar esse tipo de ameaça na minha organização?

A detecção requer monitoramento avançado: analise logs do Microsoft Entra ID em busca de aplicativos desconhecidos acessando a Graph API; monitore consultas DNS para padrões de subdomínios codificados; revise eventos de calendário criados em datas futuras incomuns; e implemente soluções de UEBA para identificar comportamentos anômalos de aplicativos OAuth.

O que devo fazer se suspeitar que meu ambiente foi comprometido?

Isole imediatamente os sistemas afetados. Revogue todas as sessões e segredos de aplicativos Microsoft Entra ID suspeitos. Colete evidências forenses, como o arquivo logAzure.txt. Realize uma varredura completa em busca de outros implantes e reforce as políticas de consentimento de aplicativos. Por fim, monitore proativamente vazamentos de dados com a Kzarka para evitar a reutilização de credenciais expostas.

Proteja sua identidade digital agora. Acesse Kzarka e verifique se seus dados foram vazados em violações recentes.