Resumo

  • O programa da APNIC 62 chama a sessão de “1.27M Attacks in 204 Days”; o resumo fala em “attack events” e os slides mostram 1.272.286 “Total Events”.
  • A coleta veio de um único sensor, um IP público e duas portas abertas intencionalmente, SSH e Telnet. Não é uma contagem de todos os ataques na Ásia-Pacífico.
  • A tabela de assinaturas registra 198.973 eventos de login SSH bem-sucedido; o funil, medido por IPs únicos, registra 4.530 origens nessa etapa.
  • Cada métrica precisa de um comprovante que declare sensores, serviços, período, taxonomia, regra de severidade, chave de deduplicação e unidade.

O mesmo total ganhou três significados

Na agenda da APNIC, a implantação da Universidade de Dhaka teria recebido 1,27 milhão de ataques em 204 dias. O texto de apresentação qualifica o total como 1,27 milhão de eventos de ataque. A capa do slide usa apenas “eventos”, e o painel fornece o número exato: 1.272.286.

Não se trata de preciosismo. Evento é um registro produzido por um sensor ou uma regra. Evento de ataque já inclui uma classificação. Ataque, na leitura comum, sugere uma ação ou um incidente delimitado. Uma cadeia técnica pode conter os três conceitos, mas eles não compartilham automaticamente o mesmo denominador.

O desenho experimental é bem definido: uma máquina virtual Ubuntu, um núcleo, 2 GB de RAM, 20 GB para retenção de logs e um endereço IP público dedicado. As portas 22 e 23 ficaram abertas para SSH e Telnet; o tráfego de entrada foi liberado deliberadamente.

Essa limitação torna o resultado útil. O sensor mostra o que scanners e sessões interativas fizeram quando encontraram dois serviços familiares em uma isca. Não mostra tudo o que atingiu a universidade, Bangladesh ou a região atendida pela APNIC.

Duas respostas para “quantos logins?”

O melhor controle está em um único slide. A decomposição por assinatura lista 198.973 eventos “SSH login successful”. Ao lado, o funil com o título “Unique IPs” reduz a etapa de login bem-sucedido a 4.530 endereços de origem. A leitura provável é volume repetido de um lado e origens deduplicadas do outro, mas o material público não traz o esquema completo para reproduzir a associação.

São aproximadamente 44 eventos bem-sucedidos por IP que chegou à etapa. O volume mede pressão e repetição. A contagem de IPs mede alcance segundo uma janela e uma chave. Nenhuma das duas medidas identifica pessoas, organizações ou campanhas.

Um endereço de origem pode ser um equipamento comprometido, um proxy, uma hospedagem compartilhada, um relay ou uma saída NAT; também pode ser realocado. Um operador pode usar muitos IPs e muitos operadores podem aparecer atrás de um. Por isso, 36.598 IPs não comprovam 36.598 atacantes humanos únicos.

Os demais blocos do painel pedem o mesmo cuidado. As 78.411 senhas únicas são sequências testadas contra a isca, não contas. Os 7.107 nomes de usuário não são identidades verificadas. Downloads de malware, comandos, URLs de C2 e sistemas autônomos também são unidades distintas.

Um login aceito pela isca não é uma invasão de produção

O adjetivo “bem-sucedido” precisa dizer onde. Um honeypot existe para aceitar, observar e conter comportamentos que um serviço real tentaria bloquear. A sessão aceita prova que a interação atravessou as regras do sensor. Não prova que um servidor de produção da universidade foi comprometido.

Os sinais posteriores continuam relevantes: execução de comandos, downloads e padrões de persistência podem orientar detecção e resposta. Seu valor está na sequência preservada — conexão, autenticação, sessão na isca, comando e carga — e não em comprimir tudo numa contagem de violações reais.

Há uma conciliação limpa por protocolo. Os 1.016.974 eventos SSH somados aos 255.312 de Telnet resultam exatamente em 1.272.286. Já as oito linhas de assinatura exibidas totalizam 1.272.287, uma a mais. O documento não explica se há sobreposição, erro de transcrição ou filtro diferente. A conclusão segura é registrar a diferença, sem inventar uma causa.

O resultado precisa carregar seu comprovante de medição

Para cada número, uma ficha curta deveria informar sensores e serviços incluídos, datas, tipo de evento, severidade, chave de deduplicação, unidade e limites da identidade por IP. Um funil também precisa definir a passagem entre etapas; uma tabela de assinaturas deve dizer se as classes são exclusivas e demonstrar sua soma.

Esse comprovante é uma proposta editorial de Theo March, não uma exigência anunciada pela APNIC ou pela Universidade de Dhaka. Ele não requer publicar payloads sensíveis. Serve para separar pressão de alcance, endereço de ator e login em isca de comprometimento real.

O que as fontes comprovam — e o que não comprovam

O programa e os slides da APNIC comprovam o título, a arquitetura do sensor e os valores apresentados. As páginas do projeto explicam o uso de honeypots para coletar tráfego suspeito, malware e padrões de ataque. Não comprovam número de pessoas ou incidentes, atribuição nacional, prevalência regional ou violação de produção. Tampouco explicam a diferença de uma unidade na tabela de assinaturas.

Fontes