Uphill Security è arrivata su Hacker News, ma i suoi dati sulle credenziali SSH richiedono un'attenta lettura

Uphill Security ha presentato a lettori di Hacker News 1,53 milioni di tentativi di accesso SSH, mettendo in luce sia un'automazione incessante sia un importante conflitto interpretativo. La sua rete globale di honeypot ha registrato 131.922 coppie distinte nome utente-password nel corso di luglio 2026. Tuttavia, queste osservazioni non dimostrano che le password provenissero da account reali.

Questa distinzione separa una telemetria delle minacce utile da un database di credenziali rubate. Il progetto mostra cosa provano gli scanner automatizzati quando incontrano un servizio SSH aperto. Non mostra quali combinazioni funzionino altrove, chi le abbia assemblate o se gli aggressori le abbiano copiate da violazioni precedenti.

Il dibattito che ne è seguito conta perché i difensori spesso interpretano erroneamente i log delle autenticazioni fallite. Alcuni liquidano il traffico come rumore di fondo innocuo. Altri trattano ogni password tentata come prova di una campagna di compromissione attiva. La realtà si colloca tra queste posizioni e richiede un esame più attento del metodo di raccolta.

La rete di honeypot ha registrato 1,53 milioni di tentativi di accesso

Il progetto ha acquisito un ampio campione di attacchi automatizzati alle credenziali SSH, non una raccolta verificata di password funzionanti.

Uphill Security ha pubblicato i suoi primi risultati il 2 agosto, coprendo il primo mese completo di operatività della rete. I risultati dell'honeypot riguardano luglio 2026 e quindici server dedicati.

Questi server utilizzavano quindici indirizzi IPv4 pubblici presso cinque provider di server virtuali privati. La maggior parte si trovava in Europa, sebbene l'infrastruttura si estendesse su diverse regioni globali. Ogni indirizzo esponeva un honeypot SSH a bassa interazione sulla porta TCP 22.

Un honeypot a bassa interazione imita quanto basta di un servizio per attirare e registrare gli aggressori senza fornire un ambiente operativo completo. In questo caso, accettava tentativi di autenticazione e registrava i nomi utente e le password inviati. Non consentiva agli intrusi di operare all'interno di una shell realistica.

La rete ha osservato 1.531.053 tentativi di accesso da 6.790 indirizzi IP unici. Tali tentativi contenevano 12.238 nomi utente unici, 97.621 password uniche e 131.922 coppie distinte nome utente-password.

La coppia più comune era root con 123456, tentata 3.861 volte. Altre combinazioni frequenti includevano root con root, password, 12345678, admin e diverse brevi sequenze numeriche.

Gli aggressori hanno provato il nome utente root 648.133 volte. Ciò rappresentava oltre il 42 percento di tutti i tentativi di autenticazione nel dataset. I nomi utente successivi più comuni erano admin, ubuntu, user e test.

La password 123456 è comparsa 73.592 volte. Altre scelte frequenti includevano 123, 1234, password, 12345678 e 12345. Questi valori ricordano dizionari consolidati di password deboli e impostazioni predefinite prevedibili dei dispositivi.

I risultati dimostrano quanto poca ricognizione sia necessaria ad alcuni scanner. Un server che espone SSH sulla sua porta standard riceve immediatamente tentativi contro identità amministrative generiche. Un operatore non deve pubblicizzare il sistema né inserirlo in una directory pubblica.

Tuttavia, l'esperimento ha conteggiato soltanto i tentativi di autenticazione. Ha escluso le scansioni di rete e gli attacchi contro altri protocolli. Inoltre, non ha seguito gli intrusi che avessero avuto successo, poiché l'honeypot era progettato per raccogliere gli invii di credenziali anziché il comportamento successivo all'autenticazione.

Questo confine è cruciale. Il dataset descrive ciò che gli scanner hanno proposto a quindici server esca. Non può rivelare direttamente quanti sistemi di produzione abbiano accettato le stesse combinazioni.

Perché il dibattito su Hacker News si è concentrato su “harvesting”

