Adapte-se ou pague o preço: uma análise do framework AdaptixC2

Introdução

Conforme destacado na nossa postagem anterior sobre o framework Mythic, os threat actors estão adotando rapidamente tecnologias e frameworks emergentes. Um excelente exemplo dessa tendência é o AdaptixC2, um framework de pós-exploração de código aberto desenvolvido há pouco tempo que logo chamou a atenção da comunidade de segurança ofensiva. Sua popularidade decorre de sua natureza de código aberto e alta extensibilidade; o framework é compatível com BOFs (Beacon Object Files), incluindo os assíncronos, e apresenta um ecossistema crescente de módulos, extensões e coleções BOF de terceiros. Estamos observando o uso crescente do AdaptixC2, especialmente em ataques de APT e campanhas de ransomware, os quais relatamos com frequência.

Para encobrir seus rastros, o AdaptixC2 emprega diversas técnicas de comunicação de rede e pós-exploração projetadas para burlar as ferramentas de monitoramento de tráfego, como soluções de IDS e NDR. Apesar do uso dessas táticas de evasão, a detecção no nível da rede continua sendo um dos métodos mais eficazes para identificar a presença e a atividade do agente, pois muitas das técnicas de pós-exploração baseadas em host do framework visam dificultar a análise forense baseada em artefatos. Como consequência, medidas defensivas padrão podem ficar aquém do necessário, tornando necessário um monitoramento avançado de endpoint que use soluções de EDR.

Este artigo apresenta formas de detectar o framework AdaptixC2 analisando seu tráfego de comando e controle e atividade no endpoint.

O framework AdaptixC2

O AdaptixC2 é um framework de comando e controle (C2) projetado para pós-exploração e interação furtiva com seus agentes maliciosos implementados em sistemas comprometidos. Ao contrário de muitas plataformas C2 de uso geral, o foco do AdaptixC2 é a comunicação avançada do agente com C2 e o uso de técnicas de evasão específicas projetadas para burlar ferramentas de segurança modernas, incluindo soluções de EDR e NDR.

Ele foi escrito em Go e C++ e sua arquitetura se baseia em um modelo que separa o componente do lado do servidor dos agentes implementados nos hosts comprometidos. Essa abordagem permite o gerenciamento centralizado do agente, o rastreamento da execução do comando e a realização de atividades de pós-exploração. A flexibilidade das comunicações de rede e a capacidade de modificar os canais de comunicação são aspectos que ganham destaque. Isso permite que o comportamento do agente seja adaptado a ambientes específicos e dificulta a detecção por ferramentas de monitoramento.

O framework fornece flexibilidade para o desenvolvimento de agentes personalizados, ao mesmo tempo em que inclui implementações do agente padrão em Go e C++ para Windows, macOS e Linux.

Além disso, possibilita uma abordagem modular para expandir sua funcionalidade. Os recursos podem ser adicionados na forma de módulos que usam BOFs. Essa abordagem permite que os operadores implementem novos recursos de pós-exploração sem recompilar o agente principal. Também agiliza o desenvolvimento e a integração de módulos personalizados.

Do ponto de vista da equipe de defesa, a atividade do AdaptixC2 pode aparecer em vários estágios de comprometimento de uma infraestrutura. Ela se alinha com várias fases da cadeia de ataque unificada e mapeia várias táticas e técnicas do MITRE ATT&CK, principalmente aquelas associadas ao controle de sistemas comprometidos, execução de comandos e manutenção de um canal C2 persistente.

• As técnicas de comando e controle (TA0011) envolvem estabelecer e manter a comunicação entre o operador e os hosts comprometidos para transmitir comandos, recuperar saídas e monitorar o status do agente. O AdaptixC2 oferece um conjunto diversificado de métodos de comunicação C2.
• O acesso a credenciais (TA0006) é a tática de coleta de credenciais. O AdaptixC2 Extension Kit implementa um amplo conjunto de métodos para obter credenciais, desde o dump padrão do LSASS até técnicas de exploração de ADCS mais sofisticadas e ataques baseados em Kerberos.
• A evasão de defesa (TA0005) é a tática projetada para burlar a detecção pelos controles de segurança. O AdaptixC2 apresenta um kit de ferramentas sofisticado de métodos avançados para implementar essa tática.
• O movimento lateral (TA0008) designa métodos que permitem que o adversário se mova dentro da infraestrutura alvo. Destes, o AdaptixC2 é compatível com PsExec e WinRM.

Neste artigo, direcionamos nosso foco para além da detecção da comunicação de rede a fim de examinar os métodos de detecção da atividade do agente nos endpoints.

Indicadores de rede do AdaptixC2

No momento da redação deste artigo, o AdaptixC2 é compatível com a transmissão de dados por meio dos protocolos HTTP/S, TCP/mTLS, SMB, DNS e DoH.

O framework apresenta duas abordagens distintas para a comunicação:

• Externa (egressa): os agentes se comunicam diretamente com o servidor de C2 usando HTTP/S, TCP e DNS/DoH.
• Interna (P2P): os agentes se comunicam com os agentes adjacentes, estabelecendo uma cadeia de volta para um host que interage diretamente com o servidor de C2. Essa abordagem usa TCP e SMB.

Egressa (comunicações externas)

A comunicação direta entre o agente e o servidor é facilitada pelos seguintes protocolos:

• HTTP(S)
• TCP
• DNS

Da lista fornecida, o HTTP é o protocolo mais comum para a comunicação do agente com C2. O TCP é menos prevalente, enquanto o módulo de transporte DNS apresenta vários problemas técnicos e raramente é utilizado. Apesar disso, examinaremos a implementação do transporte DNS e destacaremos os principais fatores que facilitam a detecção da atividade do agente no tráfego de rede.

HTTP

Devido à alta presença do HTTP, o tráfego de rede do agente pode se misturar ao fluxo de solicitações HTTP comuns. Além disso, configurar o lado do servidor do ouvinte HTTP com os princípios de OPSEC em mente permite que essa atividade seja mascarada como tráfego de rede legítimo, reduzindo significativamente a probabilidade de detecção.

O servidor identifica o agente por um valor exclusivo transmitido em um cabeçalho de solicitação HTTP, conhecido como cabeçalho de sinais de verificação. Esse valor está vinculado ao ID do agente e a outros dados técnicos que o agente precisa para funcionar. Antes da transmissão, esses dados são criptografados com o algoritmo RC4 e, em seguida, codificados em Base64. A chave de criptografia é gerada novamente sempre que um servidor HTTP é criado.

Por padrão, o cabeçalho que contém esse valor é denominado X-Beacon-Id. Esse nome é definido automaticamente, mas pode ser alterado, se necessário.

Outro parâmetro padrão é o cabeçalho User-Agent. Seu valor inicial é:
Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0.

Abaixo está um exemplo de tráfego de rede do AdaptixC2 por HTTP, utilizando valores de campo padrão.

O valor User-Agent usado aqui não é exclusivo e pode ser encontrado no tráfego de rede legítimo. O cabeçalho X-Beacon-Id serve como um indicador de rede mais distinto que pode apontar para a presença do framework AdaptixC2.

O agente criptografa o payload usando o algoritmo RC4 e o transmite dentro do corpo de uma solicitação POST. Devido a essa criptografia, o conteúdo da solicitação não pode ser descriptografado sem a chave correspondente; como consequência, geralmente é difícil criar uma lógica de detecção confiável apenas com base nesses dados.

A captura de tela a seguir mostra como o módulo NDR no Kaspersky Anti Targeted Attack detecta a comunicação entre o agente e o servidor por HTTP quando cabeçalhos padrão são usados. Essa atividade aciona um alerta Backdoor.AdaptixC2.HTTP.C&C.

O framework também permite a personalização do cabeçalho de sinais de verificação, permitindo que o operador atribua a ele qualquer nome arbitrário. Por exemplo, identificamos amostras que imitam tokens de autorização e identificadores usados por plataformas populares.

Abaixo está um exemplo de tráfego de rede do AdaptixC2 por HTTP usando cabeçalhos personalizados.

Dadas as restrições de caracteres permitidos nos cabeçalhos HTTP e considerando que o conteúdo do X-Beacon-Id consiste em dados codificados em Base64, uma regra baseada em assinatura pode ser desenvolvida para detectar solicitações iniciadas pelo agente por meio desse protocolo. Além disso, a lógica de detecção pode incorporar condições relativas à ordem específica e à presença de cabeçalhos HTTP, bem como a frequência dessas solicitações. Nesse cenário, a implementação de regras para os métodos GET e POST seria apenas um pouco diferente, mantendo todas as técnicas descritas anteriormente.

A combinação desses indicadores permite desenvolver um mecanismo de detecção capaz de identificar a atividade do agente mesmo quando ele tiver sido personalizado e mascarado como uma fonte de tráfego de rede legítimo.

Abaixo está um exemplo de tráfego de rede do agente AdaptixC2 encontrado utilizando HTTP com cabeçalhos personalizados. Aqui, o X-Beacon-Id é transmitido no campo Cookie, enquanto o User-Agent e o endpoint tentam imitar a atividade legítima do Windows Update.

A resposta do servidor segue uma estrutura padrão e é transmitida no formato JSON, contendo os campos status, data e metrics. O payload está localizado no campo data e é criptografado usando o algoritmo RC4. Os campos restantes quase não são utilizados e servem apenas para criar uma estrutura de resposta plausível.

Essa estrutura imita as respostas de serviços e plataformas que lidam com várias métricas. No entanto, mesmo com essas técnicas de encobrimento, esse formato de resposta pode servir como um indicador de rede bastante confiável. Ele é suscetível à detecção baseada em assinatura, especialmente quando complementado por uma análise de intervalos de comunicação e contagens de pacotes, excluindo plataformas legítimas conhecidas que usam formatos semelhantes.

