Detecção eficaz de beaconing de C2

Introdução

Os invasores estão adicionando recursos novos e sofisticados de comando e controle (C2) aos seus malware, que evitam facilmente as defesas estáticas comuns baseadas em assinaturas de IPS ou listas de bloqueio de IP/domínio/URL, utilizando ferramentas de framework de C2 comuns e amplamente disponíveis, como Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver e Merlin. Essas ferramentas fornecem recursos de pós-exploração, incluindo comando e controle, escalonamento de privilégios e ações no host, e foram originalmente projetadas para testes de penetração e operações de red team.

No entanto, os invasores sequestraram e incorporaram esses mesmos kits de ferramentas para fins maliciosos, pois muitos produtos são de código aberto, como Mythic e Merlin, enquanto outros produtos comerciais, como Cobalt Strike e Brute Ratel, foram roubados por invasores por meio de cópias hackeadas ou vazamentos de código-fonte. Na prática, isso transformou essas mesmas ferramentas em frameworks de C2 adversários para pós-exploração maliciosa.

As ferramentas podem facilmente moldar e alterar muitos parâmetros das comunicações de C2, permitindo que o malware evite as defesas atuais com ainda mais facilidade e por períodos mais longos, causando danos maiores nas redes das vítimas, incluindo: roubo de mais dados, descoberta de dados mais valiosos, indisponibilidade de aplicativos/serviços empresariais e manutenção de acesso oculto às redes para causar danos futuros.

As abordagens atuais para detectar o malware mais recente que utiliza frameworks de C2 empregam assinaturas e indicadores estáticos, incluindo a detecção de executáveis de implantes, assinaturas de IPS para detectar tráfego de C2 e filtros de IP/URL, que são inadequados para lidar com os perfis dinâmicos e maleáveis das ferramentas de framework de C2 amplamente disponíveis.

É necessária uma nova abordagem que não esteja tão rigidamente vinculada a ataques conhecidos, mas que seja baseada na detecção de anomalias em um conjunto abrangente de sinais fornecidos a modelos treinados de aprendizado de máquina, com acompanhamento granular do risco de dispositivos e usuários. Essa abordagem complementará as abordagens existentes, mas poderá aumentar drasticamente as taxas de detecção, mantendo baixos os falsos positivos e preparando as defesas para padrões de tráfego de C2 em evolução, facilmente possibilitados por essas mesmas ferramentas de framework de C2.

Este artigo discute as lacunas nas abordagens atuais e o aumento da eficácia obtido com o uso de uma abordagem direcionada de aprendizado de máquina, com sinais adicionais de rede e métricas de risco granulares baseadas em modelos nos níveis do usuário e da organização. Também discutimos alguns dos principais desafios para testar a eficácia de qualquer solução de detecção de beacon de C2.

Frameworks de C2 adversários

Cobalt Strike, Metasploit, Mythic e Brute Ratel são algumas das ferramentas comerciais e de código aberto de simulação de adversários originalmente projetadas para testes de red team relacionados à detecção de malware. Esses kits de ferramentas são algumas vezes chamados de ferramentas de emulação de ameaças ou frameworks de C2, pois fornecem um amplo conjunto de recursos (Gill) para simular atividades reais de ameaças durante operações de red team, com foco nas partes de comando e controle pós-exploração da cadeia de ataque.

Podemos usar alguns desses termos de forma intercambiável ao longo do artigo, mas geralmente utilizaremos frameworks de C2 para enfatizar que essas ferramentas estão sendo usadas por atores maliciosos para afetar ambientes de produção e que o problema a ser resolvido é muito mais amplo do que simulações ou emulações realizadas por red teams internos aliados.

Essas ferramentas de framework de C2 foram incorporadas, hackeadas ou roubadas e usadas por inúmeros invasores (“Cobalt Strike: International law enforcement operation tackles illegal uses of ‘Swiss army knife’ pentesting tool”), incluindo atores de Estados-nação, como o APT29 da Rússia no SolarWinds (“SolarWinds Supply Chain Attack Uses SUNBURST Backdoor”) e o TA415 da RPC (Larson e Blackford), para aprimorar e desenvolver os recursos de comunicação furtiva de diversos RATs, botnets e malware habilitados para C2.

Cobalt Strike é a ferramenta de framework de C2 mais popular, e nós a utilizamos como exemplo específico ao longo deste artigo, embora as observações se apliquem a todas as ferramentas semelhantes. O diagrama de arquitetura de alto nível do Cobalt Strike a seguir mostra seus componentes básicos (Rahman) e o fluxo de ataque em tempo de execução.

Cobalt Strike e kits de ferramentas semelhantes permitem uma configuração fácil e ampla do tráfego HTTP/S, produzindo tráfego de C2 que frequentemente parece benigno, se assemelha a tráfego HTTP/web normal e é semelhante ao tráfego de navegadores ou de aplicativos populares. As ferramentas fornecem configurações padrão que emulam tanto malware conhecidos quanto aplicativos legítimos conhecidos.

Embora DNS também seja compatível como protocolo de C2, concentraremos a discussão no C2 por HTTP/S, pois ele representa a maior parte do tráfego de rede de entrada/saída de uma organização, é mais complexo devido à variedade de aplicativos que utilizam HTTP/S e atrai a maioria dos atores maliciosos que tentam se ocultar em meio ao ruído da rede, incluindo beacons de C2 legítimos e benignos.

