Caça ao Mythic no tráfego de rede

Frameworks pós-exploração

Os threat actors costumam usar frameworks de pós-exploração em ataques cibernéticos para manter o controle sobre hosts comprometidos e mover-se lateralmente na rede da organização. Embora eles preferissem usar frameworks de código fechado, como o Cobalt Strike e o Brute Ratel C4, projetos de código aberto como o Mythic, o Sliver e o Havoc se tornaram populares nos últimos anos. Os atores maliciosos também não perdem tempo em adotar frameworks relativamente novos, como o Adaptix C2.

A análise de frameworks populares revelou que seu desenvolvimento se concentra em evitar a detecção por soluções antivírus e de EDR, muitas vezes às custas da furtividade contra sistemas que analisam o tráfego de rede. Embora ofuscar a atividade de rede de um agente seja muito desafiador, é imprescindível que os agentes se comuniquem com seus servidores de comando e controle. Como consequência, a presença de um agente no sistema e suas ações maliciosas podem ser detectadas com a ajuda de vários sistemas de detecção de intrusão (IDS) baseados em rede e, é claro, de soluções de Network Detection and Response (NDR).

Este artigo examina métodos para detectar o framework Mythic em uma infraestrutura analisando o tráfego de rede. Esse framework ganhou força significativa entre vários threat actors, incluindo o Mythic Likho (Arcane Wolf) e o GOFFEE (Paper Werewolf), e continua sendo usado em APT e outros ataques.

O framework do Mythic

O Mythic C2 é uma plataforma de comando e controle (C&C, ou C2) multiusuário projetada para gerenciar agentes maliciosos durante ataques cibernéticos complexos. O Mythic é construído em uma arquitetura de container do Docker, e seus componentes principais (o servidor, os agentes e os módulos de transporte) são escritos em Python. Essa arquitetura permite que os operadores adicionem novos agentes, canais de comunicação e modificações personalizadas em tempo real.

Como o Mythic é uma ferramenta versátil para o atacante, do ponto de vista da equipe de defesa, seu uso pode se alinhar com vários estágios da Cadeia de ataque unificada, bem como com inúmeras táticas, técnicas e procedimentos no framework MITRE ATT&CK®.

• Pivoting é uma tática em que o atacante usa um sistema já comprometido como um ponto de apoio para obter acesso a outros sistemas dentro da rede. Dessa forma, eles expandem sua presença na infraestrutura da organização aos poucos, burlando firewalls, segmentação de rede e outros controles de segurança.
• Coleta (TA0009) é uma tática focada na coleta e agregação de informações de valor para os atacantes: arquivos, credenciais, capturas de tela e registros do sistema. No contexto das operações de rede, a coleta costuma ser executada localmente em hosts comprometidos, com os dados então empacotados para transferência. Ferramentas como o Mythic automatizam a descoberta e a seleção de dados procurados pelo adversário.
• Exfiltração (TA0010) é o processo de mover as informações coletadas para fora da rede segura por meio de canais legítimos ou encobertos, como HTTP(s), DNS, SMB etc. Os atacantes podem usar agentes residentes ou retransmissões intermediárias (hosts de apoio) para ocultar a fonte e a rota de exfiltração.
• Comando e controle (TA0011) abrange os mecanismos para estabelecer e manter um canal de comunicação entre o operador e os hosts comprometidos para transmitir comandos e receber atualizações de status. Isso inclui conexões diretas, retransmissão por meio de hosts de apoio e o uso de protocolos encobertos. Frameworks como o Mythic fornecem recursos avançados de C2, como execução agendada de comandos, tunelamento e comunicação por múltiplos canais, que dificultam a detecção e o bloqueio da sua atividade.

Este artigo tem como foco a tática de Comando e controle (TA0011), cujas técnicas podem ser detectadas com eficiência no tráfego de rede de agentes Mythic.

Detecção da atividade do agente Mythic no tráfego de rede

No momento da publicação deste artigo, o Mythic é compatível com a transferência de dados por HTTP/S, WebSocket, TCP, SMB, DNS e MQTT. A plataforma também conta com mais de uma dúzia de agentes diferentes, escritos em Go, Python e C#, projetados para Windows, macOS e Linux.

O Mythic usa duas arquiteturas principais para sua rede de comando:

