Uphill Security chegou ao Hacker News, mas seus dados de credenciais SSH exigem uma leitura cuidadosa

A Uphill Security apresentou 1,53 milhão de tentativas de login SSH aos leitores do Hacker News, expondo tanto uma automação implacável quanto um grande conflito de interpretação. Sua rede global de honeypots registrou 131.922 pares distintos de nome de usuário e senha durante julho de 2026. Ainda assim, essas observações não estabelecem que as senhas vieram de contas reais.

Essa distinção separa uma telemetria de ameaças útil de um banco de dados de credenciais roubadas. O projeto mostra o que scanners automatizados tentam ao encontrar um serviço SSH aberto. Ele não mostra quais combinações funcionam em outros lugares, quem as reuniu ou se os atacantes as copiaram de violações anteriores.

O debate resultante importa porque defensores frequentemente interpretam mal logs de autenticação com falha. Alguns descartam o tráfego como ruído de fundo inofensivo. Outros tratam cada senha tentada como evidência de uma campanha ativa de comprometimento. A realidade fica entre essas posições e exige uma análise mais cuidadosa do método de coleta.

A rede de honeypots registrou 1,53 milhão de tentativas de login

O projeto capturou uma grande amostra de ataques automatizados a credenciais SSH, não uma coleção verificada de senhas funcionais.

A Uphill Security publicou suas primeiras descobertas em 2 de agosto, cobrindo o primeiro mês completo de operação da rede. As descobertas do honeypot abrangem julho de 2026 e quinze servidores dedicados.

Esses servidores usaram quinze endereços IPv4 públicos em cinco provedores de servidores virtuais privados. A maioria estava localizada na Europa, embora a infraestrutura abrangesse várias regiões globais. Cada endereço expunha um honeypot SSH de baixa interação na porta TCP 22.

Um honeypot de baixa interação imita o suficiente de um serviço para atrair e registrar atacantes sem fornecer um ambiente operacional completo. Neste caso, ele aceitou tentativas de autenticação e registrou os nomes de usuário e senhas enviados. Ele não permitia que invasores operassem dentro de um shell realista.

A rede observou 1.531.053 tentativas de login de 6.790 endereços IP únicos. Essas tentativas continham 12.238 nomes de usuário únicos, 97.621 senhas únicas e 131.922 pares distintos de nome de usuário e senha.

O par mais comum foi root com 123456, tentado 3.861 vezes. Outras combinações mais frequentes incluíram root com root, password, 12345678, admin e várias sequências numéricas curtas.

Os atacantes tentaram o nome de usuário root 648.133 vezes. Isso representou mais de 42 por cento de todas as tentativas de autenticação no conjunto de dados. Os nomes de usuário mais comuns em seguida foram admin, ubuntu, user e test.

A senha 123456 apareceu 73.592 vezes. Outras escolhas frequentes incluíram 123, 1234, password, 12345678 e 12345. Esses valores se parecem com dicionários consolidados de senhas fracas e padrões previsíveis de dispositivos.

Os resultados demonstram quão pouco reconhecimento alguns scanners precisam. Um servidor que expõe SSH em sua porta padrão recebe imediatamente tentativas contra identidades administrativas genéricas. Um operador não precisa anunciar o sistema nem colocá-lo em um diretório público.

No entanto, o experimento contou apenas tentativas de autenticação. Ele excluiu varreduras de rede e ataques contra outros protocolos. Também não acompanhou invasores bem-sucedidos, pois o honeypot foi projetado para coletar envios de login, e não comportamento pós-autenticação.

Esse limite é crucial. O conjunto de dados descreve o que scanners ofereceram a quinze servidores-isca. Ele não pode revelar diretamente quantos sistemas de produção aceitaram as mesmas combinações.

Por que o debate no Hacker News se concentrou em “coleta”

A discordância não é sobre se as medições são reais; ela diz respeito ao que as credenciais enviadas realmente representam.

Vários comentaristas do Hacker News questionaram o uso de “coleta” no artigo. A preocupação era que bots automatizados forneceram as credenciais, em vez de perdê-las para o honeypot. A rede coletou entradas dos atacantes, não segredos extraídos de sistemas controlados por atacantes.

Uma discussão argumentou que a maioria das combinações era estatisticamente interessante, mas operacionalmente inútil. Um scanner aleatório tentando root:123456 não prova que algum servidor não relacionado use esse par.