Os kits de ferramentas são altamente configuráveis, por meio de perfis maleáveis, e podem variar facilmente o tempo, a frequência, o volume, os protocolos de aplicativos, os IPs/domínios de destino, os agentes de usuário, os cabeçalhos HTTP, os verbos HTTP, os URIs, os parâmetros, os certificados SSL/TLS, o atraso do beaconing com jitter aleatório e a carga útil/o conteúdo. As ferramentas de framework de C2 também permitem um grande número de ações de pós-exploração, que são criptografadas, baixadas e executadas na memória, tornando muito difícil detectar atividades pós-comprometimento nos endpoints.

Concentraremos nossa atenção nos recursos específicos de comunicação de C2 das ferramentas de framework de C2, como o beaconing de C2, na facilidade com que as comunicações podem ser alteradas, por exemplo, por meio dos C2 Malleable Profiles do Cobalt Strike, e nos desafios enfrentados pelas organizações que tentam detectar malware furtivo.

Existem diversos bons recursos que discutem a funcionalidade dos Malleable Profiles do Cobalt Strike (Gill), mas destacaremos alguns dos recursos mais usados. Veja um trecho do perfil maleável para imitar o aplicativo Gmail em um navegador no Cobalt Strike (Mudge):

Algumas das principais funcionalidades e áreas do perfil são:

# Use an existing certificate or generate a self-signed certificate as seen in the above example.

# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime “60000”;
set jitter “15”;

# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename “interprocess_##“;
set spawnto “userinit.exe”;

# The uri path used for beacon->server communications can be varied with a list
set uri “//scs/mail-static//js/”;

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
    metadata {}
    header {}
}

# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
    header {}
}

# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {}    optional stager to download full Beacon
# 1. http-get {client}  client  — call home -> server
# 2. http-get {server}  server  — cmds -> client
# 3. http-post {client} client  — cmd output -> server
# 4. http-get {server}  server  — confirm -> client

Como pode ser observado acima, modificações simples nesses perfis podem alterar facilmente o comportamento das comunicações de C2 para imitar aplicativos comuns, seus beacons e o tráfego web. Existem mais de 240 perfis maleáveis públicos somente para o Cobalt Strike, prontamente disponíveis para uso ou que podem ser facilmente modificados.

Abordagens atuais de detecção

As abordagens atuais para detectar tráfego de C2 malicioso tendem a comparar assinaturas de bytes codificadas de forma rígida ou usar expressões regulares para corresponder à carga útil ou aos cabeçalhos (assinaturas de IPS), ou são baseadas na correspondência com listas de IP/domínio/URL. Essas abordagens são estáticas e facilmente evitadas pela natureza dinâmica e configurável dos kits de ferramentas de framework de C2 incorporados pelos invasores.

Assinaturas de IPS

Para ilustrar os desafios das soluções de IPS, veja uma das regras do Snort para detectar o Trojan Zeus (Snort):

O Snort e muitas soluções de IPS permitem diversas correspondências de conteúdo ou cabeçalhos nas camadas 3 e 4, assim como no nível do aplicativo, conforme indicado pelos verbos de ação na regra. Muitas correspondências, como a opção de regra content, são correspondências estáticas de bytes/caracteres, enquanto a opção de regra pcre é uma correspondência por expressão regular.

Ao observar lado a lado tanto o lado do adversário, por exemplo, o C2 Malleable Profile para gmail visto anteriormente, quanto o lado defensivo, por exemplo, a regra do Snort para Zeus, ficam evidentes a correspondência estática codificada de forma rígida e sua fragilidade. Imagine que um invasor tivesse criado e implantado uma nova variante do Zeus que usasse Cobalt Strike e que um IPS Snort tivesse a regra do Zeus acima em vigor, detectando efetivamente o novo malware. O invasor poderia facilmente alterar um caractere no perfil, como adicionar um espaço em MSIE para evitar a correspondência: content:"|3B 20|MSIE|20|"; assim, o malware poderia evitar a assinatura de IPS.

Embora haja conhecimento contextual e acompanhamento de estado, a abordagem de assinaturas de IPS é inerentemente limitada devido à sua correspondência estática, o que resulta em falsos negativos e evasão fácil — literalmente, alterar um caractere em um campo poderia contornar uma regra de IPS.

Isso não significa que as soluções de IPS não sejam úteis. Pelo contrário, as assinaturas de IPS devem ser mantidas, pois funcionam como uma defesa de perímetro útil, bloqueando muitas explorações de rede conhecidas de forma rápida e eficiente. Nesse caso, mesmo que um IPS alcançasse taxas de detecção de apenas 60%, esses 60% poderiam ser facilmente bloqueados ou gerar alertas, evitando um processamento posterior dispendioso.

Listas de bloqueio de IP/URL

Outras abordagens tradicionais, como o uso de listas de bloqueio de IP ou URL, são frequentemente aplicadas para tentar impedir o acesso inicial ou o download de malware durante a navegação web, assim como para bloquear possíveis tráfegos de C2.

