Taxonomia do Google para hackers Castle, Ion e Neptune explicada

2>Por que o Google resolveu renomear hackers (e o que isso muda pra quem desenvolve)

Existe um problema antigo na segurança digital que pouca gente de fora do assunto percebe: a bagunça de nomes. Quando comecei a acompanhar relatórios de inteligência de ameaças lá pelos meus primeiros anos como dev, eu abria três fontes diferentes e via o mesmo grupo chamado de três formas distintas. Um vendor chamava de APT29, outro de Cozy Bear, um terceiro de “o grupo russo que ataca cadeias de”. Era confuso pra caramba.

Foi exatamente pra resolver esse caos que o Google decidiu mudar a forma como batiza e acompanha esses atores de ameaça, criando categorias mais semânticas baseadas no comportamento: Castle, Ion e Neptune. Segundo o Eurisko.com.br, a ideia é abandonar parcialmente a sopa de letrinhas tipo APT-XX e adotar nomes que descrevam o que o grupo faz.

Vou explicar o que cada categoria significa, como isso impacta diretamente o trabalho de quem escreve código, e onde isso toca no seu dia a dia — porque, acredite, se você mantém qualquer aplicação exposta na internet, esses nomes importam.

Entendendo o “porquê” do Google: taxonomia por comportamento, não por origem

O modelo tradicional de nomenclatura (APT1, APT28, APT41) funciona bem pra pesquisadores, mas tem um problema sério: ele sugere que “APT” é uma coisa só. Não é. Cada grupo tem táticas, técnicas e objetivos diferentes. Misturar tudo num único namespace dificulta a correlação automatizada em SIEMs, EDRs e pipelines de detecção.

O Google, junto com a comunidade de threat intelligence, vem empurrando uma abordagem onde o nome carrega semântica. As três novas categorias funcionam como “clusters de comportamento”:

Castle: atores focados em espionagem persistente, ataques de longo prazo, normalmente alinhados a Estados-nação. Comportamento “paciente”, baixa visibilidade, alto custo operacional.
Ion: grupos com motivação financeira primária — ransomware, fraude em cripto, ataques a sistemas de pagamento. Velocidade de ataque alta, monetização rápida.
Neptune: atores que exploram infraestrutura marítima, subaquática ou de cabos. Pode parecer nicho, mas conecta-se diretamente aglobal e data centers submarinos.

Na minha experiência, o ganho real dessa mudança não é cosmético. Quando o nome do grupo carrega a tática predominante, fica trivial montar queries de detecção: você filtra por categoria, cruza com IoCs do seu SIEM e prioriza o que é relevante pro seu contexto. Antes, isso era trabalho braçal de correlação humana.

Na prática: consultando inteligência de ameaças via API

Vamos ao que interessa. Como dev, você provavelmente quer saber como incorporar isso no seu pipeline de segurança. Existe uma forma direta: consumir feeds de threat intelligence via API. Vou mostrar um exemplo funcional com Python usando a API pública do AlienVault OTX e mapeando pra nova taxonomia do Google.

O fluxo é simples: você consulta um indicador (IP, domínio, hash), recebe os “pulses” associados, e classifica pelo cluster de comportamento.

import requests
from typing import List, Dict

OTX_API_URL = "https://otx.alienvault.com/api/v1/indicators"

# Mapeamento simplificado da nova taxonomia do Google
# Em produção, alimente isso de um arquivo JSON versionado
THREAT_CLUSTERS = {
 "Castle": {"foco": "espionagem", "atributos": ["state-sponsored", "long dwell-time"]},
 "Ion": {"foco": "financeiro", "atributos": ["ransomware", "cryptojacking", "fraud"]},
 "Neptune": {"foco": "infraestrutura física", "atributos": ["submarine cables", "ports"]},
}