Com base nas nossas descobertas e nos exemplos fornecidos, a personalização é aplicada com mais frequência no lado do cliente, enquanto as respostas do servidor geralmente permanecem padrão. No entanto, isso também pode ser modificado. O formato de resposta do servidor é limitado apenas pela imaginação do desenvolvedor e pela necessidade de transmitir o payload criptografado por RC4.

Abaixo estão exemplos de tráfego de rede HTTP do agente AdaptixC2 encontrado utilizando uma resposta de servidor personalizada. Em um caso, os campos JSON foram modificados; em outro, eles foram completamente removidos, restando apenas o payload criptografado.

A captura de tela a seguir ilustra como o módulo NDR detecta a comunicação do agente com C2 por HTTP. Nesse caso, o tráfego de rede do agente imita a atividade de serviço legítima e não tem campos padrão. O KATA gera um alerta Backdoor.AdaptixC2.HTTP.C&C.

HTTPS

Os agentes AdaptixC2 também podem interagir com o servidor de controle por HTTPS usando um módulo de transporte dedicado. Nesse caso, os dados transmitidos são criptografados usando TLS, o que complica bastante a análise de conteúdo e reduz a eficácia das abordagens diretas baseadas em assinatura.

No entanto, mesmo com criptografia, essa atividade de rede pode ser identificada por uma combinação de indicadores indiretos associados ao estabelecimento e à manutenção da conexão. Em certos casos, as características específicas da configuração de canal seguro exclusivas do AdaptixC2 servem como fatores adicionais que simplificam a detecção.

Abaixo está um exemplo de detecção do agente AdaptixC2 com base no seu tráfego. Nesse cenário, uma regra foi acionada pelo estabelecimento de uma conexão HTTPS com parâmetros TLS distintos.

TCP

O framework AdaptixC2 também implementa um método para a comunicação do agente com C2 com base no princípio de shell reversa. Essa abordagem burla várias restrições de rede, pois as conexões de saída normalmente são permitidas pelas políticas de segurança. A conexão de shell reversa é estabelecida pelo protocolo TCP: o agente se conecta ao servidor de C2 usando sockets TCP.

Por padrão, depois que o agente inicia a conexão, o servidor de C2 responde com um banner padrão: AdaptixC2 server. Depois que esse banner é recebido, ocorre a inicialização do agente interno, seguida pela troca de dados do serviço.

Abaixo está um exemplo de tráfego de rede TCP em que o servidor retorna o banner padrão.

Se o servidor não reconhecer o agente, ele usa outra resposta padrão: Connection error…. Esses artefatos podem ser identificados pela análise baseada em assinatura do tráfego de rede.

No entanto, os valores podem ser modificados ao criar um ouvinte no lado do operador. Portanto, contar apenas com eles não é uma solução robusta para criar uma lógica de detecção.

Depois que o cliente recebe o banner, toda a comunicação subsequente entre o agente e o servidor de C2 é criptografada usando o algoritmo RC4. Como resultado, o conteúdo do tráfego geralmente é resistente à análise baseada em assinatura. Nesses casos, os seguintes indicadores comportamentais podem indicar uma atividade suspeita:

• Interação do host atípica e nunca antes observada com um servidor externo
• Um fluxo de dados criptografado persistente com alta entropia semelhante aos valores característicos do tráfego criptografado com RC4

Abaixo está uma captura de tela de um alerta do KATA, que detecta a atividade do agente AdaptixC2 no tráfego de rede TCP no modo Egresso.

O módulo de transporte em questão opera por TCP e fornece criptografia de tráfego de forma independente entre o agente e o servidor.

mTLS

Para melhorar a ocultação durante a transmissão de dados por TCP, o AdaptixC2 é compatível com o protocolo Mutual TLS (mTLS). Trata-se de uma versão estendida do protocolo TLS padrão que implementa autenticação mútua. Ao contrário do esquema TLS tradicional que apresenta um processo de autenticação unidirecional (o cliente verifica a identidade do servidor por meio do seu certificado), o mTLS requer que o servidor também solicite e verifique um certificado do cliente antes de estabelecer uma conexão segura.

Devido à verificação mútua de certificados tanto no lado do cliente quanto do servidor, é muito mais difícil interceptar e descriptografar esse tráfego.

Para detectar o payload descriptografado, foram feitas modificações no código do módulo de transporte mTLS, adicionando a capacidade de registrar dados transmitidos antes da criptografia e após a descriptografia.

Abaixo está um exemplo de log contendo a comunicação do agente pelo protocolo mTLS, juntamente com sua seção descriptografada.

A análise do payload transmitido pelo Mutual TLS (mTLS) mostra que ele é idêntico aos dados encontrados em sessões usando módulos de transporte TLS e TCP. A estrutura de comando, o formato de encapsulamento de dados e os algoritmos de criptografia permanecem consistentes, seja qual for a camada de transporte subjacente.

No entanto, a implementação da autenticação mútua (mTLS) limita bastante a eficácia das ferramentas de monitoramento de rede na detecção da atividade do agente. Quando a descriptografia do tráfego no nível da rede não é viável, a identificação da atividade do agente se torna um desafio e, como regra, só pode ser realizada usando soluções de EDR no endpoint.