Um desafio comum das listas de bloqueio é que elas frequentemente estão desatualizadas, causando falsos positivos, e são reativas, pois são atualizadas depois do comprometimento do alvo número 1 ou paciente zero.

Isso é agravado pelas técnicas de indireção de IP/domínio usadas para ocultar o domínio ou o endereço IP do servidor de C2. O Cobalt Strike possui redirecionadores, que podem ser tão simples quanto proxies IP, para ofuscar o domínio ou IP verdadeiro do servidor de C2. Também existem outras técnicas, como domain fronting usando CDNs ou mascaramento de domínio, que aproveitam incompatibilidades entre TLS (SNI) e HTTPS (host) para ocultar o domínio malicioso final de alguns filtros de segurança de URL.

Heurísticas de tráfego de rede

Uma abordagem diferente envolve o uso de heurísticas, geralmente aplicadas a padrões de tráfego de rede com base em volume ou tempo. O exemplo clássico é detectar comunicações regulares de saída, por exemplo, a cada 60 minutos, talvez para um endereço IP sem registro DNS A cadastrado.

Para evitar a detecção, os kits de ferramentas de framework de C2 permitem configurar facilmente um fator aleatório no atraso do beaconing por meio da configuração de jitter em um C2 Malleable Profile do Cobalt Strike:

Figura 4: Configurações do C2 Malleable Profile (temporização do beaconing)

Essas configurações especificam um intervalo de comunicação com o servidor de origem de 60 segundos +/- 15%, o que significa que o intervalo real variará de 51 a 69 segundos, evitando verificações simples de beaconing recorrente em intervalos constantes.

Eficácia

O problema das abordagens atuais é que elas não detectam com eficácia comunicações de C2 maleáveis e são facilmente evitadas, mesmo quando ajustadas especificamente. Elas cumprem uma finalidade ao detectar com eficiência técnicas de ataque estáticas com indicadores bem conhecidos, mas não detectam ataques mais dinâmicos ou sofisticados, ou geram um grande número de falsos positivos.

Como um ponto de referência, ao testar os C2 Malleable Profiles mais comuns do Cobalt Strike obtidos de repositórios públicos, soluções de IPS sem ajustes, como Snort e Suricata, detectaram substancialmente menos de 20% das comunicações de C2 dos kits de ferramentas de framework de C2 mais comuns.

Mesmo após adicionar regras especificamente para corresponder ao maior número possível de perfis públicos, otimizando para esse teste específico, a cobertura só poderia aumentar razoavelmente para cerca de 60% sem introduzir falsos positivos significativos, que seriam muito problemáticos em um ambiente de produção.

Existem inúmeros problemas relacionados à eficácia: não apenas falsos positivos mais altos, mas também o fato de a configuração resultante ser rigidamente construída para o teste específico em questão e facilmente evitada por meio de pequenos ajustes nos perfis. E, no fim das contas, cerca de 40% dos perfis continuam sem ser detectados, o que representa uma taxa muito alta de falsos negativos. Isso sem mencionar os falsos negativos adicionais causados por um invasor determinado que personaliza os perfis de C2 para imitar aplicativos conhecidos de uma maneira ligeiramente diferente.

Nova abordagem de detecção

É necessária uma abordagem mais eficaz, baseada não apenas em indicadores estáticos, mas em modelos direcionados de aprendizado de máquina capazes de detectar anomalias no tráfego de rede utilizando uma ampla variedade de sinais de rede que indiquem atividade suspeita de comando e controle, em comparação com o que os aplicativos legítimos normalmente fazem para usuários específicos dentro de uma organização específica. Além disso, métricas de risco granulares devem ser acompanhadas no nível do usuário para oferecer as ações de mitigação mais precisas e eficazes. São necessárias inovações nessas três áreas para alcançar grandes melhorias na detecção de beaconing furtivo de C2 proveniente de ferramentas de framework de C2:

Sinais abrangentes

É necessário um conjunto abrangente de sinais, que deve incluir características da origem, do destino e do tráfego, como certificados SSL/TLS usados tanto na origem (malware dentro do ambiente) quanto no destino (servidor de C2), domínio/IP/URL, características da origem, como agente de usuário/características do processo, tamanho/rajadas/padrões do tráfego, cabeçalhos HTTP/carga útil/URI, para citar apenas alguns.

Ao analisar diversos sinais ao longo do tempo, do volume, das camadas de rede e do perfil geral do tráfego, a detecção comportamental pode fornecer um mecanismo geral e eficaz para detectar o malware mais recente por meio de atividades suspeitas e maliciosas de beaconing de C2.

Existem várias dimensões para os tipos de sinal:

• Fluxo de rede: atributos de origem e destino, assim como padrões de tráfego
• Camadas de rede: diferentes sinais das camadas 3 a 7 (anomalias em cabeçalhos TCP/IP, impressões digitais SSL/TLS, cabeçalhos/cargas úteis HTTP e conteúdo no nível do aplicativo)
• Tempo: frequência e padrões anômalos de temporização para detectar atividades infrequentes e lentas
• Dados: conteúdo e volume (tamanhos anômalos de pacotes, rajadas e estatísticas cumulativas)

Além disso, existem vários tipos de sinal:

• Baseados em padrões de tráfego (volume, temporização, conteúdo), incluindo beaconing repetido em conjunto com um agente de usuário ou domínio incomum.
• Heurísticas (por exemplo, registradores suspeitos ou impressões digitais SSL maliciosas conhecidas)
• Anomalias (domínio, agentes de usuário ou impressões digitais SSL incomuns)

Um ponto importante é que alguns dos sinais acima fazem parte das abordagens atuais e das soluções existentes. Isso reforça que um sinal específico, como um pico de tráfego (grande volume), não é, por si só, bom ou ruim, eficaz ou ineficaz. Em vez disso, o contexto e o processamento do sinal são os fatores determinantes. Quando usado no perímetro de uma rede para bloquear/permitir tráfego, um sinal propenso a falsos positivos pode causar problemas operacionais graves. No entanto, quando fornecido a um sistema de detecção de anomalias que incorpora esse sinal em uma métrica de risco granular, discutida abaixo, e em um modelo bem treinado, ele pode ser extremamente eficaz na detecção robusta de novas ameaças com poucos falsos positivos.

Detecção de anomalias

A detecção eficaz de beaconing de C2 proveniente de kits de ferramentas de framework de C2 requer modelos de aprendizado de máquina baseados em uma variedade mais abrangente de sinais, para identificar os kits de ferramentas de framework de C2 atuais e futuros comportamentos de rede suspeitos que possam indicar atividade de C2.

A detecção de anomalias deve ser baseada em modelos nos níveis de usuário/dispositivo, função e organização. Ou seja, as anomalias pressupõem que tenhamos uma linha de base “normal” válida de atividade ou comportamento para comparação. A detecção de atividades suspeitas pode ocorrer em diferentes circunstâncias. Existem anomalias baseadas nas ações de um usuário em comparação com sua linha de base “normal” histórica, com a linha de base “normal” da organização ou com indivíduos em funções semelhantes. Todas possuem casos de uso válidos e mutuamente exclusivos, e uma boa abordagem incorporará vários modelos com diferentes escopos.

Dados de treinamento

Os conjuntos de dados de treinamento devem incluir tráfego malicioso e benigno:

• Tráfego malicioso pode ser simulado usando ferramentas gerais de teste de C2, testes específicos de beaconing adversário de C2 baseados em configurações publicamente disponíveis de ferramentas de framework de C2, assim como configurações personalizadas de uma perspectiva de red team e exercícios oficiais de red team.
• Tráfego benigno ou tráfego legítimo é melhor coletado de um número significativo de usuários reais em organizações reais durante um período suficiente para normalizar os vieses dos usuários e da organização.

Os conjuntos de dados de treinamento são o outro lado dos conjuntos de dados de teste, e muito tempo deve ser dedicado à análise e validação de bons dados de treinamento e teste. Alguns dos fatores necessários para criar bons conjuntos de dados de teste são discutidos em uma seção posterior.

Métricas de risco granulares

A saída da detecção de anomalias é fundamental. A melhor abordagem não realiza determinações simples de bloqueio/permissão ou alerta/silêncio com base em um sinal bruto. Em vez disso, ela acompanha e ajusta métricas de risco granulares nos níveis de usuário, função e organização, que podem então ser usadas para ações de remediação, como emissão de alertas, orientação ou bloqueio.

Essa abordagem para acompanhar e agir sobre o risco é fundamentalmente diferente do que normalmente é usado atualmente. A maioria das defesas de perímetro preventivas, que normalmente bloqueiam, alertam ou permitem tráfego, geralmente é estática e propensa a altas taxas de falsos positivos. O resultado é que essas soluções são habilitadas com uma política conservadora para bloquear riscos certos e conhecidos, o que gera um grande número de falsos negativos. Com firewalls, observamos problemas de falsos positivos em ações de bloqueio excessivamente agressivas baseadas em inteligência de ameaças de IP. Com soluções de IPS, temos discutido os desafios de falsos positivos das assinaturas estáticas que tentam detectar tráfego de C2 altamente configurável e dinâmico.

Entretanto, falsos positivos em uma camada de perímetro podem ser muito úteis como sinal para uma camada mais inteligente. Nesse cenário, não os usaríamos para uma avaliação binária (permitir/bloquear, alertar/ignorar), mas como uma métrica de risco granular ajustada ao longo do tempo, por exemplo, uma pontuação de risco do usuário, com um limite calibrado antes da tomada de ação. Uma métrica de risco granular — por exemplo, uma pontuação de risco de 1000 (sem risco) a 0 (risco extremo) para um usuário, dispositivo ou até mesmo endereço IP — permite modelar o espectro de cinza associado às ameaças do mundo real, nas quais raramente existem avaliações claramente 100% maliciosas ou 100% benignas.

Conceitualmente, isso é representado na ilustração a seguir, na qual três sinais diferentes podem ser detectados e, isoladamente, estariam sujeitos a falsos positivos. No entanto, quando associados a risco incremental e avaliados por um modelo calibrado de aprendizado de máquina, os mesmos sinais avaliam o risco cumulativo ao longo do tempo e, por fim, fornecem uma detecção de anomalias com alto grau de confiança.

