Uphill Security Hit Hacker News, but Its SSH Credential Data Needs a Careful Read

Uphill Security put 1.53 million SSH login attempts before hacker news readers, exposing both relentless automation and a major interpretive conflict. Its global honeypot network recorded 131,922 distinct username-password pairs during July 2026. Yet those observations do not establish that the passwords came from real accounts.

That distinction separates useful threat telemetry from a database of stolen credentials. The project shows what automated scanners try when they encounter an open SSH service. It does not show which combinations work elsewhere, who assembled them, or whether attackers copied them from previous breaches.

The resulting debate matters because defenders often misread failed authentication logs. Some dismiss the traffic as harmless background noise. Others treat every attempted password as evidence of an active compromise campaign. The reality sits between those positions and requires a closer look at the collection method.

The Honeypot Network Recorded 1.53 Million Login Attempts

The project captured a large sample of automated SSH credential attacks, not a verified collection of working passwords.

Uphill Security published its first findings on August 2, covering the network’s first complete month of operation. The honeypot findings cover July 2026 and fifteen dedicated servers.

Those servers used fifteen public IPv4 addresses across five virtual private server providers. Most were located in Europe, although the infrastructure spanned several global regions. Each address exposed a low-interaction SSH honeypot on TCP port 22.

A low-interaction honeypot imitates enough of a service to attract and record attackers without providing a complete operating environment. In this case, it accepted authentication attempts and logged their submitted usernames and passwords. It did not let intruders operate inside a realistic shell.

The network observed 1,531,053 login attempts from 6,790 unique IP addresses. Those attempts contained 12,238 unique usernames, 97,621 unique passwords, and 131,922 distinct username-password pairs.

The most common pair was root with 123456, attempted 3,861 times. Other leading combinations included root with root, password, 12345678, admin, and several short numeric sequences.

Attackers tried the username root 648,133 times. That represented more than 42 percent of every authentication attempt in the dataset. The next most common usernames were admin, ubuntu, user, and test.

The password 123456 appeared 73,592 times. Other frequent choices included 123, 1234, password, 12345678, and 12345. These values resemble established weak-password dictionaries and predictable device defaults.

The results demonstrate how little reconnaissance some scanners need. A server exposing SSH on its standard port immediately receives attempts against generic administrative identities. An operator does not need to advertise the system or place it on a public directory.

However, the experiment counted authentication attempts only. It excluded network scans and attacks against other protocols. It also did not follow successful intruders because the honeypot was designed to collect login submissions rather than post-authentication behavior.

That boundary is crucial. The dataset describes what scanners offered to fifteen decoy servers. It cannot directly reveal how many production systems accepted the same combinations.

Why the Hacker News Debate Focused on “Harvesting”

The disagreement is not about whether the measurements are real; it concerns what the submitted credentials actually represent.

Several hacker news commenters challenged the article’s use of “harvesting.” Their concern was that automated bots supplied the credentials rather than losing them to the honeypot. The network collected attacker inputs, not secrets extracted from attacker-controlled systems.

One discussion thread argued that most combinations were statistically interesting but operationally worthless. A random scanner trying root:123456 does not prove that any unrelated server uses that pair.

That criticism is well founded. A credential normally joins an asserted identity with an authenticator that grants access to a particular system. Without the corresponding host or service, a username-password pair lacks the context needed to verify it.

Even unusual combinations require caution. A bot might generate them from a dictionary, mutate known defaults, combine leaked words, or reuse lists collected from earlier campaigns. The honeypot cannot distinguish those origins from its authentication records alone.

The word “harvesting” can therefore suggest more than the experiment established. Readers might infer that the dataset contains passwords stolen from active systems. The published method does not support that conclusion.

Still, calling the data worthless goes too far. Repeated submissions reveal the assumptions embedded in automated attack infrastructure. They show which accounts attackers expect to find, which defaults remain attractive, and how aggressively particular sources operate.

