Massive credential stuffing:
coordinated campaign against SSH infrastructure

Context: what the honeypot captured

Between 11 and 13 June 2026, our SSH honeypot recorded an unusually coordinated credential stuffing campaign. Instead of the usual scattered noise —thousands of different IPs trying generic combinations—, we observed a different pattern: 53 unique IPs with homogeneous behavior, dictionaries focused on blockchain infrastructure terminology, and a second phase of GPU hardware reconnaissance in every session that passed authentication.

The dictionary: credentials targeting Solana

The most striking finding is the distribution of credentials. The most frequent usernames are not the usual admin or pi: they are terms specific to the Solana ecosystem.

Position	Username	Attempts	Context
1	root	4.447	Generic
2	sol	3.530	Solana abbreviation / common user on nodes
3	solana	2.995	Direct name of the protocol
4	ubuntu	1.654	Common base operating system
5	solv	1.538	Solv Protocol — Solana staking node
6	trader	633	Typical role in DeFi infrastructure
7	firedancer	287	Solana validator client by Jump Crypto
8	validator	275	Standard Solana node role

The most-tried passwords reflect the same logic: basic numeric combinations mixed with terms from the ecosystem.

Position	Password	Attempts
1	123456	1.711
2	123	1.036
3	12345678	977
4	solana	927
5	sol	844
6	1234	756
7	node	557
8	firedancer	502
9	solv	433
10	ethereum	275

Second phase: GPU reconnaissance

In every session that passed authentication, the attacker ran an identical hardware reconnaissance sequence before any other action. The goal: detect whether the machine has a GPU, which would indicate a staking node or a high-value crypto-mining server.

This sequence ran in 10,701 sessions — practically all of those that passed the authentication phase. The uniformity of the sequence confirms that this is an automated script, not a human operator.

Evasion technique: /bin/./uname

A relevant technical detail: instead of running uname directly, the script uses the variant /bin/./uname. This trivial path traversal (./ in the middle of an absolute path is ignored by the kernel) can evade simple detection rules based on exact string matching, which look for uname but not the variant with the dot.

Campaign structure: 53 coordinated IPs

The distribution of attempts per IP reveals a botnet structure or distributed infrastructure with load sharing:

Attacker IP	Attempts	Unique credentials
45.148.[REDACTED].183	5.173	51
2.57.[REDACTED].177	4.403	37
45.148.[REDACTED].240	3.402	101
83.168.[REDACTED].99	1.524	379
91.92.[REDACTED].61	1.522	761
192.109.[REDACTED].78	1.520	—
92.118.[REDACTED].62	1.407	—
195.178.[REDACTED].30	1.365	—

The three IPs with the highest volume of attempts use small, repetitive dictionaries (51–101 unique credentials), while the IPs with fewer attempts use broader dictionaries. This suggests a division of tasks within the campaign: some nodes test the most common credentials at high speed, others perform a broader sweep.

Payload download attempts

During the observation period, four payload download attempts were recorded. Two distinct URLs appear:

Conclusions

The observed campaign has specific characteristics that set it apart from generic mass scanning:

• Defined target: the credentials point to Solana node operators (validators, traders, firedancer). It is not random noise.
• Professional automation: custom Go client, identical command sequence, load sharing across IPs.
• Probable dual objective: access to validator keys (for stake/NFT theft) and/or use of the GPU for crypto-mining.
• Basic evasion: the /bin/./uname technique shows awareness of detection environments, albeit at an elementary level.

Data collected for cybersecurity research purposes. All information comes from unsolicited activity recorded on our own infrastructure.