Il disaccordo non riguarda la realtà delle misurazioni; riguarda ciò che le credenziali inviate rappresentano effettivamente.

Diversi commentatori di Hacker News hanno contestato l'uso di “harvesting” nell'articolo. La loro preoccupazione era che i bot automatizzati fornissero le credenziali anziché perderle a favore dell'honeypot. La rete ha raccolto input degli aggressori, non segreti estratti da sistemi controllati dagli aggressori.

Una discussione sosteneva che la maggior parte delle combinazioni fosse statisticamente interessante ma operativamente priva di valore. Uno scanner casuale che prova root:123456 non dimostra che un qualsiasi server non correlato utilizzi quella coppia.

Questa critica è fondata. Una credenziale normalmente unisce un'identità dichiarata a un autenticatore che concede accesso a un sistema specifico. Senza l'host o il servizio corrispondente, una coppia nome utente-password non dispone del contesto necessario per verificarla.

Anche le combinazioni insolite richiedono cautela. Un bot potrebbe generarle da un dizionario, modificare impostazioni predefinite note, combinare parole sottratte o riutilizzare elenchi raccolti in campagne precedenti. L'honeypot non può distinguere tali origini basandosi soltanto sui propri record di autenticazione.

La parola “harvesting” può quindi suggerire più di quanto l'esperimento abbia effettivamente dimostrato. I lettori potrebbero dedurre che il dataset contenga password rubate da sistemi attivi. Il metodo pubblicato non supporta questa conclusione.

Tuttavia, definire i dati privi di valore si spinge troppo oltre. Gli invii ripetuti rivelano le ipotesi incorporate nell'infrastruttura di attacco automatizzata. Mostrano quali account gli aggressori si aspettano di trovare, quali impostazioni predefinite restano allettanti e quanto aggressivamente operino determinate fonti.

Il progetto evidenzia anche il targeting degli account di servizio. Accanto a root e admin, gli scanner hanno provato postgres, oracle, git, ftpuser, deploy e deployer. Questi nomi corrispondono a ruoli software comuni e pratiche di distribuzione.

Alcune voci sembrano modellate dalle tendenze tecnologiche attuali. Il nome utente claude ha ricevuto 5.993 tentativi, mentre solana ne ha ricevuti 8.223. Queste etichette non dimostrano il targeting di una campagna, ma mostrano come i dizionari di attacco incorporino termini software e di prodotto riconoscibili.

Un'interpretazione utile tratta ogni coppia inviata come un'ipotesi dell'aggressore. Lo scanner prevede che un host possa esporre un account con un determinato nome e una password debole o predefinita. La ripetizione indica fiducia, praticità o riutilizzo diffuso negli strumenti di scansione.

Ciò rende i record preziosi per i test difensivi. Gli amministratori possono confrontare i nomi utente osservati con gli account locali, confermare che l'autenticazione tramite password sia disabilitata e cercare nei log modelli di tentativi concentrati.

I record restano prove deboli per attribuire gli attacchi. Un IP osservato potrebbe appartenere a un server compromesso, a un proxy, a una macchina virtuale noleggiata o a un'infrastruttura controllata tramite un altro intermediario. La geografia identifica la registrazione di rete o una posizione stimata, non la persona responsabile.

Il dibattito, in definitiva, migliora il valore del progetto. Costringe i lettori a separare la telemetria grezza da affermazioni di sicurezza più forti. Questa disciplina conta ogni volta che un dataset di grande impatto raggiunge un vasto pubblico tecnologico.

La geografia mostra l'infrastruttura, non l'identità degli aggressori

La distribuzione delle fonti mappa il luogo da cui è emerso il traffico, ma non può identificare in modo affidabile dove gli operatori vivano o lavorino.

La rete di honeypot ha registrato fonti di connessione in 129 paesi e 1.334 sistemi autonomi. Un sistema autonomo è un insieme di rotte internet gestite da un unico operatore di rete.

L'Asia ha fornito 4.084 indirizzi sorgente unici, ovvero il 60,1 percento del totale. L'Europa ne ha forniti 1.294, mentre il Nord America ne ha forniti 832. Gli indirizzi rimanenti sono stati mappati in Sud America, Africa e Oceania.

