Malware & Ameaças
Hive e Vault 7: a infraestrutura HTTPS da CIA por dentro
Como Hive separava visitantes comuns de implantes: HTTPS, certificados de cliente, relays e critérios de evidência para analisar infraestrutura de C2.
Uma página aparentemente comum pode ser apenas a fachada de uma infraestrutura muito diferente. Hive, documentado nos arquivos Vault 7 e Vault 8 atribuídos à CIA, torna esse problema concreto: o visitante casual e o implante autenticado podem receber tratamentos distintos no mesmo serviço HTTPS. Para quem trabalha com análise de tráfego, resposta a incidentes ou engenharia de segurança, a pergunta interessante é como demonstrar essa diferença sem confundir criptografia com legitimidade.
Esta é uma análise histórica com aplicação profissional. Os documentos de Hive vieram a público em 2017; a agenda editorial de outubro de 2026 não representa um novo vazamento. O objetivo é examinar arquitetura, confiança e evidências, separando os documentos publicados das conclusões que um analista pode realmente sustentar.
A decisão de cobertura: uma máquina de estados para entender o relay
O desenho de Hive tem duas decisões distintas: aceitar uma conexão TLS e reconhecer um cliente operacional. Um servidor pode oferecer conteúdo público a conexões comuns e encaminhar somente clientes reconhecidos para outra infraestrutura. A fachada é uma escolha de aplicação, não uma quebra do HTTPS.
A máquina de estados abaixo é um modelo original desse conceito, não uma transcrição do código de Hive. Ela mostra por que a observação externa de uma página normal não descreve o caminho dos clientes autenticados. Não realiza comunicação, não instala implante e não implementa um servidor de comando e controle.
def classificar_conexao(tls_valido, identidade_verificada):
if not tls_valido:
return 'REJEITADA'
if not identidade_verificada:
return 'COBERTURA'
return 'CANAL_RECONHECIDO'
assert classificar_conexao(False, True) == 'REJEITADA'
assert classificar_conexao(True, False) == 'COBERTURA'
assert classificar_conexao(True, True) == 'CANAL_RECONHECIDO'
print('tres fronteiras exercitadas')A identidade precisa resultar de verificação criptográfica apropriada, não de um booleano fornecido pelo cliente. O exemplo abstrai essa verificação para isolar a decisão de encaminhamento. Certificado de servidor, certificado de cliente e autorização após autenticação respondem perguntas diferentes.
Na análise operacional, separe também beacon e canal interativo. Uma atividade periódica com pouco volume pode indicar sinalização; uma sessão de maior volume pode indicar transferência ou interação. Esses padrões são hipóteses de triagem: atualizadores e agentes legítimos fazem coisas semelhantes. A diferença aparece quando se associa conexão ao processo, configuração e evidência em memória.
O material de Vault 8 permite estudar o código publicado de Hive, mas a distribuição de um arquivo por um vazamento não prova que ele estava implantado em um incidente. Registre versão e hash do material analisado e separe a função observada no código do comportamento observado no alvo. Uma hipótese de relay ganha força com telemetria correlacionada; o nome de uma empresa em um certificado, sozinho, não basta.
Vault 7, Vault 8 e o que foi confirmado sobre a CIA
O Departamento de Justiça dos Estados Unidos relacionou o caso Joshua Schulte ao furto de informações da área de desenvolvimento cibernético da CIA e às divulgações Vault 7 e Vault 8. Isso fornece uma base judicial para a origem geral do acervo. Não significa que cada funcionalidade de cada documento tenha sido individualmente validada no processo ou continue operacional hoje. Veja o comunicado oficial do Departamento de Justiça.
O índice do Vault 7 registra a divulgação da documentação de Hive em 14 de abril de 2017. O Vault 8 publicou código e registros de desenvolvimento em 9 de novembro daquele ano. São momentos diferentes: primeiro a descrição do projeto, depois material que ampliou as possibilidades de inspeção técnica. Ler as duas etapas como um único anúncio apaga parte importante da cronologia.
Hive: implante, comunicação e infraestrutura de operação
O guia Hive 2.9.1, datado de novembro de 2015, descreve um implante com beacon e shell interativo, orientado a estabelecer acesso inicial para outras ferramentas. A documentação lista plataformas e arquiteturas específicas, inclusive sistemas embarcados. Ela não demonstra compatibilidade universal com roteadores, câmeras ou versões atuais desses equipamentos.
Essa divisão ajuda a organizar uma investigação: o código presente no equipamento, o canal que ele utiliza e o serviço que atende esse canal são objetos separados. Encontrar um deles não identifica automaticamente os outros. Também muda o planejamento de um exercício autorizado: avaliar uma política de saída HTTPS não testa a resistência do equipamento ao comprometimento inicial.
A fachada HTTPS e o caminho até Honeycomb
Na descrição do Vault 8, um domínio de cobertura aponta para um servidor público. O tráfego passa por uma ligação com o servidor Blot, enquanto a identificação do cliente permite encaminhar comunicações do implante ao componente Honeycomb. Visitantes comuns recebem conteúdo de cobertura. A autenticação de cliente no TLS funciona como elemento de seleção; a descrição não exige que todo visitante apresente certificado.
Modelo conceitual da infraestrutura histórica
Visitante comum
→ domínio de cobertura → serviço HTTPS → conteúdo de cobertura
Cliente reconhecido
→ domínio de cobertura → relay → Blot → Honeycomb
Uma resposta pública isolada não descreve todos os caminhos internos.O esquema acima é uma síntese editorial, não um procedimento de implantação. Seu valor está em mostrar duas limitações de uma inspeção superficial: a mesma origem pode oferecer comportamentos diferentes, e a máquina visível na internet pode não ser o destino final dos dados. Um teste que só solicita a página inicial mede o caminho disponível àquele cliente, naquele momento.
Certificado, nome de empresa e confiança criptográfica
O material do Vault 8 descreve certificados usados para imitar a identidade de uma empresa de segurança. Isso exige cuidado na leitura: um nome em Subject ou Issuer não comprova que a empresa ou uma autoridade certificadora tenha emitido legitimamente o certificado. O caso também não demonstra uma quebra matemática do TLS.
Em uma avaliação, registre separadamente nome do certificado, cadeia apresentada, âncora de confiança, validade temporal e identidade esperada pelo cliente. Um software que aceita uma cadeia privada instalada localmente apresenta um cenário diferente de um navegador que confia apenas em autoridades públicas. Ignorar essa diferença pode transformar uma escolha de configuração em uma alegação incorreta de falha criptográfica.
A RFC 8446 define TLS 1.3 e seus mecanismos de autenticação. Ela serve como referência para ambientes modernos, não como prova de que Hive utilizava essa versão em 2015. A disponibilidade dos certificados para um observador de rede depende da versão do protocolo e do ponto de coleta; registros no cliente ou no terminador TLS podem ser necessários.
O que observar em uma investigação de C2 sobre HTTPS
Uma hipótese útil precisa indicar a fonte do dado e o que pode refutá-la. Conexões recorrentes com um domínio pouco conhecido podem justificar uma investigação, mas também aparecem em agentes de atualização e serviços corporativos. A decisão melhora quando rede, processo, inventário e contexto de aplicação são correlacionados.
| Observação | Hipótese de trabalho | Verificação necessária |
|---|---|---|
| Comunicação periódica | Possível beacon | Comparar com tarefas agendadas e agentes autorizados |
| Certificado de cliente inesperado | Canal reservado a um software | Identificar origem, armazenamento e processo consumidor |
| Conteúdo público pouco relacionado ao ativo | Possível fachada | Conferir proprietário, finalidade e histórico do destino |
| Processo sem função de rede documentada | Comunicação não explicada | Preservar binário, assinatura, hash e eventos associados |
| Relay e destino final diferentes | Encaminhamento intermediário | Reconstituir o caminho com registros dos pontos disponíveis |
Nenhuma linha isolada identifica Hive. A tabela organiza perguntas de análise. Em relatórios, mantenha essa distinção explícita e anote também as lacunas: retenção insuficiente, ausência de telemetria do processo ou captura sem visibilidade do conteúdo.
Laboratório local: três eventos e uma hipótese reproduzível
Um exercício pequeno pode testar a qualidade do raciocínio sem usar implantes históricos. O exemplo abaixo trabalha somente com registros fictícios em memória. Ele seleciona um evento que combina recorrência, certificado de cliente e processo sem finalidade de rede conhecida. Não faz conexões, não inspeciona máquinas e não detecta Hive.
eventos = [
{"id": "LAB-01", "recorrente": True,
"certificado_cliente": False, "processo_autorizado": True},
{"id": "LAB-02", "recorrente": True,
"certificado_cliente": True, "processo_autorizado": False},
{"id": "LAB-03", "recorrente": False,
"certificado_cliente": True, "processo_autorizado": True}
]
revisar = [e["id"] for e in eventos
if e["recorrente"] and e["certificado_cliente"]
and not e["processo_autorizado"]]
print(revisar)A saída esperada é ['LAB-02']. O próximo passo seria descobrir se a premissa sobre o processo está correta. Se ele pertencer a um agente corporativo aprovado, a hipótese enfraquece. Essa possibilidade de revisão é parte do método, não uma falha do exercício.
Como transformar a análise em um teste profissional
Comece pela pergunta que o ambiente consegue responder. Para avaliar controle de saída, defina quais processos e destinos devem comunicar. Para avaliar autenticação de cliente, utilize certificados de laboratório e serviços próprios. Para avaliar detecção, registre os eventos esperados antes de executar o cenário e compare com o que foi efetivamente coletado.
O teste deve produzir uma trilha verificável: ativo, horário com fuso, processo, destino, regra aplicada e resposta observada. Quando uma exceção for necessária, documente quem a aprovou e sua duração. Não reutilize chaves, certificados ou executáveis retirados de arquivos históricos em infraestrutura de produção.
Também vale registrar resultados negativos. Se uma conexão foi bloqueada, isso demonstra a atuação daquele controle naquele caminho. Não demonstra que todos os canais possíveis foram eliminados. Se o monitoramento não gerou alerta, confirme primeiro se os eventos chegaram ao sistema de análise antes de concluir que a regra falhou.
Perguntas frequentes sobre Hive e Vault 7
Uma página normal em HTTPS descarta um servidor de C2?
Não. Ela demonstra o comportamento oferecido ao cliente testado. A identificação de um canal de comando requer outras evidências e análise do contexto, especialmente quando o servidor diferencia clientes.
Os documentos provam que qualquer roteador atual pode ser comprometido?
Não. Os guias descrevem versões e arquiteturas históricas. A exposição de um equipamento atual exige inventário e avaliação próprios; o nome do fabricante não estabelece vulnerabilidade.
Qual é a principal lição para quem analisa tráfego?
Preservar a relação entre comunicação, processo e identidade. O dado mais interessante pode estar na diferença entre o caminho público e o caminho autenticado, e essa diferença precisa ser demonstrada com evidências acessíveis ao ambiente investigado.