• Neste modelo, os agentes se comunicam com agentes adjacentes, formando uma cadeia de conexões que leva a um nó que se comunica diretamente com o servidor de C2 do Mythic. Para isso, os agentes utilizam TCP e SMB.
• Nesse modelo, os agentes se comunicam diretamente com o servidor de C2 por meio de HTTP/S, WebSocket, MQTT ou DNS.

Comunicação P2P

O Mythic fornece recursos de pivoting por meio de pipes SMB nomeados e sockets TCP. Para detectar a atividade do agente Mythic no modo P2P, examinaremos seu tráfego de rede e criaremos as regras de detecção do Suricata correspondentes (assinaturas).

Comunicação P2P por SMB

Ao gerenciar agentes pelo protocolo SMB, um pipe nomeado é usado por padrão para a comunicação e seu nome corresponde ao UUID do agente.

Embora esse parâmetro possa ser alterado, ele serve como um indicador confiável e pode ser facilmente descrito com uma expressão regular. Exemplo:
[a-z0-9]{8}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{4}\-[a-z0-9]{12}

Para a comunicação SMB, os agentes codificam e criptografam os dados de acordo com o padrão: base64(UUID+AES256(JSON)). Esses dados são então divididos em blocos e transmitidos pela rede. A captura de tela abaixo ilustra a aparência de uma sessão de rede para estabelecer uma conexão entre agentes no Wireshark.

Os comandos e suas respostas são empacotados dentro da estrutura de dados MythicMessage. Essa estrutura contém três campos de cabeçalho, bem como os próprios comandos ou as respostas correspondentes:

• Tamanho total (4 bytes)
• Número de blocos de dados (4 bytes)
• Número do bloco atual (4 bytes)
• Dados codificados em Base64

A captura de tela abaixo mostra um exemplo de comunicação SMB entre agentes.

O agente (10.63.101.164) envia um comando para outro agente no formato MythicMessage. As três primeiras Solicitações de gravação transmitem o tamanho total da mensagem, o número total de blocos e o número do bloco atual. A quarta solicitação transmite os dados codificados em Base64. Isso é seguido por uma sequência de Solicitações de leitura, que também são transmitidas no formato MythicMessage.

Abaixo estão os dados transmitidos no quarto campo da estrutura MythicMessage.

O conteúdo é codificado em Base64. Após a decodificação, a estrutura das informações transmitidas se torna visível: primeiro aparece o UUID do host infectado, seguido por um bloco de dados criptografado usando AES-256.

O fato de os dados começarem com uma string UUID pode ser aproveitado para criar uma regra de detecção baseada em assinatura que pesquisa pacotes de rede para o padrão de identificador.

Para procurar pacotes que contenham um UUID, a seguinte assinatura pode ser aplicada. Ela usa tipos de solicitação específicos e flags de protocolo como filtros (Command: Ioctl (11), Function: FSCTL_PIPE_WAIT (0x00110018)), seguido por uma verificação para ver se o nome do pipe corresponde ao padrão do UUID.

A atividade do agente também pode ser detectada analisando os dados transmitidos em pacotes SMB WriteRequest com a flag de protocolo Command: Write (9) e uma estrutura de pacote distinta em que os campos BlobOffset e BlobLen são definidos como zero. Se o campo Dados for codificado em Base64 e, após a decodificação, começar com uma string formatada em UUID, isso indica que se trata de um canal de comando e controle.

Abaixo está a interface de usuário do KATA NDR exibindo um alerta sobre a detecção de um agente Mythic operando no modo P2P por meio de SMB. Nesse caso, a primeira regra, que verifica o tipo de solicitação, as flags de protocolo e o padrão UUID, foi acionada.

Deve-se notar que essas assinaturas têm uma limitação. Se o protocolo SMBv3 com criptografia ativada for usado, a atividade do agente Mythic não poderá ser detectada com métodos baseados em assinatura. Uma alternativa possível é a análise comportamental. No entanto, neste contexto, ela apresenta baixa precisão e uma taxa elevada de falsos positivos. O protocolo SMB é muito utilizado por organizações para vários fins legítimos, dificultando o isolamento de padrões comportamentais que definitivamente indicam atividade maliciosa.

Comunicação P2P por TCP

O Mythic também é compatível com comunicações P2P por TCP. O processo de inicialização da conexão aparece no tráfego de rede da seguinte forma:

Assim como no SMB, a estrutura MythicMessage é usada para transmitir e receber dados. Primeiro, o comprimento dos dados (4 bytes) é enviado como um DWORD big-endian em um pacote separado. Os pacotes subsequentes transmitem o número de blocos de dados, o número do bloco atual e os próprios dados. No entanto, ao contrário dos pacotes SMB, o valor do campo do número do bloco atual é sempre 0x00000000, devido ao suporte nativo à fragmentação de pacotes do TCP.

O esquema de encoding de dados também é análogo ao que observamos com o SMB e aparece da seguinte forma: base64(UUID+AES256(JSON)). Abaixo está um exemplo de um pacote de rede contendo dados do Mythic.

Os dados decodificados são exibidos da seguinte forma:

Semelhante à comunicação por SMB, as regras de detecção baseadas em assinatura podem ser criadas para o tráfego TCP para identificar a atividade do agente Mythic procurando pacotes que contenham strings formatadas em UUID. Abaixo estão duas regras de detecção do Suricata. A primeira regra é uma regra de utilitário. Ela não gera alertas de segurança, mas define uma flag interna na sessão TCP, que é verificada por outra regra. A segunda regra verifica a flag e aplica filtros para confirmar que o pacote atual está sendo analisado no início de uma sessão de rede. Em seguida, ela decodifica os dados em Base64 e procura por uma string formatada em UUID no conteúdo resultante.

Abaixo está a interface do NDR exibindo um exemplo das duas regras que detectam um agente Mythic operando no modo P2P sobre TCP.

Módulos de transporte de egress

Comunicação de egress encoberta

Para operações furtivas, o Mythic permite que os agentes sejam gerenciados por meio de serviços populares. Isso torna sua atividade menos visível no tráfego de rede. O Mythic inclui módulos de transporte baseados nos seguintes serviços:

• Discord
• GitHub
• Slack

Destes, apenas os dois primeiros permanecem relevantes no momento da redação deste artigo. A comunicação por Slack (o módulo de transporte Slack C2 Profile) não recebe mais suporte dos desenvolvedores e é considerada obsoleta; portanto, não a examinaremos mais a fundo.

O módulo de transporte Discord C2 Profile

O uso do serviço Discord como um mediador para a comunicação com o C2 dentro do framework Mythic vem ganhando popularidade nos dias atuais. Nesse cenário, é impossível distinguir o tráfego do agente da atividade normal do Discord, sendo que os comandos e seus resultados de execução são mascarados como mensagens e anexos de arquivo. A comunicação com o servidor ocorre por HTTPS e é criptografada com TLS. Portanto, é necessário descriptografá-la para detectar o tráfego do Mythic.

Análise do tráfego TLS descriptografado

Vamos supor que estamos usando uma plataforma de NDR em conjunto com um sistema de descriptografia de tráfego de rede (inspeção TLS) para detectar atividades de rede suspeitas. Nesse caso, estamos supondo que podemos descriptografar todo o tráfego TLS. Vamos examinar as possíveis regras de detecção para esse cenário.

A comunicação entre o agente e o servidor ocorre por meio de chamadas de API do Discord para enviar mensagens para um canal específico. A comunicação entre o agente e o Mythic usa a estrutura MythicMessageWrapper, que contém os seguintes campos:

• message: os dados transmitidos
• sender_id: um GUID gerado pelo agente, incluído em cada mensagem
• to_server: uma flag de direção, ou seja, uma mensagem destinada ao servidor ou ao agente
• id: não usado
• final: não usado

O campo message é de grande interesse para nós, pois ele contém os dados transmitidos codificados em Base64. A mensagem MythicMessageWrapper é transmitida em texto simples, tornando-a acessível a qualquer pessoa com permissões de leitura para mensagens no servidor do Discord.

Abaixo está um exemplo de transmissão de dados por meio de mensagens em um canal do Discord.

Para estabelecer uma conexão, o agente se autentica no servidor do Discord por meio da chamada de API /api/v10/gateway/bot. Observamos os seguintes dados no tráfego de rede:

Após a inicialização bem-sucedida, o agente se torna capaz de receber e responder a comandos. Para criar uma mensagem no canal, o agente faz uma solicitação POST ao endpoint da API /channels/<channel.id>/messages. O tráfego de rede para esta chamada é exibido na captura de tela abaixo.