Il volume di traffico ha prodotto un quadro diverso. Gli indirizzi europei hanno generato 921.439 tentativi, ovvero il 60,2 percento di tutti gli accessi. Le fonti asiatiche hanno generato 453.254 tentativi pur rappresentando molti più indirizzi unici.

Il contrasto riflette una concentrazione. Le fonti europee hanno registrato una media di 712,1 tentativi per indirizzo osservato. Le fonti nordamericane hanno registrato una media di 117,1, mentre quelle asiatiche una media di 111.

A livello nazionale, la Cina ha prodotto il maggior numero di indirizzi unici, con 1.653. Seguivano gli Stati Uniti con 721, mentre l'India ne ha prodotti 458 e il Vietnam 338.

I Paesi Bassi hanno guidato il totale dei tentativi, producendo 686.449 invii da 276 indirizzi osservati. Ciò rappresentava il 44,8 percento dell'intero dataset. La Cina ha prodotto 112.793 tentativi e gli Stati Uniti 72.314.

Questo non significa che i residenti olandesi abbiano condotto quasi metà dell'attività. Centri di hosting, relay, server infetti e infrastrutture noleggiate possono concentrare il traffico in determinate regioni di rete. Un singolo cluster di automazione può anche generare molti più tentativi di migliaia di fonti meno attive.

I risultati sui sistemi autonomi rafforzano questa lezione. La rete di Microsoft conteneva il maggior numero di indirizzi osservati unici, pari a 303. Tuttavia, una rete diversa, TechTies, ha prodotto 448.559 tentativi da 110 indirizzi.

I provider cloud e di hosting compaiono in tutto l'elenco delle fonti. DigitalOcean, Oracle, OVH, Alibaba, Tencent, Google e diverse reti di telecomunicazioni hanno tutti registrato traffico. La loro presenza non implica partecipazione da parte di queste aziende.

Gli aggressori prediligono l'infrastruttura ospitata perché offre larghezza di banda stabile e provisioning rapido. Compromettono inoltre server legittimi e utilizzano tali macchine come nodi di scansione. Entrambi i modelli indeboliscono le semplici attribuzioni a livello nazionale.

I dati contengono anche un effetto di campionamento. Il sessanta percento degli honeypot si trovava in Europa. La posizione del server può influenzare il routing, la latenza, la visibilità alle scansioni e le campagne che incontrano un indirizzo durante una finestra di osservazione limitata.

Quindici indirizzi forniscono osservazioni significative, ma non un censimento rappresentativo degli abusi SSH globali. Anche la reputazione dell'indirizzo può contare. Un IP appena assegnato potrebbe attirare traffico diverso rispetto a un indirizzo precedentemente associato a un altro servizio.

La futura espansione del progetto dovrebbe rendere più informative le comparazioni geografiche. Più indirizzi, una distribuzione regionale bilanciata e misurazioni mensili ripetute aiuterebbero a distinguere i modelli duraturi dai picchi di campagne di breve durata.

La pubblicazione dei risultati per singolo sensore aggiungerebbe un ulteriore livello di analisi. Se un honeypot ricevesse la maggior parte del traffico olandese, i ricercatori potrebbero verificare se uno scanner abbia preso di mira un intervallo ristretto di indirizzi. Se ogni sensore rilevasse comportamenti simili, la campagna probabilmente avrebbe eseguito scansioni più ampie.

Per i difensori, la lezione operativa è più semplice della mappa. Bloccare interi paesi sulla base di questo campione creerebbe una falsa sensazione di sicurezza. Limiti di frequenza, autenticazione basata su chiavi, restrizioni sugli account e monitoraggio affrontano il metodo di attacco più direttamente.

Cosa diventano gli attacchi alle credenziali SSH dopo un accesso riuscito

I tentativi falliti sono traffico di fondo finché uno non riesce, dopo di che la stessa automazione può trasformare un server in infrastruttura di attacco.