def check_indicator(ioc: str, ioc_type: str = "IPv4") -> List[Dict]:
 """Consulta OTX e retorna pulses relacionados ao IoC."""
 headers = {"X-OTX-API-KEY": "SUA_CHAVE_AQUI"} # use variável de ambiente em prod
 url = f"{OTX_API_URL}/{ioc_type}/{ioc}/general"
 resp = requests.get(url, headers=headers, timeout=10)
 resp.raise_for_status()
 return resp.json().get("pulse_info", {}).get("pulses", [])

def classify_pulse(pulse: Dict) -> str:
 """Heurística simples pra mapear um pulse num cluster do Google."""
 tags = " ".join(pulse.get("tags", [])).lower()
 name = pulse.get("name", "").lower()
 blob = f"{tags} {name}"
 if "espionage" in blob or "apt" in blob or "state-sponsored" in blob:
 return "Castle"
 if "ransomware" in blob or "fraud" in blob or "cryptojacking" in blob:
 return "Ion"
 if "submarine" in blob or "cable" in blob or "maritime" in blob:
 return "Neptune"
 return "Unclassified"

if __name__ == "__main__":
 ioc_suspeito = "185.220.101.45" # Tor exit node usado em várias campanhas
 pulses = check_indicator(ioc_suspeito)
 for pulse in pulses[:5]: # limita pra demo
 cluster = classify_pulse(pulse)
 print(f"[{cluster}] {pulse['name']} (tags: {', '.join(pulse.get('tags', [])[:3])})")

Esse script é didático, mas dá pra evoluir bastante: você pode alimentar um sistema de tickets, gerar alertas no Slack, ou bloquear automaticamente IPs classificados como Ion no seu WAF. Cuidado só com falsos positivos — IPs de Tor, por exemplo, têm uso legítimo.

Passo a passo pra integrar isso ao seu stack

Crie uma conta gratuita no AlienVault OTX e gere uma API key. Guarde em variável de ambiente, nunca no código.
Versione o dicionário THREAT_CLUSTERS num arquivo clusters.json no repositório — isso facilita auditoria.
Agende a consulta via cron ou Prefect pra rodar a cada 6h. Não faz sentido bater na API a cada request.
Cruze os resultados com seus logs de acesso (Nginx, Cloudflare, Application Gateway). Quem bateu em IoC conhecido?
Dispare alerta no canal #sec-ops do Slack quando aparecer um pulso classificado como Ion (impacto direto em receita).

Erros comuns que devs cometem ao lidar com threat intel

Já revisei código de vários times e os mesmos deslizes se repetem. Vou listar os piores:

Tratar lista de IoCs como fonte da verdade absoluta. IPs e domínios rotacionam o tempo todo. Um IoC desatualizado há 30 dias já pode estar em mãos legítimas. Use IoCs como sinal, não como veredito.
Colocar API keys hardcoded no repo. Parece óbvio, mas já vi PRs aprovadas com chave da VirusTotal commitada. Configure git-secrets ou trufflehog no CI.
Confundir atribuição com detecção. Saber que “o Lazarus Group atacou” não te protege. Saber que “um agente usando técnicas T1486 (Data Encrypted for Impact) mirou o setor financeiro brasileiro nas últimas 72h” te protege. Foque em TTPs, não em nomes.
Ignorar o mapeamento pro MITRE ATT&CK. As novas categorias do Google conversam direto com o ATT&CK. Castle ≈ grupos de Tático/Espionagem. Ion ≈ T1486, T1485, T1490. Aprenda a ler uma matriz, sério.
Não versionar a taxonomia. O Google vai evoluir os clusters. Se você amarra sua lógica de classificação num if/elif gigante, vai chorar na próxima mudança. Use uma tabela de mapeamento externa.

Armadilha extra: alerta fadiga

Quando integrei threat feeds no meu pipeline, cometi o erro clássico de gerar alerta pra qualquer match. Resultado: o time ignorou os canais do Slack em duas semanas. Aprenda a calibrar. Comece com severidade alta só pra clusters Ion (impacto financeiro direto) e adicione Castle/Neptune em modo “digest semanal”.