Depois de decodificar o Base64, o conteúdo do campo de mensagem é exibido da seguinte forma:

Uma estrutura característica de um UUID é visível no início do pacote.

Depois de processar a mensagem, o agente a exclui do canal por meio de uma solicitação DELETE para o endpoint da API /channels/{channel.id}/messages/{message.id}.

Abaixo está uma regra do Suricata que detecta a atividade de comunicação do agente baseada no Discord. Ela verifica a atividade da API para criar mensagens HTTP quanto à presença de dados codificados em Base64 contendo o UUID do agente.

Abaixo está a interface do usuário de NDR exibindo um exemplo de detecção da atividade do módulo de transporte Discord C2 Profile para um agente Mythic dentro do tráfego HTTP descriptografado.

Análise do tráfego TLS criptografado

Se o uso do Discord for permitido na rede e não houver capacidade para descriptografar o tráfego, será quase impossível detectar a atividade do agente. Nesse cenário, a análise comportamental de solicitações ao servidor do Discord pode ser útil. Abaixo está o tráfego de rede mostrando conexões TLS frequentes com o servidor do Discord, o que pode indicar que comandos estão sendo enviados a um agente.

Nesse caso, podemos usar uma regra do Suricata para detectar as sessões TLS frequentes com servidores do Discord:

Outro método para detectar essas comunicações envolve rastrear várias consultas DNS para o domínio discord.com.

A seguinte regra pode ser aplicada para detectá-las:

Abaixo está a interface do usuário de NDR mostrando um exemplo de uma regra personalizada em operação, detectando a atividade do módulo de transporte Discord C2 Profile para um agente Mythic dentro do tráfego criptografado com base em consultas DNS características.

As opções de regra propostas têm precisão baixa e podem gerar um grande número de falsos positivos. Portanto, elas devem ser adaptadas às características específicas da infraestrutura na qual serão executadas. Os parâmetros Threshold e count, que controlam a frequência de acionamento e a janela de tempo, requerem ajuste.

Módulo de transporte GitHub C2 Profile

A popularidade do GitHub o tornou um mediador atraente para gerenciar agentes Mythic. O conceito principal é o mesmo que em outros módulos de transporte de comunicação de egress encoberta. A comunicação com o GitHub utiliza HTTPS. A operação bem-sucedida requer uma conta na plataforma alvo e a capacidade de se comunicar por meio de chamadas de API. O módulo de transporte utiliza a API do GitHub para enviar comentários a Problemas pré-criados e para confirmar arquivos em uma ramificação dentro de um repositório controlado pelos atacantes. Nesse modelo, o agente interage apenas com o GitHub: ele cria e lê comentários, carrega arquivos e gerencia ramificações. Ele não se comunica com nenhum outro servidor. O algoritmo de comunicação por meio do GitHub é o seguinte:

1. O agente publica um comentário (check-in) em um Problema designado no GitHub, destinado ao envio de relatórios de resultados pelos agentes.
2. O servidor do Mythic valida o comentário, o exclui e publica uma resposta em um problema designado para uso do servidor.
3. O agente cria uma ramificação com um nome que corresponde ao UUID e grava um arquivo get_tasking nela (executa uma solicitação push).
4. O servidor do Mythic lê o arquivo e grava um arquivo de resposta na mesma ramificação.
5. O agente lê o arquivo de resposta, exclui a ramificação, pausa e repete o ciclo.

Análise do tráfego TLS descriptografado

Vamos considerar uma abordagem para detectar a atividade do agente quando for possível descriptografar o tráfego.

A comunicação do agente com o servidor utiliza chamadas de API para o GitHub. O payload é codificado em Base64 e publicado em texto simples; portanto, qualquer pessoa que possa visualizar o repositório ou analisar o conteúdo do tráfego pode decodificá-lo.

A análise da comunicação do agente revelou que o tráfego mais útil para criar regras de detecção está associado à publicação de comentários de check-in, à criação de uma ramificação e à publicação de um arquivo.

Durante a fase de check-in, o agente publica um comentário para registrar um novo agente e estabelecer a comunicação.

Os dados transmitidos são codificados em Base64 e contêm o UUID do agente e a parte da mensagem criptografada usando AES-256.