L'honeypot non ha osservato comandi successivi all'accesso, quindi non può dire cosa gli scanner intendessero fare in seguito. La ricerca indipendente sugli incidenti fornisce il contesto mancante.

MITRE classifica l'indovinamento di password come una tecnica di accesso alle credenziali e identifica SSH sulla porta TCP 22 come un bersaglio comune. La sua voce sull'indovinamento di password descrive inoltre fallimenti ripetuti seguiti da un possibile successo come un importante schema di rilevamento.

Una password riuscita fa più che esporre un terminale interattivo. L'account potrebbe fornire accesso a codice sorgente, file di ambiente, chiavi private, token cloud, credenziali di database o sistemi di distribuzione.

I privilegi determinano il danno immediato. Un accesso root offre a un attaccante un controllo esteso. Un account di servizio con restrizioni può comunque esporre dati preziosi o consentire movimenti laterali tramite autorizzazioni dei file deboli e credenziali ereditate.

Gli attaccanti possono anche modificare le impostazioni di autorizzazione SSH per mantenere la persistenza. MITRE documenta l'aggiunta di chiavi controllate dall'avversario a authorized_keys, anche tramite interfacce di gestione cloud. Una chiave inserita consente a un intruso di tornare anche dopo la modifica della password originale.

Microsoft ha documentato malware che inizia con attacchi brute force SSH automatizzati. La sua analisi delle minacce Linux descrive un accesso riuscito seguito da uno script dannoso e da un bot controllato via IRC.

Quella botnet supportava attività di denial-of-service distribuito e l'esecuzione arbitraria di comandi. Altre compromissioni Linux utilizzano i sistemi catturati per il mining di criptovalute, l'invio di spam, la scansione o il traffico proxy.

Una distinta indagine su un attacco Linux ha ricostruito una compromissione riuscita tramite brute force SSH attraverso download di script in più fasi. Il server interessato è poi diventato un punto di lancio per attività dannose più ampie.

Questi casi spiegano perché i fallimenti ripetuti meritano attenzione. Uno scanner può provare migliaia di combinazioni deboli a basso costo. Gli basta un solo account esposto per giustificare quello sforzo.

Mostrano anche perché il dataset di Uphill Security non dovrebbe essere trattato come una fuga di password. Il segnale importante è il flusso di lavoro automatizzato attorno a questi tentativi. Gli attaccanti cercano continuamente sistemi in cui credenziali comuni funzionano ancora.

I risultati relativi a root evidenziano il divario più netto tra rischio e comodità. Gli amministratori di produzione talvolta mantengono l'accesso root per operazioni di emergenza. I bot presuppongono che una parte di questi sistemi consenta anche l'autenticazione tramite password.

Gli account di servizio creano un problema più sottile. I team possono creare utenti git, deploy o di database per l'automazione, poi trascurare i permessi di accesso interattivo. Vecchi script di deployment possono conservare password molto tempo dopo il cambiamento del flusso di lavoro originale.

Disabilitare una shell interattiva aiuta, ma gli amministratori devono rivedere l'intera configurazione SSH. Il port forwarding, l'esecuzione di comandi, il trasferimento di file e il comportamento dei comandi forzati possono ciascuno creare diversi percorsi di accesso dopo l'autenticazione.

Le autorizzazioni cloud ampliano il potenziale raggio d'impatto. Una macchina virtuale compromessa potrebbe accedere ai metadati dell'istanza, alle identità collegate, ai servizi interni o ai segreti di deployment. L'account locale può diventare un punto d'ingresso in un ambiente più ampio.

È qui che i dati degli honeypot SSH diventano operativamente utili. Indicano ai team quali nomi utente ricevono attenzione di routine e quanto poco l'oscurità protegga un servizio pubblico. Forniscono inoltre input realistici per validare avvisi e controlli di limitazione della velocità.

La domanda corretta non è se ogni combinazione tentata funzioni. È se un qualsiasi account di produzione sia ancora in grado di accettarne una.

I dati supportano l'hardening, ma non conclusioni universali