Como isso afeta diretamente quem programa

Você pode achar que inteligência de ameaças é coisa de SOC analyst, mas tem implicações práticas pra você, dev, hoje:

Rate limiting e WAFs: ao classificar tráfego pelos clusters do Google, você ajusta regras por categoria de ameaça em vez de tentar bloquear “tudo que é ruim” genericamente.
Modelagem de risco em dependências: se sua usa componentes de fornecedores chineses (susceptíveis a Castle) ou de provedores russos (susceptíveis a Ion), a classificação te ajuda a priorizar pentests.
Decisões de arquitetura: se sua aplicação lida com cripto ou pagamento, a probabilidade de encontrar agentes Ion é alta. MFA forte, segredos em HSM, segregação de contas — tudo isso vira requisito, não nice-to-have.
Compliance: LGPD, PCI-DSS e SOC2 pedem monitoramento de ameaças alinhado a frameworks. Usar uma taxonomia padrão (como a do Google + MITRE) facilita evidência em auditoria.

FAQ — perguntas que devs reais fazem

1. As categorias Castle, Ion e Neptune substituem os nomes antigos tipo APT28?

Não completamente. APT28 continua sendo chamado APT28 em muitos relatórios. O que muda é que agora existe uma camada adicional de classificação por comportamento. Pense como tags semânticas em cima dos identificadores clássicos. Você continua usando o nome antigo, mas adiciona o cluster como atributo.

2. Preciso pagar pra ter acesso a threat intel com essa taxonomia?

Não necessariamente. O Google Threat Intelligence Group publica relatórios públicos. Feeds como AlienVault OTX, AbuseIPDB (tier gratuito) e MISP open source já cobrem a maior parte do necessário. Pra SOC maduro, aí sim vale considerar feeds comerciais (Mandiant, Recorded Future, CrowdStrike).

3. Vale a pena implementar threat intel numa aplicação pequena?

Depende do que você considera “pequeno”. Se for um SaaS B2B com dados de clientes, sim. Se for um blog pessoal, provavelmente não — foque em manter dependências atualizadas e WAF básico. A regra de bolso: se você cobra clientes, tem threat model relevante.

4. Como o MITRE ATT&CK se relaciona com Castle/Ion/Neptune?

O ATT&CK é o “como” (técnicas). Os clusters do Google são o “porquê” e o “onde” (motivação e alvo). Eles se complementam. Um agente Castle típico vai usar técnicas como T1071 (Application Layer Protocol), T1027 (Obfuscated Files) e T1566 (Phishing). Um Ion vai aparecer mais em T1486 (Data Encrypted for Impact), T1490 (Inhibit System Recovery).

5. O Google vai mesmo forçar todo mundo a usar essa taxonomia?

Forçar, não. Mas a tendência é clara: o ecossistema de threat intel converge pra nomes com semântica embutida. Empresas como CrowdStrike (Fancy Bear → Grizzly Steppe → BEAR), Microsoft (Volt Typhoon → Storm-1811) e Mandiant já fazem algo parecido. O nome “Castle/Ion/Neptune” é mais uma peça nesse quebra-cabeça.

Considerações finais

Renomear hackers pode parecer exercício acadêmico, mas na prática muda como a indústria se comunica, automatiza e prioriza defesa. Pra quem programa, isso significa menos tempo traduzindo relatórios entre vendors e mais tempo aplicando mitigação efetiva.

Se você chegou até aqui, minha sugestão: comece pequeno. Crie um script que consome um feed público, classifique os indicadores pela nova taxonomia, e integre com seu log de aplicação. Em duas tardes você terá algo funcional e, de quebra, ganha um item novo no seu portfólio de segurança.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Quer que eu detalhe a integração com MITRE ATT&CK ou um caso real de uso de cluster Ion em fintech? É só pedir.