Malware & Ameaças
HACIENDA: o mapa de serviços do GCHQ e sua arquitetura técnica
O que as slides de HACIENDA mostram: Nmap, observações de serviços, bases de resultados e ORBs. Parser XML local e análise de proveniência.
O diferencial de HACIENDA não era descobrir uma porta isolada: era transformar observações de serviços em uma base consultável para decisões de inteligência. O caso ajuda a entender como enumeração, normalização, histórico e priorização formam uma capacidade operacional maior que a soma dos scans.
Esta é uma análise de documentos históricos, com um modelo técnico original para estudar resultados. Atribuímos HACIENDA ao contexto GCHQ/JTRIG presente no material publicado. Não chamamos a ferramenta de MI6: o SIS, o GCHQ e o MI5 têm funções distintas, mesmo quando participam de estruturas de cooperação.
O documento público: Nmap, geolocalização e banco de resultados
As slides de HACIENDA preservadas pela EFF, nas páginas iniciais do conjunto, descrevem Nmap para scans, GEOFUSION para geolocalização e coleta de nomes, banners, aplicações e estado de portas. Também mencionam uma base interna do JTRIG e disponibilidade em GLOBAL SURGE.
O conjunto reúne materiais de mais de uma apresentação e agência. LANDMARK e OLYMPIA, discutidos posteriormente no mesmo PDF, não devem ser apresentados como módulos comprovados do código de HACIENDA. Ter documentos no mesmo arquivo não demonstra que são um único programa.
A fonte revela um desenho operacional; não oferece o código-fonte completo de HACIENDA. O parser, a comparação temporal e as políticas abaixo são exemplos didáticos nossos. Não representam uma implementação vazada nem comprovam que todos os detalhes de uma reconstrução eram usados pelo GCHQ.
A primeira fronteira é o escopo, não o scanner
Uma capacidade de inventário precisa saber quais destinos pode observar. Em um trabalho profissional, essa decisão nasce da autorização e da titularidade, não de uma geolocalização aproximada. Uma faixa atribuída a um país pode hospedar serviços de empresas estrangeiras, CDN ou recursos compartilhados.
Um modelo seguro separa entrada solicitada, escopo aprovado e destinos efetivamente usados. Descobertas novas são candidatos, não expansão automática do escopo. Em integrações, isso vale também para resolução DNS e redirecionamento: o serviço encontrado por um hostname pode mudar de endereço durante a execução.
Escopo autorizado
↓
Observação limitada de serviços
↓
Normalização por ativo, protocolo e porta
↓
Proveniência e momento da observação
↓
Comparação com baseline
↓
Revisão técnica e priorizaçãoAberta, fechada e filtrada não descrevem a mesma coisa
A documentação do Nmap distingue estados de portas conforme respostas e visibilidade do scanner. Aberta indica um serviço aceitando conexões naquele teste; filtrada indica que a observação não permitiu decidir da mesma maneira. Não converta silêncio em porta fechada ou host inexistente.
O resultado pertence a uma perspectiva: origem, horário, caminho e perfil do teste. Um serviço pode estar disponível internamente e filtrado externamente. Dois resultados diferentes podem representar uma mudança de política, não uma mudança no processo que escuta a porta.
Para estudar SYN e respostas TCP, acompanhe o significado das flags e confirmações no contrato do protocolo. Um scanner observa uma interação delimitada. A resposta não autoriza inferir versão vulnerável, credenciais fracas ou possibilidade de exploração sem uma etapa adicional de evidência.
XML ajuda a preservar estrutura e proveniência
Para consumir resultados automaticamente, prefira um formato estruturado. O manual de saída XML explica a finalidade desse formato. Um parser que extrai campos do texto apresentado ao usuário pode confundir espaçamento, tradução ou colunas opcionais com dados.
Este exemplo lê uma fixture inteiramente local. Ele não executa Nmap e não varre nenhuma rede. O endereço pertence ao espaço de documentação; a porta e o estado são sintéticos. Em uma implementação real, limite tamanho do arquivo e quantidade de nós e use um parser configurado para entradas não confiáveis.
import xml.etree.ElementTree as ET
xml = '''<nmaprun><host>
<address addr="192.0.2.10" addrtype="ipv4"/>
<ports><port protocol="tcp" portid="443">
<state state="open"/><service name="https"/>
</port></ports></host></nmaprun>'''
raiz = ET.fromstring(xml)
observacoes = []
for host in raiz.findall('host'):
ip = host.find("address[@addrtype='ipv4']").get('addr')
for porta in host.findall('ports/port'):
observacoes.append((ip, porta.get('protocol'),
int(porta.get('portid')),
porta.find('state').get('state')))
assert observacoes == [('192.0.2.10', 'tcp', 443, 'open')]
print(observacoes)A tupla usa IP, transporte e porta como identidade da observação. O estado é um atributo dessa identidade. O nome do serviço é outra camada: a porta 443 sugere um uso habitual, mas não garante que aquele processo fale HTTPS. Quando houver detecção de serviço, preserve também a evidência e o método usado.
Um banner não é uma prova de versão vulnerável
Headers HTTP, banners SSH e respostas de protocolo podem ajudar a identificar uma tecnologia. Porém, são informação fornecida pelo próprio serviço ou intermediário. Um banner genérico, alterado ou herdado de um proxy pode não representar a versão do componente que processa a operação sensível.
Para relacionar um resultado a um CVE, descreva uma cadeia: componente observado, versão plausível, pré-condições do aviso, alcance e teste aplicável. O salto de “porta aberta” para “vulnerabilidade crítica” elimina justamente as etapas que um profissional precisa revisar.
Uma base de inventário útil mantém evidência bruta, resultado normalizado e classificação separados. Se uma regra de classificação mudar amanhã, o sistema pode recalcular a conclusão sem fingir que a rede mudou. Hash, horário e perfil permitem voltar ao material que sustentou a análise.
Histórico transforma listas em perguntas técnicas
| Comparação | Interpretação inicial | Próxima verificação |
|---|---|---|
| Serviço novo | Aumento observado de superfície | Titularidade, finalidade e controle de acesso |
| Aberta passou a filtrada | Visibilidade ou política mudou | Mesma origem, perfil e caminho |
| Banner mudou | Identificação apresentada mudou | Build real e intermediários |
| IP mudou com mesmo nome | Resolução ou infraestrutura mudou | Registro DNS, CDN e escopo autorizado |
Em um laboratório, use dois conjuntos de observações com a mesma política. O controle negativo pode incluir um timeout: ele deve aparecer como ausência de conclusão, não como remoção confirmada do serviço. Compare também o orçamento de coleta. Um segundo teste mais amplo não é equivalente ao primeiro.
Ao agrupar ativos, não use apenas o banner. Serviços distintos podem apresentar a mesma string, e um mesmo produto pode servir vários tenants. Preserve identidade lógica, endereço observado e vínculo com o proprietário. Isso evita que uma conclusão válida para um endpoint seja aplicada automaticamente a todos.
Contrato de exportação e qualidade do inventário
Uma aplicação profissional do modelo precisa definir o significado de cada campo exportado. Associe a identidade do ativo ao protocolo e à porta, ao instante da observação, à perspectiva de rede e à versão da ferramenta. Registre também o hash da configuração e do escopo autorizado. Esses dados permitem comparar execuções sem confundir uma mudança na coleta com uma mudança no serviço. Este contrato é uma proposta de engenharia para o laboratório, não uma descrição de campos internos confirmados do HACIENDA.
Trate campo ausente como desconhecido. Um coletor que não informou o estado da porta não deve produzir automaticamente “fechada”; um erro de parsing não deve remover um ativo do histórico. Preserve o XML original e vincule cada registro normalizado à observação que o gerou. Se o parser for corrigido, produza uma nova interpretação identificada, mantendo a anterior disponível para comparação.
Antes de comparar duas rodadas, confira timeout, taxa, método de sondagem e ponto de coleta. A mudança de “filtrada” para “aberta” pode refletir uma política de rede ou uma perspectiva diferente. O resultado só sustenta uma conclusão quando sua proveniência explica como foi obtido e quais limitações continuam presentes.
ORBs e o limite entre reconhecimento e comprometimento
O acervo histórico menciona uso do reconhecimento para identificar Operational Relay Boxes, ou ORBs. A declaração ao tribunal contextualiza essas máquinas como infraestrutura intermediária em operações. Isso não significa que todo serviço catalogado foi comprometido nem que o scan instala um relay.
Em uma investigação, separe três evidências: máquina observável, acesso não autorizado e uso como intermediário. Uma comunicação entre dois hosts não comprova a terceira etapa sem análise de processo, encaminhamento e contexto. A classificação deve acompanhar o que foi visto, não o objetivo descrito em uma apresentação.
Como aplicar a lição em uma ferramenta profissional
Projete coletores como capacidades limitadas: destinos definidos, timeout, taxa, cancelamento, identidade da execução e parser de saída. Cada resultado deve informar a ferramenta e sua versão. Reexecutar um comando com parâmetros diferentes cria outra observação, não uma atualização invisível da mesma prova.
Para o leitor, a visualização ideal combina tabela de serviços, linha do tempo e detalhes expansíveis. O resumo explica a mudança; o detalhe contém protocolo, evidência e limitação. Uma tela cheia de JSON não substitui essas relações, mas o JSON exportável mantém a análise revisável.
HACIENDA mostra o poder de organizar reconhecimento em uma base de conhecimento. A versão profissional dessa lição depende de escopo, proveniência e hipóteses testáveis. O resultado não é uma lista impressionante de portas: é uma explicação verificável de como a superfície mudou e quais decisões isso permite tomar.