L'esperimento rafforza la tesi per eliminare l'esposizione basata su password, pur lasciando senza risposta diverse questioni di ricerca.

La risposta difensiva più chiara è richiedere l'autenticazione a chiave pubblica per l'accesso SSH amministrativo. Una chiave privata offre una resistenza ai tentativi online molto maggiore di una password scelta da una persona.

CISA consiglia agli amministratori di richiedere l'autenticazione a chiave pubblica dove possibile, disabilitare l'autenticazione tramite password e limitare i tentativi ripetuti. Le sue linee guida per l'hardening SSH raccomandano inoltre di separare i servizi di gestione dal normale traffico Internet.

Spostare SSH su un'altra porta può ridurre le scansioni rumorose, ma non sostituisce i controlli di autenticazione. Scanner estesi possono individuare servizi su porte non standard. Una modifica della porta riduce soprattutto il traffico meno sofisticato e il volume dei log.

Disabilitare l'accesso root diretto rimuove dall'accesso basato su password l'identità più bersagliata. Gli amministratori dovrebbero invece utilizzare account nominativi, privilegi limitati ed elevazione controllata.

Anche gli account di servizio inutilizzati meritano una revisione. Un account git o deploy dovrebbe esporre soltanto le capacità richieste dal suo flusso di lavoro. La configurazione dovrebbe negare shell, forwarding, sottosistemi e comandi non necessari al servizio.

La limitazione della velocità aggiunge un ulteriore livello. NIST descrive il throttling come una difesa primaria contro i tentativi online di indovinare password. Le sue linee guida sulle password favoriscono inoltre blocklist e credenziali generate da macchine rispetto a regole arbitrarie di composizione.

I log dovrebbero collegare i fallimenti ai successi successivi. Diecimila password rifiutate da un indirizzo possono essere rumorose ma contenute. Un accesso riuscito dopo fallimenti ripetuti richiede un'indagine immediata.

I team dovrebbero inoltre monitorare ciò che segue l'autenticazione. Nuovi processi, scansioni in uscita, larghezza di banda inattesa, chiavi modificate, attività pianificate, directory nascoste e connessioni a pool di mining possono rivelare una compromissione.

L'isolamento di rete riduce le conseguenze di un avviso mancato. I carichi di lavoro pubblici non dovrebbero ricevere accesso senza restrizioni ai sistemi di gestione, ai database sensibili o agli archivi di credenziali. Il principio del privilegio minimo resta importante dopo il fallimento dell'autenticazione.

Tuttavia, il progetto Uphill Security presenta ancora limitazioni importanti. Quindici indirizzi IP osservati per un mese non possono descrivere ogni regione, provider o stagione. Le campagne iniziano e terminano, mentre gli scanner adattano i propri dizionari.

L'honeypot ha registrato i valori inviati ma non li ha convalidati rispetto a servizi esterni. Una simile convalida sarebbe eticamente pericolosa e potenzialmente illegale. I ricercatori non dovrebbero testare combinazioni raccolte su sistemi non correlati.

Il progetto ha inoltre pubblicato stringhe di credenziali reversibili. Sebbene i valori provenissero da attaccanti, alcuni potrebbero corrispondere a password reali per coincidenza o riutilizzo. L'hashing delle future pubblicazioni consentirebbe l'analisi della frequenza con una minore esposizione non necessaria.

L'autore include già l'hashing delle password tra i miglioramenti previsti. Il confronto con elenchi di password noti potrebbe inoltre separare gli input comuni da dizionario dai valori insoliti. Questo processo dovrebbe utilizzare dati di riferimento legittimamente ottenuti e gestiti in modo responsabile.

Tempistiche più dettagliate rivelerebbero la struttura delle campagne. I ricercatori potrebbero raggruppare i picchi per rete di origine, ordine delle credenziali, comportamento delle connessioni e copertura dei sensori. Sequenze simili potrebbero rivelare software di scansione condiviso senza richiedere l'attribuzione dell'attaccante.

Un ambiente a maggiore interazione potrebbe mostrare cosa accade dopo l'autenticazione, ma comporta rischi maggiori. Un simile honeypot deve contenere gli intrusi, limitare gli abusi in uscita e impedire che l'esca danneggi altri sistemi.