Observe que os sinais desse exemplo podem não ser tão simples quanto sinais estáticos. Por exemplo, um “domínio incomum, agente de usuário não reconhecido e certificado SSL/TLS” poderia ser uma anomalia quando comparado à linha de base “normal” anterior do tráfego daquele usuário específico, às funções profissionais semelhantes de outros usuários ou à organização inteira. Um “registrador suspeito” pode ser uma combinação da reputação do domínio correlacionada ao longo do tempo. E o “beaconing periódico” não é mais uma simples correspondência com uma taxa ou duração fixa; ele pode detectar atividades anormais, porém regulares e repetidas dentro de uma janela de tempo, semelhantes a atividades relacionadas a bots, em oposição às chamadas externas legítimas de daemons de aplicativos.

Na prática, isso permite ajustar uma pontuação de risco de maneira incremental e apropriada com base em um sinal de baixa fidelidade. Nenhuma ação de bloqueio ou alerta é realizada até que a pontuação de risco cumulativa ultrapasse um limite alto e calibrado. Isso permite capturar casos em que há muitos indicadores de baixa fidelidade e ligeiramente arriscados que, quando combinados com um indicador de maior fidelidade e maior risco para determinado usuário ou dispositivo, geram cumulativamente um alerta e uma ação de risco crítico, com uma probabilidade drasticamente menor de falsos positivos.

Avaliação e testes

Uma nova abordagem pode ser teoricamente sólida e, na prática, falhar de forma desastrosa; muitas vezes, a comprovação depende dos dados ou dos testes. Os fornecedores de soluções e as organizações que procuram soluções precisam de uma abordagem robusta para testar novas ameaças e avaliar soluções. Para alcançar resultados precisos, é essencial testar com um conjunto de dados diversificado que inclua tráfego malicioso e benigno.

Tráfego benigno

O tráfego benigno deve ser realista, abrangente e semelhante ao de produção em termos do número de usuários e atividades. Um bom tráfego, muitas vezes dependente do usuário, deve ser estudado em uma grande amostra de usuários e durante um período razoável. Esse conjunto de dados de teste medirá as taxas de falsos positivos (FP). A principal variação nos conjuntos de dados estará nos sinais do cliente, como aplicativos, agentes de usuário e certificados SSL/TLS do cliente em uso; nos sinais de destino observados nos domínios/endereços IP de destino; e nos sinais de padrões de tráfego encontrados nos cabeçalhos, na carga útil, no tamanho e na temporização.

A boa notícia é que um bom tráfego benigno pode ser facilmente coletado das operações diárias dos usuários da organização, enquanto a má notícia é que ele precisa ser validado como benigno. A abordagem prática é realizar uma amostragem estatística do tráfego benigno até obter um determinado fator razoável de confiança e, então, dedicar a maior parte do tempo aos alertas da solução de detecção de C2 em teste, verificando se são verdadeiros positivos ou falsos positivos. Em outras palavras, primeiro devem ser realizadas a amostragem e a verificação para estabelecer uma linha de base; em seguida, pressupõe-se que o conjunto de dados benignos esteja limpo e prossegue-se com a identificação dos falsos positivos com base nos testes.

Tráfego malicioso

O uso de perfis públicos de ferramentas populares de framework de C2 fornece uma base sólida para testar tráfego malicioso. Esses perfis representam configurações práticas e usadas com frequência que evitam as defesas e ajudam a medir as taxas de falsos negativos (FN). No entanto, é necessário considerar cuidadosamente a criação de um conjunto de dados representativo de “tráfego malicioso”, pois potencialmente existem vários níveis de cobertura e de elementos testados pelos conjuntos de dados, conforme ilustrado no diagrama a seguir:

1. Ferramentas de simulação de violação e ataque, como SafeBreach, são excelentes para testes de cobertura e testes repetidos. Seus casos de teste de C2 normalmente incluem pelo menos alguma simulação de atividade de frameworks de C2. A vantagem é a disponibilidade de uma grande variedade de funcionalidades, incluindo ataques gerais de malware, com GUIs e arquiteturas bem projetadas, além de procedimentos de teste e relatórios repetíveis. Essas ferramentas podem fornecer uma ampla variedade de cenários, incluindo: atividades lentas e de baixo volume, infraestrutura de IaaS/CSP, tráfego HTTP e não HTTP, tráfego SSL/HTTPS e falsificação de diversos agentes de usuário.
2. Ferramentas de framework de C2 (perfis públicos). Testes aprofundados de frameworks de C2 exigem trabalho direcionado. Uma abordagem é criar um conjunto de dados de teste com base nos perfis públicos específicos de ferramentas de framework de C2, por exemplo, Cobalt Strike. Esses perfis maleáveis públicos tendem a ser amplamente compartilhados e usados por muitos usuários e atores maliciosos, pois incluem emulações úteis de aplicativos benignos, como gmail. Essa abordagem normalmente fornece testes mais abrangentes dos frameworks de C2 específicos.
3. Ferramentas de framework de C2 (perfis personalizados). A personalização interna dos C2 Malleable Profiles pode fornecer testes ainda mais realistas de frameworks de C2. Essas configurações personalizadas podem ser desenvolvidas durante operações internas de red team. Isso exige mais trabalho e investimento, pois os operadores de red team precisam ter domínio das ferramentas de framework de C2.
4. Ataques realistas. Os testes mais realistas envolvem testes de caixa-preta com programas externos de testes de penetração ou bug bounty. Nesses cenários, os requisitos do exercício são cuidadosamente elaborados para exigir ou incentivar explorações POC reais que utilizem ferramentas específicas de framework de C2 ou qualquer comportamento de beaconing de C2, com a ressalva de evitar a detecção durante um período. Os objetivos dos exercícios não consistem apenas em testar vetores de acesso inicial, como normalmente ocorre, mas em se concentrar na atividade pós-violação, demonstrando a capacidade de instalar uma carga útil de backdoor com atividade de C2 comprovada. Isso enriquece o conjunto de dados de teste para além dos frameworks de C2, pode testar código POC de backdoor com comunicações de C2 personalizadas e também representa um excelente teste da resiliência de qualquer ferramenta de detecção contra um “invasor” qualificado que utilize TTP diferentes ou personalizadas.