DNS

O AdaptixC2 permite a transmissão de dados e comandos do C2 por meio do DNS tradicional sobre UDP e do DNS sobre HTTPS (DoH).

Esse método de comunicação permite o encobrimento do canal de comunicação entre o agente e o servidor. Ao usar o DNS padrão sobre UDP, o payload é encapsulado em solicitações de resolução de nome de domínio legítimas; no modo DNS sobre HTTPS, a troca de dados ganha um disfarce a mais como tráfego HTTPS de rotina.

DNS sobre UDP

O DNS sobre UDP é um protocolo padrão para a resolução de nomes de domínio muito utilizado pelos atacantes para estabelecer canais de comunicação secretos.

No AdaptixC2, esse protocolo serve como o principal transporte para o Beacon DNS. Ele facilita a entrega de comandos e a transferência de dados coletados entre o agente implementado em um sistema comprometido e o servidor de C2, que neste caso é o servidor DNS autoritativo para o domínio associado.

O Beacon DNS é compatível com quatro operações principais, que são identificadas de forma inequívoca pelo segundo elemento (da esquerda para a direita) dentro da estrutura de solicitação DNS.

Cada tipo de operação recebe um identificador de string específico:

• Inicialização (www/hi): registro do agente com o servidor de C2 e o handshake inicial
• Transferência de dados (cdn/put): envio de fragmentos de dados (por exemplo, saída de comando ou dados exfiltrados)
• Recuperação de dados (api/get): download de tarefas, comandos e configurações do servidor
• Sinal de verificação (hb): manutenção da atividade da sessão, sondagem periódica por tarefas pendentes e confirmação de downloads de dados bem-sucedidos

Apesar das diferenças na lógica de processamento, todos os tipos de pacotes aderem a uma estrutura de nome de domínio unificada e hierárquica. Cada subdomínio delimitado por pontos tem uma semântica estritamente definida e é interpretado pelo handler correspondente no servidor de C2. A captura de tela abaixo mostra um fragmento do tráfego do agente usando o protocolo DNS.

O pacote inicial executa a inicialização do agente usando o identificador de operação www. As solicitações subsequentes mantêm a comunicação entre o agente e o servidor usando o identificador hb.

A análise do tráfego de rede revela solicitações DNS anômalas com uma estrutura de subdomínio hierárquica distinta.

No dump de pacotes fornecido, as solicitações DNS seguem este formato:

Vamos nos aprofundar na estrutura de um pacote de inicialização usando um exemplo específico:

Decomposição de campo:

• ID de sessão (base[0]): um identificador de sessão exclusivo de 8 bytes (neste exemplo, 39912991). É usado para identificar todas as solicitações de um agente específico em uma única sessão.
• Identificador de operação (base[1]): especifica o tipo de operação, como registro do agente, ocorrência de sinais de verificação ou processamento da tarefa. É representado como uma string ASCII.
• Número de sequência (base[2]): um número de sequência do pacote de 8 bytes, criptografado usando XOR. Serve como uma defesa contra ataques de repetição, garantindo que cada solicitação permaneça exclusiva, mesmo quando os dados são idênticos.
• Não usado (base[3]): este campo não é utilizado pelo handler.
• Dados criptografados (base[4]): o payload, codificado em Base32 e criptografado com o algoritmo RC4. No pacote de inicialização, esse campo contém dados críticos: informações do sistema operacional (versão, build e arquitetura x86/x64), o nome do processo que hospeda o agente, o nome do host, as credenciais do usuário, as informações do ambiente de rede e muito mais.

Essa estrutura de solicitação DNS exibe várias características típicas do tunelamento DNS:

1. Alto aninhamento de subdomínio: uma solicitação contém mais de oito níveis de subdomínio, o que é atípico para tráfego DNS legítimo.
2. Alta entropia de nome: os subdomínios consistem em sequências de caracteres pseudoaleatórias, como strings hexadecimais ou encoding semelhante à Base32/Base64.
3. Encoding de dados estruturados: subdomínios como 2HNLIUOKKYKFYML3KIJDPOBHLO67TE5PKSWA indicam o uso de algoritmos de encoding para encapsular um payload.

Essa técnica permite que os atacantes burlem os controles de segurança de perímetro tradicionais, pois o tráfego DNS (porta 53/UDP) quase nunca é submetido à inspeção profunda de pacotes e normalmente é permitido para conexões de saída por padrão.

O uso de literais de strings como www, cdn, api e hb, combinado com uma hierarquia de subdomínio estritamente estruturada e comprimentos de campo previsíveis, cria um indicador de rede distinto para identificar a atividade do agente. Indicadores adicionais de comprometimento incluem o que mencionamos acima: nomes de domínio com comprimento longo anormal (mais de 100 caracteres) junto com alta entropia de subdomínio, um número excessivo de níveis de aninhamento (mais de cinco subdomínios) e a frequência de solicitações, como sinais de verificação periódicos direcionados ao mesmo domínio.