The project also highlights service-account targeting. Alongside root and admin, scanners tried postgres, oracle, git, ftpuser, deploy, and deployer. Those names map to common software roles and deployment practices.

Some entries appear shaped by current technology trends. The username claude received 5,993 attempts, while solana received 8,223. Those labels do not prove campaign targeting, but they show how attack dictionaries incorporate recognizable software and product terms.

A useful interpretation treats each submitted pair as an attacker hypothesis. The scanner predicts that a host might expose a named account with a weak or default password. Repetition indicates confidence, convenience, or widespread reuse within scanning tools.

That makes the records valuable for defensive testing. Administrators can compare observed usernames with local accounts, confirm that password authentication is disabled, and search logs for concentrated guessing patterns.

The records remain poor evidence for attributing attacks. An observed IP could belong to a compromised server, a proxy, a rented virtual machine, or infrastructure controlled through another intermediary. Geography identifies network registration or estimated location, not the responsible person.

The debate ultimately improves the project’s value. It forces readers to separate raw telemetry from stronger security claims. That discipline matters whenever a striking dataset reaches a broad technology audience.

The Geography Shows Infrastructure, Not Attacker Identity

The source distribution maps where traffic emerged, but it cannot reliably identify where the operators lived or worked.

The honeypot network recorded connection sources across 129 countries and 1,334 autonomous systems. An autonomous system is a collection of internet routes managed under one network operator.

Asia supplied 4,084 unique source addresses, or 60.1 percent of the total. Europe supplied 1,294, while North America supplied 832. The remaining addresses mapped to South America, Africa, and Oceania.

Traffic volume produced a different picture. European addresses generated 921,439 attempts, or 60.2 percent of all logins. Asian sources generated 453,254 attempts despite representing far more unique addresses.

The contrast reflects concentration. European sources averaged 712.1 attempts per observed address. North American sources averaged 117.1, while Asian sources averaged 111.

At the country level, China produced the most unique addresses, with 1,653. The United States followed with 721, while India produced 458 and Vietnam produced 338.

The Netherlands led by total attempts, producing 686,449 submissions from 276 observed addresses. That was 44.8 percent of the entire dataset. China produced 112,793 attempts, and the United States produced 72,314.

This does not mean Dutch residents conducted nearly half of the activity. Hosting centers, relays, infected servers, and rented infrastructure can concentrate traffic within particular network regions. One automation cluster can also generate far more attempts than thousands of less active sources.

The autonomous-system results reinforce that lesson. Microsoft’s network contained the largest number of unique observed addresses, at 303. However, a different network, TechTies, produced 448,559 attempts from 110 addresses.

Cloud and hosting providers appear throughout the source list. DigitalOcean, Oracle, OVH, Alibaba, Tencent, Google, and several telecommunications networks all registered traffic. Their presence does not imply participation by those companies.

Attackers favor hosted infrastructure because it offers stable bandwidth and rapid provisioning. They also compromise legitimate servers and use those machines as scanning nodes. Both patterns weaken simple country-level attribution.

The data also contains a sampling effect. Sixty percent of the honeypots were in Europe. Server location can affect routing, latency, scanning visibility, and which campaigns encounter an address during a limited observation window.

Fifteen addresses provide meaningful observations but not a representative census of global SSH abuse. Address reputation can also matter. A newly allocated IP might attract different traffic from an address previously associated with another service.

The project’s future expansion should make geographic comparisons more informative. More addresses, balanced regional placement, and repeated monthly measurements would help distinguish durable patterns from short-lived campaign bursts.

Publishing per-sensor results would add another layer. If one honeypot received most Dutch traffic, researchers could investigate whether a scanner targeted a narrow address range. If every sensor saw similar behavior, the campaign likely scanned more broadly.

For defenders, the operational lesson is simpler than the map. Blocking entire countries based on this sample would create false confidence. Rate limits, key-based authentication, account restrictions, and monitoring address the attack method more directly.