Os testes podem envolver uma ou várias abordagens, mas devem ser feitas escolhas explícitas sobre como criar, coletar e validar os conjuntos de dados de teste e como medir os resultados esperados. A criação e a coleta dos conjuntos de dados de teste são muito importantes para que os testes possam ser automatizados e facilmente repetidos.

Também é fundamental medir métricas completas durante os testes: verdadeiros e falsos positivos, verdadeiros e falsos negativos. Embora a coleta de todas as métricas pareça óbvia, é difícil ser preciso na definição e claro e repetível na metodologia de medição, o que pode levar a resultados enganosos.

Metas de falsos positivos e falsos negativos

Com as novas ameaças evasivas criadas por frameworks de C2, qualquer solução de detecção mais recente não terá taxas de FP e FN amplamente aceitas. No entanto, é fundamental criar metas de FP e FN. Com conjuntos de dados de teste de qualidade conhecida, podem ser criadas linhas de base para o ambiente atual e para os usuários/dispositivos, o que permite então definir metas razoáveis em relação a essas linhas de base.

Por exemplo, suponha que uma organização que tenha apenas um IPS esteja iniciando uma avaliação de novas soluções de detecção de C2 e não esteja claro quais taxas de FP/FN são aceitáveis. A organização ainda pode definir metas razoáveis seguindo uma metodologia de teste como esta:

• Criar dados de teste de qualidade para tráfego benigno com base em dados de produção e para tráfego malicioso com base, por exemplo, em perfis maleáveis públicos de C2 para Cobalt Strike, validando manualmente amostras desses conjuntos de dados.
• Criar uma metodologia de teste clara e repetível, definindo ferramentas de teste e medição.
• Medir todas as métricas (TP/TN/FP/FN) durante os testes
• Testar novas soluções e comparar métricas. Por exemplo, o IPS poderia ser ajustado especificamente para obter melhores taxas de TP para o tráfego malicioso, mas garantindo que as taxas de FP/TN/FN também fossem medidas e validadas. Assim, a eficácia de diferentes soluções pode ser avaliada adequadamente, especialmente quanto ao impacto total na organização, conforme descrito na seção Impacto abaixo.
• Testar novos conjuntos de dados e comparar. Procure personalizar os conjuntos de dados para refletir ajustes razoáveis realizados por um invasor. Existem várias maneiras de fazer isso.
  • Por exemplo, ao testar o Cobalt Strike, seus C2 Malleable Profiles podem ser facilmente modificados para emular aplicativos benignos de forma ligeiramente diferente ou aplicativos benignos completamente novos usados na organização específica. Isso pode ser feito por meio da captura do tráfego HTTP/S de saída usando um proxy.
  • Teste não apenas uma, mas várias ferramentas de framework de C2, pois elas diferem em recursos e técnicas. Usar uma ferramenta de framework de C2 diferente também é uma boa alteração, pois a modelagem de seu tráfego de C2 será diferente.
  • Criar uma carga útil de teste personalizada com suas próprias comunicações de C2 codificadas manualmente é outra forma de alterar os conjuntos de dados de teste, mas exige mais tempo e investimento.

Teste de resiliência

Ao testar novos conjuntos de dados em diferentes soluções, também obtemos informações valiosas sobre a rigidez em comparação com a resiliência das diferentes soluções. Neste artigo, levantamos a questão de que abordagens codificadas de forma rígida e baseadas em assinaturas não são apenas menos eficazes na detecção de frameworks de C2, mas também são rígidas, resultando em altas taxas de FP/FN e permitindo contornos fáceis por meio de alterações simples nos ataques, como modificações em perfis maleáveis.

A resiliência de qualquer solução pode ser testada garantindo que os conjuntos de dados sejam modificados de maneira razoável, ou seja, permanecendo na mesma categoria de TTP. Em outras palavras, podemos realizar um teste realista de resiliência alterando as comunicações de C2 no conjunto de dados de tráfego malicioso usando perfis maleáveis de C2 e monitorando as taxas de TP/TN/FP/FN. Observamos como a cobertura varia e também compreendemos quais alterações precisam ser realizadas na solução de detecção para manter a cobertura de determinadas metas de TP/TN/FP/FN.