Questo crea il compromesso centrale del progetto. Un honeypot semplice acquisisce in sicurezza un'ampia telemetria di autenticazione, ma non ha profondità comportamentale. Un sistema realistico fornisce prove più ricche, aumentando al contempo le esigenze di contenimento, legali e operative.

I risultati attuali supportano l'hardening pratico perché gli attaccanti tentano ripetutamente account prevedibili. Non supportano affermazioni sui tassi globali di compromissione, sulla nazionalità degli attaccanti o sulla validità nel mondo reale di 131.922 coppie di credenziali.

Cosa osservare dopo l'attenzione di Hacker News

La fase successiva dovrebbe verificare se questi schemi persistono, se le campagne si raggruppano tra i sensori e cosa tentano i bot riusciti dopo l'autenticazione.

Il primo segnale è la coerenza mensile. Un ulteriore periodo di raccolta può mostrare se root, admin e le password numeriche brevi rimangono predominanti. Classifiche stabili sosterrebbero la conclusione che dizionari standard guidano gran parte dell'attività.

Grandi cambiamenti nelle classifiche indicherebbero un ricambio delle campagne. Un improvviso aumento di un nome utente specifico di un prodotto potrebbe riflettere un nuovo targeting, un modello di configurazione divulgato o uno scanner che cicla ripetutamente attraverso la rete.

Il secondo segnale è la distribuzione a livello di sensore. Statistiche per indirizzo e per regione rivelerebbero se il traffico intenso raggiunge l'intera rete o si concentra su una subnet. Questa distinzione migliorerebbe l'interpretazione del picco nei Paesi Bassi.

Un deployment geografico bilanciato rafforzerebbe i confronti. L'attuale concentrazione europea rende difficile generalizzare i totali grezzi per continente. Più provider potrebbero inoltre ridurre l'influenza della cronologia degli indirizzi di una singola società di hosting.

Il terzo segnale è il comportamento post-autenticazione controllato. Un ambiente attentamente isolato potrebbe accettare combinazioni esca selezionate e registrare i primi comandi impartiti dagli attaccanti. Ciò collegherebbe i tentativi sulle credenziali a obiettivi misurabili.

Il contenimento deve venire prima di tutto. L'ambiente dovrebbe bloccare scansioni in uscita, spam, traffico di denial-of-service e accesso a segreti reali. I ricercatori avrebbero inoltre bisogno di chiare politiche di conservazione, privacy e divulgazione.

Le future pubblicazioni dovrebbero distinguere, ove possibile, i tentativi generati dagli elenchi riutilizzati. L'analisi delle sequenze può aiutare perché gli scanner spesso inviano le credenziali in ordini coerenti. Confrontare queste sequenze tra indirizzi IP può identificare strumenti condivisi.

Pubblicare hash invece di password reversibili migliorerebbe inoltre il disegno della ricerca. I lettori potrebbero confrontare valori deboli noti tramite procedure documentate senza ricevere un elenco in chiaro degli invii degli attaccanti.

La risposta di Hacker News ha già fornito una correzione utile: i numeri grandi richiedono etichette precise. “Coppie di credenziali inviate” descrive accuratamente le prove. “Credenziali raccolte” rischia di implicare una validità che l'esperimento non ha mai verificato.

Per gli operatori, la prossima azione non dipende dalla ricerca futura. Fate l'inventario di ogni servizio SSH esposto a Internet, verificate che l'autenticazione tramite password sia disabilitata e riesaminate se gli account di servizio consentono più accesso del previsto.

I team dovrebbero conservare queste decisioni insieme a note sugli incidenti, configurazioni e prove di autenticazione. Una base di conoscenza ingegneristica ricercabile può aiutare a mantenere connesso il contesto operativo tra i documenti locali.

Poi ponete una domanda diretta: se uno scanner automatizzato tenta root:123456 stanotte, il vostro server si limiterà a registrare il tentativo oppure diventerà l'infrastruttura di qualcun altro?