A combinação dessas características permite a detecção eficaz de agentes AdaptixC2 que utilizam DNS sobre UDP como canal de comando e controle e exfiltração de dados.

A captura de tela a seguir mostra como o módulo NDR detecta a comunicação entre o agente e o servidor realizada através do protocolo DNS. Essa atividade aciona um alerta Backdoor.AdaptixC2.DNS.C&C.

DNS sobre HTTPS

Para implementar o Beacon DNS, o agente AdaptixC2 também é compatível com o protocolo DNS sobre HTTPS (DoH). Esse mecanismo encapsula consultas DNS padrão em mensagens HTTP transmitidas por uma conexão TLS segura. Do ponto de vista da análise de rede, o DoH mascara a atividade do agente como tráfego da Web legítimo, dificultando a detecção de ações maliciosas por meio de ferramentas de monitoramento projetadas para analisar o tráfego não criptografado.

Abaixo está uma captura de tela do tráfego de rede durante a inicialização do agente, exibida sem a descriptografia TLS.

O tráfego de rede gerado pelo agente revela não apenas conexões com o servidor de C2, mas também tentativas de resolução de nomes por meio de resolvedores públicos confiáveis especificados durante a fase de criação do agente. Em especial, o tráfego analisado inclui consultas DNS direcionadas aos seguintes resolutores públicos:

• https://dns.google/dns-query
• https://cloudflare-dns.com/dns-query
• https://dns.quad9.net/dns-query

O uso desses serviços permite que os atacantes ocultem o tráfego malicioso dentro do fluxo geral de solicitações legítimas para serviços de infraestrutura populares.

Ao criar um agente, o User-Agent padrão usado é Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0. Vale destacar que o Firefox versão 20.0 está obsoleto e era compatível com sistemas operacionais como Windows 7/8, Windows Server 2003 e Windows XP.

Depois de descriptografar a sessão TLS, a estrutura do pacote é exibida da seguinte forma:

Características da operação do agente via DoH:

1. Método de transmissão: o método POST é usado para enviar consultas DNS pelo mecanismo DoH.
2. Cabeçalhos de conteúdo: a presença dos dois cabeçalhos, a saber, Content-Type: application/dns-message e Accept: application/dns-message, está em conformidade com a especificação RFC 8484 e é uma característica do tráfego DoH.
3. Estrutura do payload: o texto da solicitação POST replica totalmente a estrutura dos pacotes de DNS sobre UDP. A string de subdomínio de alta entropia (codificada em Base32 e, em seguida, criptografada em RC4) é transmitida sem modificações e é encapsulada em uma mensagem DNS binária, que é então transportada na solicitação HTTPS.

Apesar do uso da criptografia HTTPS, a implementação do DoH no AdaptixC2 apresenta vários indicadores de rede estáveis que permitem uma detecção eficaz. Esses indicadores incluem o uso da versão obsoleta do Firefox no cabeçalho User-Agent, solicitações POST regulares para o endpoint /dns-query e uma estrutura de nome de domínio repetitiva com comprimentos de subdomínio previsíveis. Juntas, essas características formam um perfil comportamental distinto do tráfego DoH do agente AdaptixC2.

A imagem abaixo exibe a interface KATA com um alerta que detecta a atividade do agente AdaptixC2 durante sua inicialização via DNS sobre HTTPS usando a descriptografia de tráfego. A regra Backdoor.AdaptixC2.HTTP.C&C foi acionada.

P2P (comunicação interna)

O AdaptixC2 oferece recursos de pivoting por meio de pipes SMB nomeados e sockets TCP. Para identificar a atividade do agente no modo P2P, examinaremos seu tráfego de rede e destacaremos os recursos e padrões específicos que permitem a detecção dessas ações maliciosas.

SMB

Para estabelecer a comunicação entre os agentes por meio do protocolo SMB, o framework utiliza pipes nomeados. O nome do pipe pode ser personalizado para qualquer valor quando o ouvinte é criado.

As mensagens transmitidas entre os agentes são criptografadas usando o algoritmo RC4, tornando seu conteúdo resistente à análise baseada em assinatura. No entanto, durante a comunicação SMB, características distintas podem ser identificadas, não apenas nos pacotes em si, mas também na sua sequência e frequência. Essas anomalias permitem detectar a atividade do agente dentro da rede.

A captura de tela abaixo ilustra como uma sessão de estabelecimento de conexão entre agentes aparece no Wireshark.

Durante a inicialização do agente, focamos na seguinte sequência de comandos:

• Resposta GetInfo
• Resposta Ioctl: STATUS_BUFFER_OVERFLOW
• Resposta de leitura

Desses comandos, a Resposta de leitura está diretamente relacionada à atividade do agente. A resposta contém o tamanho do pacote subsequente como um único DWORD (4 bytes), variando de 100 a 140 em decimal. O pacote a seguir contém informações técnicas para o registro do agente, criptografado com RC4. Abaixo está um exemplo de uma Resposta de leitura.