Repetir os testes com conjuntos de dados alterados dessa maneira é análogo a um invasor alterar suas TTP. Isso avalia a resiliência e a eficácia da nova solução de detecção, pois podemos verificar se ela ainda é capaz de detectar alterações dentro da mesma categoria de técnica de ameaça, ou seja, comunicações de C2 por HTTP/S.

Impacto de falsos positivos e falsos negativos

A medição das taxas de FP/FN é útil e permite melhorias relativas, mas também precisamos medir ou pelo menos estimar o impacto dos FPs e FNs; caso contrário, é impossível avaliar a verdadeira utilidade de qualquer solução de detecção. Em outras palavras, uma taxa de FP de 1% ou uma melhoria de 5% na taxa de FP não tem contexto, a menos que possamos medir o impacto desses 1% ou +5% de alguma forma que faça sentido para os responsáveis pelas decisões de orçamento de segurança.

Estas são duas abordagens que podem ajudar a converter as taxas de TP/TN/FP/FN em um impacto mais quantificável:

1. Impacto sobre o usuário ao longo do tempo: considere o número absoluto de falsos positivos equivalente às taxas de FP e normalize-o como uma taxa por usuário ao longo do tempo. Essa é uma medida qualitativa, mas muitas vezes faz mais sentido do que taxas percentuais ou números absolutos. Por exemplo, em vez de 1% de FPs ou 2.437 falsos positivos, pode ser mais fácil avaliar o impacto de 0,1 falso positivo por usuário por dia. Se isso fosse um gateway web seguro, alguém na organização poderia determinar se uma determinada meta de FP é aceitável com base no impacto sobre o usuário ao longo do tempo. Nesse caso, malware habilitado por framework de C2 resulta em violações, e o impacto sobre o usuário é mais bem caracterizado como tempo de inatividade ou perda de dados por usuário durante determinado período. Temos N% de probabilidade de uma perda de $X por usuário a cada ano. Essas estimativas geralmente são aproximadas, mas qualquer ponto de partida é útil, pois pode ser revisado e aprimorado por meio de iterações regulares. Se o impacto for avaliado em termos de usuários ao longo do tempo, torna-se fácil avaliar soluções de detecção ou proteção, que frequentemente têm preços definidos com base no número de usuários por ano.
2. Impacto sobre as operações de segurança em termos de tempo, dinheiro e probabilidade de violação. Além do impacto sobre o usuário final, deve ser avaliado o impacto administrativo, especialmente sobre as equipes de operações, que frequentemente dedicam tempo ao tratamento de alertas de detecção. O tempo gasto respondendo a alertas ruidosos pode ser convertido diretamente em custo salarial de FTE. O fator adicional da fadiga de alertas é um impacto real que pode ser estimado em termos de eficácia, como o tempo de resposta, e, mais importante, como a perda de tempo e atenção dedicados a ameaças realmente mais impactantes que são ignoradas ou não investigadas. Esse último impacto se torna um fator no impacto de uma violação — as violações têm maior probabilidade de ocorrer quando as operações de segurança têm falsos positivos demais para investigar e excluir.

Uma avaliação de impacto frequentemente é a única maneira de compreender informações essenciais, como o custo real da eficácia da detecção. Por exemplo, uma solução de detecção excessivamente agressiva, configurada para ter poucos FNs e muitos FPs, é inútil e prejudicial, pois as operações de segurança desperdiçam uma quantidade excessiva de tempo respondendo a alertas de baixa fidelidade, em vez de se dedicarem a atividades de maior impacto. Da mesma forma, uma solução de detecção excessivamente conservadora, com poucos FPs, mas muitos FNs, expõe a organização a um alto risco de possível violação, o que pode ser inaceitável do ponto de vista de uma avaliação geral de risco.

O impacto deve ser estimado e avaliado ao mesmo tempo que as principais métricas de TP/FP/TN/FN.

Testes realistas

Use red teams com pessoas, não apenas ferramentas automatizadas de violação ou teste de penetração. É altamente recomendável usar não apenas usuários e ambientes de produção para testar soluções de beaconing de C2, mas também cenários adversários realistas, como testes de penetração ou programas de bug bounty. Ao ajustar os valores das recompensas e os requisitos para demonstrar a implantação explícita e ações pós-exploração bem-sucedidas de kits de ferramentas populares de framework de C2, podemos tornar o “tráfego malicioso” real e mensurável. Isso poderia ser ampliado para qualquer atividade de beaconing de C2, incluindo código personalizado para testar a resiliência da solução de detecção, e o requisito de teste deveria incluir a demonstração de atividades diárias bem-sucedidas de beaconing e execução de comandos durante uma semana, sem detecção.

Se um teste de penetração externo ou programa de bug bounty for repetido, as diferenças nas taxas de detecção serão mensuráveis e úteis para avaliar a eficácia e o ROI.

Com uma abordagem rigorosa aos testes, não apenas a eficácia será medida de forma abrangente, mas também poderão ser criadas metas e objetivos contínuos em relação a uma linha de base atual/histórica. E, certamente, se os mesmos testes e medições forem realizados para várias soluções, será trivial comparar o desempenho e tomar decisões de compra/implementação.

Considerações de design