Isso permite uma assinatura que detecta substrings formatadas em UUID nas solicitações de criação de comentários do GitHub.

Outro estágio adequado para detecção é quando o agente cria uma ramificação separada com seu UUID como nome. Todas as comunicações relevantes subsequentes com o servidor ocorrerão dentro dessa ramificação. Aqui está um exemplo de uma solicitação de criação de ramificação:

Portanto, podemos criar uma regra de detecção para identificar strings formatadas em UUID nas solicitações de criação de ramificação.

Depois de criar a ramificação, o agente grava um arquivo nela (envia uma solicitação push), que contém dados codificados em Base64.

Portanto, podemos criar uma regra para acionar solicitações de publicação de arquivo para uma ramificação cujo nome corresponda ao padrão UUID.

A captura de tela abaixo mostra como a solução de NDR registra todas as comunicações suspeitas usando a API do GitHub e, posteriormente, identifica a atividade do agente Mythic. O resultado é um alerta com o veredicto Trojan.Mythic.HTTP.C&C.

Análise do tráfego TLS criptografado

A comunicação com o GitHub ocorre por HTTPS; portanto, na ausência do recurso de descriptografia de tráfego, os métodos baseados em assinatura para detectar a atividade do agente não podem ser aplicados. Vamos considerar uma abordagem comportamental de detecção da atividade do agente.

Por exemplo, é possível detectar conexões a servidores GitHub com frequência e finalidade atípicas, originadas de segmentos de rede nos quais essa atividade não é esperada. A captura de tela abaixo mostra um exemplo de várias sessões TLS de um agente. O tráfego reflete a execução de vários comandos, bem como o tempo de inatividade, manifestado como consultas constantes ao servidor enquanto aguarda novas tarefas.

Várias sessões TLS com o serviço GitHub de segmentos de rede não característicos podem ser detectadas usando a regra apresentada abaixo:

Além disso, várias consultas DNS ao serviço podem ser registradas no tráfego.

Essa atividade é detectada com a ajuda da seguinte regra:

A captura de tela abaixo mostra a interface do NDR com um exemplo da primeira regra em ação, detectando rastros da atividade do perfil do GitHub para um agente Mythic no tráfego TLS criptografado.

As opções de regra sugeridas podem produzir falsos positivos; portanto, para melhorar sua eficácia, elas devem ser adaptadas às características específicas da infraestrutura na qual serão executadas. Os parâmetros da palavra-chave threshold devem ser configurados, especificamente os valores count e seconds, que controlam o número de eventos necessários para gerar um alerta e a janela de tempo para sua ocorrência no NDR.

Comunicação de egress direta

O modelo de comunicação de egress permite que os agentes interajam diretamente com o servidor de C2 por meio dos seguintes protocolos:

• HTTP(S)
• WebSocket
• MQTT
• DNS

Os dois primeiros protocolos são os mais prevalentes. O módulo de transporte baseado em DNS ainda está em desenvolvimento, e o módulo baseado em MQTT tem pouco uso entre os operadores. Não os examinaremos no escopo deste artigo.

Comunicação por HTTP

HTTP é o protocolo mais comum para construir uma rede de controle do agente Mythic. O container de transporte HTTP atua como um proxy entre os agentes e o servidor do Mythic. Ele permite que os dados sejam transmitidos em formato de texto simples e criptografados. Fundamentalmente, os metadados não são criptografados, o que permite a criação de regras de detecção baseadas em assinatura.

Abaixo está um exemplo de tráfego de rede não criptografado do Mythic por HTTP. Durante uma solicitação GET, os dados codificados em Base64 são transmitidos no valor do parâmetro query.

Após a decodificação, o UUID do agente, gerado de acordo com um padrão específico, torna-se visível. Esse identificador é seguido por um objeto JSON que contém os parâmetros-chave do host, coletados pelo agente.

Se a criptografia de dados for aplicada, o tráfego de rede para a comunicação do agente será exibido conforme mostrado na captura de tela abaixo.

Depois de descriptografar o tráfego e decodificar do Base64, os dados de comunicação revelam a estrutura familiar: UUID+AES256(JSON).

Portanto, para criar uma assinatura de detecção para esse caso, também podemos contar com a presença de um UUID nos dados codificados em Base64 nas solicitações POST.