Individualmente, esses comandos não são muito relevantes; no entanto, sua ordem estrita e o posicionamento no início do fluxo de dados SMB são elementos-chave para a lógica de detecção.

Outra característica comportamental da comunicação usando esse transporte é o tráfego gerado enquanto o agente está ocioso. A cada N segundos, o agente verifica se há novos comandos lendo o pipe nomeado.

A frequência dessas verificações de comandos por SMB é herdada do intervalo de consulta do módulo de transporte principal no modo Egresso, por meio do qual os comandos são retransmitidos ao servidor de C2. Dependendo dos valores de Sleep e Jitter, essas solicitações serão executadas em intervalos variados.

Se o agente estiver ocioso e nenhum comando estiver presente, seu tráfego com o agente principal será exibido da seguinte forma:

A estrutura da Ioctl Request é apresentada abaixo:

Dado o tipo de solicitação específico e as flags de protocolo características (Comando: Ioctl (11), Function: FSCTL_PIPE_PEEK), bem como a sequência de pacotes estrita durante o modo ocioso, a atividade do agente AdaptixC2 no transporte SMB pode ser identificada usando métodos baseados em assinatura.

A imagem abaixo mostra a interface KATA com um alerta que detecta a operação do agente AdaptixC2 no modo P2P pelo protocolo SMB. Nesse caso, a regra foi acionada ao detectar a atividade do agente durante sua fase de inicialização.

TCP

Além dos canais de comunicação nomeados, o AdaptixC2 fornece a capacidade de fazer pivoting por TCP.

Esse transporte é baseado em sockets TCP brutos e implementa um modelo de transmissão de dados cliente-servidor. Para dificultar a detecção, o framework permite um parâmetro Prepend data: dados personalizados que devem ser adicionados no início de cada mensagem do agente.

Na configuração padrão, a porta é definida como 9000 e o Prepend data é previamente preenchido com um valor de \x12\xabSimple\x20word\xa. No entanto, é impossível criar um ouvinte com esse valor específico, pois ele aciona um erro de sintaxe. Como consequência, encontrar um payload utilizando esse valor de Prepend data padrão é impossível em um cenário do mundo real.

Além disso, a análise revelou que esse campo não é realmente utilizado pelo agente durante a comunicação e não tem impacto funcional no fluxo de tráfego.

A captura de tela abaixo mostra o tráfego de rede durante a inicialização do agente e a comunicação subsequente.

Consistente com o comportamento de transporte SMB, a primeira mensagem transmite o comprimento dos dados, normalmente variando de 100 a 140 em decimal, como um DWORD big-endian (de 4 bytes). Esse valor representa o tamanho do pacote seguinte, que contém os metadados de serviço do agente. Toda a comunicação entre os agentes é criptografada usando o algoritmo RC4, tornando-a resistente à análise de assinatura baseada em conteúdo.

Apesar disso, vários recursos característicos podem ser identificados, indicando uma alta probabilidade de atividade do agente AdaptixC2 por TCP. Isso envolve não apenas os pacotes individuais, mas também sua sequência específica dentro do fluxo de dados.

Um dos principais métodos para detectar a atividade do agente é identificar a comunicação de rede entre hosts internos na porta 9000, que é usada por esse transporte por padrão. Além disso, a própria estrutura de troca de dados é muito reveladora, pois contém elementos idênticos aos encontrados no protocolo SMB: o tamanho característico do pacote inicial e seu valor contido, o algoritmo de criptografia usado e a sequência de mensagens. Todas as comunicações subsequentes seguem um padrão semelhante, com a exceção de que as restrições do pacote de payload são flexibilizadas para acomodar o conjunto diversificado de comandos e seus tamanhos de saída correspondentes.

A captura de tela abaixo ilustra o processo de inicialização do agente seguido pela transmissão de vários comandos.

Ao considerar essas características específicas, é possível construir uma assinatura de streaming capaz de detectar a atividade do agente após a execução de apenas alguns comandos.

A imagem abaixo mostra a interface KATA com um exemplo de um agente AdaptixC2 sendo detectado no modo P2P por TCP, usando uma regra baseada na lógica descrita acima.

Em resumo, os indicadores baseados em rede permitem a detecção efetiva do AdaptixC2 durante a fase de interação entre um agente, sua infraestrutura C2 e outros agentes. No entanto, os recursos de detecção não estão limitados a isso. O endpoint continua sendo uma fonte crítica de telemetria, onde a execução de módulos específicos e comportamentos típicos de pós-exploração podem ser identificados. Da mesma forma, a próxima seção se concentrará na análise da atividade do agente no host e nas oportunidades de detecção fornecidas pelas soluções de EDR.

Detecção de atividade pós-exploração usando módulos AdaptixC2 como exemplo