Essa crítica tem fundamento. Uma credencial normalmente associa uma identidade declarada a um autenticador que concede acesso a um sistema específico. Sem o host ou serviço correspondente, um par de nome de usuário e senha não tem o contexto necessário para verificá-lo.

Mesmo combinações incomuns exigem cautela. Um bot pode gerá-las a partir de um dicionário, modificar padrões conhecidos, combinar palavras vazadas ou reutilizar listas coletadas em campanhas anteriores. O honeypot não consegue distinguir essas origens apenas a partir de seus registros de autenticação.

Portanto, a palavra “coleta” pode sugerir mais do que o experimento estabeleceu. Leitores podem inferir que o conjunto de dados contém senhas roubadas de sistemas ativos. O método publicado não sustenta essa conclusão.

Ainda assim, chamar os dados de inúteis vai longe demais. Envios repetidos revelam as suposições incorporadas à infraestrutura automatizada de ataque. Eles mostram quais contas os atacantes esperam encontrar, quais padrões continuam atraentes e com que agressividade fontes específicas operam.

O projeto também destaca o direcionamento a contas de serviço. Além de root e admin, os scanners tentaram postgres, oracle, git, ftpuser, deploy e deployer. Esses nomes correspondem a funções comuns de software e práticas de implantação.

Algumas entradas parecem moldadas por tendências tecnológicas atuais. O nome de usuário claude recebeu 5.993 tentativas, enquanto solana recebeu 8.223. Esses rótulos não comprovam direcionamento de campanha, mas mostram como dicionários de ataque incorporam termos reconhecíveis de software e produtos.

Uma interpretação útil trata cada par enviado como uma hipótese do atacante. O scanner prevê que um host possa expor uma conta nomeada com uma senha fraca ou padrão. A repetição indica confiança, conveniência ou ampla reutilização em ferramentas de varredura.

Isso torna os registros valiosos para testes defensivos. Administradores podem comparar os nomes de usuário observados com contas locais, confirmar que a autenticação por senha está desativada e procurar nos logs padrões concentrados de tentativas.

Os registros continuam sendo uma evidência fraca para atribuir ataques. Um IP observado pode pertencer a um servidor comprometido, um proxy, uma máquina virtual alugada ou uma infraestrutura controlada por outro intermediário. A geografia identifica o registro da rede ou a localização estimada, não a pessoa responsável.

Em última análise, o debate aumenta o valor do projeto. Ele obriga os leitores a separar telemetria bruta de alegações de segurança mais fortes. Essa disciplina importa sempre que um conjunto de dados marcante alcança uma ampla audiência de tecnologia.

A geografia mostra a infraestrutura, não a identidade do atacante

A distribuição das fontes mapeia onde o tráfego surgiu, mas não consegue identificar com segurança onde os operadores viviam ou trabalhavam.

A rede de honeypots registrou fontes de conexão em 129 países e 1.334 sistemas autônomos. Um sistema autônomo é uma coleção de rotas da internet gerenciada por um operador de rede.

A Ásia forneceu 4.084 endereços de origem únicos, ou 60,1 por cento do total. A Europa forneceu 1.294, enquanto a América do Norte forneceu 832. Os endereços restantes foram mapeados para a América do Sul, África e Oceania.

O volume de tráfego produziu um quadro diferente. Endereços europeus geraram 921.439 tentativas, ou 60,2 por cento de todos os logins. Fontes asiáticas geraram 453.254 tentativas, apesar de representarem muito mais endereços únicos.

O contraste reflete concentração. Fontes europeias tiveram uma média de 712,1 tentativas por endereço observado. Fontes norte-americanas tiveram média de 117,1, enquanto as asiáticas tiveram média de 111.

No nível dos países, a China produziu o maior número de endereços únicos, com 1.653. Os Estados Unidos vieram em seguida, com 721, enquanto a Índia produziu 458 e o Vietnã produziu 338.

Os Países Baixos lideraram em número total de tentativas, produzindo 686.449 envios a partir de 276 endereços observados. Isso representou 44,8 por cento de todo o conjunto de dados. A China produziu 112.793 tentativas, e os Estados Unidos produziram 72.314.

Isso não significa que residentes neerlandeses conduziram quase metade da atividade. Centros de hospedagem, relés, servidores infectados e infraestrutura alugada podem concentrar tráfego em determinadas regiões de rede. Um cluster de automação também pode gerar muito mais tentativas do que milhares de fontes menos ativas.