A captura de tela abaixo mostra como a plataforma de NDR detecta a comunicação do agente com o servidor por meio de HTTP, gerando um alerta com o nome Trojan.Mythic.HTTP.C&C.

Comunicação por HTTPS

Os agentes Mythic podem se comunicar com o servidor por meio de HTTPS usando o módulo de transporte correspondente. Nesse caso, os dados são criptografados com TLS e não são passíveis de análise baseada em assinatura. No entanto, a atividade dos agentes Mythic pode ser detectada se eles usarem o certificado SSL padrão. Abaixo está um exemplo de tráfego de rede de um agente Mythic com esse certificado.

Para este propósito, a seguinte assinatura é aplicada:

WebSocket

O protocolo WebSocket permite a comunicação bidirecional simultânea (full-duplex) entre um cliente e um host remoto. O Mythic pode utilizá-la para gerenciar agentes.

O processo de comunicação do agente com o servidor por meio do WebSocket é o seguinte:

1. O agente envia uma solicitação ao container do WebSocket para alterar o protocolo da conexão HTTP(S).
2. O agente e o container WebSocket passam a usar o WebSocket para enviar e receber mensagens.
3. O agente envia uma mensagem ao container WebSocket solicitando tarefas do container Mythic.
4. O container do WebSocket encaminha a solicitação para o container do Mythic.
5. O container do Mythic retorna as tarefas ao container do WebSocket.
6. O container do WebSocket encaminha essas tarefas ao agente.

Vale a pena mencionar que nesse modelo de comunicação, tanto o container do WebSocket quanto o container do Mythic estão localizados no servidor do Mythic. Abaixo está uma captura de tela da conexão inicial do agente ao servidor.

Uma análise da sessão TCP mostra que os dados reais são transmitidos no campo data codificados em Base64.

A decodificação revela a estrutura de dados familiar: UUID+AES256(JSON).

Portanto, podemos usar uma abordagem semelhante às discutidas acima para detectar a atividade do agente. A assinatura deve se basear na string do UUID no início do campo de dados. Primeiro, a regra verifica se os dados da sessão correspondem ao formato data:base64, então, ela decodifica o campo data e procura uma string que corresponda ao padrão do UUID.

Abaixo está a assinatura Trojan.Mythic.WebSocket.C&C sendo acionada na comunicação do agente Mythic por meio do WebSocket.

Conclusões

O framework de pós-exploração Mythic continua ganhando popularidade e evoluindo rapidamente. Novos agentes estão surgindo, projetados para encobrir a persistência nas infraestruturas alvo. Apesar dessa evolução, as várias implementações de comunicação de rede no Mythic compartilham muitas características comuns que permanecem bastante consistentes ao longo do tempo. Essa consistência permite que as soluções IDS/NDR detectem efetivamente a atividade do agente do framework por meio da análise do tráfego de rede.

O Mythic apresenta várias opções de gerenciamento de agentes utilizando vários protocolos de rede. Nossa análise das comunicações do agente por meio desses protocolos revelou que a atividade do agente pode ser detectada procurando padrões de dados específicos no tráfego de rede. O critério de detecção principal envolve o rastreamento de strings do UUID em posições específicas nos dados transmitidos codificados em Base64. No entanto, embora a abordagem geral para detectar a atividade do agente seja semelhante entre os protocolos, cada uma requer filtros específicos do protocolo. Por causa disso, criar uma assinatura universal única para detectar agentes Mythic no tráfego de rede é um desafio; regras de detecção individuais devem ser criadas para cada protocolo. Este artigo forneceu assinaturas que estão incluídas no Kaspersky Anti-Targeted Attack (KATA).

O módulo NDR do KATA foi projetado para identificar as ameaças atuais nas infraestruturas de rede. Ele permite detectar todos os frameworks de pós-exploração populares com base nos seus padrões de tráfego característicos. Como os componentes de rede desses frameworks são alterados com pouca frequência, o uso de uma solução de NDR garante alta eficácia na descoberta do agente.

Veredictos da Kaspersky nas soluções da Kaspersky (Kaspersky Anti-Targeted Attack com módulo NDR e Kaspersky NGFW)

Trojan.Mythic.SMB.C&C
Trojan.Mythic.TCP.C&C
Trojan.Mythic.HTTP.C&C
Trojan.Mythic.TLS.C&C
Trojan.Mythic.WebSocket.C&C