Vamos examinar os recursos do agente AdaptixC2 usando uma cadeia de ataque pós-exploração típica como exemplo. Essa cadeia reflete os cenários mais comuns da progressão de um ataque em um host comprometido, que pode servir como base para a criação da lógica de detecção. Observe que as ações descritas abaixo podem servir como indicadores não apenas do AdaptixC2, mas também de outras atividades de pós-exploração na infraestrutura.

Acesso a credenciais

Depois de obter acesso a um host, os atacantes normalmente precisam de credenciais. Para obtê-las, eles podem empregar vários módulos AdaptixC2. Vamos considerar os cenários mais prováveis para sua aplicação.

Se o atacante tiver as permissões necessárias, ele poderá executar um ataque no sistema LAPS para obter acesso ao atributo que armazena a senha da conta do administrador local.

Essa atividade pode ser detectada monitorando as solicitações de acesso aos atributos do Active Directory relacionados ao LAPS, pois eles armazenam senhas locais gerenciadas e informações administrativas relativas à sua rotação. O acesso não autorizado a tais informações pode indicar uma tentativa de obter credenciais privilegiadas.

O Kaspersky EDR (KEDR) Expert detecta essa atividade usando as seguintes regras: computer_discovery_via_ldap, laps_passwords_scan_via_ldap e not_signed_process_ldap_request.

Além disso, para obter acesso às credenciais, um atacante pode tentar extrair informações confidenciais diretamente da memória do processo lsass.exe. Esse processo é responsável pela autenticação e armazena temporariamente hashes de senha, tíquetes Kerberos e outras credenciais usadas pelo sistema para autenticar usuários e serviços. Esse tipo de atividade em um host comprometido é quase sempre acompanhado pela abertura do processo com direitos de acesso elevados, utilizando mecanismos de dump de memória ou chamando APIs do sistema para ler regiões de memória protegidas. Essas ações são anômalas para a maioria dos processos do usuário e do aplicativo e servem como um forte indicador de comprometimento do sistema.

Portanto, para detectar essa atividade, o monitoramento deve se concentrar nos processos que acessam a memória do lsass.exe, pois esses eventos identificam ações maliciosas com alta precisão.

O Kaspersky EDR (KEDR) Expert detecta essa atividade usando a regra suspicious_lsass_memory_access.

Além disso, os atacantes podem tentar extrair credenciais de seções do registro que armazenam parâmetros de autenticação, dados em cache e valores de configuração que afetam a operação dos mecanismos de segurança. Em conjunto, essas ações podem levar ao subsequente escalonamento de privilégios ou movimento lateral dentro da rede.

Para identificar essa atividade, é necessário monitorar o acesso a seções de registro críticas. Isso permite o rastreamento de solicitações originadas de processos atípicos ou suspeitos.

O KEDR Expert detecta essa atividade usando a regra registry_key_sam_users_queried.

Um dos métodos mais comuns para obter credenciais envolve acessar diretórios que contêm dados do usuário do navegador. Os navegadores modernos armazenam uma quantidade significativa de informações confidenciais nos perfis locais, incluindo logins e senhas salvos, cookies de sessão, tokens de autenticação, histórico de navegação e dados de preenchimento automático de formulários. Ao obter acesso aos diretórios de perfis, um atacante pode extrair credenciais para serviços da Web corporativos, sistemas de e-mail e plataformas em nuvem, bem como usar cookies de sessão ativos para burlar os mecanismos de reautenticação e MFA.

Em alguns casos, esses dados são protegidos por ferramentas do sistema operacional; no entanto, quando acessado dentro do contexto do usuário ou com privilégios elevados, eles podem ser descriptografados e utilizados para prolongar o ataque. A obtenção de acesso aos dados do navegador geralmente serve como ponto de partida para o movimento lateral, o comprometimento de contas adicionais e o estabelecimento da persistência na infraestrutura.

Para detectar essa atividade, é necessário monitorar o acesso aos diretórios que contêm dados confidenciais do navegador. É importante considerar não apenas o acesso aos catálogos de perfis em si, mas também a natureza das operações executadas: leitura em massa de arquivos do banco de dados, cópia desses arquivos para diretórios temporários, criação de arquivos comprimidos e inicialização de processos que normalmente não interagem com perfis de usuário.

Deve ser dada atenção especial aos casos em que essas ações são executadas fora de uma sessão interativa do usuário, por exemplo, com base no contexto de processos com privilégios elevados ou contas de serviço. Isso pode indicar uma tentativa de coleta centralizada de credenciais. A correlação de eventos de arquivo com a atividade de rede também é útil, pois os dados extraídos geralmente são preparados para exfiltração para recursos externos.

O KEDR Expert detecta essa atividade usando a regra credencials_from_web_browsers.

Além disso, a aquisição de credenciais também depende bastante de ataques ao protocolo Kerberos. Configurações incorretas nesse mecanismo de autenticação podem permitir que um atacante obtenha acesso a contas com privilégios elevados, criando as condições para a progressão do ataque. O AdaptixC2 é compatível com módulos especializados projetados para explorar recursos específicos do protocolo Kerberos.