Os resultados dos sistemas autônomos reforçam essa lição. A rede da Microsoft continha o maior número de endereços observados únicos, 303. No entanto, uma rede diferente, a TechTies, produziu 448.559 tentativas a partir de 110 endereços.

Provedores de nuvem e hospedagem aparecem em toda a lista de fontes. DigitalOcean, Oracle, OVH, Alibaba, Tencent, Google e várias redes de telecomunicações registraram tráfego. Sua presença não implica participação dessas empresas.

Atacantes favorecem infraestrutura hospedada porque ela oferece largura de banda estável e provisionamento rápido. Eles também comprometem servidores legítimos e usam essas máquinas como nós de varredura. Ambos os padrões enfraquecem a atribuição simples no nível de país.

Os dados também contêm um efeito de amostragem. Sessenta por cento dos honeypots estavam na Europa. A localização do servidor pode afetar roteamento, latência, visibilidade para varreduras e quais campanhas encontram um endereço durante uma janela limitada de observação.

Quinze endereços fornecem observações significativas, mas não um censo representativo do abuso global de SSH. A reputação do endereço também pode importar. Um IP recém-alocado pode atrair tráfego diferente de um endereço anteriormente associado a outro serviço.

A futura expansão do projeto deve tornar comparações geográficas mais informativas. Mais endereços, distribuição regional equilibrada e medições mensais repetidas ajudariam a distinguir padrões duradouros de picos de campanha de curta duração.

Publicar resultados por sensor acrescentaria outra camada. Se um honeypot recebesse a maior parte do tráfego neerlandês, pesquisadores poderiam investigar se um scanner visava uma faixa estreita de endereços. Se todos os sensores observassem comportamento semelhante, a campanha provavelmente fez uma varredura mais ampla.

Para defensores, a lição operacional é mais simples do que o mapa. Bloquear países inteiros com base nesta amostra criaria falsa confiança. Limites de taxa, autenticação baseada em chaves, restrições de conta e monitoramento abordam o método de ataque de forma mais direta.

No que ataques a credenciais SSH se transformam após um login bem-sucedido

Tentativas fracassadas são tráfego de fundo até que uma seja bem-sucedida, após o que a mesma automação pode transformar um servidor em infraestrutura de ataque.

O honeypot não observou comandos pós-login, portanto não pode afirmar o que seus scanners pretendiam fazer em seguida. Pesquisas independentes sobre incidentes fornecem o contexto que falta.

O MITRE classifica a adivinhação de senhas como uma técnica de acesso a credenciais e identifica SSH na porta TCP 22 como um alvo comum. Sua entrada sobre adivinhação de senhas também descreve falhas repetidas seguidas de um possível sucesso como um padrão importante de detecção.

Uma senha bem-sucedida faz mais do que expor um terminal interativo. A conta pode fornecer acesso a código-fonte, arquivos de ambiente, chaves privadas, tokens de nuvem, credenciais de banco de dados ou sistemas de implantação.

Os privilégios determinam o dano imediato. Um login de root dá a um invasor amplo controle. Uma conta de serviço restrita ainda pode expor dados valiosos ou permitir movimentação lateral por meio de permissões fracas de arquivos e credenciais herdadas.

Os invasores também podem modificar as configurações de autorização SSH para manter a persistência. O MITRE documenta a adição de chaves controladas por adversários a authorized_keys, inclusive por interfaces de gerenciamento em nuvem. Uma chave implantada permite que um intruso retorne depois que a senha original for alterada.

A Microsoft documentou malware que começa com força bruta automatizada de SSH. Sua análise de ameaças para Linux descreve um login bem-sucedido seguido por um script malicioso e um bot controlado por IRC.

Essa botnet apoiava atividades de negação de serviço distribuída e execução arbitrária de comandos. Outros comprometimentos de Linux usam sistemas capturados para mineração de criptomoedas, envio de spam, varreduras ou tráfego de proxy.

Uma investigação separada de ataque contra Linux rastreou um comprometimento bem-sucedido por força bruta de SSH por meio de downloads escalonados de scripts. O servidor afetado então se tornou um ponto de lançamento para atividades maliciosas mais amplas.

Esses casos explicam por que falhas repetitivas merecem atenção. Um scanner pode tentar milhares de combinações fracas a baixo custo. Ele precisa de apenas uma conta exposta para compensar esse esforço.

Também mostram por que o conjunto de dados da Uphill Security não deve ser tratado como um vazamento de senhas. O sinal importante é o fluxo de trabalho automatizado em torno dessas tentativas. Os invasores buscam continuamente sistemas nos quais credenciais comuns ainda funcionam.