What SSH Credential Attacks Become After a Successful Login

Failed guesses are background traffic until one succeeds, after which the same automation can turn a server into attack infrastructure.

The honeypot did not observe post-login commands, so it cannot say what its scanners intended to do next. Independent incident research provides the missing context.

MITRE classifies password guessing as a credential-access technique and identifies SSH on TCP port 22 as a common target. Its password guessing entry also describes repeated failures followed by a possible success as an important detection pattern.

A successful password does more than expose an interactive terminal. The account might provide access to source code, environment files, private keys, cloud tokens, database credentials, or deployment systems.

Privileges determine the immediate damage. A root login gives an attacker broad control. A restricted service account can still expose valuable data or permit lateral movement through weak file permissions and inherited credentials.

Attackers can also modify SSH authorization settings for persistence. MITRE documents the addition of adversary-controlled keys to authorized_keys, including through cloud management interfaces. A planted key lets an intruder return after the original password changes.

Microsoft has documented malware that begins with automated SSH brute forcing. Its Linux threat analysis describes a successful login followed by a malicious script and an IRC-controlled bot.

That botnet supported distributed denial-of-service activity and arbitrary command execution. Other Linux compromises use captured systems for cryptocurrency mining, spam delivery, scanning, or proxy traffic.

A separate Linux attack investigation traced a successful SSH brute-force compromise through staged script downloads. The affected server then became a launch point for wider malicious activity.

These cases explain why repetitive failures deserve attention. A scanner can try thousands of weak combinations at low cost. It needs only one exposed account to repay that effort.

They also show why the Uphill Security dataset should not be treated as a password leak. The important signal is the automated workflow around those guesses. Attackers continually search for systems where common credentials still work.

The root results expose the clearest mismatch between risk and convenience. Production administrators sometimes retain root access for emergency operations. Bots assume that some fraction of those systems will also permit password authentication.

Service accounts create a subtler problem. Teams may create git, deploy, or database users for automation, then overlook interactive login permissions. Old deployment scripts can preserve passwords long after the original workflow changes.

Disabling an interactive shell helps, but administrators must review the complete SSH configuration. Port forwarding, command execution, file transfer, and forced-command behavior can each create different access paths after authentication.

Cloud permissions widen the potential blast radius. A compromised virtual machine might access instance metadata, attached identities, internal services, or deployment secrets. The local account can become an entry point into a larger environment.

This is where SSH honeypot data becomes operationally useful. It tells teams which usernames receive routine attention and how little obscurity protects a public service. It also supplies realistic inputs for validating alerts and rate controls.

The right question is not whether every attempted combination works. It is whether any production account remains able to accept one of them.

The Data Supports Hardening, but Not Universal Conclusions

The experiment strengthens the case for removing password-based exposure while leaving several research questions unanswered.

The clearest defensive response is to require public-key authentication for administrative SSH access. A private key offers far more resistance to online guessing than a human-selected password.

CISA advises administrators to require public-key authentication where feasible, disable password authentication, and limit repeated attempts. Its SSH hardening guidance also recommends separating management services from ordinary internet traffic.

Moving SSH to another port can reduce noisy scans, but it does not replace authentication controls. Broad scanners can discover services on nonstandard ports. A port change mostly reduces unsophisticated traffic and log volume.

Disabling direct root login removes the most heavily targeted identity from password-based access. Administrators should use named accounts, limited privileges, and controlled elevation instead.

Unused service accounts also deserve review. A git or deploy account should expose only the capabilities its workflow requires. Configuration should deny shells, forwarding, subsystems, and commands that the service does not need.

Rate limiting adds another layer. NIST describes throttling as a primary defense against online password guessing. Its password guidance also favors blocklists and machine-generated credentials over arbitrary composition rules.

Logs should connect failures with later success. Ten thousand rejected passwords from an address can be noisy but contained. A successful login after repeated failures demands immediate investigation.