Para identificar essa atividade, a auditoria do Active Directory para Kerberos deve ser configurada de forma correta. Isso permite a detecção de ataques analisando os eventos de segurança do Windows, especificamente os IDs de evento 4768 e 4769, que registram a emissão e o uso de tíquetes de autenticação.

O KEDR Expert detecta esse comportamento por meio da regra possible_asreproasting_via_preauth_value.

Evasão de defesa

Durante operações maliciosas, os atacantes procuram minimizar artefatos suspeitos para evitar controles de segurança. Uma técnica comum para conseguir isso é injetar código malicioso no espaço de endereço de um processo legítimo.

Como consequência, o payload é executado sob a identidade de um sistema ou processo do usuário confiável, dificultando a detecção por mecanismos de segurança baseados em assinatura e comportamentais.

Para detectar essa atividade, a equipe de defesa deve monitorar o uso de funções da WinAPI frequentemente associadas à injeção de processos. Isso inclui chamadas que permitem obter acesso a um processo remoto, alocar memória dentro do seu espaço de endereço, escrever código arbitrário e iniciar a execução.

Essas ações geralmente ocorrem em sequência, formando uma cadeia característica: abrir um processo alvo, alocar memória, gravar dados e iniciar uma nova thread ou modificar o contexto de execução. Essas sequências, especialmente quando ocorrem entre processos com privilégios ou níveis de confiança diferentes, são fortes indicadores de uma tentativa de injeção de processo.

Outra flag é quando um processo de usuário padrão inicia essas operações em relação a processos do sistema ou processos legítimos de uso amplo. Os atacantes preferem essa abordagem para mascarar atividades maliciosas e contornar as camadas de defesa tradicionais.

Movimento lateral

A progressão adicional de um ataque quase sempre envolve o movimento lateral dentro da rede, um recurso totalmente integrado ao AdaptixC2.

Vamos examinar as técnicas de detecção de movimento lateral usando a exploração do serviço WinRM (Gerenciamento remoto do Windows) como exemplo principal.

Para detectar essa atividade, a equipe de defesa deve monitorar os processos característicos do WinRM, pois eles facilitam a execução remota de comandos. Normalmente, os processos que gerenciam as sessões do WinRM atuam como processo principal para quaisquer novos processos iniciados por meio do gerenciamento remoto. Como resultado, os comandos executados por meio do WinRM geram processos secundários que podem parecer ter sido iniciados localmente, mas sua árvore de processos revela um processo principal vinculado à infraestrutura do WinRM. Essa cadeia específica é um artefato crítico para revelar o abuso do gerenciamento remoto.

Além disso, a inicialização de shells de comando, utilitários administrativos ou ferramentas de reconhecimento via WinRM é considerada bastante suspeita, principalmente se esse comportamento for anômalo para o host específico.

O KEDR Expert detecta essa atividade usando a regra suspicious_processes_spawned_by_winrm.

Conclusão

O framework de pós-exploração do AdaptixC2 continua evoluindo e ganhando força. À medida que surgem novos agentes e mecanismos de persistência furtiva, o repertório de técnicas usadas para obter um ponto de apoio, executar funções de comando e controle e mover-se lateralmente também se expande. No entanto, apesar da diversidade de protocolos compatíveis, as comunicações de rede do AdaptixC2 mantêm várias características persistentes. É por isso que as soluções de NDR são eficazes em detectar o agente com base na análise do tráfego de rede. Os produtos Kaspersky fornecem essa funcionalidade no Kaspersky Anti Targeted Attack.

O KATA foi projetado para identificar ameaças modernas na infraestrutura de rede, detectando estruturas comuns de pós-exploração por meio de suas assinaturas de comunicação distintas. Mesmo quando um agente emprega técnicas avançadas de evasão, mascaramento ou ofuscação no endpoint, ele deve manter uma conexão com seu servidor de C2 para receber comandos, exfiltrar resultados e coordenar os estágios de ataque subsequentes. Como consequência, o monitoramento do tráfego de rede continua sendo um método vital e eficaz para descobrir a atividade do AdaptixC2.

Complementando a detecção da camada de rede, é importante fornecer visibilidade às atividades em estações de trabalho e servidores usando uma solução avançada de detecção e resposta de endpoint, como o Kaspersky EDR Expert. Um bundle como esse permite a captura de cadeias de ação específicas de pós-exploração e correlaciona eventos isolados do host em um contexto de ataque unificado. O uso combinado do KATA e do KEDR melhora a abrangência da detecção, identificando as manifestações de rede do framework e as manobras internas do agente. Essa abordagem em multicamadas é essencial para combater ataques modernos sofisticados que dependem de ferramentas de pós-exploração e gerenciamento oculto.

Vereditos da solução da Kaspersky (Kaspersky Anti Targeted Attack)

Backdoor.AdaptixC2.TLS.C&C
Backdoor.AdaptixC2.TCP.C&C
Backdoor.AdaptixC2.SMB.C&C
Backdoor.AdaptixC2.HTTP.C&C
Backdoor.AdaptixC2.DNS.C&C