Os resultados de root expõem o descompasso mais claro entre risco e conveniência. Administradores de produção às vezes mantêm acesso root para operações de emergência. Bots presumem que uma parcela desses sistemas também permitirá autenticação por senha.

Contas de serviço criam um problema mais sutil. As equipes podem criar usuários git, deploy ou de banco de dados para automação e, depois, negligenciar permissões de login interativo. Scripts antigos de implantação podem preservar senhas muito depois de o fluxo de trabalho original mudar.

Desabilitar um shell interativo ajuda, mas os administradores precisam revisar toda a configuração de SSH. Encaminhamento de portas, execução de comandos, transferência de arquivos e comportamento de comando forçado podem criar diferentes caminhos de acesso após a autenticação.

Permissões em nuvem ampliam o potencial raio de impacto. Uma máquina virtual comprometida pode acessar metadados da instância, identidades anexadas, serviços internos ou segredos de implantação. A conta local pode se tornar um ponto de entrada para um ambiente maior.

É aqui que os dados de honeypots SSH se tornam operacionalmente úteis. Eles informam às equipes quais nomes de usuário recebem atenção rotineira e quão pouco a obscuridade protege um serviço público. Também fornecem entradas realistas para validar alertas e controles de taxa.

A pergunta certa não é se toda combinação tentada funciona. É se alguma conta de produção continua capaz de aceitar uma delas.

Os Dados Sustentam o Reforço da Segurança, mas Não Conclusões Universais

O experimento reforça o argumento pela eliminação da exposição baseada em senha, mas deixa várias questões de pesquisa sem resposta.

A resposta defensiva mais clara é exigir autenticação por chave pública para o acesso administrativo via SSH. Uma chave privada oferece muito mais resistência a tentativas online do que uma senha escolhida por humanos.

A CISA aconselha os administradores a exigir autenticação por chave pública quando viável, desabilitar a autenticação por senha e limitar tentativas repetidas. Suas orientações de reforço do SSH também recomendam separar os serviços de gerenciamento do tráfego comum da internet.

Mover o SSH para outra porta pode reduzir varreduras ruidosas, mas não substitui controles de autenticação. Scanners amplos podem descobrir serviços em portas não padronizadas. Uma mudança de porta reduz principalmente o tráfego pouco sofisticado e o volume de logs.

Desabilitar o login direto de root remove da autenticação baseada em senha a identidade mais visada. Os administradores devem usar contas nominativas, privilégios limitados e elevação controlada.

Contas de serviço não utilizadas também merecem revisão. Uma conta git ou deploy deve expor apenas os recursos exigidos pelo seu fluxo de trabalho. A configuração deve negar shells, encaminhamento, subsistemas e comandos de que o serviço não precisa.

A limitação de taxa adiciona outra camada. O NIST descreve a limitação como uma defesa primária contra tentativas online de adivinhação de senhas. Suas orientações sobre senhas também favorecem listas de bloqueio e credenciais geradas por máquina em vez de regras arbitrárias de composição.

Os logs devem relacionar falhas a sucessos posteriores. Dez mil senhas rejeitadas de um endereço podem ser ruidosas, mas contidas. Um login bem-sucedido após falhas repetidas exige investigação imediata.

As equipes também devem monitorar o que ocorre após a autenticação. Novos processos, varreduras de saída, largura de banda inesperada, chaves alteradas, tarefas agendadas, diretórios ocultos e conexões com pools de mineração podem revelar comprometimento.

O isolamento de rede reduz as consequências de um alerta perdido. Cargas de trabalho públicas não devem receber acesso irrestrito a sistemas de gerenciamento, bancos de dados sensíveis ou repositórios de credenciais. O princípio do menor privilégio continua importante depois que a autenticação falha.

No entanto, o projeto Uphill Security ainda tem limitações importantes. Quinze endereços IP observados durante um mês não podem descrever todas as regiões, provedores ou períodos do ano. Campanhas começam e terminam, enquanto scanners ajustam seus dicionários.

O honeypot registrou os valores enviados, mas não os validou em serviços externos. Essa validação seria eticamente perigosa e potencialmente ilegal. Pesquisadores não devem testar combinações coletadas em sistemas não relacionados.

O projeto também publicou strings de credenciais reversíveis. Embora os valores tenham vindo de invasores, alguns podem coincidir com senhas reais por acaso ou reutilização. O uso de hash em versões futuras permitiria análise de frequência com menos exposição desnecessária.