A pesquisa e o design relacionados a esses conceitos e à abordagem geral são discutidos em mais detalhes em: Security systems and methods for detecting malleable command and control (Mulugeta).

Benefícios

Detecção de anomalias de novas ameaças desconhecidas

Essa abordagem mitiga com eficácia ameaças desconhecidas ao utilizar modelos de aprendizado de máquina treinados no comportamento de aplicativos específico dos usuários de uma organização. A métrica granular de risco do usuário reduz significativamente os falsos positivos.

Em contrapartida, as abordagens reativas existentes dependem da identificação de uma primeira vítima ou paciente zero, um sacrifício em nome do bem maior, seguida de análises e pesquisas do fornecedor que podem levar dias ou até meses antes que ele disponibilize uma nova assinatura ou regra para bloquear a nova ameaça para os clientes que ainda não foram atacados. Por definição, essa abordagem é ineficaz para bloquear ameaças maleáveis novas e emergentes.

Uma abordagem de detecção de anomalias, que utiliza modelos específicos e calibrados de aprendizado de máquina, pode detectar de maneira exclusiva comportamentos suspeitos sem exigir um ciclo de análise, lançamento e atualização. A abordagem mantém sua robustez mesmo com a evolução das táticas de ameaças.

Análise abrangente de sinais

A detecção de anomalias em um conjunto abrangente de sinais, como tempo, volume, comunicações TCP/IP, impressões digitais SSL/TLS e cargas úteis de protocolos de aplicativos, pode detectar com eficácia comunicações maleáveis e sofisticadas de C2.

Detecção de kits de ferramentas adversários

Essa abordagem pode detectar com eficácia o uso das mais recentes ferramentas de framework de C2 e dos frameworks de C2, assim como novas atividades suspeitas de beaconing de C2, ao se basear na detecção de anomalias utilizando uma ampla variedade de sinais de rede específicos dos usuários do ambiente e comparando-os com o tráfego legítimo e benigno do ambiente.

Eficácia da detecção

As abordagens atuais, como assinaturas de IPS e bloqueios de IP/domínio/URL, não detectam uma alta proporção das comunicações avançadas de C2 presentes nos malware mais recentes, de 40% a 80%, dependendo dos cenários de teste.

Com o uso de uma nova abordagem que emprega um modelo calibrado de aprendizado de máquina, detecção de anomalias em um conjunto rico de sinais e uma métrica de risco granular, mais de 85% a 95% desses ataques atualmente não detectados podem ser identificados.

Isso resulta em uma taxa geral de detecção de verdadeiros positivos superior a 95%, com o mínimo de falsos positivos.

Conclusão

Os kits de ferramentas de framework de C2 proporcionaram aos invasores técnicas sofisticadas para evitar a detecção de comando e controle (C2). Em especial, kits de ferramentas amplamente disponíveis, como Cobalt Strike, Brute Ratel e Mythic, podem ser acessados como código de fonte aberta ou como código comercial hackeado/roubado.

As abordagens estáticas tradicionais, que dependem fortemente de assinaturas estáticas e de indicadores, como listas de bloqueio de IP/URL, enfrentam limitações graves e são facilmente contornadas por essas ameaças em evolução.

Para enfrentar esse desafio, é necessária uma abordagem fundamentalmente diferente que utilize modelos de aprendizado de máquina. Esses modelos incorporam um conjunto abrangente de sinais de rede e são especificamente treinados nos níveis do usuário e da organização. Além disso, utilizam métricas granulares de risco do usuário para reduzir os falsos positivos e medir as áreas cinzentas frequentemente associadas às ameaças.

A eficácia das abordagens de aprendizado de máquina deve ser cuidadosamente avaliada pelos usuários. Testes rigorosos em uma base robusta de tráfego malicioso e benigno são essenciais para determinar sua eficácia na detecção e mitigação dessas novas ameaças.

Referências

1. “Cobalt Strike: International law enforcement operation tackles illegal uses of ‘Swiss army knife’ pentesting tool.” The Record from Recorded Future News, 3 July 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Accessed 23 August 2024.
2. Gill, Andy. “Understanding Cobalt Strike Profiles – Updated for Cobalt Strike 4.6.” ZSEC Blog, 13 April 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Accessed 23 August 2024.
3. Larson, Selena, and Daniel Blackford. “Cobalt Strike: Favorite APT Tool to Crimeware.” Proofpoint, 29 June 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.
4. Mudge, Raphael. “Malleable C2 Profiles: gmail.” Malleable-C2-Profiles normal gmail.profile, rsmudge, 28 Feb 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.
5. Mulugeta, Dagmawi. “Security systems and methods for detecting malleable command and control.” Free Patents Online, 20 August 2024, https://www.freepatentsonline.com/12069081.html.
6. Rahman, Alyssa. “Cobalt Strike | Defining Cobalt Strike Components & BEACON.” Google Cloud, 10 December 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.
7. Snort. “SID 1:25050.” Snort Rule: MALWARE-CNC Win.Trojan.Zeus variant outbound connection, https://www.snort.org/rule_docs/1-25050.
8. “SolarWinds Supply Chain Attack Uses SUNBURST Backdoor.” Google Cloud, 13 December 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.