Teams should also monitor what follows authentication. New processes, outbound scans, unexpected bandwidth, altered keys, scheduled tasks, hidden directories, and connections to mining pools can expose compromise.

Network isolation reduces the consequences of a missed alert. Public workloads should not receive unrestricted access to management systems, sensitive databases, or credential stores. Least privilege matters after authentication fails.

However, the Uphill Security project still has important limitations. Fifteen IP addresses observed for one month cannot describe every region, provider, or season. Campaigns start and stop, while scanners adjust their dictionaries.

The honeypot recorded submitted values but did not validate them against external services. Such validation would be ethically dangerous and potentially unlawful. Researchers should not test collected combinations against unrelated systems.

The project also published reversible credential strings. Although the values came from attackers, some may match real passwords by coincidence or reuse. Hashing future releases would support frequency analysis with less unnecessary exposure.

The author already lists password hashing among planned improvements. Cross-referencing against known password lists could also separate common dictionary inputs from unusual values. That process should use lawful, responsibly obtained reference data.

More detailed timing would reveal campaign structure. Researchers could group bursts by source network, credential order, connection behavior, and sensor coverage. Similar sequences might expose shared scanning software without requiring attacker attribution.

A higher-interaction environment could show what happens after authentication, but it carries greater risk. Such a honeypot must contain intruders, restrict outbound abuse, and prevent the decoy from harming other systems.

That creates the project’s central tradeoff. A simple honeypot safely captures broad authentication telemetry but lacks behavioral depth. A realistic system provides richer evidence while increasing containment, legal, and operational demands.

The current results support practical hardening because attackers repeatedly try predictable accounts. They do not support claims about global compromise rates, attacker nationality, or the real-world validity of 131,922 credential pairs.

What to Watch After the Hacker News Attention

The next phase should test whether these patterns persist, whether campaigns cluster across sensors, and what successful bots attempt after authentication.

The first signal is monthly consistency. Another collection period can show whether root, admin, and short numeric passwords remain dominant. Stable rankings would support the conclusion that standard dictionaries drive much of the activity.

Large ranking changes would point toward campaign turnover. A sudden rise in a product-specific username could reflect new targeting, a leaked configuration pattern, or one scanner repeatedly cycling through the network.

The second signal is sensor-level distribution. Per-address and per-region statistics would reveal whether heavy traffic reaches the full network or concentrates on one subnet. That distinction would improve interpretation of the Netherlands spike.

A balanced geographic deployment would strengthen comparisons. The current European concentration makes raw continent totals difficult to generalize. More providers could also reduce the influence of one hosting company’s address history.

The third signal is controlled post-authentication behavior. A carefully isolated environment could accept selected decoy combinations and record the first commands attackers issue. That would connect credential guessing with measurable objectives.

Containment must come first. The environment should block outbound scanning, spam, denial-of-service traffic, and access to real secrets. Researchers would also need clear retention, privacy, and disclosure policies.

Future releases should distinguish generated guesses from reused lists where possible. Sequence analysis can help because scanners often submit credentials in consistent orders. Matching those sequences across IP addresses can identify shared tooling.

Publishing hashes instead of reversible passwords would also improve the research design. Readers could compare known weak values through documented procedures without receiving a plain list of attacker submissions.

The hacker news response has already supplied a useful correction: large numbers need precise labels. “Submitted credential pairs” accurately describes the evidence. “Harvested credentials” risks implying validity that the experiment never tested.

For operators, the next action does not depend on future research. Inventory every internet-facing SSH service, verify that password authentication is disabled, and review whether service accounts permit more access than intended.

Teams should preserve those decisions alongside incident notes, configurations, and authentication evidence. A searchable engineering knowledge base can help keep operational context connected across local documents.

Then ask one direct question: if an automated scanner tries root:123456 tonight, will your server merely log the attempt, or will it become someone else’s infrastructure?