O autor já lista o hash de senhas entre as melhorias planejadas. A referência cruzada com listas conhecidas de senhas também poderia separar entradas comuns de dicionário de valores incomuns. Esse processo deve usar dados de referência obtidos legalmente e de forma responsável.

Dados temporais mais detalhados revelariam a estrutura das campanhas. Pesquisadores poderiam agrupar picos por rede de origem, ordem das credenciais, comportamento de conexão e cobertura dos sensores. Sequências semelhantes poderiam expor software de varredura compartilhado sem exigir atribuição ao invasor.

Um ambiente de maior interação poderia mostrar o que acontece após a autenticação, mas envolve maior risco. Esse honeypot precisa conter intrusos, restringir abusos de saída e impedir que o chamariz prejudique outros sistemas.

Isso cria a principal troca do projeto. Um honeypot simples captura com segurança uma ampla telemetria de autenticação, mas não tem profundidade comportamental. Um sistema realista fornece evidências mais ricas, ao mesmo tempo que aumenta as exigências de contenção, legais e operacionais.

Os resultados atuais sustentam o reforço prático da segurança porque os invasores tentam repetidamente contas previsíveis. Eles não sustentam alegações sobre taxas globais de comprometimento, nacionalidade dos invasores ou a validade no mundo real de 131,922 pares de credenciais.

O Que Observar Após a Atenção do Hacker News

A próxima fase deve testar se esses padrões persistem, se as campanhas se agrupam entre sensores e o que bots bem-sucedidos tentam fazer após a autenticação.

O primeiro sinal é a consistência mensal. Outro período de coleta pode mostrar se root, admin e senhas numéricas curtas continuam predominantes. Classificações estáveis sustentariam a conclusão de que dicionários padronizados impulsionam grande parte da atividade.

Grandes mudanças na classificação apontariam para rotatividade de campanhas. Uma ascensão repentina de um nome de usuário específico de produto pode refletir novo direcionamento, um padrão de configuração vazado ou um scanner repetidamente circulando pela rede.

O segundo sinal é a distribuição no nível dos sensores. Estatísticas por endereço e por região revelariam se o tráfego pesado alcança toda a rede ou se concentra em uma sub-rede. Essa distinção melhoraria a interpretação do pico nos Países Baixos.

Uma implantação geográfica equilibrada fortaleceria as comparações. A atual concentração europeia torna difícil generalizar totais brutos por continente. Mais provedores também poderiam reduzir a influência do histórico de endereços de uma empresa de hospedagem.

O terceiro sinal é o comportamento controlado após a autenticação. Um ambiente cuidadosamente isolado poderia aceitar combinações de isca selecionadas e registrar os primeiros comandos emitidos pelos invasores. Isso conectaria a adivinhação de credenciais a objetivos mensuráveis.

A contenção deve vir primeiro. O ambiente deve bloquear varreduras de saída, spam, tráfego de negação de serviço e acesso a segredos reais. Os pesquisadores também precisariam de políticas claras de retenção, privacidade e divulgação.

Versões futuras devem distinguir, quando possível, tentativas geradas de listas reutilizadas. A análise de sequências pode ajudar porque scanners frequentemente enviam credenciais em ordens consistentes. A correspondência dessas sequências entre endereços IP pode identificar ferramentas compartilhadas.

Publicar hashes em vez de senhas reversíveis também melhoraria o desenho da pesquisa. Os leitores poderiam comparar valores fracos conhecidos por meio de procedimentos documentados, sem receber uma lista em texto simples de envios de invasores.

A resposta no Hacker News já forneceu uma correção útil: números grandes precisam de rótulos precisos. “Pares de credenciais enviados” descreve corretamente as evidências. “Credenciais coletadas” corre o risco de implicar uma validade que o experimento jamais testou.

Para operadores, a próxima ação não depende de pesquisas futuras. Faça o inventário de cada serviço SSH exposto à internet, verifique se a autenticação por senha está desabilitada e revise se as contas de serviço permitem mais acesso do que o pretendido.

As equipes devem preservar essas decisões junto com notas de incidentes, configurações e evidências de autenticação. Uma base de conhecimento de engenharia pesquisável pode ajudar a manter o contexto operacional conectado entre documentos locais.

Depois, faça uma pergunta direta: se um scanner automatizado tentar root:123456 hoje à noite, seu servidor apenas registrará a tentativa ou se tornará a infraestrutura de outra pessoa?